SYSTEM DESIGN METHODS
The unified process
Waterfall model (often used in traditional engineering areas)
Waterfall model: requirements analysis → design → coding & debugging → testing & verification →
maintenance. Criticism:
• The model is not robust against change (a client can change his/her mind halfway through
the project / the money can run out / a design can turn out to be too costly or complex)
• Many of the system’s details only become known to us as we progress in the
implementation. Some of the things we learn invalidate our design and we must backtrack.
Unified process
(Rational) Unified process / (R)UP: Software is developed in time-boxed mini projects called
iterations. It can be adapted to work with other (agile) methodologies. Each iteration:
❖ Has clearly defined milestones
❖ Has an output that is not just an experimental prototype, but a subset of the final system
(should result in a complete and executable system that will be integrated into the whole)
❖ Tackles new requirements
❖ May occasionally revisit existing software and improve it
❖ Is either deep and narrow, or broad and shallow
❖ Leads to rapid feedback, and an opportunity to modify/adapt the design
The unified process has 4 phases. Each phase overlaps with some elements of the waterfall model,
and each phase splits into multiple iterations. The phases do not overlap with each other; only the
activities of these phases overlap. The phases are:
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
The best practices of the unified process are:
➔ Develop software iteratively | involve users early | manage requirements | visually model
software with UML | verify software quality (test, release the code in every iteration, code
reviews) | embrace change
Inception
Inception: emphasis is on business modeling and requirements
Goals:
- Envision the product scope, vision, and business case (including a costs estimate)
- Upon completion, the stakeholders have a basic agreement on the vision of the project and
are able to decide whether to continue or not
, - It typically only lasts a few weeks
Inception artifacts:
Vision document; what is the general vision of the project and what are the key features and
constraints?
List of use-cases; how will end-users interact with the system?
Project glossary; what is some of the domain-specific lingo?
Business case; how will we make money? + rough estimate of the costs
Risk assessment; what might go wrong?
Project plan (showing phases and iterations); HOW will we move forward? → how, not what
Inception is not about:
➢ Deciding how many weeks ‘feature X’ will take to implement. You need a rough estimate: 1
month or 1 year? 10K or 1M? [rough estimates]
➢ Identifying every possible interaction that every imaginable user can have with your system.
You want to have an idea of which people will end up using the system and should have a
few carefully thought out use cases.
➢ Choosing the color of the icon or which operating system to support. You want to think
about whether it will run on tablets, mobile phones, desktops, or in the cloud. [no details].
Risks = everything that can lead a project to run over budget, over time, have bad quality, or become
a failure. It can be hard to identify where the risks lie in any project.
Elaboration
Elaboration: the scope becomes a set of requirements, and you’ll have a detailed budget estimate
Goals:
- Develop a ‘mile high and inch deep’ view of the system and problem domain
- Make architectural decisions (about structure of the system, and about what the impact is of
the decisions that we make)
- Make an executable architecture prototype, thereby eliminating critical risk for the central
use cases developed in the inception phase
- Start building a prototype early, even if the requirements are not complete
Artifacts:
Use-case model – describes how users will interact with the system (main approach with
UML to describe user requirements)
Supplementary requirements – capturing the non-functional requirements, e.g. making sure
that the system is online 99% of the time, or the system should work flawlessly when used by
10.000 students at the same time
Software architecture description – the organization and structure of the major elements of
the system, how these are related, what they do and what they are responsible for. It’s also
about making the right decisions to meet the requirements and assignment of work to parts
of the team. In terms of a description, it includes the motivation or rationale for why the
system is designed the way it is.
The unified process
Waterfall model (often used in traditional engineering areas)
Waterfall model: requirements analysis → design → coding & debugging → testing & verification →
maintenance. Criticism:
• The model is not robust against change (a client can change his/her mind halfway through
the project / the money can run out / a design can turn out to be too costly or complex)
• Many of the system’s details only become known to us as we progress in the
implementation. Some of the things we learn invalidate our design and we must backtrack.
Unified process
(Rational) Unified process / (R)UP: Software is developed in time-boxed mini projects called
iterations. It can be adapted to work with other (agile) methodologies. Each iteration:
❖ Has clearly defined milestones
❖ Has an output that is not just an experimental prototype, but a subset of the final system
(should result in a complete and executable system that will be integrated into the whole)
❖ Tackles new requirements
❖ May occasionally revisit existing software and improve it
❖ Is either deep and narrow, or broad and shallow
❖ Leads to rapid feedback, and an opportunity to modify/adapt the design
The unified process has 4 phases. Each phase overlaps with some elements of the waterfall model,
and each phase splits into multiple iterations. The phases do not overlap with each other; only the
activities of these phases overlap. The phases are:
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
The best practices of the unified process are:
➔ Develop software iteratively | involve users early | manage requirements | visually model
software with UML | verify software quality (test, release the code in every iteration, code
reviews) | embrace change
Inception
Inception: emphasis is on business modeling and requirements
Goals:
- Envision the product scope, vision, and business case (including a costs estimate)
- Upon completion, the stakeholders have a basic agreement on the vision of the project and
are able to decide whether to continue or not
, - It typically only lasts a few weeks
Inception artifacts:
Vision document; what is the general vision of the project and what are the key features and
constraints?
List of use-cases; how will end-users interact with the system?
Project glossary; what is some of the domain-specific lingo?
Business case; how will we make money? + rough estimate of the costs
Risk assessment; what might go wrong?
Project plan (showing phases and iterations); HOW will we move forward? → how, not what
Inception is not about:
➢ Deciding how many weeks ‘feature X’ will take to implement. You need a rough estimate: 1
month or 1 year? 10K or 1M? [rough estimates]
➢ Identifying every possible interaction that every imaginable user can have with your system.
You want to have an idea of which people will end up using the system and should have a
few carefully thought out use cases.
➢ Choosing the color of the icon or which operating system to support. You want to think
about whether it will run on tablets, mobile phones, desktops, or in the cloud. [no details].
Risks = everything that can lead a project to run over budget, over time, have bad quality, or become
a failure. It can be hard to identify where the risks lie in any project.
Elaboration
Elaboration: the scope becomes a set of requirements, and you’ll have a detailed budget estimate
Goals:
- Develop a ‘mile high and inch deep’ view of the system and problem domain
- Make architectural decisions (about structure of the system, and about what the impact is of
the decisions that we make)
- Make an executable architecture prototype, thereby eliminating critical risk for the central
use cases developed in the inception phase
- Start building a prototype early, even if the requirements are not complete
Artifacts:
Use-case model – describes how users will interact with the system (main approach with
UML to describe user requirements)
Supplementary requirements – capturing the non-functional requirements, e.g. making sure
that the system is online 99% of the time, or the system should work flawlessly when used by
10.000 students at the same time
Software architecture description – the organization and structure of the major elements of
the system, how these are related, what they do and what they are responsible for. It’s also
about making the right decisions to meet the requirements and assignment of work to parts
of the team. In terms of a description, it includes the motivation or rationale for why the
system is designed the way it is.
