76.3601 introduction to software engineeringt–76.3601 — introduction to software engineering ......
TRANSCRIPT
AB HELSINKI UNIVERSITY OF TECHNOLOGY
T–76.3601 — Introduction to Software Engineering
http://www.soberit.hut.fi/T-76.3601/
Casper [email protected]
Software Life-Cycle Models
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Software Engineering?
1. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software
2. The study of approaches in (1).IEEE Computer Society
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Software Process?• Process
• Webster: 1. A continuing development involving many changes. 2. A particular method for doing something, usually involving a number of steps or operations.
• IEEE: A sequence of steps performed for a given purpose.
• Software Process
• CMM(I): a set of activities, methods, practices and transformations that people use to develop and maintain software and the associated products
• Simply: the way an organization/team/individual develops software
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Leavitt’s Organizational Diamond
Structure, Culture, Management,
Decision making
Tools, Methods, Facilities, Environment
PracticesProceduresInstructions
KnowledgeSkills, Needs,Motivation
Structure
Technology
Process People
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Knowledge,Skills, Needs,Motivation
Tools, Methods, Facilities,
Environment
Practices,Procedures,Instructions
Structure,Culture,Management,
Decision making
Structure
Technology
Process People
Adapted from Leavitt, H.J. Applied organizational change in industry: Structural, technological and humanistic approaches. Handbook of Organizational. J.G. March. Chicago, Rand McNally. 1965
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The Sandbox
Requirements managementDocumentation
Quality Control (V & V)Configuration Management
Specifi-cation
Defi-nition
Imple-men-tation
Testing
Instal-lation,
Mainte-nance
Project Management
Program management
Process management (Quality System)
Business ManagementCMM
RUP
USDP
Time Boxing
SPICE
CMM
UML
Z
SA/SD
eXtreme Programming
CleanRoom
Object Orientation
Basic activities
Support activities
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Process: Adaptability• the framework activities will always be applied on
every project ... BUT
• the tasks and degree of rigor for each activity will vary based upon many factors, e.g.:
• the type project
• project characteristics
• team characteristics
• common sense judgement
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Prescriptive Models• Prescriptive process models advocate an orderly approach
to software engineering
• That leads to a few questions...
• If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?
• Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper LasseniusAB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Problems
• No speci!cations
• No design
• Totally unsatisfactory
• Need life"cycle model
• #Game plan$
• Phases
• Milestones
• Problems
• lack of visibility
• easily leads to poorly structured systems
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.
Build and Fix Model• Problems
• No specifications
• No design
• Lack of visibility
• Easily leads to poorly structured systems
• Totally unsatisfactory
• Need life-cycle model
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Problems
• No speci!cations
• No design
• Totally unsatisfactory
• Need life"cycle model
• #Game plan$
• Phases
• Milestones
• Problems
• lack of visibility
• easily leads to poorly structured systems
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Waterfall Model
• Planning and control
• Documentation-driven
• “Doing the homework”
• Formal change management
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Problems
• No speci!cations
• No design
• Totally unsatisfactory
• Need life"cycle model
• #Game plan$
• Phases
• Milestones
• Problems
• lack of visibility
• easily leads to poorly structured systems
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Characterized by
• Feedback loops
• Documentation!driven
• "Doing the homework"
• Planning and control
• Advantages
• Documentation
• Maintenance easier
• Disadvantages
• In#exible partitioning
• Speci$cation changes expensive
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The Waterfall Model• Strengths
• Easily manageable process (manager’s favourite?)
• Probably the most effective model, if you know the requirements
• Extensive documentation
• Weaknesses
• Inflexible partitioning of the project into distinct phases
• Difficult to respond to changing customer requirements
• Feedback on system performance available very late and changes can be very expensive
• Applicability
• Appropriate when the requirements are well understood
• Short, clearly definable projects (e.g. maintenance)
• Very large, complex system development that requires extensive documentation. Safety critical systems.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Cost to Detect and Correct a Fault
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Rapid Prototyping Model
• Linear
• “Rapid”
• Exploratory vs. throw-away prototypes
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Problems
• No speci!cations
• No design
• Totally unsatisfactory
• Need life"cycle model
• #Game plan$
• Phases
• Milestones
• Problems
• lack of visibility
• easily leads to poorly structured systems
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Incremental Model
• Divide project into builds
• Each build adds functionality
• Prioritized user requirements
• Requirements frozen during each build!
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Problems
• No speci!cations
• No design
• Totally unsatisfactory
• Need life"cycle model
• #Game plan$
• Phases
• Milestones
• Problems
• lack of visibility
• easily leads to poorly structured systems
Picture from Schach: Classical and Object-Oriented Software Engineering, 5th ed.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Incremental Model• The concept of growing a system via iterations: iterative and incremental
development (IID)
• Divide the project into increments
• Each increment adds functionality
• Each iteration is a self-contained mini project composed of activities such as requirements analysis, design, programming and test
• At the end of the iteration an iteration release: a stable, integrated and tested partially complete system
• Most releases internal, final iteration release is the complete product
• Prioritize user requirements
• MOSCOW priorities: must, should, could, want
• High-priority requirements into early increments
• Freeze requirements during each increment
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Incremental Development Advantages• Customer value can be delivered at the end of each increment making
system functionality available earlier
• Final product better matches true customer needs
• Early increments act as a prototype to help
• elicit requirements for later increments
• get feedback on system performance
• Lower risk of overall project failure
• Smaller sub-projects are easier to control and manage
• A meaningful progress indicator: tested software
• The highest priority features tend to receive the most testing
• Job satisfaction is increased for developers who can see early results of their work
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Incremental Development Disadvantages
• Can be harder to plan and control than waterfall development
• Can be more expensive than waterfall development
• May require more experienced staff
• System architecture must be adaptive to change
• Software project contracts are still mostly drawn up according to the waterfall model and all changes cause renegotiations
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Synchronize-and-Stabilize Model
• Microsoft’s life-cycle model
• Requirements analysis—interview potential customers
• Draw up specifications
• Divide project into 3 or 4 builds
• Each build is carried out by small teams working in parallel
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Synch-and-Stabilize
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Product vision
Functional specification
Development
subcycleDevelopment
subcycle
Development
subcycle
Buffer time Buffer time Buffer time
Alpha release Beta release Feature
complete
Beta release
UI freeze
Code complete
• Final test
• Final debug
• StabilizeFinal release
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Sync-and-Stabilize
• At the end of the day—synchronize (test and debug)
• At the end of the build—stabilize (freeze build)
• Components always work together
• Get early insights into operation of product
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Spiral Model
• Radial dimension: cumulative cost to date
• Angular dimension: progress through the spiral
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
• Radial dimension: cumulative cost to date
• Angular dimension: progress through the spiral
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The Spiral Model• A meta-model -> other models can be derived
• Risk management is central
• Problems
• Hard to match to contract software
• Not enough flexibility and freedom in contract mechanisms
• Great deal of reliance on risk-assessment expertise
• Applicability
• Internal software development
• A framework for risk-driven application of other models
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Still Other Process Models• Component based development—the process to
apply when reuse is a development objective
• Formal methods—emphasizes the mathematical specification of requirements
• AOSD—provides a process and methodological approach for defining, specifying, designing and constructing aspects
• Unified process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Rational Unified Process (RUP)
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
UP Work Products
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
21
Inception phase
Elaboration phase
Construction phase
Transition phase
Vision document
Initial use-case model
Initial project glossaryInitial business case
Initial risk assessment.
Project plan, phases and iterations.
Business model, if necessary.
One or more prototypesInception
Use-case model
Supplementary requirements including non-functional
Analysis modelSoftware architecture
Description.
Executable architectural prototype.
Preliminary design model
Revised risk listProject plan including
iteration plan
adapted workflows milestones
technical work products
Preliminary user manual
Design model
Software components
Integrated software increment
Test plan and procedure
Test casesSupport documentation
user manuals
installation manuals description of current
increment
Delivered software increment
Beta test reportsGeneral user feedback
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach. 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005.
AB HELSINKI UNIVERSITY OF TECHNOLOGY
Questions?