Development Process: Unified Process
Traditionally, the waterfall model aims to complete every phase before moving on to the next. This isn’t great when for
example the requirements change later on. The WF model has got five phases:
1. Requirements analysis
2. Design
3. Coding and debugging
4. Testing and verification
5. Maintenance
This course will focus on the Unified Process (UP): develop software in time-boxed mini-projects called iterations. The
output of an iteration is not just a prototype but a production subset of the final product, and each iteration tackles some of
the requirements.
UP defines four different phases, each split into multiple iterations:
1. Inception: Define the scope of the project
2. Elaboration: Plan the project, specify features, baseline architecture
3. Construction: Finish the construction
4. Transition: Hand over the project to end users
Furthermore, UP identifies six distinct kinds of ‘engineering activity’:
1. Business modelling
2. Requirement engineering
3. Analysis & Design
4. Implementation
5. Test
S. Deployment
and thee kinds of ‘supporting’ activity:
Project Management workflow
Configuration and Change Management
Environment: development kit, tools for building and process control
Iterations
Iteration 1: Inception
Envision the product scope, vision and business case. Upon completion, the stakeholders have a based agreement on the
vision of the project and are able to decide whether or not to continue. (Should take up to a few weeks.)
Has to deliver:
, a vision document
initial list of use-cases
initial project glossary (what is some of the domain specific lingo)
initial business case (how to make money)
initial risk assessment (what might go wrong)
project plan phases and iterations
one or several prototype experiments
It should provide a general overview of time, costs, possibilities etc., an idea of the target audience, and a few brief but
carefully thought out use cases.
Iteration 2: Elaboration
Time to make Software Architecture Description, which includes the system behavior, especially in terms of large scale
responsibilities of systems and subsystems (and their collaborations). Regarding a description, the architecture includes
the motivations for why the system is designed that way.
Has to deliver:
use case model how users will interact with the system
supplementary requirements capturing non-functional requirements
Software Architecture Description
executable architecture prototype, thereby elimination critical risk, for the central use cases developed in the
inception
revised risk list and revised business case
development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation
criteria for each of them
Iteration 3: Construction
Mainly to develop and test a baseline product. Upon completion, there should be a clear description of the product along
with user manuals. The tool should be ready to be deployed, regardless of all features being fully implemented.
Iteration 4: Transition
Aims to deliver the first version of the software to its users.
This process usually involves a lot of tuning, bug-fixing, processing enhancement request and implementing unfinished
features.
Following: Iteratively refining the baseline until the final product is implemented.
, Requirement Engineering
Aims to describe what the system should do, allowing customers and developers to agree on that description.
Requirements are a contract for the minimal functionality that you can promise to deliver.
Requirement Engineering is a cyclic process:
Elicitation
Talk to clients and end-users (many customers have little technical skills or don’t even know what they want
themselves, so ask and brainstorm cleverly);
Gather existing documentation;
Observe how future users work now.
Specification
e.g. use cases and scenarios
Validation and verification
Negotiation
Types of requirements: FURPS+ model
Functional: features, capabilities
Usability: help, documentation
Reliability: frequency of failure, uptime, recoverability
Performance: response time, accuracy, throughput
Supportability: adaptability, maintainability
but also sub-factors like implementation, legal and interface appear.
What makes a good set of requirements?
Correctness: it accurately captures the client’s views
Consistency: it does not contradict other requirements
Completeness: all possible scenarios are accounted for
Clarity: unambiguously formulated
Realism: it can be implemented and delivered
Verifiability: it can be (automatically) tested
(Alternatively: SMART, which means: Specific, Measurable, Attainable, Realistic, Time-bound)
Scenarios and use cases
These document the system’s behavior from the users point of view, in a way that customers can understand what the
system does.
A scenario is a narrative description of what people do and experience as they try to make use of computer systems and
applications.
Traditionally, the waterfall model aims to complete every phase before moving on to the next. This isn’t great when for
example the requirements change later on. The WF model has got five phases:
1. Requirements analysis
2. Design
3. Coding and debugging
4. Testing and verification
5. Maintenance
This course will focus on the Unified Process (UP): develop software in time-boxed mini-projects called iterations. The
output of an iteration is not just a prototype but a production subset of the final product, and each iteration tackles some of
the requirements.
UP defines four different phases, each split into multiple iterations:
1. Inception: Define the scope of the project
2. Elaboration: Plan the project, specify features, baseline architecture
3. Construction: Finish the construction
4. Transition: Hand over the project to end users
Furthermore, UP identifies six distinct kinds of ‘engineering activity’:
1. Business modelling
2. Requirement engineering
3. Analysis & Design
4. Implementation
5. Test
S. Deployment
and thee kinds of ‘supporting’ activity:
Project Management workflow
Configuration and Change Management
Environment: development kit, tools for building and process control
Iterations
Iteration 1: Inception
Envision the product scope, vision and business case. Upon completion, the stakeholders have a based agreement on the
vision of the project and are able to decide whether or not to continue. (Should take up to a few weeks.)
Has to deliver:
, a vision document
initial list of use-cases
initial project glossary (what is some of the domain specific lingo)
initial business case (how to make money)
initial risk assessment (what might go wrong)
project plan phases and iterations
one or several prototype experiments
It should provide a general overview of time, costs, possibilities etc., an idea of the target audience, and a few brief but
carefully thought out use cases.
Iteration 2: Elaboration
Time to make Software Architecture Description, which includes the system behavior, especially in terms of large scale
responsibilities of systems and subsystems (and their collaborations). Regarding a description, the architecture includes
the motivations for why the system is designed that way.
Has to deliver:
use case model how users will interact with the system
supplementary requirements capturing non-functional requirements
Software Architecture Description
executable architecture prototype, thereby elimination critical risk, for the central use cases developed in the
inception
revised risk list and revised business case
development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation
criteria for each of them
Iteration 3: Construction
Mainly to develop and test a baseline product. Upon completion, there should be a clear description of the product along
with user manuals. The tool should be ready to be deployed, regardless of all features being fully implemented.
Iteration 4: Transition
Aims to deliver the first version of the software to its users.
This process usually involves a lot of tuning, bug-fixing, processing enhancement request and implementing unfinished
features.
Following: Iteratively refining the baseline until the final product is implemented.
, Requirement Engineering
Aims to describe what the system should do, allowing customers and developers to agree on that description.
Requirements are a contract for the minimal functionality that you can promise to deliver.
Requirement Engineering is a cyclic process:
Elicitation
Talk to clients and end-users (many customers have little technical skills or don’t even know what they want
themselves, so ask and brainstorm cleverly);
Gather existing documentation;
Observe how future users work now.
Specification
e.g. use cases and scenarios
Validation and verification
Negotiation
Types of requirements: FURPS+ model
Functional: features, capabilities
Usability: help, documentation
Reliability: frequency of failure, uptime, recoverability
Performance: response time, accuracy, throughput
Supportability: adaptability, maintainability
but also sub-factors like implementation, legal and interface appear.
What makes a good set of requirements?
Correctness: it accurately captures the client’s views
Consistency: it does not contradict other requirements
Completeness: all possible scenarios are accounted for
Clarity: unambiguously formulated
Realism: it can be implemented and delivered
Verifiability: it can be (automatically) tested
(Alternatively: SMART, which means: Specific, Measurable, Attainable, Realistic, Time-bound)
Scenarios and use cases
These document the system’s behavior from the users point of view, in a way that customers can understand what the
system does.
A scenario is a narrative description of what people do and experience as they try to make use of computer systems and
applications.
