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 7.9 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.
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller semstroop. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $4.27. You're not tied to anything after your purchase.
