SOM SV
Isabelle 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
Isabelle 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
