INF3705 SUMMARISED
NOTES 2022/20223
INF305
Yellow = answered textbook questions Blue = unanswered questions
Chapter 3 – Process Models
Prescriptive process models prescribe a set of process elements:
Framework activities, tasks, work products, quality assurance…
Generic framework act...
Chapter 3 – Process Models
Prescriptive process models prescribe a set of process elements:
Framework activities, tasks, work products, quality assurance…
Generic framework activities:
Communication Planning Modeling Construction Deployment
Linear process model:
1. Waterfall model (Classic life cycle)
Systematic, linear, sequential approach
For projects with these characteristics:
o The problem is well understood (well-defined requirements)
o The delivery date is realistic
o Major changes in requirements are unlikely
For when work flows in a reasonably linear fashion
The linear nature can lead to ‘blocking states’, where you have
to wait for other team members to complete dependent tasks
Inappropriate model for today’s fast-paced changing software
Problems:
o Real projects rarely follow a sequential flow
o The customer has to state all requirements explicitly
o Working version of the program appears late in the project
Software projects that would be amenable to the waterfall model:
o A well-understood modification to an existing program
o A straightforward implementation of a numerical calculation
or business rule, even if it is complex
o A constrained enhancement to an existing program
Incremental process models:
For when requirements are well-defined, and a limited set of software
functionality must be provided quickly, and then refined later.
2. Incremental model
Combines elements of the waterfall model applied iteratively
Linear sequences each produce deliverable increments of software
The first increment is usually a core product, used by customers
Each increment focuses on the delivery of an operational product
Good when staffing is unavailable for a complete implementation
Increments can be planned to manage technical risks
Software projects amenable to the incremental model:
o A project that has significant functionality that must be
delivered in a very tight time frame (Add on extras later)
1
,3. RAD model
An incremental model that emphasizes a short development cycle
A high-speed adaptation of the waterfall model, where rapid
development is achieved by using component-based construction
For when requirements are understood and scope is constrained
For when business applications can be modularized
A fully functional system is constructed in a very short time
Each major function is addressed by a separate RAD team and then
integrated to form a whole
To achieve rapid development, this model assumes the existence
of: a project that can be modularized in a manner that allows
major functionality to be delivered within 60-90 days (This
isn’t always the case – sometimes timelines can be longer)
Drawbacks:
For large projects, RAD requires sufficient human resources to
develop the increments in parallel
Projects will fail if people don’t commit to rapid activities
If a system can’t be modularized, you can’t build components
Might not work if high performance is an issue
Might not be appropriate when technical risks are high
Evolutionary process models:
For when core requirements are well understood and a limited version
of the product must be introduced, which will evolve over time.
Iterative, and can easily accommodate product requirement changes.
4. Prototyping
For when the customer defines a set of general objectives
For when the developer is unsure of the form of the software
Can be used as a standalone process model, but is more commonly
used as a technique that can be implemented within other models
The prototype helps to identify software requirements
It should be discarded (at least in part)
Problems with prototyping:
o The customer sees a working version and wants to keep it
o Developers may become comfortable with inefficient choices
Software projects amenable to the prototyping model:
o Ones which involve human-machine interaction and/or heavy
computer graphics
o Ones where results can easily be examined without real-time
interaction (e.g. command-driven systems using mathematical
algorithms) i.e. not embedded software!
Process adaptations required if the prototype will evolve into a
deliverable system / product:
o More rigorous design rules and SQA procedures must be
applied from the beginning
2
, o The prototype must be designed with extensibility in mind
and be implemented using a programming environment that is
amenable to production system development
o The prototype is initially a mechanism for identifying
requirements, and then becomes the framework for extensions
that will cause it to evolve into a production system
5. Spiral model
Combines the iterative nature of prototyping with the controlled
and systematic aspects of the waterfall model
Rapid development of increasingly complete versions of software
Software is developed in a series of evolutionary releases
Each framework activity represents 1 segment of the spiral path
Risk-driven model: risk evaluation during each iteration
Anchor point milestones are noted for each evolutionary pass
This model can apply throughout the life of the software
Good for developing large-scale systems and software
Not good if you have a fixed budget, because project cost is
revised as each circuit is completed
Prototyping reduces risks, and can be applied at any stage
Problems:
o May be hard to convince customers that it’s controllable
o Demands considerable risk assessment and expertise
o Problems if a major risk is not uncovered and managed
What happens to the software as you move outwards along the
spiral process flow:
o The product moves towards a more complete state
o The level of abstraction at which work is performed is
reduced (i.e. implementation-specific work accelerates as
we move further from the origin)
6. Concurrent development model
Represented as a series of framework activities, software
engineering actions & tasks, and their associated states
All activities exist concurrently but reside in different states
What the states represent and how they come into play:
o The different parts of a project (framework activities)
will be at different stages of completeness (e.g. ‘under
development’, ‘awaiting changes’, ‘done’), so you can say
that all activities are being performed concurrently
o The challenge is to manage the concurrency and to be able
to assess the status of the project
A series of events are defined that will trigger transitions
from state to state for each of the software activities / tasks
This model is applicable to all types of software development
Often used for the development of client/server applications
Provides an accurate picture of the current state of the project
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 Tutor23. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy this summary for R54,34. You're not tied to anything after your purchase.
