outline outline
play

Outline Outline PSP Overview SW Process & Process Maturity - PDF document

Outline Outline PSP Overview SW Process & Process Maturity The The The 5-Level CMM Personal Software Process Personal Software Process PSP Levels Strategy Strategy Logic & Principles of the PSP Productivity An Overview AU INSY


  1. Outline Outline PSP Overview SW Process & Process Maturity The The The 5-Level CMM Personal Software Process Personal Software Process PSP Levels Strategy Strategy Logic & Principles of the PSP Productivity An Overview AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 1 Humphrey Ch. 1 - slide 1 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 2 Humphrey Ch. 1 - slide 2 PSP Overview PSP Definition PSP Overview PSP Definition “The personal software process (PSP) is a self-improvement process designed to help you control, manage, and improve the way you work. It is a structured framework of forms, guidelines, and procedures for developing software. Properly used, the PSP provides the historical data you need to better make and meet commitments and it makes routine elements of your job more predictable and more efficient.” (Humphrey, 1995, p. 1) AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 3 Humphrey Ch. 1 - slide 3 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 4 Humphrey Ch. 1 - slide 4 The PSP is not magic! The PSP is not magic! PSP Strategy (cf. Humphrey, 1995, p. 9) PSP Strategy (cf. Humphrey, 1995, p. 9) (cf. Humphrey, 1995, p. 2) (cf. Humphrey, 1995, p. 2) Identify large-system SW methods / The PSP is not magic. practices which can be used by individuals Define subset of these that can be applied It can be a great help in guiding your while developing small programs SW development. Structure these so they can be gradually learned Provide exercises for learning these But you must make the improvements methods / practices it suggests yourself. AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 5 Humphrey Ch. 1 - slide 5 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 6 Humphrey Ch. 1 - slide 6 1

  2. Why do we need a SE Why do we need a SE discipline? (Humphrey, 1995, p. 2, 3) Need for SE Discipline (cont.) discipline? (Humphrey, 1995, p. 2, 3) Need for SE Discipline (cont.) Most software development: Following this analogy: • Large-scale SW development is treated as “crowd • Does not follow a defined process control”: • Is performed intuitively • One doesn’t worry about what each individual does, • Requires extensive testing and repair • Just what the overall process is like. • Use unpredictable, nonrepeatable processes This approach is: This is similar to Brownian Motion • Expensive • Error-prone • Individual particles of gas cannot be predicted. • Risky • The entire volume can be described We need: statistically. • More detailed methodologies • Standards • Frameworks AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 7 Humphrey Ch. 1 - slide 7 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 8 Humphrey Ch. 1 - slide 8 A Disciplined SE Organization A Disciplined SE Organization Need for SE Discipline (cont.) Need for SE Discipline (cont.) (Humphrey, 1995, p. 3) (Humphrey, 1995, p. 3) Examples of disasters In order to address these issues, a • Thorac disciplined SE organization will: – Administered too much radiation (no safety control) and killed two patients. • Have well-defined practices. • Telephone system • Strive to continually improve these – Switching system failure shut down large segments of the US practices. • Power system – Overload carried over and affected multiple adjacent grids and “blacked out” much of Northeast. AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 9 Humphrey Ch. 1 - slide 9 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide Humphrey Ch. 1 - slide 10 10 SW Process & SW Process & What is Software Process? What is Software Process? Process Maturity Process Maturity (Humphrey, 1995, p. 4, 5) (Humphrey, 1995, p. 4, 5) A “software process is the sequence of steps required to develop or maintain software… [It] sets out the technical and management framework for applying methods, tools, and people to the software task.” AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 11 Humphrey Ch. 1 - slide 11 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 12 Humphrey Ch. 1 - slide 12 2

  3. Software Process Definition Software Process Definition Process Maturity (Humphrey, 1995, p. 6) Process Maturity (Humphrey, 1995, p. 6) (Humphrey, 1995, p. 5) (Humphrey, 1995, p. 5) A “software process definition is a description of [the SW An organization’s software development] process. When properly designed and presented, the development process maturity definition guides software engineers as they work… [It] identifies roles and specifies tasks… establishes measures and indicates the following things about provides exit and entry criteria for every major step. An effectively designed definition helps to ensure that every work the organization’s development item is properly assigned and its status is tracked. process: It also provides an orderly mechanism for learning. As better methods are found, they are incorporated into the organization’s • How well defined it is official process definitions. A defined process thus permits each new project to build on its own experiences as well as its • How repeatable predecessors’.” • How well managed cf. Kellner’s list of benefits of operationally defining a process. • Whether it is optimizing / improving (Humphrey, p. 5) AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 13 Humphrey Ch. 1 - slide 13 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide Humphrey Ch. 1 - slide 14 14 The 5-Level CMM CMM Overview The 5-Level CMM CMM Overview CMM = Capability Maturity Model • An orderly way for organizations to determine the capabilities of their current processes and to establish priorities for improvement. • 5 Levels AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide Humphrey Ch. 1 - slide 15 15 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide Humphrey Ch. 1 - slide 16 16 Key Process Areas of the CMM Key Process Areas of the CMM 5 Levels of the CMM (cf. Humphrey, 1995, p. 6, 7) 5 Levels of the CMM (cf. Humphrey, 1995, p. 6, 7) (cf. Humphrey, 1995, p. 7) (cf. Humphrey, 1995, p. 7) Continuous process improvement C M M L e v e l K e y P r o c e s s A r e a s based on quantitative feedback • A d H o c , C h a o t i c 1 . I n i t i a l from the process and from • P r o c e s s d e p e n d e n t o n e a c h i n d i v i d u a l 5. Optimizing innovative ideas and technologies. d e v e l o p e r 2 . R e p e a t a b l e • S W C o n f i g M g t • S W Q A • S W S u b c o n t r a c t M g t Process and product are measured 4. Managed • S W P r o j T r a c k i n g & O v e r s i g h t and can be controlled. • S W P r o j P l a n n i n g • R e q ’ s M g t Documented, standardized, 3. Defined • P e e r R e v i e w s 3 . D e f i n e d and integrated software • I n t e r g r o u p c o o r d i n a t i o n process. • S W P r o d E n g i n e e r i n g • I n t e g r a t e d S W M g t 2. Repeatable Basic project mgt. Tracking cost, • T r a i n i n g schedule, and functionality. Can • S W P r o c e s s D e f i n i t i o n repeat earlier successful processes • S W P r o c e s s F o c u s 1. Initial • Q u a l i t y M g t on similar projects. 4 . M a n a g e d • Q u a n t i t a t i v e P r o c e s s M g t • P r o c e s s C h a n g e M g t 5 . O p t i m i z i n g CMM Levels Ad hoc. Depends on each individual • T e c h n o l o g y C h a n g e M g t engineer’s approach, techniques, and skills. • D e f e c t P r e v e n t i o n AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide Humphrey Ch. 1 - slide 17 17 AU INSY 560, Winter 1997, Dan Turk AU INSY 560, Winter 1997, Dan Turk Humphrey Ch. 1 - slide 18 Humphrey Ch. 1 - slide 18 3

Recommend


More recommend