Cloud Computing Software Maintenance

Hello all,

We are currently using S3M to assess a BIGDATA software maintenance based on Cloudera and another on HBASE both in the health industry. Genomics has forced some research institutes to use these technologies and now we are looking at software maintenance issue.

Technologies may evolve but the software maintenance fundamentals stay the same.

Honda Recall - transmission software

Just a note on a recall I just got in the mail today.

Honda is recalling my Honda CRV to update the automatic transmission software to prevent transmission damage.

Soon there will be as much software maintenance to cars then mechanic maintenance

S3M now in Korea

On September 22nd, 2011 I was invited to give a talk to the CIO conference in SEOUL, South Korea. You can see the slides of this presentation.

Recently Bankware Global has obtained the gold partner status and has obtained from ÉTS University in Montréal Canada the exclusive rights to offer consulting services to help Korean companies use the software maintenance maturity model (S3M). Bankware Global intends to offer services to the banking industry and join with IBM Korea to service the other market segments.

A first mandate will be conducted with Woori FIS one of the IT support organization of a large Korean Bank. I plan to support Bankware Global in their lead assessor training while they will apply the S3M principles to assess the maturity of Woori Bank FIS.

I will visit Korea again in November and January to help with the knowledge transfer for the introduction of our book concepts: Software Maintenance Management: Evaluation and Continuous Improvement in Korea.

Deux nouveaux livres en AQL - chez Hermès

Je viens tout juste d'envoyer le texte de deux nouveaux livres concernant l'assurance qualité du logiciel à l'éditeur Hermès. Ce nouveau livre développé avec le Dr. Claude Laporte résume un ensemble de techniques d'améliorations que nous avons utilisé couramment.

Je travailles actuellement sur le livre des techniques avancées d'AQL pour les entreprises qui possèdent un niveau de maturité 4 et 5 !

This week I will work at improving the SLA of a large Canadian Bank. SLA's in this Bank are dispersed in every business unit. Reworking the SLA's require that we:

- First review the maintenance work categories

- Then look at the time tracking mechanisms

- Ensure a ticketing process

- Make an inventory of each software application

This will tajke a while!

Alain

Summary of my talk at the QUATIC2010 Conference in Porto last month

Quality of Evolution session

Alain April, from the École de Technologie Supérieure in Canada, presented the first paper, titled ‘Studying Supply and Demand of Software Maintenance and Evolution Services’. He started by noting that often CIOs don’t have adequate data on productivity and ROI for maintenance activities. While new projects are usually properly planned and budgeted for, maintenance management is often based requests that are estimated to take less than a certain number of person-days to implement, with indicators such as the length of the waiting list or the number of requests handled being the maintenance management tools. Alain argued that instead of using absolute values, internal and external benchmarking should be used to compare maintenance effort of a project with respect to other projects within and outside the organisation, e.g. using the ISBSG data set. Moreover, Alain argued that organizations should adopt the ISO14764 standard categories of maintenance work (adaptive, preventive, corrective, perfective). This would not only allow the IT departments to charge its customers accordingly, but also to track the trend of each type of maintenance work, making clear to management that increased preventive maintenance is needed to decrease corrective maintenance. In other words, this paper looked at simple but effective ways to monitor and communicate the quality of the evolution of maintenance effort.

Software Maintenance Process Workshop in Boston

Hello,

I just came back from the WCRE conference where Mira Kajko-Mattsson and I presented some maintenance processes to the audience. I will post the link to the presentations soon !

Sabbatical-Sabbatique

Hello All,

I know that I have not posted since the beginning of my sabbatical but I should re-start putting content soon ! I am back in Montreal and ready for the summer

Bonjour à tous,

Je suis de retour de sabbatique et vais recommencer à mettre du contenu bientôt. De retour à Montréal et prêt pour l'été !

The S3M prices dropped

Hello all,

As per the latest workgroup meeting we have decided that the prices of the Software Maintenance Maturity Model will be reduced on yearly memberships as of March 1st 2009.

The executive board has decided that active members can now access Silver, Gold and Partner content based on their participation. New members will be granted Bronze membership and can access higher rights when participating actively.

I hope this will help in promoing the framework use in the future.

Dr. April & Abran

Montréal, Canada

Maintaining in the new year

Hi,

We are starting up the year with graduate students research setup.

Its a good size class with 90% students working in the industry.

Will keep you posted of our projects and discussions.

Salvage is the final decision

Using Dr Koskinen approach to decision making can help support this business case.

1) Continue to use/maintain the current software by modernizing it (baby steps first)
2) Replacement a) try to find a solution ou there
b) complete rewrite of the system

Rewrite is estimated à 160,000 hours of effort. After discussions the decision is to salvage the existing system. Strategy will be to migrate to newer technology and refactor worst parts. Scalability is also an issue. I propose to go with 'cloud computing' backend. Looking at the system there are currently enough information to pass from C+ to C#. A small pilot done this week shows that the effort will be around 6,500 hours to convert. Only 8% of the system requires refactoring. This will take 3,000 hours to do and includes the migration of the obsolete Borland database to a more recent (and scalable) technology can easily be achieved.

Parallel run is mandatory so existing Dabatase + stubs will be used in parallel with new database. I'm out of there and preparing the new software maintenance course at the University starting in September.

The un-maintainable system

I am in california all week long. We are looking at an un-maintainable system in the stock exchange business domain here. The story goes like this. The system has been developed in the nineties and has been changed daily over time. Its now in a position that they cannot easily touch it without creating side effects. With staff turnaround the key developers and maintainers have moved on and this is starting to create a lot of problems for management. They would like to know if this system can be salvaged or move on. I'm in the system salvaging business ! I'll try my best first.

What to do ? I guess you've all been there so here is the way out.First we've run gather the team and asked what they think can be done, over a period of three months, to unlock this issue. I'm not here for long so I cannot afford to create a dependency on my knowledge/tools, here's what came out:

- Get a task force going to find who knows the environment/systems and dependencies
- Identify the low bearing fruits (what can be fixed first: by humans and by toolset)
- Decide on key areas re-structure/re-engineering
- Make a maintenance plan for this system

I decided to attack the automated assessment of the 'beast' and give them a picture of where complexity and dependency is located. So today i've looked at all the change tickets of this year to map where change has been mostly happening this year. I also made a test run of the source code in our toolset to calibrate the measures. Tomorrow i'll tell you more about it.

Maintenance and Agile: SCRUM, Xtreme, DSDM

Maintenance is agile. No need to say more ! Maintenance personnel probably invented Agile and never used the term! 

Scrum, Xtreme and DSDM practices can be applied without much modification:

1. Daily meetings
2. Quick iterations
3. Impact assesssment, customer contact to validate change/defect
4. TRAC (or similar toolset) displaying In progress, completed, reopened, closed tickets and other information
5. Usage of Wiki for collaborating with others
6. Requirement workshop for complex changes/defects
7. Review and Retrospective

Maintenance has a small iteration length. For projects, plan a  "maintenance slots" in an iteration/span>

Maintenance

Here is an added list of secrets:

• New Secret #1 - Stop the bleeding first. Implement a Standard Operating Environment standard that restricts the introduction of too many new technologies and identifies the one that are going out. This will promote the use of some and discourage some other. 
• New Secret #2 - If old harware makes it to the museum should'nt it be time to stop running old software in production and move it to the museum?
• New Secret #3 - Stop pushing garbage into production. Its time to put a formal transition process in place. If its not finished its not ready to be maintained.
• New Secret #4 - Hire people in maintenance first. Anyone who has not maintained a software cannot understand how to develop one. Its a simple affair and you have to walk in those shoes first or else you cannot understand how to develop maintainable code.
• New Secret #5 - All development projects must deliver a test system on a test platform. Enough of delivering only code and documentation. Give us your test system and all the test cases and tools. If you did not build this how the hell did you test that software?
• New Secret #6 - The software project must give us the defect list and the SLA terms before the transition can be completed. If they developed a software without any SLA terms it means that there are no formal quality characteristics in that software. We need to know that before we take over the responsibility for this software.
• Secret #7 - Cleanup the process so that it helps out instead of slowing down everyone. Maintenance is already 'agile'. As a friend said recently 'with everyone using agile now it all looks like maintenance to me!'. Consider having separate maintenance groups as it raises awareness of quality issues at delivery time and beforehand.
• Secret #8 - Get on with measuring the productivity and use www.isbsg.org database to compare. This is a wise decision before your boss decides to ask you for the numbers because he thinks of Offshoring.

Secrets of Software Maintenance

I remember this post by David EddyPublished: July 1, 2000 in TDAN.com July 2000. In my next post I will try to update this list with some new hints  !

• Secret #1 - There are no secrets. If you can accept this reality, you are well on your way to understanding the true "secrets."
• Secret #2 - Maintenance is an inherently bottom-up process, primarily because maintenance is a game of details, and managers are not hired to "do" details.
• Secret #3 - Good maintenance, like good development, is just the consistent application of sound life-cycle practices (requirement analysis, configuration control, independent verification and validation, et al.) that have been well known and understood, if spottily applied, for decades.
• Secret #4 - Development and maintenance are merely two sides of the same coin. To believe that one is better or worse than the other entirely misses the point. They are a continuum very much like the mathematical oddities of a Möbius strip or a Klein bottle.
• Secret #5 - The administrative infrastructure that supports the development/maintenance effort must become self-sustaining. Otherwise, the effort will be seen as busywork (read "costly, paper-pushing bureaucratic waste of time"); and it will die as soon as the original sponsors shift their focus or, worse, mutate to take on an expensive life of its own that is unrelated to productive work.
• Secret #6 - The job of management is to put into place the practices which enable the work of fixing, extending, and enhancing systems that support the business. 
• Secret #7 - Organizations that are more intent on affixing blame for software problems than on ensuring that the conditions which caused the problem are removed/resolved will always regard maintenance as a headache to be endured until the mythical silver bullet is found.
• Secret #8 - There are no spectacular winning-touchdown-in-the-last-3-seconds events in this game and certainly no silver bullets. Success is simply the steady, incremental application of the basics one small tactical step at a time.

Hints and tips on solutions to maintenance problems

Here are common solutions that I apply:

Staff issues

1)The personnel does not understand the system - Training or send the staff to the user site to learn by looking at the others using it;

2) Management is too focused on development - Communicate better the importance of maintenance. Report regularly on maintenance activities. Use Dr. Abran's reporting approach where trending and internal benchmarking are the key representations. Also you can benchmark against ISBSG 'maintenance dabatase' to show you are doing well !

3) Maintenance personnel is down - Retention bonuses, mix the teams, rotate staff send some to operations/development for a while, update their toys (equipment, phones, ..), give $ or a restaurant/cinema voucher when a challenging change in prod is defect free, implicate them in R&D, SLA's, Contract, DRP or Transition (only if it is perceived as fun :). 

Time problems

4) System changes constantly - Group requests in packs and do a certain number of versions per year.

5) Changes are piling up - Ask the CCB to prioritize them...what you have no CCB well establish one... what you do not know what a CCB is...a Change Control Board where user representatives are forced to 'inner fighting' to set your priorities...I like to see then go at it !

6) Night changes blast the online production - Do a small reengineering project to free up some batch schedule time. Squeeze that request in your work schedule.

Technical problem

7) Production system is hard to maintain - Start on the 'rejuvenation journey'. Each small change must trigger a small internal improvement. This works for systems that we often change and that are there to stay. Else look at Dr. Koskinen arguments to convince management that its time to invest a bit if you want to reduce maintenance costs.

8) Production system is hard to test - Well two elements to this one: long term would be to force development (or suppliers) to give you a testing system with the new systems they transition to you. For the existing, install a test system..if its not already there..and each time you touch it you spend a bit of time developing the test tools surrounding it.

The need to compromise 

9) Maintenance is done only in panic mode and compromises the production - Slow down...or manage up...you'r gona bust...or production will bust you... Allow more time to QA and look closely at what the night fix have done.

10) Maintenance personnel does not have enough tjink time to fix problems - Assign seniors to juniors to coach them before they proceed too far.

Maintenance costs problems

11) Costs are going up - Establish different costs by maintenance categories. Customers love enhancements and hate defects. Raise costs in enhancements and lower costs in other maintenance categories. Outsource/Offshore parts of the 'low interest' work to show you care. You better think about it yourself before someone thinks about it for you. Its time to make a business case to convert the system to a more recent language or platform.

Evolution all the time - an opportunity to improve it

Code evolves constantly during the initial development. When you look at the TRAC project (trac.edgewall.org)  you can see all the tickets raised during the development stage of a project. Soon I will be posting a software maintenance version of TRAC that we are developing currently. I will place it in the S3M WIKI so you can take it and try it. We also have developed a script to install TRAC easily. I will place it there too ! Lets get back to our topic. 

When you open up the code to make a change you have an opportunity to make a small improvement. I like this approach instead of creating a reengineering project. What to look for:

- A loop that is too long or too deep.

- A class that has no cohesion

- An interface that does not give a coherent abstraction level

- Too many parameters

- Classes that do not do anything meaningful

Steve McConnell's book 'Code complete' tells you some more 

Deciding where maintenance goes

We always have a debate on where software maintenance should be done. Is it better in a separate group or the developer maintains the software he builds for the rest of his life! Our second survey results look quite the same as the first one:

Cust. Sat: How do end-users feel when served by this group. Costs seem higher or lower with this model? Is it longer to be served by this group? How about the quality of the software over time.

Arguments Against                                 Arguments for

Separate Maintenance                            Separate Maintenance

Cust. Sat: Users like the initial developers      Initially less happy 

Costs:   Seem to cost less                            Seem to cost more

Delays:     Slow and impacts other projects      Perceived as Quicker

Quality:   Mostly in the developers head              Tend to be higher here

Size:          Good model for small shops            Better fit in big organizations

Opening up the blog this morning

Welcome to the software maintenance blog. 

We just got the website going today and I am feeling my way around to see all the features. 

Friday I had to buy a copy of my last book 'Software Maintenance Management'. The editor did not tell me it was out and did not sent a copy beforehand. Times are tough !

This week I will start up the Wiki and the Blog with the first Articles and will continue to fill up the site with content. Feel free to send me comments for improvements.

I also have a meeting to help a friend who has an ERP firm to plan the reengineering of his product out of Borland C++ to C#. I will meet up with a Ph.d. student we met at CSMR to see what can be planned for the summer.