CSC 205 - Software Engineering I
1
Overview - Software Lifecycles, Processes, Methods and Tools• Software lifecycle basics• Software lifecycles
– build-and-fix– waterfall– rapid prototype– incremental– spiral
• Process improvement– CMM & ISO9000
• Methods and Tools
CSC 205 - Software Engineering I
2
Software Lifecycle
• A series of steps through which a software product progresses
• Lifetimes vary from days to months to years• Consists of
– people!– overall process– intermediate products– stages of the process
CSC 205 - Software Engineering I
3
Software Production Personnel
• Client– individual or organization that wants a product to be
developed• Developer(s)
– (members of) an organization producing the product• User(s)
– person who authorizes the client to contract the developer
– person(s) who will utilize software in operation• internal software development: client = developer• contract software development: client ≠ developer
CSC 205 - Software Engineering I
4
What is a process?
• Device for producing a product (getting the job done!)
• Level of indirection– Process description describes wide class of
instances• Humans create process descriptions to solve
classes of problems• Thus
– software processes are devices for creating and evolving software products
CSC 205 - Software Engineering I
5
Intermediate Software Products
• Objectives– Demarcate end of phases– Enable effective reviews– Specify requirements for next phase
• Form– Rigorous– Machine processible (highly desirable)
• Content– Specifications, Tests, Documentation
CSC 205 - Software Engineering I
6
Phases of a Software Lifecycle
• Standard Phases– Requirements Analysis & Specification– Design– Implementation and Integration– Operation and Maintenance– Change in Requirements– Testing throughout!
• Phases promotes manageability and provides organization
CSC 205 - Software Engineering I
7
Requirements Analysis and Specification
• Problem Definition —> Requirements Specification– determine exactly what client (and user) wants and process constraints– develop a contract with client– what task the product is to do
• Difficulties– client asks for wrong product– client is computer/software illiterate– specifications may be ambiguous, inconsistent, incomplete
• Validation– extensive specification reviews to check that requirements satisfies client needs– look for ambiguity, consistency, incompleteness– check for feasibility, testability– develop system/acceptance test plan
CSC 205 - Software Engineering I
8
Design
• Requirements Specification —> Design– develop architectural design (system structure): decompose software into
modules with module interfaces– develop detailed design (module specifications): select algorithms and data
structures– maintain record of design decisions and traeability– how the product is to do its task
• Difficulties– miscommunication between module designers– design may be inconsistent, incomplete, ambiguous
• Verification– extensive design reviews (inspections with checklists) to determine that
design conforms to requirements– check module interactions– develop integration test plan
CSC 205 - Software Engineering I
9
Implementation and Integration
• Design —> Implementation– implement modules and verify they meet their specifications– combine modules according to architectural design– how the product does its task
• Difficulties– module interaction errors– order of integration has a critical influence on product quality and
productivity
• Verification and Testing– extensive code reviews (inspections with checklists) to determine that
implementation conforms to requirements and design– develop and test on unit/module test plan: focus on individual module
functionality– test on integration test plan: focus on module interfaces– test on system test plan: focus on requirements and determine whether product
as a whole functions correctly
CSC 205 - Software Engineering I
10
Operation and Maintenance
• Operation —> Change– maintain software after (and during) user operation– integral part of process– determine whether product as a whole still functions correctly
• Difficulties– design not extensible– lack of up-to-date documentation– personnel turnover
• Verification and Testing– extensive review to determine that change is made correctly and all
documentation updated– test to determine that change is correctly implemented– test to determine that no inadvertent changes were made to compromise
system functionality (check that no affected software has regressed)
CSC 205 - Software Engineering I
11
Build-and-Fix
Build FirstVersion
Retirement
Operations Mode
Modify untilClient is satisfied
CSC 205 - Software Engineering I
12
Waterfall (collapsed) - See Schach, pg. 66
Requirements
Verify
Retirement
Operations
Test
ImplementationVerify
Design
Req. Change
CSC 205 - Software Engineering I
13
Rapid Prototyping - See Schach, pg. 71
Rapid Prototype
Verify
Retirement
Operations
Test
ImplementationVerify
Design
Req. Change
CSC 205 - Software Engineering I
14
For each build:Perform detaileddesign, implement.Test. Deliver.
Incremental - See Schach, pg. 73
Requirements
Verify
Retirement
Operations
Verify
Arch. Design
CSC 205 - Software Engineering I
15
The Spiral Model [Boehm,1988]
Concept of Operation
Requirements Plan
Requirements OAC
Risk Assessment
Risk Ite
m Set
Risk Managem
ent Plan
Requirements
Risk Control
Requirements Validation
Abstract Specification Plan
Abstract Specifcation OAC
Risk Assessment
Risk Control
Abstract Specification
Abstract Specification Validation
Concrete Specification Plan
Concrete Specification OAC
Concrete Specification
Concrete Specification Validation and Verification
Software Development Plan
Risk Assessment
Risk Control
Progress through steps
Cumulative cost
Evaluate alternatives, identify, resolve risks
Develop, verify next-level product
Plan next phases
CommitReviewpartition
Determine objectives, alternatives, constraints (OAC)
CSC 205 - Software Engineering I
16
(Extremely) Simplified Spiral Model
Requirements
Verify
Retirement
Operations
Test
ImplementationVerify
Design
Req. Change
Add a Risk Analysisstep to each phase!
Risk Assessment
Risk Assessment
Risk Assessment
CSC 205 - Software Engineering I
17
• CMM is not a software lifecycle model ...• but a strategy for improving the software process
regardless of the process model followed– Basic premise: the use of new software methods alone will
not improve productivity and quality, because software management is, in part, the cause of problems
– CMM assists organizations in providing the infrastructure required for achieving a disciplined and mature process
• Includes– technical aspects of software production– managerial aspects of software production
Capability Maturity Model (CMM) [Watts Humphrey,1989]
CSC 205 - Software Engineering I
18
Capability Maturity Model (continued)• Five maturity levels
– 1. initial – ad hoc process– 2. repeatable process – basic project management– 3. defined process – process modeling and definition– 4. managed process – process measurement– 5. optimizing process – process control and dynamic
improvement• to move from one stage to the next, the SEI
provides a series of questionnaires and conducts process assessments that highlight current shortcomings
CSC 205 - Software Engineering I
19
ISO 9000
• Further attempt to improve software quality based on International Standards Organization (ISO)
• ISO 9000 = series of five related standards – within ISO 9000 standard series ISO 9000-3 focuses on software
and software development• Basic features:
– stress on documenting the process in both words and pictures– requires management commitment to quality– requires intensive training of workers– emphasizes measurement
• Adopted by over 60 countries (USA, Japan, European Union, ...)• To be ISO 9000 compliant, a company’s process must be
certified
CSC 205 - Software Engineering I
20
Software Methods and Tools
• Methods provide a means or procedure for accomplishing a task
• Tools are devices for performing some task– analytical tools– software tools
• Methodology guides the proper use of methods and tools
• Process helps to enact a methodology• Environments are a synergistic collection of
tools with process support
CSC 205 - Software Engineering I
21
Analytical Tools
• Problem solving techniques that help in software development– cost-benefit analysis
¤ compare expected benefits against estimated costs– stepwise refinement
¤ divide and conquer– abstraction
¤ focus on some important property and ignore (for the time being) irrelevant details
• Analytical tools underlie many software development methods
CSC 205 - Software Engineering I
22
Software Tools
• Software tools are an automated implement for performing a task
• Tools facilitate work because they are– fast, immune to boredom and "cheating"
• Actual Software Tools are ...– powerful, effective, convenient, natural, reliable,
robust– Most software development tools are not
¤ exceptions: compilers, editors, loaders• these have been polished, refined, and debugged through long-
term use and hence made reliable and robust • these have been made natural and effective through extended
exposure and maintenance
CSC 205 - Software Engineering I
23
Tool Obstacles
• Tool use obstacles– developers tend to be like hammer and screwdriver carpenters– tools are not powerful and/or effective– tools are unreliable and/or unrobust
¤ comes with time and money– tools are inconvenient and/or unnatural
¤ comes from successful use
• Tool building obstacles– Short history of large-scale software development– Limited success in
¤ developing software well¤ exploiting “tools” successfully
– Few software techniques have had time and use required to achieve tool status
– No “tools” at all in some key areas (e.g., real-time analysis)
CSC 205 - Software Engineering I
24
Requirements Preview
• Requirements determine the “What” of a software product’s functionality.
• Requirements analysis and specification transforms– informal product definitioninto– formal requirements specification
• A step in between is transforming the product definition into a natural language statement of the system’s functionality