Summary
Samenvatting Systeemontwikkelingsmethoden (INFOBSOM)
- Course
- Institution
Stof voor midterm van SOM
[Show more]
Seller
Follow
IsabelleU
Reviews received
Content preview
SOM SVIsabelle van Aard
102 – Programming tools .
➢ When designing software, you use programming language features that help you structure
code. Python → functions, classes and modules
➢ Function (def)
o Groups related code and provides a generic interface to that code via parameters
and return values
➢ Module (import)
o Groups functions and constants that are useful in other parts of an application.
▪ The math module is a collection of mathematical constants and functions
➢ Class
o Groups functions and data that belong together
➢ Inheritance
o Class inheritance allows you to indicate that certain types are related and should
behave the same.
▪ Bv rectangle and circle are both shapes of which you can compute an area
➢ A class should act purely as a contract of how [shapes] are implemented, not as an actual
representation of a shape.
➢ Abstract base classes
o Most OO languages have a concept abstract class to cover this case. Abstract classes
are the same as regular classes, but you can’t make instances of them.
o They serve as an interface. You can specify the structure of your code without
having to actually implement it. → shape defines what the area method looks like,
but there is no implementation yet.
103 – Development processes (Waterfall and RUP)
➢ Waterfall model
1. Requirements analysis
2. Design
3. Coding and debugging
4. Testing and verification
5. Maintenance
➢ Criticism on waterfall model
o Waterfall model aims to complete every phase before moving on to the next
o Critics: model is not robust against change
▪ Client can change mind halfway through project
▪ Money can run out
▪ Design can turn out to be too costly or complex to implement
➢ Alternatives to waterfall model:
o The (Rational) Unified Process (RUP)
o Extreme Programming
o Scrum
o Kanban
o Do whatever
1
,➢ The (Rational) Unified Process
o Popular development process for many years
o Components of RUP can be adapted to work with other methodologies such as Agile
→ nice foundation
o Emphasizes iterative software development. Develop software in time-boxed mini-
projects called iterations. Each iteration has clearly defined milestones, including a
tested, integrated, executable system
o The iterative lifecycle is based on the successive enlargement and refinement of a
system through multiple iterations with feedback and adaptation. The system grows
incrementally over time, iteration by iteration. The system may take many iterations
to be production ready
o The output of an iteration is not (just) an experimental prototype but a production
subset of the final system. Each iteration tackles new requirements and
incrementally extends the system. An iteration may occasionally revisit existing
software and improve it.
o Stakeholders usually have changing requirements (end users, project management).
Each iteration involves choosing a small subset of the requirements and quickly
design, implement and test them → rapid feedback + opportunity to modify or
adapt understanding of the requirements or design
o 4 phases, split into multiple iterations
▪ Inception → define the scope of the project
▪ Elaboration → plan the project, specify features, baseline architecture
▪ Construction → finish the construction
▪ Transition → hand over the project to end users
o Each phase overlaps with some elements of the waterfall model, but the balance
between them shifts as time passes
o UP best practices
▪ Develop software iteratively and involve users early
▪ Manage requirements
▪ Visually model software (UML)
▪ Verify software quality → test, code reviews, release in every iteration
▪ Embrace change
➢ Inception
o Envision the product scope, vision and business case. Upon completion, the
stakeholders have a basic agreement on the vision of the project and are able to
decide to continue or not. Duration: few weeks
o Artifacts
▪ Vision document – general vision of project, key features and constraints
▪ Initial list of use-cases – interaction with end users
▪ Initial project glossary – domain-specific lingo
▪ Initial business case – how will we make money
▪ Initial risk assessment – what might go wrong
▪ Project plan, showing phases and iterations – how will we move forward
▪ >1 prototype experiments
o Not about deciding how many weeks feature X will take to implement. You need
ballpark estimate (1 month or 1 year)
o Idea of which people will end up using the system => few carefully thought out use
cases, but not every possibility
2
, o Not about which GUI library to use but about if it will run on tablets, phones or in
the cloud
o Very hard to identify where the risks lie in any project. Bv changing limit on credit
card
➢ Elaboration
o Goals
▪ Analyze the problem domain, establish architectural foundation, develop
project plan and eliminate highest risks
▪ Mile high and inch deep view of the system
▪ Make architectural decisions
▪ Build executable architecture prototype, thereby eliminating critical risk, for
the central use cases developed in the inception phase.
▪ Start building prototype early, even is requirements not been finalized.
o Artifacts
▪ Use-case model
▪ Supplementary requirements capturing the non-functional requirements
▪ Software architecture description → includes organization and structure of
the major elements of the system; why the system is designed the way it is
▪ Revised risk list and revised business case
▪ A development plan for the overall project, including the coarse-grained
project plan, showing iterations and evaluation criteria for each iteration
o Results
▪ A stable vision of the software system and its architecture
▪ Minimized the risks that could cause the project to fail if you choose to
continue
▪ Better estimates for project costs and planning
➢ Construction
o Goal: develop and test a baseline product
o Upon completion, there should be a clear description of the product status and user
manuals. Tool should be ready to be deployed, even if not all features are fully
implemented
➢ Transition
o Deliver the first version of the software to
its users (beta testing, training users)
o Involves a lot of tuning, etc
o Goals
▪ Enabling users to use your
product
▪ Achieving consensus with all
stakeholders that the baseline
product is complete
▪ Iteratively refining the baseline
until the final product is implemented
➢ Activities
o UP: 6 distinct kinds of ‘engineering activity’
1. Business modeling → document existing business processes to establish a
common understanding between various stakeholders about how the
organization works
3
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 EFT, 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 this summary from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller IsabelleU. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy this summary for R130,20. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
73091 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy summaries for 14 years now