The Software Process

The Software Process

Overview • 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.

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.

, Location Commentary • Session 1 – 100,000 Ft. , • Session 2 – 2,000 Ft.

ספק “עולם הדג של אברום” לקוח משתמש Made in China יצרן מפתח Terminology – מינוח • Systems analysis, • Requirements + specifications phases, • Operations mode • Maintenance, • Design • Architectural design, detailed design, • Client, • Developer, • Vendor, • Manufacturer , • User,

Testing 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 ,

Documentation 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.

, Requirements Phase • Assumption: • The SW being consideredis economically justifiable, • Concept exploration • Determine what the client needs, not what the client wants , • Requirement Engineering, • Moving target problem • The Rapid prototype,

Requirements Phase Documentation • Rapid prototype or , • Requirements document.

Requirements Phase Testing • Requirements Review, • Rapid prototyping.

Requirements Phase Testing

Specification 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.

Specification 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.

Specification 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.

Design 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.

Design Phase Documentation • Architectural design, • Detailed design , • Keeping records of design decisions.

Design 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.

Implementation Phase • Implement the detailed design in code , • The modules should be tested while they are being implemented.

Implementation 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.

Implementation 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).

Integration Phase • Combine the modules and check the product as a whole , • Bottom-up vs. Top-Down integration methods.

Integration Phase Documentation • Commented source code , • Test cases for the product as a whole.

Integration Phase Testing • SQA involvement, • Special care for interfaces, • Product testing, • Acceptance testing – customer,(Checking correctness, robustness, …) , • Validation testing.

Integrating 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.

Maintenance 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.

Maintenance Phase Documentation • Record of all changes made, with reasons, • The CCB – (Change Control Board) meeting minutes , • Regression test cases.

Maintenance 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!

Retirement – פרישה • Good SW is maintained, • Sometimes SW is rewritten from scratch, • SW might become un-maintainable because: • Maintenance is no longer cost-effective, • A drastic change in design has occurred, • The product must be implemented on a totally new hardware/operating system, • Documentation is missing or inaccurate, • 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.

, Inherent 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,

(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!

(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.

(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?

(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).

(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.

Is 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!

Is 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!

Improving 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).

SEI 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).

SEI 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.

SEI CMM (Cont’d) … • 5 STAGES OF MATURITY • Initial level Ad hoc process, • Repeatable level Basic project management, • Defined level Process definition, • Managed level Process measurement , • Optimizing level Process control.

[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? ,

[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.

[SEI CMM] Level 3. קו פרשת המים

[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).

The Software Process