1 / 39

Chapter 2 Software Process: A Generic View

Chapter 2 Software Process: A Generic View. Quick Look. What is software process A series of predictable steps that helps you create a timely, high-quality result. Who does the process Software engineers and their managers adapt the process to their needs and then follow it.

kairos
Download Presentation

Chapter 2 Software Process: A Generic View

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. Chapter 2Software Process:A Generic View

  2. Quick Look • What is software process • A series of predictable steps that helps you create a timely, high-quality result. • Who does the process • Software engineers and their managers adapt the process to their needs and then follow it

  3. Quick Look (cont.) • Why is it important • It provides stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic • What are the steps • At a detailed level, the process that you adopt depends on the software you’re building

  4. Quick Look (cont.) • What is the work product • Programs, documents, and data • How do I ensure that I’ve done it right • Employing software process assessment mechanisms • Indicators • Quality, timeliness, long-term viability

  5. Software engineering • Fritz Bauer, 1969 • The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines • IEEE, 1993 • The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

  6. Software Engineering is aLayered Technology tools methods process model a “quality” focus

  7. Layered Technology (cont.) • Any engineering approach must rest on an organizational commitment to quality • Software process is the glue that holds the technology layers together and enables rational and timely development of computer software

  8. Layered Technology (cont.) • Software engineering methods provide the technical how-to’s for building software • Communication, requirement analysis, design modeling, program construction, testing, and support • Software engineering tools provide automated or semi-automated support for the process and the methods • CASE (Computer-Aided Software Engineering)

  9. A Generic View of Software Engineering • The work associated with software engineering can be categorized into three generic phases • The definition phase focuses on what • The development phase focuses on how • The support phase focuses on change associated with correction, adaptation, enhancement, and prevention

  10. A Process Framework • Process framework • Framework activities • work tasks • work products • milestones & deliverables • QA checkpoints • Umbrella Activities

  11. Framework Activities • Communication • Planning • Modeling • Analysis of requirements • Design • Construction • Code generation • Testing • Deployment

  12. Umbrella Activities • Software project management • Formal technical reviews • Software quality assurance • Software configuration management • Document preparation and production • Reusability management • Measurement • Risk management

  13. The Process Model: Adaptability • the framework activities will always be applied on every project ... BUT • the tasks (and degree of rigor) for each activity will vary based on: • the type of project (an “entry point” to the model) • characteristics of the project • common sense judgment; concurrence of the project team

  14. The CMMI • Software Engineering Institute (SEI) at Carnegie Mellon University • Capability Maturity Model Integration (CMMI) for determining an organization’s current stat of process maturity • The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. • Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. • Specific practicesrefine a goal into a set of process-related activities. http://www.sei.cmu.edu/cmmi

  15. The CMMI (cont.) • One model, two representations • Staged: organizational maturity approach • Continuous: process capability approach

  16. The CMMI (cont.)

  17. The CMMI (cont.) • 5 levels • Initial • Managed • Defined • Quantitatively managed • Optimized

  18. 1. Initial Process: undefined, ad hoc Result: outcome depends on individuals Lacking: any reasonable process

  19. 2. Managed 1. INITIAL Process undefined, ad hoc, depends on individuals Process tracks documents, cost, schedule, functionality (after fact) Result repeatable only on similar projects Lacking:completeprocess

  20. 3. Defined 2. REPEATABLE Basic project management to track cost & schedule, repeatable on similar projects Process documented, standardized, tailorable Result consistency Lacking: predictable outcomes

  21. 4. Quantitatively managed 3. DEFINED Consistent: Documented, standardized, tailorable Process detailed measurement; control Result process and products with quantified quality predictability Lacking mechanism for process improvement

  22. 5 Optimized 4. MANAGED Predictable: process & products measured Process Continual process improvement through quantitative feedback; Extensible scope Innovative ideas and technologies Graphics reproduced with permission from Corel.

  23. The CMMI (cont.) • The SEI has associated key process areas (KPAs) with each of the maturity levels • The KPAs describe those software engineering functions that must be present to satisfy good practice at a particular level

  24. The CMMI (cont.) • Each KPA is described by identifying the following characteristics • Goals • Commitments • Abilities • Activities • Methods for monitoring implementation • Methods for verifying implementation

  25. The CMMI (cont.) • 18 KPAs are defined across the maturity model and mapped into different levels of process maturity • Level 2 • Software configuration management, software quality assurance, software subcontract management, software project tracking and oversight, software project management, requirement management • Level 3 …

  26. Process Areas for CMMI

  27. Process Patterns • Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors • A template is used to define a pattern • An example process pattern template proposed by Ambler in 1998 • Pattern name • Intent • Type • Initial context • Problem • Solution • Resulting context • Related patterns • Known uses/examples

  28. Process Patterns (cont.) • Typical examples: • Customer communication (a process activity) • Analysis (an action) • Requirements gathering (a process task) • Reviewing a work product (a process task) • Design model (a work product)

  29. Process Assessment • The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. • Many different assessment options are available: • SCAMPI • CBA IPI • SPICE (ISO/IEC15504) • ISO 9001:2000 • Plan-do-check-act

  30. Assessment and Improvement

  31. Personal Software Process (PSP) • What is it • Developed by a team leaded by W.S. Humphrey in 1995 at CMU/SEI • PSP is a software engineering methodology by which an individual software developer can continuously improve his or her abilities, in particular: • learn to make accurate predictions of time required and quality obtained; • improve the quality of the software produced; • learn how to evaluate technology and methods. Source: http://www.ipd.uka.de/PSP/

  32. Personal Software Process (cont.) • Recommends five framework activities: • Planning • High-level design • High-level design review • Development • Postmortem

  33. Personal Software Process (cont.) • PSP emphasizes the need to record and analyze the types of errors you make, so you can develop strategies to eliminate them • PSP represents a disciplined, metrics-based approach to software engineering

  34. PSP Defect Type Standard

  35. Team Software Process (TSP) • What is it • TSP provides a defined process framework for managing, tracking and reporting the team's progress. • Using TSP, an organization can build self-directed teams that plan and track their work, establish goals, and own their processes and plans.

  36. Team Software Process (cont.) • TSP defines the following framework activities: • Launch • High-level design • Implementation • Integration and test • Postmortem • TSP makes a wide variety of scripts, forms, and standards to guide team members • For example, scripts for project launch

  37. Team Software Process (cont.) p. 71

  38. PSP, TSP, and CMMI

  39. The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!

More Related