2. The period of time that starts when a software
product is conceived and ends when the product
is no longer available for use.
The software life cycle typically includes a
requirement phase
design phase
implementation phase
test phase
installation and check out phase
operation and maintenance phase, and sometimes
retirement phase.
3.
4. This model is easy to understand and reinforces
The notion of “define before design” and “design
before code”
The model expects complete & accurate
requirements early in the process, which is
unrealistic
5. i. Difficult to define all requirements at the
beginning of a project
ii. Not suitable for accommodating any change
iii. A working version of the system is not seen until
late in the project’s life
iv. It does not scale up well to large projects
v. Real projects are rarely sequential.
6. te a m # 3
te a m # 2
b u s in e ss
m o d e l in g
te a m # 1 b u s in e s s data
m o d e lin g m od e lin g
p ro c e s s
b u s in e s s m o d e l in g
m o d e lin g d a ta
m o d e lin g
listen ap pl icatio n
g e n era t io n
to build/revise testin g
&
tu rn o ver
p ro c es s
custom er m ock-up d a ta
m o d e lin g
m o d e lin g
a p p lic a tio n
g e n e ra tio n
p roce ss
m o d e lin g te s tin g
&
tu rn o v e r
a p p lic a tio n
g e n e r a tio n
custom er
test-drives te s tin g
m ock-up &
tu r n o v e r
6 0 - 9 0 da ys
Prototype
RAD
7.
1)When prototype is shown to the user, he gets a proper clarity and 'feel' of the
functionality of the software and he can suggest changes and modifications.
2) This type of approach of developing the software is used for non-IT-literate
people. They usually are not good at specifying their requirements, nor can tell
properly about what they expect from the software.
3) When client is not confident about the developer's capabilities, he asks for a small
prototype to be built. Based on this model, he judges capabilities of developer.
4) Sometimes it helps to demonstrate the concept to prospective investors to get
funding for project.
5) It reduces risk of failure, as potential risks can be identified early and mitigation
steps can be taken.
6) Iteration between development team and client provides a very good and
conductive environment during project.
7) Time required to complete the project after getting final the SRS reduces, since
the developer has a better idea about how he should approach the project.
8. 1) Prototyping is usually done at the cost of the developer. So it should be done using
minimal resources. It can be done using Rapid Application Development (RAD) tools.
Please note sometimes the start-up cost of building the development team, focused on
making prototype, is high.
2) Once we get proper requirements from client after showing prototype model, it may be
of no use. That is why, sometimes we refer to the prototype as "Throw-away" prototype.
3) It is a slow process.
4) Too much involvement of client, is not always preferred by the developer.
5) Too many changes can disturb the rhythm of the development team.
9. Not an appropriate model in the absence of user
participation.
Reusable components are required to reduce
development time.
Highly specialized & skilled developers are
required and such developers are not easily
available.
10. System/information increment 1
engineering
analysis design code test delivery of
1st increment
increment 2 analysis design code test delivery of
2nd increment
increment 3 analysis design code test delivery of
3rd increment
increment 4 analysis design code test
delivery of
4th increment
ca lenda r time
11. They are effective in the situations where
requirements are defined precisely and there is no
confusion about the functionality of the final
product.
After every cycle a useable product is given to the
customer.
Popular particularly when we have to quickly
deliver a limited functionality system.
12. This model has the same phases as the waterfall model, but
with fewer restrictions. Generally the phases occur in the same
order as in the waterfall model, but they may be conducted in
several cycles. Useable product is released at the end of the
each cycle, with each release providing additional
functionality.
Customers and developers specify as many requirements as
possible and prepare a SRS document.
Developers and customers then prioritize these requirements
Developers implement the specified requirements in one or
more cycles of design, implementation and test based on the
defined priorities.
13.
14.
15.
16.
17.
18.
19. Component assembly model—the process to apply when reuse is a
development objective
Concurrent process model—recognizes that different part of the
project will be at different places in the process
Formal methods—the process to apply when a mathematical
specification is to be developed
Cleanroom software engineering—emphasizes error detection
before testing