Software Development Process

1. Software Development Process

2. Process Improvement Using the Shewhart Cycle • PLAN - Plan a change aimed at improvement, collect data, and establish a timetable. • DO – Implement the change on a small scale. • CHECK – Study the results of your actions. What did you find? • ACT – Apply the change or abandon it, or run through the cycle again under different conditions.

3. Why Must the Software Development Process be Written?

4. Why Must the Software Development Process be Written? • So it can be: • read • understood • questioned • communicated • modified • improved

5. Won’t a Written Process Stifle Creativity? • A process does not define how software engineers do what they do • It can even leave them more time to be creative since it removes mundane aspects of their jobs • Written processes and procedures in other engineering disciplines haven’t stifled creativity

6. Our Process Was Never Written Down, But It Seems to Work – Why Write It Down? • To make it easier to train new people • To facilitate making process improvements • To identify areas where improvements are needed • To help achieve predictable software development

7. How Can a Software Engineering Manager Be Persuaded to Follow a Written Procedure? • Build a case based on controlling costs • Show how collecting data on one project can be used to make changes in the process to reduce the costs on the next project

8. How Can a Written Process Improve Software Quality? • In a large company it can help to connect software engineering to other engineering disciplines. • It helps establish a corporate memory on software development so the organization can learn from past mistakes. • It helps improve the use of valuable resources

9. How Can a Written Process Improve Software Quality? (cont’d) • It facilitates the introduction of new technology • It helps to improve consistency and lower overall costs • It provides a framework for continuous process improvement

10. We Don’t Have a Written Process and Software Quality Is OK – Why Change? • Over time customers become more concerned with quality – OK quality may not be good enough. • Improving quality may be important too stay competitive.

11. What is Software Quality Anyway? • Low levels of defects • High reliability • User satisfaction • Low occurrence of “bad fixes” • Effective customer support • Rapid repairs for defects • Capers Jones

12. What Do We Do After We Write Down Our Current Process? • Collect process data • Evaluate quality and customer satisfaction • Identify and implement areas for process improvement

13. How Can the Process Be Tailored to Meet the Needs of the Project Team? • The documented process should be viewed as a framework • Specific project plans can be developed that deviate from the documented process as long as those deviations are appropriate and agreed to by all concerned.

14. How Can Information Collected From Using the Process Be Used for Process Improvement? • By collecting data on errors found at various stages of development, the potential areas for process improvement can be identified. • Collecting data on customer reported problems will increase the likelihood that similar types of problems will be caught and corrected in the future.

15. Who Is Responsible for Enforcing the Process? • Ideally, there should be no need for enforcement. • Project managers should bear most of the responsibility to ensure that the process is followed. • The Quality Assurance organization may have some oversight in this area.

16. Who Should Be the Keeper of the Process? The responsibility for the process should be shared by those who are bound to follow it.

17. Summary • A written software development process is essential so it can be read, understood, communicated, followed and improved. • A written process is a required element for predictable software development. • The process should be owned by the software development organization.