Software Development Process

Huzefa Kagdi, Ph.D. Department of Electrical Engineering and Computer Science Wichita State University Wichita, KS, USA

General Issues
A large number of software projects fail
Never delivered/completed Do not meet requirements or user needs Excessive failures (bugs) Excessively over budget or late

Text

Quality and reliability of many software systems cannot be formally assessed Prolonged Software Crisis

Standish Group Data

Data on 9236 projects completed in 2004

Software Engineering
Application of a systematic, disciplined, quantiable approach to the development, operation, and maintenance of software [IEEE]
Quality Focus Process Methods Tools

Text

A Layered Approach
Focus on quality
e.g., space craft navigation vs. word processor

Text

Process layer that enables rational and timely development of software

e.g., Waterfall model Key process areas must be established for effective delivery of software technology

Methods provide support for process

e.g., OO

Tools provide support for methods

e.g., MS .Net

Challenges with Software Production

Complexity - domain, size, teams, user-base Conformity - conform to the existing process or have the process conform to the software Changeability - software can easily be changed, but a bridge is almost impossible to move Invisibility - software is very hard to visualize Brooks No Silver Bullet [IEEE Computer 9(4), 1987] Software is very difcult to develop, and most likely will not get easier Reuse is one solution suggested In 20 years, 6% per year production improvement
6

Text

Software Development Process

Text

A structured approach to the development of software products and associated artifacts A structured set of activities or tasks required to develop a software system
[Sommerville]

Characteristics of Software Process

Predictability Repeatable Support software
testability and maintainability change early defect removal Support feedback

Text

Typical (Broad) Activities

Application (problem) domain analysis Requirements elicitation and analysis Software Requirements Specication (SRS) Architecture and design Implementation Testing Deployment Maintenance/Evolution Retirement (phase out)
9

Text

Domain Analysis
What is the software product about?
e.g., stock market, student registration, and poker

Text

Help understand the domain vocabulary

e.g., bull vs. bear market

Effective communication between developers and customers Extract and align solution vocabulary Reduce/void misconception and preconception about overloaded terms
e.g., What does football mean?

10

Requirements Elicitation and Analysis

What is this system supposed to do? Customers may explain the (current) business process, but may not help much with what the software should do Often incomplete (good), unclear (worse), or contradictory (worst) requirements Analyst/developer extracts and help prioritize requirements Resultant artifact is a scope and/or vision document (often turns into a legal contract)

Text

11

Software Requirements Specication (SRS)

Detailed description of the system functionalities Dene external interfaces and interactions among entities (e.g., hardware and users) Also includes non-functional requirements such as performance and security Possible end product is a set of use cases Bases for estimation of cost and time Baseline for verication

Text

12

(Desirable) Characteristics of SRS

Correct Unambiguous Complete Consistent Priority ranking Veriable Changeable Traceable

Text

13

Architecture and Design

Abstract representation of the system Independent of the specic implementation technology (e.g., C++ or Java) Architecture - blueprint/foundation/structure of the system (e.g., client-server style) Design - Distribution of functional responsibilities to logical units and their relationships (e.g., object oriented solution) Architecture is design, but not all design is architectural Resultant artifacts are architecture description and design documents/models
14

Text

Implementation
Realization of an operational system according to the design Selection of implementation technologies Involves programming/coding Resultant artifacts includes source code, build system, executables, and distribution documents

Text

15

Testing
Goal is to uncover defects/bugs as early as possible (and NOT to show that a system is bug free!) Involves unit, integration, and acceptance testing Resultant artifacts are test cases and/or test suites

Text

16

Deployment
Release the software in the production environment May occur at the producer site or consumer site or both (e.g., push updates via Internet) Artifacts may include FAQs, ChangeLogs May need Customer support

Text

17

Maintenance
All software evolves over time Corrective - x uncovered defect Adaptive - Platform change Enhancement - Perfective, additional functionality Preventive - re-engineering, make system more maintainable

Text

18

Costs of the Activities/Phases

Text

19

Cost of Post-delivery Maintenance

Text

(a) Between 1976 and 1981 (b) Between 1992 and 1998
20

Cost of Detecting and Correcting Faults - Phase View

Text

21

Software Development Process Model

Abstract representation of a process How exactly and in what order the activities should occur? Broad models
Waterfall Evolutionary/iterative development Formal Many variants

Text

22

Waterfall Model
A sequential ow of activities Main Activities in life cycle
Requirements specication Design Construction (implementation) Integration Testing and debugging (validation) Installation Maintenance

Classical model and provides a reference point

23

Supporting Points
Time spent early is time (and effort) saved later
e.g., detect bugs early in the process

Text

Emphasis on documentation Straightforward Feasible for a specialized domains with wellunderstood (and infrequently changed) requirements
e.g., mission-control defense or space projects

24

Opposing Points
Fragile against changing requirements and needs (moving target!) Some design issues and problems become known only during implementation Customers/end users may not get to see and provide feedback until (too) late in the process McConnell and Parnas criticisms

Text

25

Spiral Model

Text

26

Activities in Spiral Model

Detail requirements Preliminary design Create rst prototype (maybe on paper) Evaluate and create the next prototype Do risk assessment with costumer Iterate prototypes until it reects the nal system Construct the nal, real system Test and deploy the system Maintain the system
27

Text

Iterative/Incremental Model
Cyclic ow of activities An essential set of requirements implement the initial version/iteration Rene existing, and add new, functionality via more iterations Each iteration produces a deliverable to the customers/end users Includes Agile Methods such as XP and SCRUM
28

Iteration

Text

Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Time

Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test

Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.

3 weeks (for example) Iterations are fixed in length, or timeboxed. The system grows incrementally.

29

Timeboxed Iterations

Text

30

Iteration
Short iteration lengths
Two to six weeks Rapid feedback and adaptation. Long iterations increase project risk.

Text

If deadline seems difcult to achieve, then de-scope

Remove tasks or requirements from the iteration but include them in a future iteration

31

Development/Evolution Path

Text

Early iterations are farther from the "true path" of the system. Via feedback and adaptation, the system converges towards the most appropriate requirements and design.

In late iterations, a significant change in requirements is rare, but can occur. Such late changes may give an organization a competitive business advantage.

one iteration of design, implement, integrate, and test

32

Example Schedule
1 2 3 4 5 ... 20 requirements workshops Imagine this will ultimately be a 20iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.

Text

requirements

requirements

software

software

90%

90%

50% 20% 2% Iteration 1 30% 5% Iteration 2 a 3-week iteration 8% Iteration 3 10% Iteration 4 20% Iteration 5

week 1 M T W Th F

week 2 M T W Th F

week 3 M T W Th F

kickoff meeting clarifying iteration goals with the team. 1 hour

team agile modeling & design, UML whiteboard sketching. 5 hours

start coding & testing

de-scope iteration goals if too much work

final check-in and codefreeze for the iteration baseline Use-case modeling during the workshop

demo and 2-day requirements workshop

next iteration planning meeting; 2 hours

Most OOA/D and applying UML during this period

33

Supporting Points
Change centric and driven Constant feedback Operational version after each increment No big bang integration effort Short (requirement and design) fault incubation and/or hibernation period Improved time to market No Big Design Up Front (BDUF) Used in the development of a number of ubiquitous software products today
34

Text

Opposing Points
Communication overhead for feedback Need to be careful of feature creep

Text

35

But...Do Requirements Change?

40 35 30
Requirements change

Text

25 20 15 10 5 0 10 100 1000 Project Size in Function Points 10000

36

Standards
Capability Maturity Model (CMM)
accesses how well an adopted process is followed and not how good it is? superseded by CMMI(Interface), which provides standards to organize processes with documentation

Text

Software Process Improvement Capability Determination (SPICE)

framework for comparing processes

Six Sigma
Improve operational performance via statistical analysis Goal is to reduce defects largely used in manufacturing
37

Text

Questions/Comments/Thoughts?

38

Credits

Text

Some contents adopted from Wikipedia, Applying UML and Patterns - Larman, Software Engineering: A Practitioners Guide Pressman, and Dr. Jonathan I. Maletics slides.

39