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.