Computer Engineering 203 R Smith Process/Plan Model 7/ 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/ 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/ 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/ Disciplined Process Every process describes itself as disciplined. What does it mean to be disciplined?

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

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

Computer Engineering 203 R Smith Process/Plan Model 7/ 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/ 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/ Observations on PSP/TSP Because PSP/TSP stresses self managing teams it is often a hard sell to management.