This is a handy overview and summary of the mid-term material in the lectures and knowledge clips of the subject 'System Design Methods'. It got me to a 8.3 as grade, and I hope it will help you just as much. I wrote it in a way that this difficult stuff is easy to understand.
Good luck! :-)
• 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.
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, creditcard of Stuvia-tegoed voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper semstroop. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €3,99. Je zit daarna nergens aan vast.
