The document discusses various software development process models. It describes the waterfall model, which involves sequential phases from requirements to maintenance. The main drawback is difficulty accommodating changes after a phase is complete. The document also covers prototyping, rapid application development (RAD), incremental development, and spiral development - all of which allow for more iterative processes and incorporating feedback.

1. SOFTWARE DEVELOPMENT PROCESS MODELS
1

2. Group Members
2
 MS.RUSAIK RUSNI (0080)
 ARM.RUSAN (0081)
 MT.AHAMED NAFAIS (0084)
 SM.LAREEF (0086)
 A.ATHHARUL HAQ (0087)
 SI.IHJAS (0088)

3. What is a process model?
3
 A structured set of activities required to develop a
software system
 Specification;
 Design;
 Validation;
 Evolution.
 A software process model is an abstract
representation of a process. It presents a description
of a process from some particular perspective.

4. The software design process
4

5. The debugging process
5

6. The testing process
6

7. Waterfall model (classic lifecycle)
7
 Requirements analysis and definition
 System and software design
 Implementation and Coding
 Integration and system testing
 Operation and maintenance
 The main drawback of the waterfall model is the
difficulty of accommodating change after the process
is underway. One phase has to be complete before
moving onto the next phase.

8. The waterfall model
8

9. 9
 The water fall model is easy to implementation.
 For implementation of small systems water fall model is use full.
 The project requires the fulfillment of one phase, before proceeding to
the next.
 It is easier to develop various software through this method in short
span of time.

10. 10
 The requirement analysis is done initially and sometimes it
is not possible to state all the requirement explicitly in the
beginning.
 The customer can see working model of the project only at
the end.
 If we want to go backtrack then it is not possible in this
model.
 It is difficult to follow the sequential flow in software
development process.

11. What is prototyping
11
 The Prototyping Model is a systems development
method (SDM) in which a prototype (an early
approximation of a final system or product) is built,
tested, and then reworked as necessary until an
acceptableprototype is finally achieved from which
the complete system or product can now be
developed

12. Why prototype?
•Evaluation and feedback are central to interaction
design
•Stakeholders can see, hold, interact with a
prototype more easily than a document or a
drawing
•Team members can communicate effectively
•You can test out ideas for yourself
•Is quick, cheap and easily changed

13. Types of prototyping
 Throw-away Prototyping
 Evolutionary Prototyping
 Low Fidelity Prototyping
 High Fidelity Prototyping

14. Journey of the Prototyping
process
Goals
Functionality
Evaluate
Develop

15. Prototyping model
15
 Advantages
 Users can try the system and provide feedback during
development
 An operational prototype can be produced in weeks.
 Prototyping enables earlydetection of errors
 Problems
 Lack of process visibility.
 Management is required.
 It’s a expensive method in creating.
 System performance and security issues can be overlooked

16. Introduction of RAD
 RAD-based methodologies adjust the SDLC phases
to get some part of system developed quickly and
into the hands of the users.
 Rapid Application development focuses on gathering
customer requirements through
 workshops or focus groups,
 early testing of the prototypes by the customer using
iterative concept,
 reuse of the existing prototypes (components),
 continuous integration and rapid delivery.

17. What is RAD?
 Rapid application development (RAD) is a software
development methodology that uses minimal planning
in favor of rapid prototyping. A prototype is a working
model that is functionally equivalent to a component of
the product.
 In RAD model the functional modules are developed in
parallel as prototypes and are integrated to make the
complete product for faster product delivery.
 The most important aspect for this model to be
successful is to make sure that the prototypes
developed are reusable.

18. RAD Vs. Waterfall
 RAD-based methodologies are well suited for projects with
short time schedules as they increase speed.
 Waterfall-based methodologies are the worst choice when
time is essential as they do not allow for easy schedule
changes.

19. RAD Model Design Phases
Following are the phases of RAD Model:
 BusinessModeling:
 The business model for the product under development is designed in terms
of flow of information and the distribution of information between various
business channels.
 A complete business analysis is performed to find the vital information for
business,
 how it can be obtained,
 how and when is the information processed and what are the factors driving
successful flow of information.
 Data Modeling:
 The information gathered in the Business Modeling phase is reviewed and
analyzed to form sets of data objects vital for the business.
 The attributes of all data sets is identified and defined.
 The relation between these data objects are established and defined in detail
in relevance to the business model.

20.  Process Modeling:
 The data object sets defined in the Data Modeling phase are converted to
establish the business information flow needed to achieve specific
business objectives as per the business model.
 The process model for any changes or enhancements to the data object
sets is defined in this phase.
 Process descriptions for adding , deleting, retrieving or modifying a data
object are given.
 Application Generation:
 The actual system is built and coding is done by using automation tools to
convert process and data models into actual prototypes.
 Testing and Turnover:
 The overall testing time is reduced in RAD model as the prototypes are
independently tested during every iteration.
 However the data flow and the interfaces between all the components
need to be fully tested with complete test coverage.
 Since most of the programming components have already been tested, it
reduces the risk of any major issues.

21.  Following images illustrates the RAD Model:

22. When to Use RAD
 RAD is used when
 The team includes programmers and analysts who are
experienced with it
 There are pressing reasons for speeding up application
development
 The project involves a new ecommerce application and
needs quick results
 Users are modern and highly engaged with the goals of the
company

23. Advantage & Disadvantage of RAD
Advantage Disadvantage
 Changing requirements can be
accommodated.
 Progress can be measured.
 Iteration time can be short with use of
powerful RAD tools.
 Productivity with fewer people in short
time.
 Reduced development time.
 Increases reusability of components
 Encourages customer feedback
 Dependency on technically strong team
members for identifying business
requirements.
 Only system that can be modularized can
be built using RAD.
 Requires highly skilled
developers/designers.
 High dependency on modeling skills.
 Inapplicable to cheaper projects as cost of
modeling and automated code generation is
very high.
 Management complexity is more.

24. Incremental development]
24
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest
priority requirements are included in early
increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve

25. Incremental development
25

26. Incremental development advantages
26
 Customer value can be delivered with each increment
so system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive
the most testing.

27. Spiral development
27
 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.

28. Spiral model sectors
28
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key
risks.
 Development and validation
 A development model for the system is chosen which can be any
of the generic models.
 Planning
 The project is reviewed and the next phase of the spiral is
planned.

29. Spiral model of the software process
29

30. Rapid software development
30
 Because of rapidly changing business environments,
businesses have to respond to new opportunities and
competition.
 Rapid software development and delivery is now often
the most critical requirement for software systems.
 Businesses may be willing to accept lower quality
software if rapid delivery of essential functionality is
possible.

31. Requirements
31
 Because of the changing environment, it is often
impossible to arrive at a stable, consistent set of
system requirements.
 Therefore a waterfall model of development is
impractical and an approach to development based on
iterative specification and delivery is the only way to
deliver software quickly.

32. Characteristics of rapid software development
process
32
 The processes of specification, design and
implementation are concurrent. There is no detailed
specification, and design documentation is
minimized.
 The system is developed in a series of increments. End
users evaluate each increment and make proposals for
later increments.
 System user interfaces are usually developed using an
interactive development system.

33. An iterative development process
33

34. Advantages of incremental development
34
 Accelerated delivery of customer services. Each
increment delivers the highest priority functionality to
the customer.
 User engagement with the system. Users have to be
involved in the development which means the system
is more likely to meet their requirements and the
users are more committed to the system.

35. Problems with incremental development
 Management problems 35
 Progress can be hard to judge and problems hard to find
because there is no documentation to demonstrate what
has been done.
 Contractual problems
 The normal contract may include a specification; without a
specification, different forms of contract have to be used.
 Validation problems
 Without a specification, what is the system being tested
against?
 Maintenance problems
 Continual change tends to corrupt software structure
making it more expensive to change and evolve to meet
new requirements.

36. Prototyping
36
 For some large systems, incremental iterative
development and delivery may be impractical; this is
especially true when multiple teams are working on
different sites.
 Prototyping, where an experimental system is
developed as a basis for formulating the requirements
may be used. This system is thrown away when the
system specification has been agreed.

37. Incremental development and prototyping
37

38. Conflicting objectives
38
 The objective of incremental development is to
deliver a working system to end-users. The
development starts with those requirements which are
best understood.
 The objective of throw-away prototyping is to
validate or derive the system requirements. The
prototyping process starts with those requirements
which are poorly understood.

39. Agile methods
39
 Dissatisfaction with the overheads involved in
design methods led to the creation of agile methods.
These methods:
 Focus on the code rather than the design;
 Are based on an iterative approach to software
development;
 Are intended to deliver working software quickly and
evolve this quickly to meet changing requirements.
 Agile methods are probably best suited to
small/medium-sized business systems or PC
products.

40. Principles of agile methods
40
Principle Description
Customer involvement The customer should be closely involved throughout the
development process. Their role is provide and prioritise new
system requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognised and
exploited. The team should be left to develop their own ways of
working without prescriptive processes.
Embrace change Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process used. Wherever possible, actively work
to eliminate complexity from the system.

41. Problems with agile methods
41
 It can be difficult to keep the interest of customers
who are involved in the process.
 Team members may be unsuited to the intense
involvement that characterizes agile methods.
 Prioritizing changes can be difficult where there are
multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches
to iterative development

42. Extreme programming
42
 Perhaps the best-known and most widely used agile
method.
 Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only
accepted if tests run successfully.

43. The XP release cycle
43

44. Extreme programming practices 1
44
Incremental planning Requirements are recorded on Story Cards and the Stories to be
included in a release are determined by the time available and
their relative priority. The developers break these Stories into
development ‘Tasks’.
Small Releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent and
incrementally add functionality to the first release.
Simple Design Enough design is carried out to meet the current requirements
and no more.
Test first development An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.

45. Extreme programming practices 2
45
Pair Programming Developers work in pairs, checking each otherÕs work and
providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers own all the
code. Anyone can change anything.
Continuous Integration As soon as work on a task is complete it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable pace Large amounts of over-time are not considered acceptable as the
net effect is often to reduce code qualit y and medium term
productivity
On-site Customer A representative of the end-user of the system (the Customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

46. 2.11. Rapid Application Development (RAD)
46
 Agile methods have received a lot of attention but
other approaches to rapid application development
have been used for many years.
 These are designed to develop data-intensive business
applications and rely on programming and presenting
information from a database.

47. RAD environment tools
47
 Database programming language
 Interface generator
 Links to office applications
 Report generators

48. A RAD environment
48

49. Evolutionary development
 Exploratory development
 Objective is to work with customers and to evolve a final
system from an initial outline specification. Should start with
well-understood requirements and add new features as
proposed by the customer.
 Throw-away prototyping
 Objective is to understand the system requirements. Should
start with poorly understood requirements to clarify what is
really needed.

50. Evolutionary development

51. Evolutionary development
 Problems
 Lack of process visibility;
 Systems are often poorly structured;
 Special skills (e.g. in languages for rapid prototyping) may be
required.
 Applicability
 For small or medium-size interactive systems;
 For parts of large systems (e.g. the user interface);
 For short-lifetime systems.

52. FORMAL METHODS MODEL
52
 Comprises set of activities that leads to formal
 mathematical specification of computer software.
 Enables a software engineer to specify, develop and
 verify a computer based system by applying
 mathematical notation.
 Problems of ambiguity, incompleteness and
 inconsistency can be managed by this method.
 Provides a base for verification therefore enable a

53. UNIFIED PROCESS MODEL
53
 Comprises best features and characteristics of conventional
 software process models.
 Emphasize importance of customer communication and
 streamlined methods for describing the customers view of
 system.
 Phases of Unified Process
 Inception = Involves customer communication and
 planning activities.
 Elaboration = Encompasses the customer
 communication and modeling activities of the generic
 process model. Architectural representation using Use
 Case Model, Analysis Model, Design Model,
 Implementation Model and Deployment Model.


54. UNIFIED PROCESS MODEL
54

55. 55
 Construction = Develops or acquires the software
 components that will make each use case operational for
 end users.
 Transition = Software is given to end user for beta testing
 and user feedback reports both defects and necessary
 changes.
 Production = Coincides with the deployment activity of
 process. The on going use of software is monitored,
 support for the operating environment is provided, and
 defect reports and requests for changes are submitted
 and evaluated.

56. 56
Thank you...