2.1/65 The Software Process. 2.2/65 Overview Location Commentary, Terminology, “Documentation”...

2.1/65

The Software Process

2.2/65Overview

• Location Commentary,

• Terminology,

• “Documentation” and “Testing” Phases,

• The Classical Development Phases,

• Inherent Problems of SW Production,

• Improving the SW Process,

• SEI Capability Maturity Model ,

• ISO 9000 & SPICE.

2.3/65


• Terminology,





• SEI Capability Maturity Model,


2.4/65

• Session 2 – 2,000 Ft.

Location Commentary

• Session 1 – 100,000 Ft. ,

,

2.5/65


• Terminology,







2.6/65Terminology – מינוח

• Systems analysis,– Requirements + specifications phases,

• Operations mode– Maintenance,

• Design– Architectural design,

detailed design,

• Client,

• Developer,

• Vendor,

• Manufacturer ,

• User,

ה“ של דעולם ברום”אג

ספק

משתמשלקוח

יצרן

Made in China

מפתח

2.7/65


• Terminology,







2.8/65Testing Phase?

• There is NO testing phase!,

• Testing is an activity performed throughout SW production,

• Testing related terminology:

• Verification – ,אישור אימות– Performed at the end of each phase,

• Validation - חוקי תוקף מתן– Performed before delivering the product to the

client ,

2.9/65Documentation Phase?

• There is NO documentation phase!,

• Why?:

• Every phase must be fully documented before starting the next phase,

• Postponed documentation may never be completed,

• The responsible individual may leave,

• The product is constantly changing, we need the documentation to do this ,

• The design (for example) will be modified during development, but the original designers may not be available to document it.

2.10/65


• Terminology,







2.11/65Requirements Phase

• Assumption:– The SW being considered

is economically justifiable,

• Concept exploration– Determine what the client needs,

not what the client wants ,

• Requirement Engineering,

,

• Moving target problem– The Rapid prototype,

2.12/65Requirements Phase Documentation

• Rapid prototype or ,

• Requirements document.

2.13/65Requirements Phase Testing

• Requirements Review,

• Rapid prototyping.

2.14/65Requirements Phase Testing

2.15/65Specification Phase

• Specifications document (“specifications”):– Legal document,– Must not have phrases like “optimal,” or “98%

complete”, – Explicitly describes the functionality of the

product,– List all inputs and outputs, – Lists all constrains , …

• Specifications must not be:– Ambiguous, foggy, misty– Incomplete ,– Contradictory.

2.16/65Specification Phase Documentation

• Only when specification is completed – we can really plan the project!Only now we can appreciate time & money, (the needed personnel, environment, tools …),

• SDP ,

• Specification document (specifications) – EPS.

2.17/65Specification Phase Testing

• Check the spec doc.

• Check the SDP,

• Traceability,– Every part of the specification can be linked to a

statement in the requirements ,

• Review – walkthrough.

2.18/65Design Phase

• Specification Phase — what,

• Design Phase — how,

• Architectural design:– Decompose the product into modules,

• Detailed design:– Design each module: data structures, algorithms ,

• Retain design decisions:– When a dead-end is reached,– For the maintenance team,– Ideally, the design should be open-ended.

2.19/65Design Phase Documentation

• Architectural design,

• Detailed design ,

• Keeping records of design decisions.

2.20/65Design Phase Testing

• Traceability: – Every part of the design can be linked to a statement

in the specification document, and – Every statement of the specification document is

reflected in some part of the design ,

• Review, looking for: – Logical faults, – Interface fault, – Lack of exception handling & nonconformance to

specifications.

2.21/65Implementation Phase

• Implement the detailed design in code ,

• The modules should be tested while they are being implemented.

2.22/65Implementation Phase Documentation

• Source code– Test cases (with expected output) ,

• Test case and Test case results,– They will be the base for the regression testing

library.

2.23/65Implementation Phase Testing

• Review,– Code review,

• Test cases,– Informal testing (desk checking):

Modules should be tested while they are being implemented,

– These tests are verification ,

– Formal testing (SQA).

2.24/65Integration Phase

• Combine the modules and check the product as a whole ,

• Bottom-up vs. Top-Down integration methods.

2.25/65Integration Phase Documentation

• Commented source code ,

• Test cases for the product as a whole.

2.26/65Integration Phase Testing

• SQA involvement,

• Special care for interfaces,

• Product testing,

• Acceptance testing – customer,(Checking correctness, robustness, …) ,

• Validation testing.

2.27/65Integrating COTS SW – מדף תוכנת

• “Shrink-wrapped SW”,

• Commercial Off-The-Shelf (COTS),

• COTS SW is often downloaded ,

• “Click-wrapped SW”,– First version, Alpha version – Alpha testing,– Corrected Alpha version – Beta testing.

2.28/65Maintenance Phase

• Maintenance:– Any change once the client has accepted the SW:

Corrective, Enhancement, Perfective,Adaptive,

• Most of the money is devoted to this phase ,

• The problem of lack of documentation.

2.29/65Maintenance Phase Documentation

• Record of all changes made, with reasons,

• The CCB – (Change Control Board) meeting minutes ,

• Regression test cases.

2.30/65Maintenance Phase Testing

• New change testing &…

• Regression testing ,

• Customer are very happy with new capabilities, but they are more than upset with disappearance of previous capabilities!

2.31/65Retirement – פרישה

• Good SW is maintained,

• Sometimes SW is rewritten from scratch,

• SW might become un-maintainable because:1. Maintenance is no longer cost-effective,2. A drastic change in design has occurred,3. The product must be implemented on a totally new

hardware/operating system,4. Documentation is missing or inaccurate,5. Hardware is to be changed — it may be cheaper to rewrite

the SW from scratch than to modify it ,

• True retirement is a rare event.

2.32/65


• Terminology,







2.33/65Inherent Problems of SW Production

• Aristotelian categories– Essence – ,מהות ,תמצית– Accidents – תאונות,

• Hardware has inherent limits – so does SW,

• SW inherent limits [Brooks 1986]:– Complexity – מורכבות,– Conformity – , תאימות מוסכמות ,קבלת– Changeability – גמישות,– Invisibility – נראות , אי

• Brooks claim: No Silver Bullet,,

2.34/65(Essence) Complexity – מורכבות

• While (X>t)read (t)…

How many test cases? (assuming integers: 216 X 216 - what about DW?)

• SW is far more complex than hardware:– Traditional abstraction will not work,– “We cannot understand the whole, so we cannot

understand any part” – Is that true?– Management is difficult,– Maintenance is a nightmare (documentation, too) ,

• OOP can reduce Complexity!

2.35/65(Essence) Complexity – מורכבות (Cont’d)

• Complexity affects management as well,

• How to obtain accurate data regarding the process?,

• How to manage turnover?,

• Complexity affects maintenance as well ,

• Poor docs >> No docs >> Incorrect docs.

2.36/65

(Essence) Conformity – , מוסכמות קבלת תאימות

• Does SW needs to conform the world – or is it the other way?

• Type 1: Existing gold refinery:– In order to increase the gold yield, management wants

to computerize the control system, – The SW model –

must conform to the real world – not the other way… ,

• Type 2: New gold refinery:– Is SW the most conformable component?

2.37/65(Essence) Changeability – גמישות

• Software is easier to change than hardware ,

• Pressure to change:– Reality is changing,– Useful SW – users pressure to extend functionality,– Easier to change (what about programmable HW?) ,– SW has a longer lifetime (~15 yrs)

compared to hardware (~4 yrs).

2.38/65(Essence) Invisibility – נראות אי

• SW is invisible and un-visualizable,

• Complete views are incomprehensible,

• Partial views are misleading ,

• However, all views can be helpful…– Control Flow,– Data Flow,– Time sequences ,– Dependency Pattern.

2.39/65Is There a Silver Bullet?

• What about:– High-level languages,– Rapid prototype,– Incremental development,– Time sharing,– CASE tools,

• These did not solve the intrinsic problems,

• We have experienced ,– 6% annual productivity increase!,– Productivity is doubled every 12 years! ,

• But, no “silver bullet” (order-of-magnitude increase) is possible!

2.40/65Is There a Silver Bullet? (Cont’d)

• What can be improved?

• Whenever possible – Buy (instead of make),

• The NIH syndrome,

• Emphasis the requirements, specification and design phases,

• Training designers ,

• There is hope!

2.41/65


• Terminology,







2.42/65Improving the SW Process

• U.S. Department of Defense initiative:– “After two decades of largely unfulfilled promises about

productivity and quality gains from applying new SW methodologies and technologies, industry and government organizations are realizing that their fundamental problem is the inability to manage the SW process [DoD, 1987]” ,

• Translate…,

• SW Engineering Institute (SEI) Initiatives:– CMM - Capability maturity model,– ISO 9000-series,– SPICE – SW Process Improvement Capability

dEtermination (ISO 15504).

2.43/65


• Terminology,







2.44/65SEI CMM – Capability Maturity Model …

• Not a life-cycle model,

• Set of strategies for improving the SW process:– SW–CMM for SW,– P–CMM for human resources (“people”),– SE–CMM for systems engineering,– IPD–CMM for integrated product development,– SA–for SW acquisition ,

• These strategies are being unified into CMMI (Capability Maturity Model Integration).

2.45/65SEI CMM …

• A strategy for improving the SW process:– Put forward in 1986 by the SEI,

• Fundamental idea:– Improving the SW process leads to:

Improved SW quality,Delivery on time, within budget,

– Improved management leads toImproved techniques ,

• Five levels of “maturity” are defined:– Organization advances stepwise from level to level.

2.46/65SEI CMM (Cont’d) …

• 5 STAGES OF MATURITY

1.Initial level Ad hoc process,

2.Repeatable level Basic project management,

3.Defined level Process definition,

4.Managed level Process measurement ,

5.Optimizing level Process control.

2.47/65[SEI CMM] Level 1. – Initial

• The Lowest Level,

• Most organizations world-wide are at level 1!,

• Ad hoc approach:– Entire process is unpredictable,– Management consists of…

responses to crises,

• How can we tell? ,

2.48/65[SEI CMM] Level 2. – Repeatable

• Basic SW management,

• Management decisions should be made on the basis of previous experience with similar products,

• Measurements (“metrics”) are made, these can be used for making cost and duration predictions in the next project– (e.g. Tracking costs and schedules) ,

• Problems are identified, immediate corrective action is taken.

2.49/65[SEI CMM] Level 3.

קו פרשת המים

2.50/65[SEI CMM] Level 3. – Defined

• The SW process is fully documented,

• Managerial and technical aspects are clearly defined,

• Continual efforts are made to improve quality, productivity,

• Reviews are performed to improve SW quality(e.g. Walkthrough, inspection) ,

• CASE tools are applicable now (and not at levels 1 or 2).

2.51/65[SEI CMM] Level 4. – Managed

• Quality and productivity goals are set for each project,

• Quality, productivity are continually monitored ,

• Statistical quality controls are in place– e.g. Faults per 1,000 LOC.

2.52/65[SEI CMM] Level 5. – Optimizing

• Continuous process improvement,

• Statistical quality and process controls ,

• Information from one project is always being used for projects that are built later on.

2.53/65[SEI CMM Levels] Summary

2.54/65[SEI CMM] Key Process Areas

• There are key process areas (KPAs) for each level,

• Example: level 2 KPAs include:– Requirements management,– Project planning,– Project tracking,– Configuration management,– Quality assurance ,

• Compare:– Level 2: Detection and correction of faults ,– Level 5: Prevention of faults.

2.55/65[SEI CMM] Experience …

• It takes:– 3 to 5 years to get from level 1 to level 2, – 1.5 to 3 years from level 2 to level 3,– SEI questionnaires highlight shortcomings,

suggest ways to improve the process ,

• Original idea: Defense contracts would be awarded only to capable firms.

2.56/65[SEI CMM] Experience (cont’d)

• Profitability:

• Hughes Aircraft (Fullerton, CA) spent $500K (1987–90):– Savings: $2M per year, moving from level 2 to level 3,

• Raytheon moved from level 1 in 1988 to level 3 in 1993:– Productivity doubled ,– Return of $7.70 per dollar invested in process

improvement ,

• http://www.sei.cmu.edu/cmm/cmms/cmms.html

2.57/65


• Terminology,







2.58/65ISO 9000 …

• A different attempt to improve SW quality,

• International Standards Organization – ISO,

• Standards which are applicable to a wide variety of industrial activities,

• ISO 9001 for quality systems ,

• ISO 9000-3, guidelines to apply ISO 9001 to SW.

2.59/65ISO 9000 (Cont’d)

• There is an overlap with CMM, but they are not identical,

• Not process improvement,

• Stress on documenting the process,

• Emphasis on measurement and metrics,

• ISO 9000 is required to do business with the E.U.,

• Also by many U.S. businesses, for example, GE ,

• More and more U.S. businesses are ISO 9000 certified.

2.60/65SPICE - ISO/IEC 15504 …

• International process improvement initiative,

• Original name: SW Process Improvement Capability dEtermination (SPICE),

• Started by British Ministry of Defence (MOD),

• Includes process improvement, SW procurement,

• Extends and improves CMM, ISO 9000,

• Framework, not a methodCMM, ISO 9000 conform to this framework,

• Now referred to as ISO/IEC 15504,

• Or just 15504 for short ,

• SPICE.

2.61/65SPICE (Cont’d)

• SPICE is an international initiative to support the development of an international standard for SW Process Assessment. The project has three principal goals:

• To develop a working draft for a standard for SW process assessment,

• To conduct industry trials of the emerging standard ,

• To promote the technology transfer of SW process assessment into the SW industry world-wide.

2.62/65Process Improvement Data …

• SEI report on 13 organizations in the original study,

• They used a variety of process improvement techniques, not just SW–CMM,

2.63/65Process Improvement Data (Cont'd)

• Results of 34 Motorola projects:

2.64/65Summary


• Terminology,







2.65/65

The Software Process

The End

2.1/65 The Software Process. 2.2/65 Overview Location Commentary, Terminology, “Documentation”...

Documents

Transcript of 2.1/65 The Software Process. 2.2/65 Overview Location Commentary, Terminology, “Documentation”...