1. Computer Engineering 203 R Smith Process/Plan Model 7/2009 1 Development Process Models Development Process Models are different ways to look at the processes used on a specific project. Project characteristics influence the process model that is used. – Size: people, time, function – Complexity – Risk – Requirements

2. Computer Engineering 203 R Smith Process/Plan Model 7/2009 2 Other Factors How knowledge is kept and stored Impact of change – Change after implementation is always expensive and considered waste Stability of workforce Complexity of the customer

3. Computer Engineering 203 R Smith Process/Plan Model 7/2009 3 Development Process Models There are many different models for developing software. – SEI/CMM – IEEE – PSP/TSP – Agile Methods Extreme Programming

4. Computer Engineering 203 R Smith Process/Plan Model 7/2009 4 Disciplined Process Every process describes itself as disciplined. What does it mean to be disciplined?

5. Computer Engineering 203 R Smith Process/Plan Model 7/2009 5 Planned Process models can also be called planned development models. Because a process model is called planned does not mean that it is rigid. Because a process model is called Agile does not mean it is undisciplined.

6. Computer Engineering 203 R Smith Process/Plan Model 7/2009 6 Plan v Agile Having a plan does not mean that the plan can not change Being Agile does not mean that you do not have a plan

7. Computer Engineering 203 R Smith Process/Plan Model 7/2009 7 Development Process Models They all have some common objectives: – Better Improved Quality – Faster Lower overall development time – Cheaper Lower resource costs

8. Computer Engineering 203 R Smith Process/Plan Model 7/2009 8 Development Process Models The different development models employ many of the same development techniques. The different development models see the same phases in development. – Requirements gathering – Requirements analysis – Design – Implementation – Deployment

9. Computer Engineering 203 R Smith Process/Plan Model 7/2009 9 Development Process Models If the different models have so much in common why are there different models?

10. Computer Engineering 203 R Smith Process/Plan Model 7/2009 10 Development Process Models The process models can fall into two basic camps each having a different focus on certain aspects of the model. Long term/Short term Process/People Large/Small Predictability/Flexibility

11. Computer Engineering 203 R Smith Process/Plan Model 7/2009 11 Development Process Models How knowledge is kept and transferred – Agile has a person to person focus Low overhead for small groups – In process development models it is through documents Knowledge is maintained outside of individuals

12. Computer Engineering 203 R Smith Process/Plan Model 7/2009 12 Development Process Models Each model has its own success stories. Supporters of each model show how to incorporate elements of the other model. No one model has been clearly more successful. A large percentage of all development projects follow no set model.

13. Computer Engineering 203 R Smith Process/Plan Model 7/2009 13 Development Process Model The key is to understand the strengths and weaknesses of each model. Understand the characteristics of both the project you are undertaking and the team/resources you have available. Adapt what works best for the project.

14. Computer Engineering 203 R Smith Process/Plan Model 7/2009 14 Process Models SEI/CMM – Process focus; people are interchangeable – Predictability Agile Methods/Extreme Programming – People focus; people make the difference – Flexibility

15. Computer Engineering 203 R Smith Process/Plan Model 7/2009 15 Process Models Process does not mean without change or the ability to adapt.

16. Computer Engineering 203 R Smith Process/Plan Model 7/2009 16 SEI/CMM Software Engineering Institute Capability Maturity Model – Federally funded starting in 1984 – SEI established to address the issues directly related to software development – Initial version published in 1989 by Watts Humphrey

17. Computer Engineering 203 R Smith Process/Plan Model 7/2009 17 The Model 5 Levels – Initial – Repeatable – Defined – Managed – Optimizing As you progress through the level risk decreases and predictability increases

18. Computer Engineering 203 R Smith Process/Plan Model 7/2009 18 The Spirit of CMM CMM is not: – A methodology for Software Development – A production template – A set of process laws CMM is conceptual and non-specific Not a quick fix CMM is a discipline and guideline

19. Computer Engineering 203 R Smith Process/Plan Model 7/2009 19 The Spirit of CMM Looking at the forest and not the trees – What does this mean? The big picture not the details The primary objective is to improve a development organizations ability to develop software

20. Computer Engineering 203 R Smith Process/Plan Model 7/2009 20 Key Process Areas At each level beyond level one there are Key Process Areas defined, KPAs. Within each KPA there is: – Commitment to perform – Ability to perform – Activities to perform – Measurement and analysis – Verifying implementation

21. Computer Engineering 203 R Smith Process/Plan Model 7/2009 21 Key Process Areas Commitment – Management actively supports the process with resources – Management believes in the process Ability – Resources and training Activity – Defined processes and procedures

22. Computer Engineering 203 R Smith Process/Plan Model 7/2009 22 Key Process Areas Measurement – Gathering quantitative data for process improvement Verification – Regular review of the process

23. Computer Engineering 203 R Smith Process/Plan Model 7/2009 23 Level 1 Initial No formal procedures Not repeatable Whatever is being done General chaos Very little learning or process improvement

24. Computer Engineering 203 R Smith Process/Plan Model 7/2009 24 Level 2 Repeatable At level 2 you implement processes and then study them repeating what works and discarding what does not. You become a “conscious” organization, able to learn and improve. At level 2 the focus is at the project level. Policies and procedures apply to individual projects not the entire organization.

25. Computer Engineering 203 R Smith Process/Plan Model 7/2009 25 Level 2 Repeatable Repeatable requires documented policies and procedures, so you know what you did. Level 2 is the first time formal controls are put in place. Level 2 is the time for experimentation. Level 2 is generally the hardest level to achieve, in many cases requiring 2+ years.

26. Computer Engineering 203 R Smith Process/Plan Model 7/2009 26 Level 2 KPAs Requirements management – The requirements process is controlled Documented, under change control – Software Project Plans are consistent with requirements Software Project Planning – Software project activities are planned and documented – Commitments are made and documented – Software estimates are documented for planning and tracking

27. Computer Engineering 203 R Smith Process/Plan Model 7/2009 27 Level 2 KPAs Project Tracking and Oversight – Actual results are tracked against plans – Corrective actions are taken – Changes to commitments are agreed to by affected groups Software Configuration Management – SCM activities are planned – Selected work products are identified and controlled

28. Computer Engineering 203 R Smith Process/Plan Model 7/2009 28 Level 2 KPAs Software Quality Assurance – SQA activities are planned – Adherence to standards, procedures and policies is verified objectively – Noncompliance issues are addressed Software Subcontract Management – Only qualified subcontractors are selected – Commitments are agreed to – Subcontractor performance is tracked

29. Computer Engineering 203 R Smith Process/Plan Model 7/2009 29 Issues in Achieving Level 2 Lack of commitment – Inability of senior management to keep their hands off. – Lack of commitment of resources. Over analysis – Looking at the trees and not the forest. – Being more concerned with the letter rather than the intent.

30. Computer Engineering 203 R Smith Process/Plan Model 7/2009 30 Issues in Achieving Level 2 Change in mind set – Not the way we have always done it. – Thinking in terms of size not dates. – Making conscious decisions – The need to get objective data. Level 2 is not Rocket Science, but it does require commitment and discipline.

31. Computer Engineering 203 R Smith Process/Plan Model 7/2009 31 Level 3 Defined At level 3 the focus shifts from project to organization. At level 2 you experimented to determine what works and what does not work, at level 3 you define the processes that worked for the entire organization. Level 2 also changed the organization’s way of thinking.

32. Computer Engineering 203 R Smith Process/Plan Model 7/2009 32 Level 3 KPAs Software Process Improvement focused on the organizational level. – Process improvement efforts are coordinated across the organization. Organization Process Definition – Standard processes are defined across the organization. Training Program – The organization has a coordinated management and technical training program.

33. Computer Engineering 203 R Smith Process/Plan Model 7/2009 33 Level 3 KPAs Integrated Software Management – Establish how the organization as a whole does software project planning. Software Product Engineering – Software work products are verified and validated against requirements. – Applicable support is delivered to customers and end-users.

34. Computer Engineering 203 R Smith Process/Plan Model 7/2009 34 Level 3 KPAs Intergroup Coordination – Activities among project groups are coordinated. – Commitments among groups are established and maintained. Peer Reviews – Defects in software work products are removed early in the software lifecycle. – Software work products are reviewed by the producers peers.

35. Computer Engineering 203 R Smith Process/Plan Model 7/2009 35 Level 3 Estimates put only 3 to 7% of development shops at level 3. Level 3 needs a strong commitment from Senior Management to be successful.

36. Computer Engineering 203 R Smith Process/Plan Model 7/2009 36 Level 4 Managed Level 4 is about measurement and gauging the effectiveness of the development process. Goals are quantitative and require the consistent gathering of metrics.

37. Computer Engineering 203 R Smith Process/Plan Model 7/2009 37 Level 4 KPAs Quantitative Process Management – Use of metrics to evaluate existing process effectiveness. Software Quality Management – Use of metrics to evaluate product quality. Estimates put only 2 to 3% of development shops at level 4

38. Computer Engineering 203 R Smith Process/Plan Model 7/2009 38 Level 5 Optimizing Level 5 is characterized as a continuous state of improvement. Quality, technology and processes used are under regular review for areas that can be improved.

39. Computer Engineering 203 R Smith Process/Plan Model 7/2009 39 Level 5 KPAs Defect Prevention Technology Change Management Process Change Management Estimates put less than 2% of development shops at Level 5

40. Computer Engineering 203 R Smith Process/Plan Model 7/2009 40 Summary of CMM Document and discipline Measure the results Make changes Measure the result of the changes

41. Computer Engineering 203 R Smith Process/Plan Model 7/2009 41 PSP/TSP as they relate to CMM In CMM the focus is on what, in Personal Software Process and Team Software Process the focus is on how. Results – Major improvements in software quality – Effort and schedule estimates within 10% of plan – Shorter test cycles

42. Computer Engineering 203 R Smith Process/Plan Model 7/2009 42 PSP In PSP the focus is retraining individual habits. A series of 10 programming exercises is required. Skills in estimating size and quality improvement are emphasized Acquiring discipline and keeping focus are also stressed.

43. Computer Engineering 203 R Smith Process/Plan Model 7/2009 43 TSP In TSP the focus is on self directed teams Management needs training as much as the team, to coach and motivate. Key are Launch/Relaunch meetings at each of the 4 phases. Postmortem, what was learned.

44. Computer Engineering 203 R Smith Process/Plan Model 7/2009 44 TSP Phases Requirements High Level Design Implementation Integration and Test

45. Computer Engineering 203 R Smith Process/Plan Model 7/2009 45 Within each Launch Review Project Objectives Establish Roles Agree and Document Team Goals Define the Development Process Plan Support Facilities Produce a Development Plan Produce a Quality Plan

46. Computer Engineering 203 R Smith Process/Plan Model 7/2009 46 Within each Launch Develop Detailed Plans for each Engineer Merge Plans Rebalance the workload Assess Risks Hold Weekly Meetings

47. Computer Engineering 203 R Smith Process/Plan Model 7/2009 47 Observations on PSP/TSP Because PSP/TSP stresses self managing teams it is often a hard sell to management.