Software Configuration Management into a CMMI Level 1 Project

1,727
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,727
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
116
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Software Configuration Management into a CMMI Level 1 Project

    1. 1. Introducing Software Configuration Management into a CMMI Level 1 Project Presented at the KWSQA March 2006 by Pat Cross, London St. Consulting
    2. 2. What I want you to go away with <ul><ul><li>Remembering how important Software Configuration Management (SCM) is. </li></ul></ul><ul><ul><li>Remembering how hard it is for new people to understand SCM - or care about it. </li></ul></ul><ul><ul><li>Having some guidelines to implementing SCM in projects that have started with no clear processes. </li></ul></ul>
    3. 3. What I want to cover today <ul><ul><li>How do you recognize a CMMI Level 1 project, and how does it feel? </li></ul></ul><ul><ul><li>Quick tour of SCM </li></ul></ul><ul><ul><li>Some guidelines to beginning the implementation of SCM </li></ul></ul><ul><ul><li>Questions, stories and ideas from the floor </li></ul></ul>
    4. 4. <ul><li>CMM has been broadened to Capability Maturity Model Integrated (CMMI) to cover systems of all sorts. </li></ul>The CMM and CMMI Models Repeatable 2 Managed 4 Optimizing 5 Initial 1 Defined 3 Predictable process Continuously improving process Standard, consistent process Disciplined process Heroics
    5. 5. CMM Level 1 <ul><ul><li>The Capability Maturity Matrix Integrated (CMMI) has 5 levels of process maturity </li></ul></ul><ul><ul><li>Level 1 has no uniform processes – just heroics </li></ul></ul><ul><ul><li>60% of companies are at Level 1 </li></ul></ul><ul><ul><li>Even some companies that are better than Level 1, have projects within them that are working at Level 1 </li></ul></ul>
    6. 6. How does Level 1 development feel? <ul><ul><li>At the beginning of a project - exciting, free. Perhaps some schedule pressure. </li></ul></ul><ul><ul><li>In the middle - uncomfortable, sense of injustice, some fear. </li></ul></ul><ul><ul><li>At the end of development - panic, forced heroism, anger. </li></ul></ul>
    7. 7. How does Level 1 maintenance feel? <ul><ul><li>Baffling - lack of documentation means hard to trouble shoot, hard to fix. </li></ul></ul><ul><ul><li>Confusing - hard to keep track of </li></ul></ul><ul><ul><ul><li>changes planned to go in </li></ul></ul></ul><ul><ul><ul><li>changes tried but unsuccessful </li></ul></ul></ul><ul><ul><ul><li>changes actually made to system </li></ul></ul></ul><ul><ul><li>Increasing disengagement </li></ul></ul>
    8. 8. What is Software CM? <ul><li>SCM is the art of managing the information about the product itself, including the source and executable code. </li></ul><ul><li>SCM keeps you up to date on what you have, and protects your information and code from loss and unauthorized changes. </li></ul><ul><li>SCM keeps you sane. </li></ul>
    9. 9. Quick Tour of SCM <ul><ul><li>Classic CM has four parts: </li></ul></ul><ul><ul><ul><li>configuration identification (what shall we manage?) </li></ul></ul></ul><ul><ul><ul><li>configuration change control (who authorizes what and how?) </li></ul></ul></ul><ul><ul><ul><li>configuration status accounting (snapshots) </li></ul></ul></ul><ul><ul><ul><li>configuration audits (inventory checking) </li></ul></ul></ul><ul><ul><li>Software also needs extra specific tools and documents </li></ul></ul>
    10. 10. Configuration Identification <ul><li>Early in the project, decide what pieces of software you want to treat as ‘an item’. Each item needs its own requirements, design and test documents. </li></ul><ul><ul><li>If the code piece is too big, the effect of a change on other parts of the software is hard to determine. </li></ul></ul><ul><ul><li>If the pieces are too small, the administrative costs go up. </li></ul></ul><ul><li>Requirement and design documents are also Configuration Items (CIs) </li></ul>
    11. 11. Configuration Change Control <ul><li>Changes are the most dangerous events in a software’s life. </li></ul><ul><li>Deep technical insights are needed to judge all the effects of a change. </li></ul><ul><li>It’s helpful to have a group of guru’s to make these decisions - the Configuration Control Board (CCB). </li></ul><ul><li>The CCB also authorizes extra work. </li></ul>
    12. 12. Configuration Status Accounting <ul><li>During development many people need to be clear about what version of requirements are current, what is the present version of design and the development versions of code. </li></ul><ul><li>Sometimes you need to know all this information about some point in time in the past - or about a set of slightly different clients </li></ul><ul><li>The system of retrieving this related information needs to be simple. </li></ul>
    13. 13. Configuration Audits <ul><li>From time to time, someone needs to check that all the information related to every Configuration Item exists and is where it ought to be. </li></ul><ul><li>If anything is missing, it should be re-constituated, maintenance will need it later. </li></ul>
    14. 14. Software Additions for SCM <ul><li>Software CM also includes: </li></ul><ul><ul><li>a repository for code </li></ul></ul><ul><ul><li>Version Description Documents for each version, describing the details of the components and the extent of testing. This is useful for developers. </li></ul></ul><ul><ul><li>Release Notes for each version explaining new features and known problems. This is for users. </li></ul></ul><ul><ul><li>a database showing the relationship between all versions. This is particularly needed when there is a lot of branching. </li></ul></ul>
    15. 15. Repositories and Databases <ul><li>It is virtually impossible to manage code versions without a tool </li></ul><ul><ul><li>while you can make one in-house, you are better off buying a commercial one </li></ul></ul><ul><li>Features should include: </li></ul><ul><ul><li>identification of every change and who signs it in </li></ul></ul><ul><ul><li>ability to recreate any version </li></ul></ul><ul><ul><li>relationship between versions of requirements and design documents and versions of code </li></ul></ul>
    16. 16. Some CM Terms <ul><ul><li>Configuration Item (CI) - a convenient product subsystem </li></ul></ul><ul><ul><li>Change forms eg CR, ECN, IR </li></ul></ul><ul><ul><li>Impact Statements </li></ul></ul><ul><ul><li>Configuration Control Board (CCB) - a group which judges technical and managerial aspects of changes and approves or disapproves </li></ul></ul><ul><ul><li>Baseline - a reference freeze point for a CI </li></ul></ul>
    17. 17. SQA and SCM <ul><li>In some companies SQA is also responsible for SCM. </li></ul><ul><li>In all circumstances, SQA is responsible for assuring that SCM has the proper procedures, human resources and tools. </li></ul><ul><li>Many people think a tool is all you need. </li></ul><ul><li>SQA may need to take missionary action to introduce procedures and get human resources assigned. </li></ul>
    18. 18. SCM in a Level 1 Company <ul><li>Level 1 companies do not have stable procedures for any actions. </li></ul><ul><li>For SCM specifically, they tend to think procedures are time-wasting bureaucracy. </li></ul><ul><li>SCM procedures and resources are required for Level 1 registration. </li></ul>
    19. 19. Behaviour Changes (1) <ul><li>Any change in human behaviour requires an ‘emotional event’. </li></ul><ul><li>Even if people agree with you theoretically, they will not change what they do unless the change is tied to an emotion. </li></ul><ul><li>For SCM, even the remembered emotions around “nasty surprises” can be enough to nudge them into change. </li></ul>
    20. 20. Behaviour Changes (2) <ul><li>Once they are willing to change, they need to learn and practice the change, until it becomes normal </li></ul><ul><ul><li>it is easy to backslide when the project pressure mounts. </li></ul></ul><ul><li>Once it becomes ‘just how we do things here’, you can relax. </li></ul><ul><li>For SCM this can take about a year. </li></ul>
    21. 21. Guidelines - In the Beginning <ul><ul><li>You have to have an ALLY (preferably the Project Leader) </li></ul></ul><ul><ul><li>Even if you are the Project Leader, you still have to have an ally </li></ul></ul><ul><ul><li>If you don’t have an ally, spend your time selling to find one. Use present problems and future projections, stress outcomes. </li></ul></ul><ul><ul><li>When you find an ally, teach them as much CM as possible. </li></ul></ul>
    22. 22. Guidelines - Start with a Vulnerability <ul><ul><li>Find the situation which is giving most grief now, propose a simple fix </li></ul></ul><ul><ul><li>Discuss it in detail with your ally and a little bit with the others. Get the Project Leader on board in any case. </li></ul></ul><ul><ul><li>Alter the fix to meet their needs and write a one page description using project vocabulary. </li></ul></ul>
    23. 23. Example of a Fix (1) <ul><ul><li>Vulnerability : </li></ul></ul><ul><ul><li>The project is suffering because different people are changing the product and no-one knows what is today’s product. </li></ul></ul><ul><ul><li>Fix: </li></ul></ul><ul><ul><li>Appoint one person to be the the point of contact for all changes. Everyone has to bring their changes to her. </li></ul></ul>
    24. 24. Example of a Fix (2) <ul><ul><li>Vulnerability : </li></ul></ul><ul><ul><li>One group makes changes and other groups’ work is affected badly. Anger is in the air. </li></ul></ul><ul><ul><li>Fix: </li></ul></ul><ul><ul><li>Set up a ‘vetting’ committee of all the groups to review changes by email. Default is ‘accept’ after one day. (This is a proto-CCB.) </li></ul></ul>
    25. 25. Example of a Fix (3) <ul><ul><li>Vulnerability : </li></ul></ul><ul><ul><li>Maintenance is required at night-time, when normal authorization is not available. </li></ul></ul><ul><ul><li>Fix: </li></ul></ul><ul><ul><li>Set up 3 lists of actions </li></ul></ul><ul><ul><ul><li>No authorization required (eg refresh certain data) </li></ul></ul></ul><ul><ul><ul><li>Retroactive authorization required (alter certain scripts) </li></ul></ul></ul><ul><ul><ul><li>Forbidden without prior authorization (core code) </li></ul></ul></ul>
    26. 26. Guidelines - Implement the process <ul><ul><li>Project Leader should explain the new process and its benefits and move decisively to use them. </li></ul></ul><ul><ul><li>Let it settle a few weeks before SQA checks how it is working out, Project Leader should back SQA publicly. </li></ul></ul><ul><ul><li>Take the feedback to SQA seriously, make sure actions are taken and followed up. </li></ul></ul>
    27. 27. Guidelines - The Uses of a Roadmap <ul><ul><li>Deciding on how to implement CM completely is a necessary job for you and your ally </li></ul></ul><ul><ul><li>Showing the group the vision and the map increases speed of implementation. </li></ul></ul><ul><ul><li>Showing the vision and map to other interacting groups helps them to adapt to your changes. </li></ul></ul>
    28. 28. Questions and Discussion
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×