INF3705 SUMMARISED
NOTES 2022/2023
,CHAPTER 3 – PROCESSMODELS.
1.1 P RESCRIPTIVEMODELSOR CONVENTIONALMODELS.
Every software engineering organization should describe a unique set of framework activities f
software processes it adopts. It should populate each framework activity with a set of software
engineering actions, and define each action in terms of a task set that identifies the work (and
products) to be accomplished to meet the development goals. It should then adapt the resulta
model to accommodate the specific nature of each project, the people who will do the work an
environment in which the work will be conducted. Regardless of the process model that is sele
software engineers have traditionally chosen a generic process framework that encompasses t
following framework activities:
• Communication – This framework activity involves heavy communication and collaboratio
with the customer (and other stakeholders) and encompasses requirements gathering an
related activities.
• Planning – This activity establishes a plan for the software engineering work that follows.
describes the technical tasks to be conducted, the risks that are likely, the resources tha
required, the work products to be produced, and a work schedule.
• Modeling – this activity encompasses the creation of models that allow the developer and
customer to better understand software requirements and the design that will achieve th
requirements.
• Construction – This activity combines code generation (either manual or automated) and
testing that is required to uncover errors in the code.
• Deployment – The software (as a complete entity or as a partially completed increment) i
delivered to the customer who evaluates the delivered product and provides feedback b
the evaluation.
We call these models prescriptive because they prescribe a set of process elements namely fra
activities, software engineering actions, tasks, work products, quality assurance and change co
mechanisms for each project. Each process model also prescribes a workflow that is, the mann
which the process elements are interrelated to one another.
All software process models can accommodate the generic framework activities, but each appl
different emphasis to these activities and defines a workflow that invokes each framework acti
well as software engineering actions and tasks) in a different manner.
1.2 T HE WATERFALL MODEL.
There are times when requirements of a problem are reasonably well understood, when work flows
communication through deployment in a reasonably linear fashion. This situation is sometimes enc
when well-defined adaptations or enhancements to an existing system must be made. It may also o
limited number of new development efforts, but only when requirements are well-defined and reaso
stable.
The waterfall model, sometimes called the classic life cycle, suggest a systematic, sequential a
software development that begins with customer specification of requirements and progresses
planning, modeling, construction, and deployment, culminating in on-going support of the com
software.
, http://wikistudent.ws/Unisa
The waterfall model is the oldest paradigm for software engineering. However, over the past t
decades, criticism of this process model has caused even ardent supporters to question its effic
Among the problems that are sometimes encountered when the waterfall model is applied are:
• Real projects rarely follow the sequential flow that the model proposes. Although the lin
model can accommodate iteration, it does so indirectly. As a result, changes can cause
as the project team proceeds.
• It is often difficult for the customer to state all requirements explicitly. The waterfall mo
requires this and has difficulty accommodating the natural uncertainty that exists at the
beginning of many projects.
• The customer must have patience. A working version of the program will not be availab
late in the project time-span. A major blunder, if undetected until the working program i
reviewed, can be disastrous.
In an interesting analysis of actual projects it was found that the linear nature of the waterfall m
leads to “blocking states” in which some project team members must wait for other members o
to compete dependent tasks. In fact, the time spent waiting can exceed the time spent on pro
work. The blocking state tends to be more prevalent at the beginning and end of a linear sequ
process.
Today, software work is fast-paced and subject to a never-ending stream of changes (to featur
functions and information content). The waterfall model is often inappropriate for such work.
it can serve as a useful process model in situations where requirements are fixed and work is t
to completion in a linear manner.
1.3 I NCREMENTALPROCESSMODEL.
There are many situations in which initial software requirements are reasonably well-defined, b
overall scope of the development effort precludes a purely linear process. In addition, there m
compelling need to provide a limited set of software functionality to users quickly and then refi
expand on that functionality in later software releases. In such cases, a process model that is d
produce the software in increments is chosen.
1.3.1 T HE I NCREMENTAL MODEL .
The incremental model combines elements of the waterfall model applied in an iterative fashi
incremental model applies linear sequences in a staggered fashion as calendar time progress
linear sequence produces deliverable increments of the software. It should be noted that the
flow for any increment may incorporate the prototyping paradigm.
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed, but many supplementary features (some known, others unknow
undelivered. The core product is used by the customer (or undergoes detailed evaluation). A
of use and or evaluation, a plan is developed for the next increment. The plan addresses the
modification to the core product to better meet the needs of the customer and the delivery of
features and functionality. This process is repeated following the delivery of each increment,
complete product is produced.
The incremental process model, like prototyping and other evolutionary approaches, is iterati
nature. But unlike prototyping, the incremental model focuses on the delivery of an operation
product with each increment. Early increments are “stripped down” versions of the final prod
they do provide capability that serves the user and also provides a platform for evaluation by
, http://wikistudent.ws/Unisa
Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project. Early incr
can be implemented with fewer people. If the core product is well received, additional staff (i
required) can be added to the implement of the next increment. In addition, increments can
to manage technical risks.
1.3.2 T HE RAD MODEL .
Rapid application development (RAD) is an incremental software process model that emphasi
short development cycle. The RAD model is a high-speed adaptation of the waterfall model, i
rapid development is achieved by using a component based construction approach. If require
well understood and project scope is constrained, the RAD process enables a development te
create a fully functional system within a very short period.
Like other process models, the RAD approach maps into the generic framework activities.
Communication works to understand the business problem and the information characteristic
software must accommodate. Planning is essential because multiple software teams work in
different system functions. Modeling encompasses three major phases, business modeling, d
modeling and process modeling and establishes design representations that serve as the bas
construction activity. Construction emphasizes the use of pre-existing software components a
application of automatic code generation. Finally, deployment establishes a basis for subsequ
iterations, if required.
Obviously, the time constraints imposed on a RAD project demand “scalable scope”. If a busi
application can be modularized in a way that enables major function to be completed in less t
months, it is a candidate for RAD. Each major function can be addressed by a separate RAD t
then integrated to form a whole.
Like all process models, the RAD approach has drawbacks which are:
• For large, but scalable projects, RAD requires sufficient human resources to create the
number of RAD teams.
• If developers and customers are not committed to the rapid-fire activities necessary to
the system in a much abbreviated time frame, the RAD project will fail.
• If a system cannot be properly modularized, building the components necessary for RA
problematic.
• If high performance is an issue, and performance is to be achieved through tuning the i
to system components, the RAD approach may not work.
• RAD may not be appropriate when technical risks are high.
1.4 E VOLUTIONARYPROCESSMODELS.
Software, like all complex systems, evolves over a period of time. Business and product requir
often change as development proceeds, making a straight-line path to an end product unrealis
market deadlines make completion of a comprehensive software product impossible, but a lim
version must be introduced to meet competitive or business pressure; a set of core product or
requirements is well understood, but the details of product or system extensions have yet to be
In these and similar situations, software engineers need a process model that has been explicit
designed to accommodate a product that evolves over time.
Evolutionary models are iterative. They are characterized in a manner that enables software e
to develop increasingly more complete versions of the software.
