Working is too easy

1. PROTYPING/RAPID PROTOTYPING MODEL:-
• This model specify that before the actual system is being built the
working model or the prototype system should be built in.
• Prototype means dummy,
• it is a modern and advance implementation system with limited
functional capabilities & is comparatively inefficient with the actual
system.

2. Prototype Model

3. Need for a prototype in software development
• An important purpose is to illustrate the input data formats, messages,
reports, and the interactive dialogues to the customer.
• This is a valuable mechanism for gaining better understanding of the
customer’s needs.
• it is impossible to get the perfect product in the first attempt. The experience
gained in developing the prototype can be used to develop the final product.
• A prototyping model can be used when technical solutions are unclear to the
development team.

4. When to use the Prototype Model
•A prototype of the actual product is preferred in
situations such as:
•• user requirements are not complete
•• technical issues are not clear
•Requirements are unstable or have to be clarified
as the requirements clarification stage of a
waterfall model develop user interfaces
•New, original development

5. ADVANTAGES:-
• i)The prototype which is developed is generally discarded after the
system is being built
• but the experience gain during the development of prototype
helps the design issue as expected from the customer.
• ii)Developing a prototype in place of actual system & putting it for
customer reference resolves different technical & design issue as
expected from the customer.

6. Prototyping Strengths
• Customers can “see” the system requirements as they are
being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of
additional needed functionality
• The prototyping model is suitable for projects for which
either the user requirements or the underlying technical
aspects are not well understood.

7. Prototyping Weaknesses
• Tendency to abandon structured program development
for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• Process may continue forever (scope creep)

8. EVOLUTIONARY/INCREMENTAL LIFE CYCLE MODEL:-
• Evolutionary model is based upon principle of incremented
developments of the functional unit & then integrating it for
visible.
• Each incremental version of the product is a fully functional s/w
product providing more features than its previous version.
• Each incremental version is tested individually before being
integrated into the system.
• This incremental model, they are developed in different phases
can be useful to the customers as they can be used as standalone
units when they are treated independently.

9. Incremental Model

10. ADVANTAGES:-
• i)Exact destination of customer requirements can be known.
• ii)It is also reduces the maintenance tasks duration because
before delivery of a module, the customers are consulted.
• iii)As the individual module takes place, so final product will
contain limited amount of errors.
• iii)It can be built upon object oriented platform which promotes
modular s/w
development.
• The goal was to design and deliver to the customer a minimal
subset of the whole system that was still a useful system.

11. DISADVANTAGES:-
•i)It is only helpful for large s/w products because
we can find individual modules for incremental
implementation.
•ii)It is also used when the customer is ready to
receive the product.

12. Incremental Model Strengths
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early

13. Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete and fully functional system
to allow for the definition of increments
• Well-defined module interfaces are required (some will be
developed long before others)
• Total cost of the complete system is not lower

14. When to use the Incremental Model
• Most of the requirements are known up-front
but are expected to evolve over time
• A need to get basic functionality to the market
early
• On projects which have lengthy development
schedules

15. SPIRAL MODEL/RISK MANAGEMENT MODEL:-
• This model contains the elements from all the other life cycle
model along with the necessary risks involves in each of the
developmental phase. So it is called as meta model.
• Each loop of the spiral represents a phase of the software process.
• For example, the innermost loop might be concerned with
feasibility study
• Each phase in this model is split into four sectors (or quadrants).

16. SPIRAL MODEL/RISK MANAGEMENT
MODEL:-
• the software process is represented as a spiral, rather than a
sequence of activities with some backtracking from one activity to
another.

17. Spiral Model

18. Spiral Model Strengths
• Provides early indication of insurmountable risks, without
much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users

19. Spiral Model Weaknesses
• Time spent for evaluating risks too large for
small or low-risk projects
• Time spent planning, resetting objectives,
doing risk analysis and prototyping may be
excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-
development phase activities

20. When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected

21. List of Books
• 1. Rajib Mall, Fundamentals of Software Engineering, PHI.
• 2. R.S. Pressman, Software Engineering Practitioner’s Approach, TMH.
• 3. S.L. Pfleeger, Software Engineering – Theory and Practice, 2nd Edition,
Pearson Education.
• 4. M.L. Shooman, Software Engineering – Design, Reliability and
Management, McGraw Hill.
• [5] M Fowler, UML Distilled: A Brief Guide to the Standard Object
Modelling Language, 3rd edition, Addison-Wesley, 2003.
• [6] S. Bennett, S McRobb R Farmer, Object-Oriented Systems Analysis and
Design using UML, 3rd edition, McGraw-Hill, 2006.
• [7] Sommerville, Software Engineering, 8th edition, Addison-
Wesley, 2006.
• [8] R .S Pressman, Software Engineering: A Practioner's Approach,
5th edition, McGraw-Hill, 2009