76.3601 introduction to software engineering...software engineering? 1. the application of a...
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?
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.
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
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
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
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
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...
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?
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
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 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
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
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
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
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
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
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
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
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
Agile Software Development
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
The Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have
come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
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.
Kent Beck et allii
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
What is “Agility”
• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed
• Yielding...
• Rapid, incremental delivery of software
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
An Agile Process
• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction activities
• Delivers multiple software increments
• Adapts as changes occur
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
From Waterfall to Agility
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Time
Specification
Design
Implementation
Test
Waterfall Iterative/Incremental XP
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Extreme Programming (XP)• The most widely used agile process, originally proposed
by Kent Beck
• XP Planning
• Begins with the creation of user stories
• Agile team assesses each story and assigns a cost
• Stories are grouped for a deliverable increment
• A commitment is made on the delivery date
• After the first increment, projct velocity is used to help define subsequent delivery dates for other increments
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
Extreme Programming (XP)
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
Extreme Programming (XP)• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards (Chapter 8)
• Difficult solutions prototyped using spike solutions
• Encourages refactoring—an iterative refinement of the internal program design
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
Extreme Programming (XP)• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards (Chapter 8)
• Difficult solutions prototyped using spike solutions
• Encourages refactoring—an iterative refinement of the internal program design
• XP Coding
• Recommends the construction of unit tests before coding commences
• Encourages pair programming
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
Extreme Programming (XP)• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards (Chapter 8)
• Difficult solutions prototyped using spike solutions
• Encourages refactoring—an iterative refinement of the internal program design
• XP Coding
• Recommends the construction of unit tests before coding commences
• Encourages pair programming
• XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and executed to assess customer visible functionality
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
Scrum• Originally proposed by Schwaber and Beedle
• Distinguishing features
• Development work partitioned into packets
• Testing and documentation on-going as the product is constructed
• Work occurs in sprints and is derived from a backlog of existing requirements
• Meetings are very short and sometimes conducted without chairs (scrums)
• Demos are delivered to the customer within the time-box allocated
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
Scrum
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Challenges and Solutions for a Flexible Process
• Challenges
• Detailed design work must be started before the product architecture is fully defined
• Buffering need
• The system must be integrated before the completion of all its modules
• Design work partitioned
• The development team must be able to respond to new information even at a late stage of the project
• Flexibility in architecture
• Solutions
• Greater investment in architectural design
• Earlier feedback on a product’s system level performance
• Development team with a grater amount of “generational” experience
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
A Flexible Process• IS
• Iterative
• Based upon rapid, frequent, intense, systematic iterations, starting early in the process and involving customers
• NEEDS
• A modular and scaleable product architecture
• An experienced team
• Early customer/user involvement
• IS NOT
• Cheaper than a traditional process
• Fire-fighting
• Unmanaged ad-hoc hacking
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Two Different Project Types
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Two Different Project Types• Functionality driven
• Example: a new operating system
• Certain functionalities must be in place
• They are well-known in advance
• The schedule is allowed to slip so that the required functionality can be developed
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Two Different Project Types• Functionality driven
• Example: a new operating system
• Certain functionalities must be in place
• They are well-known in advance
• The schedule is allowed to slip so that the required functionality can be developed
• Schedule driven
• Example: consecutive releases of a word processor
• Release deadline set and fixed
• Product released on schedule
• Final configuration of features unknown until late in the project
• Features must be prioritized for this to work
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Two Different Project Types• Functionality driven
• Example: a new operating system
• Certain functionalities must be in place
• They are well-known in advance
• The schedule is allowed to slip so that the required functionality can be developed
• Schedule driven
• Example: consecutive releases of a word processor
• Release deadline set and fixed
• Product released on schedule
• Final configuration of features unknown until late in the project
• Features must be prioritized for this to work
A one-size process d
oes not fit all!
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Process Choice• There is not uniformally applicable process which is
applicable to any type and size of project
• High costs may occur if you force an inappropriate process on a development team
• However, one organization cannot have a vast number of different processes in use
• Sometimes you don’t have a possibility to choose
• A chosen process model can be tailored to suit the project
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Process Choice• For large systems, management is usually the principal
problem, so you need a strictly managed process
• For smaller systems, more informality is possible
• Hybrid models:
• Large systems are usually made up of several sub-systems
• The same process model need not be used for all subsystems
• Prototyping or agile development for high-risk specifications
• Waterfall model for well-understood developments
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Dimensions Affecting Process Model SelectionDimensions Affecting Process Model
Selection (Boehm & Turner 2003)
AB HELSINKI UNIVERSITY OF TECHNOLOGY Casper Lassenius
Plan-driven vs. Agile• Neither plan-driven nor agile methods provide a silver
bullet
• Both have home grounds where one clearly dominates the other
• Both agility and disciplines are critical
• Increasingly rapid pace of change
• E.g., larger projects using agile methods need plan-driven process aspects to be integrated to be successful
• Build your method up—don’t tailor it down
AB HELSINKI UNIVERSITY OF TECHNOLOGY
Questions?