SE Lecture4
SE Lecture4
SE Lecture4
Lecture 4
15 July 2024
Topics covered in this lecture
Prototype Model
Spiral Model
2
Prototype Model
• Most of the customer are not sure about the
functionality they require from the software, as a
result the final s/w is not according to exact
demand.
• In this model, a working model of actual
software is developed initially. The prototyping
model can be considered to be an extension of the
waterfall model. This model suggests building a
working prototype of the system, before
development of the actual software .
• The prototype is just like a sample software
having limited functional capabilities, low
reliability, or inefficient performance as
compared to the actual software.
3
Prototype Model
• Refining it through user feedback, and repeating the
process until a satisfactory solution is achieved.
• Then shown to the user, as per the feedback of the user
prototype is rebuilt and modified and again shown to the
user, the process continue till the customer is not satisfied.
• After this process the final SRS document is developed.
Developing the prototype help in building the actual design.
• Developing a working prototype in the first phase
overcomes the disadvantage of the waterfall model where
the reporting about serious errors is possible only after
completion of software development.
3
Software Prototyping - Types
There are different types of software prototypes used in the industry. Following
are the major software prototyping types used widely −
• Throwaway/Rapid Prototyping
• Evolutionary Prototyping
• Incremental Prototyping
• Extreme Prototyping
3
Throwaway/Rapid Prototyping
• Throwaway prototyping, also known as rapid or exploratory prototyping, involves creating a
temporary, simplified version of the software to validate the feasibility of specific features,
test ideas, or gain user feedback on the initial design. The throwaway prototype is not
intended to be used in the final product; instead, it is discarded once it has served its purpose.
• Once the developers have gathered the necessary information, they can then start developing
the actual software product from scratch, using the lessons learned from the prototype. This
approach is particularly useful for testing complex or risky features, as it helps to minimize the
potential impact of these features on the overall project
3
Throwaway/Rapid Prototyping
• The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the
users can get quick feedback on their requirements, they may be able to refine them early in
the development of the software. Making changes early in the development lifecycle is
extremely cost effective since there is nothing at that point to redo.
• If a project is changed after a considerable work has been done then small changes could
require large efforts to implement since software systems have many dependencies. Speed is
crucial in implementing a throwaway prototype, since with a limited budget of time and
money little can be expended on a prototype that will be discarded.
3
Evolutionary Prototyping
3
Incremental Prototyping
3
Extreme Prototyping
Extreme prototyping is used in the web development domain. It consists of
three sequential phases.
First, a basic prototype with all the existing pages is presented in the
HTML format.
Then the data processing is simulated using a prototype services layer.
Finally, the services are implemented and integrated to the final prototype.
This process is called Extreme Prototyping used to draw attention to the
second phase of the process, where a fully functional UI is developed with
very little regard to the actual services.
3
Advantages
• Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers. Because changes cost exponentially more to implement as they are
detected later in development, the early determination of what the user really wants can result
in faster and less expensive software.
• Improved and increased user involvement: Prototyping requires user involvement and allows
them to see and interact with a prototype allowing them to provide better and more complete
feedback and specifications. The presence of the prototype being examined by the user prevents
many misunderstandings and miscommunications that occur when each side believe the other
understands what they said.
3
Diadvantages
Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing
the complete project. This can lead to overlooking better solutions, preparation of incomplete
specifications or the conversion of limited prototypes into poorly engineered final projects that are hard
to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is
used as the basis of a final deliverable, which may not be noticed if developers are too focused on
building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a prototype, intended to
be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for
example, often unaware of the effort needed to add error-checking and security features which a
prototype may not have.) This can lead them to expect the prototype to accurately model the
performance of the final system when this is not the intent of the developers.
3
Diadvantages
• Developer misunderstanding of user objectives: Developers may assume that users share their
objectives (e.g. to deliver core functionality on time and within budget), without understanding wider
commercial issues.
• Developer attachment to prototype: Developers can also become attached to prototypes they have
spent a great deal of effort producing; this can lead to problems like attempting to convert a limited
prototype into a final system when it does not have an appropriate underlying architecture. (This may
suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)
• Excessive development time of the prototype
• Expense of implementing prototyping: the start up costs for building a development team focused on
prototyping may be high.
3
Spiral Model
5
Spiral Model
• The spiral model combines the idea of iterative development with the systematic,
controlled aspects of the waterfall model.
• This Spiral model is a combination of iterative development process model and
sequential linear development model i.e. the waterfall model with a very high
emphasis on risk analysis. It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
• This model can be considered as the model, which combines the strengths of various
other models.
• Conventional software development processes do not take uncertainties into account.
• Important software projects have failed because of unforeseen risks.
• The other models view the software process as a linear activity whereas this model
considers it as a spiral process.
5
Spiral Model
• The following are the primary activities in this model:
– Finalizing Objective: The objectives are set for the particular phase of the project.
– Risk Analysis: The risks are identified to the extent possible. They are analyzed
and necessary steps are taken.
– Development: Based on the risks that are identified, an SDLC model is selected and is
followed.
– Planning: At this point, the work done till this time is reviewed. Based on the review,
a decision regarding whether to go through the loop of spiral again or not will be
decided. If there is need to go, then planning is done accordingly.
5
Spiral Model
• In the spiral model, these phases are followed iteratively. In this model Software development
starts with lesser requirements specification, lesser risk analysis, etc. The radical dimension
this model represents cumulative cost. The angular dimension represents progress made in
completing the cycle.
• The inner cycles of the spiral model represent early phases of requirements analysis and after
prototyping of software, the requirements are refined.
• In the spiral model, after each phase a review is performed regarding all products developed
up to that point and plans are devised for the next cycle. This model is a realistic approach to
the development of large scale software.
5
Why Spiral Model is called Meta Model?
• The Spiral model is called a Meta-Model because it subsumes all the other SDLC models. For
example, a single loop spiral actually represents the Iterative Waterfall Model.
• The spiral model incorporates the stepwise approach of the Classical Waterfall Model.
• The spiral model uses the approach of the Prototyping Model by building a prototype at the
start of each phase as a risk-handling technique.
• Also, the spiral model can be considered as supporting the Evolutionary model – the
iterations along the spiral can be considered as evolutionary levels through which the
complete system is built.
5
Advantages of the Spiral Model
1.Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.
2.Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
3.Flexibility in Requirements: Change requests in the Requirements at a later phase can be
incorporated accurately by using this model.
5
Advantages of Spiral Model
4. Customer Satisfaction: Customers can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.
5.Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and adaptability in
response to changing requirements or unexpected events.
5
Diadvantages of Spiral Model
• Not suitable for small size project as the cost of risk analysis may exceed the
actual cost of the project, High administrative overhead.
• Risk analysis requires highly specific expertise.
• Difficulty in time management: As the number of phases is unknown at the start
of the project, time estimation is very difficult.
• Complexity: The Spiral Model can be complex, as it involves multiple iterations
of the software development process.
5
Assignment Questions