1 / 47

Development Process Models

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. Other Factors.

donat
Download Presentation

Development Process Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 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 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? 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. 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 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 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 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? 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 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 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. 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. 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 Computer Engineering 203 R Smith Process/Plan Model 7/2009

  15. Process Models • Process does not mean without change or the ability to adapt. 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 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 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 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 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 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 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 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 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. 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. 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 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 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 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 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 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 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 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. 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. Computer Engineering 203 R Smith Process/Plan Model 7/2009

  44. TSP Phases • Requirements • High Level Design • Implementation • Integration and Test 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 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 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. Computer Engineering 203 R Smith Process/Plan Model 7/2009

More Related