Chapter 2

Software Processes (2/2)

Computer Science Faculty

Software Department
Jalalabad City – 2601
Spring Semester, 2024
 Software Prototyping
 A prototype is an initial version of a software system
that is used to demonstrate concepts, try out design
options, and find out more about the problem and its
possible solutions.

 A software prototype can be used in a software

development process to help anticipate changes that
may be required:
 In requirements engineering process to help with requirements
elicitation and validation
 In design process to explore particular software solutions and
to support user interface design
Process of Prototype Development
 Prototype Development
 In the initial stage the objectives of prototyping should
be made explicit from the start of the process.
 These may be to develop a system to prototype the
user interface, to develop a system to validate
functional system requirements, or to develop a system
to demonstrate the feasibility of the application to
managers.
 Prototype Development
 The next stage in the process is to decide what to put
into and, perhaps more importantly, what to leave out
of the prototype system.
 To reduce prototyping costs and accelerate the delivery
schedule, you may leave some functionality and
management out of the prototype.
 You may decide to relax non-functional requirements
such as response time and memory utilization.
 Error handling may be ignored unless the objective of
the prototype is to establish a user interface.
 Standards of reliability and program quality may be
reduced.
 Prototype Development
 The final stage of the process is prototype evaluation.
 Provision must be made during this stage for user
training and the prototype objectives should be used
to derive a plan for evaluation.
 Users need time to become comfortable with a new
system and to settle into a normal pattern of usage.
 Once they are using the system normally, they then
discover requirements errors and omissions.
 Prototype Development
 May be based on rapid prototyping languages or tools

 May involve leaving out functionality

 Prototype should focus on areas of the product that are not
well-understood
 Error checking and recovery may not be included in the
prototype
 Focus on functional rather than non-functional requirements
such as reliability and security
 Throw-away Prototypes
 Prototypes should be discarded after development as
they are not a good basis for a production system

 It may be impossible to tune the system to meet non-functional

requirements, such as performance, security, robustness, and
reliability requirements, which were ignored during prototype
development.
 Rapid change during development inevitably means that the
prototype is undocumented. The only design specification is the
prototype code. This is not good enough for long-term
maintenance.
 The changes made during prototype development will probably
have degraded the system structure. The system will be
difficult and expensive to maintain.
 The prototype probably will not meet normal organizational
quality standards
 Prototype Development Benefits
 Users are actively involved in the development
 Since in this methodology a working model of the
system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better
solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
Requirements validation, Quick implementation of
incomplete but, functional application.
 Prototype Development Problems
 Leads to implementing and then repairing way of
building systems.

 Practically, this methodology may increase the

complexity of the system as scope of the system may
expand beyond original plans.

 Incomplete application may cause application not to be

used as the full system was designed, Incomplete or
inadequate problem analysis.
 Boehm’s Spiral Model
 A risk-driven software process framework (the spiral
model) was proposed by Boehm (1988).

 Process is represented as a spiral rather than as a

sequence of activities with backtracking

 Each loop in the spiral represents a phase in the

process

 No fixed phases such as specification or design – loops

in the spiral are chosen depending on what is required

 Risks are explicitly assessed and resolved throughout

the process
 Four Sectors in Each Loop
Each loop in the spiral is split into four sectors:
 Objective setting
 Specific objectives for that phase of the project are
defined.
 Constraints on the process and the product are
identified and a detailed management plan is drawn
up.
 Project risks are identified. Alternative strategies,
depending on these risks, may be planned.
 Four Sectors in Each Loop
 Risk assessment and reduction
 For each of the identified project risks, a detailed
analysis is carried out.
 Steps are taken to reduce the risk.
 For example, if there is a risk that the requirements
are inappropriate, a prototype system may be
developed.

 Informally, risk simply means something that can go

wrong.
 Four Sectors in Each Loop
 Development and validation
 After risk evaluation, a development model for the
system is chosen.
 For example, throwaway prototyping may be the best
development approach if user interface risks are
dominant.
 If safety risks are the main consideration,
development based on formal transformations may be
the most appropriate process, and so on.
 If the main identified risk is sub-system integration,
the waterfall model may be the best development
model to use.
 Four Sectors in Each Loop
 Planning
 The project is reviewed and a decision made whether to
continue with a further loop of the spiral.
 If it is decided to continue, plans are drawn up for the next phase
of the project.
Boehm’s Spiral Model
 Spiral Model Usage
 Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.
 Key Points
 Processes should include activities to cope with
change. This may involve a prototyping phase that
helps avoid poor decisions on requirements and design.
 Processes may be structured for incremental
development and delivery or Boehm’s spiral model
so that changes may be made without disrupting the
system as a whole.
 Assignment # 1

 Component based Development

 Aspect Oriented Development
 Personal software process
 Team software process
 Thank you!
Cell Phone: +93 787 544 117

Email: [email protected]

Twitter: https://twitter.com/kkhanh4t

Facebook: https://www.facebook.com/KKhanH4M/

Linkedin: https://www.linkedin.com/in/kamran-khan-97b092154