SOFTWARE ENGINEERING

UNIT 1.2
PROCESS MODELS

HETAL CHUDASAMA,
DEPARTMENT OF INFORMATIN TECHNOLOGY,
GCET.

1
 GENERIC PROCESS MODEL
 Process : collection of work activities, actions,
and tasks (AAT) that are performed to create
work product.
 Process Model : Abstract representation of
process.
 Process Framework: defines the relationship of
these AAT with the process and with each
other. (PF = FA +UA)
 Framework activity : set of SE actions, and SE
action is set of tasks.
 Framework activities (applicable to all software
projects)
 Umbrella activities (applicable across entire
software process)
 Process flow : Organization of framework AAT
as per sequence and time.
 Process Pattern : process related problems
encountered during SE work and suggested
solutions.
2
 TYPES OF PROCESS FLOW
Linear process flow executes each
of the five framework activities in
sequence.

Iterative process flow repeats one

or more of the activities before
proceeding to the next.

Evolutionary process flow

executes activities in circular manner.

Parallel process flow executes one

or more activities in parallel with
other activities.
3
DIFFERENT PROCESS MODELS
 Process model is selected based on Process Models
different parameters
 Type of the project and people
 Classic Waterfall Model (Linear Sequential Model)
 Complexity of the project
 Size of team  Iterative waterfall model
 Expertise of people in team  Incremental Process Model
 Working environment of team  V shape model
 Software delivery deadline  Evolutionary Model
 Prototyping Model
 The Spiral Model
 Rapid Application Development Model
 Concurrent Models
 Agile Model
SOFTWARE DEVELOPMENT LIFE CYCLE

❖ Requirement gathering
❖ Feasibility Analysis
❖ Planning and defining requirements
❖ Designing
❖ Development(Coding and implementation)
❖ Testing
❖ Deployment
❖ Maintenance

5
REQUIREMENT GATHERING AND ANALYSIS

 Gather requirements from their stakeholders, including customers, target market, industry experts,
and developers.
 Business analyst and Project manager conducts meeting with stake holders and collect all functional
(what exactly customer want) and non-functional requirement(how your product will look like in
future).
 Create Customer Requirement Specification (CRS).
 Investigating the validity and possibility of incorporating these requirements into the software
system.
 Feasibility check(economical, legal, operational, technical, shedule) by higher management and team
leaders

6
PLANNING AND DEFINING REQUIREMENTS

 What do we want?
 team members work together to discuss and plan out:
Intentions behind the project, Requirements of the project , Anticipated issues, Opportunities, Risks
 The quality proof of the project is a result of planning.
 Converting the information gathered during analysis phase into clear requirements for the
development team.
 This process guides the development of several important documents:
 a software requirement specification (SRS), a Use Case document, and a Requirement Traceability
Matrix document.
7
DESIGNING

 How will we get what we want?

 It design overall architecture of the software.
 The original plan and vision are elaborated into a software design document (SDD) or Design Document Specification
(DDS) software by architects.
 It include Data Flow Diagram, Use case diagram, Class diagram, Activity diagram, State transition diagram, Database
design.
 Will also decide algorithms, programming language, templates, platform to use, and application security measures.
 This is also where you can flowchart how the software responds to user actions.
 turning the software specifications into a design plan called the Design Specification
 Includes the development of a prototype model.
 Also includes the overall architecture of the software, data structures, and interfaces. It has two steps:
 High-level design (HLD): It gives the architecture of software products.
 Low-level design (LLD): It describes how each and every feature in the product should work and every component. 8
DEVELOPMENT

 Let’s create what we want.”

 development team members divide the project into software modules and turn the software requirement
into code that makes the product.
 It’s important that every developer sticks to the agreed blueprint and guidelines.
• This is the longest phase in SDLC model.
• This phase consists of Front end + Middleware + Back-end.
• In front-end: Development of coding is done.
• In Middleware: They connect both the front end and back end.
• In the back-end: A database is created.
• Programmer will use suitable programming language, framework, database.

9
TESTING

 Did we get what we want?

 it’s important to have your quality assurance team perform validation testing to make sure it is functioning
properly and does what it’s meant to do.
 we test for defects and deficiencies. We fix those issues until the product meets the original specifications.
 During this stage, unit testing, integration testing, system testing, acceptance testing are done.
 Most other common testing methods are white box, black box, grey box test methods.

10
DEPLOYMENT

 Let’s start using what we got.

 After detailed testing, the conclusive product is released in phases as per the organization’s strategy.
 Based on the assessment, the software may be released as it is or with suggested enhancement in the
object segment.
 This stage usually involves deployment engineers who make software available to customers. They may
install the software at a company and/or help individual customers run the application on their computers.

11
MAINTENANCE

 Let’s get this closer to what we want.

 Once when the client starts using the developed systems, then the real issues come up and requirements to
be solved from time to time.
 The plan almost never turns out perfect when it meets reality. Further, as conditions in the real world
change, we need to update and advance the software to match.
 includes ongoing support, bug fixes, upgrades, enhancement and updates to the software.

12
 WATERFALL MODEL
Understanding Best Feasible Classic life cycle or
problem requirements linear sequential model
Requirements gathering Software
Requirement analysis Requirement
specification of system Specifications
Design is prepared Software
Defining system
Design
architecture, HLD,LLD
Document
Developing system in small units
Efficiency of
Tested for its functionality
individual
modules
Modules integrated into a system Corrective,
Efficiency of
Entire system testing perfective, adaptive
system
(Alpha, Beta, Acceptance) maintenance
Modules interaction testing Fix issues 13
Handover product Enhances product
Customer feedback Patches are release
CLASSIC WATERFALL MODEL
 Earliest and base process model used for software development.
 Simplest software development model to understand and use but idealistic .
 Earlier days it was very popular but now a days it is not used, but various other models are derived
from this model.
 Inspired by a natural phenomenon – waterfall.
 It follows sequential process flow, (output of one phase will be input to next phase) so also referred
to as linear-sequential life cycle model or classic life cycle model or classic water fall model
 Maintains a linear and forward/downward/sequential approach throughout process, no
backward/upward movement
 Activities of each stage can begin only after you’re done with tasks of the previous stage and all
activities are properly documented.
 Developers believe in completing and documenting the scheduled tasks in each phase as it continue
to move ahead. 14
CLASSIC WATERFALL MODEL

 No customer involvement (if intermediate changes suggested by customer, developers may need to
go back to accommodate those changes, which is not allowed)
 It is a rigid model as it does not allow any intermediate changes or once requirements specified by the
customers, it can not be modified one software development gets start.
 Well defined enhancement of an existing system.
 Encountered during well defined and reasonably stable requirements for new development
 60% of efforts will be in maintenance phase only as all problems, bugs will be visible and debugged at
the end only

15
CLASSIC WATERFALL MODEL

16
CLASSIC WATERFALL MODEL

When to use
 Requirements are very well known, understood and fixed and will not change
 Product definition is stable
 Technology is understood and not dynamic
 There are no ambiguous (unclear) requirements
 Ample (sufficient) resources with required expertise are available freely
 The project is not complicated and big and cost is low
 Minimum risk

17
 Classic Waterfall Model
Advantages Disadvantages
• Rigid model as no intermediate changes possible
▪ Process and tasks are well • Difficult for customers to state all requirements
documented explicitly.
▪ Easy to manage and arrange tasks • Unable to accommodate changes at later stages, that
▪ Simple to implement and easy to is required in most of the cases.
• High Risk of failure as Working version is only
use available at end.
▪ Works well for small and low • If a problem encounters, can lead development with
budget projects major mistakes and changes.
▪ Elaborated documents are • Delay in any step may lead to Deadlock .
prepared at each stage • Not suitable for large projects.
• Can lead to blocking state (some team members must
▪ Project completely depends on wait for other, to complete dependent tasks.)
project team with minimum client • No feedback exchange b/w teams working at different
interaction phases, Needs high maintenance
• No parallelism or phase overlapping or backtrack
18
• Difficult to measure progress within stages
• No incremental delivery
ITERATIVE WATERFALL MODEL

 In Iterative waterfall model, the feedback paths

are provided from every phase to its preceding
phases
 There is no feedback to feasibility study
 The feedback paths allow for correction of the
errors committed during a phase, as and when
these are detected in a later phase.
 Phase containment of errors is required as they
introduced the error correction mechanism in the
previously frozen phases.

19
ITERATIVE WATERFALL MODEL

20
 Iterative waterfall model
Advantages Disadvantages
▪ Feedback Path allows correcting ▪ Difficult to incorporate change
errors requests
▪ Corrected changes will be ▪ Risk handling not supported
reflected to later phases ▪ Overlapping of phases not
▪ Simple to use and easy to supported
implement ▪ Limited customer interactions
▪ Risk Reduction ▪ Incremental delivery not
▪ Predictable Outcomes supported
▪ Easy to Manage
▪ Quality assurance When to use
▪ Requirements are well known and
stable.
▪ Technology is understood. 21

▪ Experienced development team

V-SHAPE MODEL
 In waterfall model, testing comes only after development, if any enhancement we need then we have to start
from the beginning. But V-model supports parallel testing to overcome this problem.
 It follows linear execution like waterfall model, but It is extension of waterfall model.
 Process executes in a sequential manner in V-shape.
 It is also known as Verification and Validation model (Verification phase -> coding -> validation phase.)
 It is based on the association of a testing phase for each development phase of the lifecycle.
 The next phase starts only after completion of the previous phase i.e. for each development activity, there is a
testing activity corresponding to it.
 Verification phase(Testing corresponds to Requirement analysis→ System design→ Architecture design→
Module design)
 Validation Phase(Unit testing → Integration testing → System testing → Acceptance testing)
22
 V-Model is often used in safety-critical systems, such as aerospace and defense systems, because of its emphasis
on thorough testing and its ability to clearly define the steps involved in the software development process.
 V-SHAPE MODEL
Developer’s life cycle Tester’s life cycle
Activities during Output of
the phase the phase Test designing

Understand customer Mutually agreed

requirements requirement documents
Requirement analysis High Level System Design :
Feasibility study Components(Hardware,
Software, Database)
Architect analyzes System High Level Software Design:
Design Documents technical decisions

Software blueprint Low Level System Design:

Module designing Modules ready
Validation :
Actual construction Verification : Are Are we making
23

Module integration we making the the product right?

right product?
VALIDATION PHASE

 Acceptance test : Before closing requirement phase, acceptance test should also be
planned.Testing by customers or users for acceptance of the product.
Done during requirement analysis.
 System testing : It is done just before product delivery to test entire system
functionality. Done during System design.
 Integration test : It is done to test software’s internal modules and its
communication. Done during architecture design.
 Unit testing : It is done by individual developers to test module functionality. Also
known as white box testing. Done during module design.

24
 V shaped Model
Advantages Disadvantages
▪ It inherits all the advantages of ▪ Testing at each phase in the
waterfall model. beginning can be time
▪ Time spent early in software consuming.
development cycle, can reduce cost at ▪ Difficult to incorporate change
later stage. requests
▪ Emphasize planning for verification ▪ Risk handling not supported
and validation of the product in early ▪ Overlapping of phases not
stage of the development. supported
▪ Testing in beginning phases, saves lots
of testing time during validation. When to use
▪ Less chances of bugs or defects as ▪ Requirements are well known
most of them will be detected in and stable.
beginning. ▪ Technology is understood.
25

▪ Experienced development team.

INCREMENTAL PROCESS MODEL
 This model applies linear sequence in staggered manner as time progresses.
 Initially core working product (basic requirements are addressed but many supplementary features remain
undelivered) is delivered.
 Each linear sequence produces deliverable “increments” of the software.
 We do not build the full software in a single time, instead first we break down customer’s requirements into
multiple standalone modules and then develop each module one-by-one, as per customer’s requirements and
feedback for previous modules.
 Every module will develop as per waterfall model by going through each of the phases of life cycle model, Every
subsequent release or increment adds functionality of previous release, This process continues till fully functional
software gets ready.
 Each module will consider the feedback provided by previous module.
 Customer’s requirements are gathered at the beginning of the project, then after we increment the software
module-by-module, till complete product is produced.
 Core product gets evaluated by customers and modified for additional features.
 Useful for website designing and product based companies. E.g. ERP 26
INCREMENTAL PROCESS MODEL

Fully functionalized
software

27
 Incremental Process Model
Advantages Disadvantages
▪ Generates working software quickly and early. ▪ Overall cost and time is higher.
▪ Breakdown of system into modules require
▪ Maximum customer interaction proper understanding.
▪ Early customer feedback ▪ Not all requirements collected up initially in
▪ Customer can respond to each built. one time.
▪ Initial product with important or prioritized ▪ Each iteration phase is rigid and no
functionality can be deliver faster overlapping of phases.
▪ Proper planned execution needed.
▪ More flexible as it can accommodate changes
through customer interaction and feedbacks. When to use
▪ It is easier to test and debug during a smaller ▪ When the requirements of the complete
iteration. system are clearly defined and understood
▪ Lowers initial delivery cost. ▪ staffing is unavailable for a complete
implementation by the business deadline.
▪ Easier to manage risk because risky pieces are
▪ Prioritized requirements to be developed first.
identified and handled during iteration.
▪ Product delivery needs to be earlier.
▪ Changes are easy to implement. ▪ Customer demands quick delivery of product.
28

▪ Partial systems are successively built to produce ▪ Product with long development schedule.
final total system. ▪ Project is large with high-risks.
INCREMENTAL PROCESS MODEL

 There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort prevent a purely linear process.
 In addition, there may be a compelling need to provide a limited set of software functionality to users quickly and
then refine and expand on that functionality in later software releases.
 In such cases, there is a need of a process model that is designed to produce the software in increments.
 e.g. word-processing software developed using the incremental model
 It might deliver basic file management, editing and document production functions in the first increment
 more sophisticated editing in the second increment;
 spelling and grammar checking in the third increment; and
 advanced page layout capability in the fourth increment.

29
EVOLUTIONARY PROCESS MODEL

 It is combination of iterative and incremental model of SDLC.

 Software requirements are first broken down into several modules, each module is incrementally
constructed.
 Customer interaction is more as Customer feedback will be taken after every module and after every
increment.
 Small changes can be easily accommodates as it does module by module development.
 Also known as design a little, build a little, test a little, deploy a little model.
 Product will be delivered module by module to the customer.
 Also known as successive version model.
 Examples: prototyping paradigm, spiral model, concurrent development model. 30

 Andriod updates, OS updates

EVOLUTIONARY PROCESS MODEL

▪ Incremental model first implements few

basic features and deliver it to the
customers. Then build next part and
deliver next part and repeat this step until
desired system is fully functional.
▪ Iterative model is flexible as feedback
considered in every iteration and included
in next iteration.

31
EVOLUTIONARY PROCESS MODEL

 Evolutionary process model resembles iterative enhancement model.

 The same phases as defined for the waterfall model occur here in a cyclical fashion.
 This model differs from iterative enhancement model in the sense that this does not
require a useable product at the end of each cycle.
 In evolutionary development, requirements are implemented by category rather than
by priority.
 This model is useful for projects using new technology that is not well understood.
This is also used for complex projects where all functionality must be delivered at
one time, but the requirements are unstable or not well understood at the beginning. 32
EVOLUTIONARY PROCESS MODEL

33
EVOLUTIONARY PROCESS MODEL

 Often changes in product requirement as development proceeds and tight market deadlines makes completion of
comprehensive software product impossible, So, limited version of software is introduced to meet business pressure.
 When a set of core product or system requirements is well understood but the details of product or system extensions
have yet to be defined.
 In this situation there is a need of process model which specially designed to accommodate product that evolve with
time.
 Evolutionary Process Models are specially meant for that which produce an increasingly more complete version of the
software with each iteration.
 Evolutionary Models are iterative.
 Evolutionary models are
➢ Prototyping Model
➢ Spiral Model

34
 Evolutionary Process Model
Advantages Disadvantages
▪ Risk analysis is better. ▪ Not suitable for smaller projects.
▪ It supports changing requirement. ▪ Highly skilled resources are required.
▪ Initial operating time is less. ▪ Overall High cost.
▪ Better suitable for large mission-critical and long ▪ Constant customer interaction is time
projects. consuming.
▪ User gets partially built software, no need to wail ▪ Constant and clear interaction between
till full functional software get build. development team is necessary.
▪ Easy to solve error as it will be detected and get
▪ Delivery of full software can be late due to
solved in each module instead of solving for entire
constant feedback and different changes.
fully build software at last.
▪ Will reduce cost of development. ▪ Sometimes difficult to divide project into
smaller parts.
When to use
▪ When customers want to start using core features instead of waiting for full project.
▪ When project is large as step by step development.
▪ Customer requirements are not fixed but conceptually clear 35

▪ Object-oriented based software development as all development is divided into different

units.
Incremental Model Evolutionary Model
• The requirements are clear to the development team. • The requirements are not clear, and it evolves during
• The requirements are split into slices, and one by one, the development cycle.
slices are picked based on selection criteria. • At the initial stage, based on their understanding of
• The development of each slice goes into multiple the customer’s requirements, they developed the core
iterations for the refinement of functionality, and in modules and functionalities and delivered them to the
the end, a deliverable product is released. customer for feedback.
• It is called an increment, and in each increment, a • This is called an iteration. In each iteration, they
deliverable product is given to the user. release a working software after performing
• In this model, requirements do change. But to a integration and level of tastings.
certain extend, like the addition and removal of • The development team does not know how much has
certain functionalities. been completed and how much needs to be complete
• The development team knows how much has been in the near future.
completed and how much needs to be complete 36
soon.
PROTOTYPING MODEL

 Prototype is working or dummy model or replica of software with some limited

functionality.
 It is applied when customers do not know the exact project requirements.
 We do not develop full software, but firstly we develop prototype of a software.
 After this, the prototype software will be handed over to the customer and the
customer will use the prototype product and check any possible problems and will
give the feedback.
 If any problem in the product or customer is not satisfied with the product than
we remove the problems from the product or we create new version of prototype
of the product.
 Types of prototyping model : Rapid throwaway prototype, Evolutionary prototype 37
PROTOTYPING MODEL

 Communicates with stackholders and defines

objective of Software.
 Identify requirements & design quick plan.
 Model a quick design (focuses on visible part
of software).
 Construct Prototype & deploy.
 Stakeholders evaluate this prototype and
provides feedback.
 Iteration occurs and prototype is tuned based
on feedback.
38
 Prototyping model
Advantages Disadvantages
▪ Users are actively involved in the development ▪ Protype developing phase is time
▪ More accurate requirements are gathered consuming and expensive.
▪ Since in this methodology a working model of the ▪ User may lose interest, if initial prototype is
system is provided, the users get a better not interested.
understanding of the system being developed ▪ Prototyping tools are gathers.
▪ Errors can be detected much earlier ▪ Very slow process, prototyping takes time.
▪ Missing functionalities identified easily ▪ Costly with respect to time and money.
▪ Quick feedback gives better idea of users, needs ▪ It is a throw away prototype if users are
▪ Flexibility in design satisfied with the prototype.
▪ Good for project with changing requirements ▪ Many changes during prototyping can
disturb the rhythm of development.
When to use
▪ Customers have general objectives of software but do not have detailed requirements for functions
and features.
▪ Developers are not sure about efficiency of an algorithm, adaptability of OS, form of human-machine
iteration and technical feasibilities.
▪ Needs to have lots of interaction with the user. 39

▪ System is complicated and large.

▪ Illustration of user interface.
SPIRAL MODEL

 Customers’ feedback and accommodation of those changes were not there through out the development, it was
only included during prototyping phase in prototype model.
 Due to this, Some projects need restart of project from in between due to various problems.
 Big project must work on risk analysis well in advanced so that it can make developers aware about various risk
that can be generated in later phase of development life cycle.
 Recognizing the project risk factor and remove it at earlier stage of a life cycle model, and throughout
consideration of customer interaction result into spiral model.
 Also known as Risks (new technology, critical timeline, lack of crystal clear requirements) driven software
development model.
 It is combination of Iterative nature of prototype and controlled and systematic aspects of waterfall model and
allows incremental releases of the product, Software is developed in a series of incremental releases.
 Early iteration release might be model or prototype but later iterations provides more complete
version of software. 40

 Till the customer gets satisfied with the product, model will go into next spiral.
 SPIRAL MODEL
 Spiral model has 4 phases, shown by four quadrants.
Risks analysis, Risk resolving
 At any point of time, project will be in one of the Identifying requirements
Software evaluation,
four quadrants. (customer, business,
Prototype building for best solution
system)
 It also has third dimension of prototypes. Requirement analysis
 That Angular dimension represents progress made
in the completion of each cycle.
 Circle represents iterations of spiral model.
 Each circle ends with potential product release.
 Each loop of the spiral, from X-axis clockwise Builds software ,
through 360 represents one phase.
Customer Assign number to
 Product will not be released in each iteration, but feedback and builds &
only in the last iteration. evaluation for providing it to
customer with
 Each path around spiral is indicative of increased next build
cost. updates
Testing
 More the radius of spiral, cost will be more. 41
 Also called meta model(mixture of linear, iterative,
incremental, prototype model)
SPIRAL MODEL
▪ It is divided into four framework activities, Each activity represent one segment of the spiral path.
▪ First circuit around spiral results in development of product specification.
▪ Subsequent passes around spiral used to develop prototype and progressively more sophisticated
versions of software.
▪ Each pass through the planning region results in adjustments to
▪ the project plan
▪ Cost & schedule adjustment based on feedback from customers after delivery
▪ Developer and customer better understand and react to risks at each evolutionary level.
▪ Uses prototyping as risk reduction mechanism.
▪ Enables you to apply prototyping approach at any stage in evaluation of product. 42

▪ Demands consideration of risks at all stages of product, reduces risks before it

 Spiral Model
Advantages Disadvantages
▪ High amount of risk analysis hence, avoidance of ▪ Can be a costly model to use.
Risk is enhanced. ▪ Difficult to convince customer about
▪ Strong approval and documentation control. controllable nature of evolutionary
▪ Additional functionality can be added at a later approach.
date. ▪ It needed and relies on considerable risk
▪ Software is produced early in the Software Life assessment expertise.
Cycle. ▪ Project’s success is highly dependent on the
▪ Cost estimation is easy. risk analysis phase.
▪ Features are added in systematic way. ▪ Doesn’t work well for smaller projects.
▪ Through out customer interaction ▪ More documentation.
▪ Flexible ▪ Complex, expensive and time consuming
▪ Allows incremental release and testing ▪ Needs proper and experienced team for risk
▪ Resolves all possible risks involved in project at analysis
earlier in life cycle ▪ Not proper time management
▪ Good feedback mechanism. ▪ Iterations may go on infinitely.
▪ Maintenance is costly
43
 Spiral Model
When to use

▪ For development of large scale / high-risk projects.

▪ When costs and risk evaluation is important.
▪ Users are unsure of their needs and so changes are required at any time or
requirement keeps changing.
▪ Requirements are complex.
▪ Significant (considerable) changes are expected.
▪ System is to be developed early and in smaller modules.
▪ When frequent releases are required.
▪ When risk and cost evaluation is important
▪ When we do not know when the project is going to end.
44
RAPID APPLICATION DEVELOPMENT MODEL (RAD)

 It is adaption of waterfall model and based on prototyping and incremental development model.
 Main focus of this model is to gather the requirements from the customers through prototypes and continuously
deliver them using iterative model.
 It results in rapid delivery to the customer and customer involvement during complete development cycle of
product reducing the risk of non-conformance with the actual user requirements.
 Project can be broken down into small modules.
 Each module can be assigned independently to the separate teams.
 These start working on the assigned module parallelly.
 These modules can finally be combined to form the final product.
 Development of each module involves the various basic steps as in waterfall model.
45
RAPID APPLICATION DEVELOPMENT MODEL (RAD)

46
RAPID APPLICATION DEVELOPMENT MODEL (RAD)
▪ Communication : This phase is used to understand business problem.
▪ Planning : Multiple software teams work in parallel on different systems/modules.

▪ Business Modeling : Information flow among the business.

▪ BA collects information from clients and product is developed as per business information.
▪ Ex. What kind of information drives (moves)?
▪ Who is going to generate information?
▪ From where information comes and goes?

▪ Data Modeling: Information refine into set of data objects that are needed to support business.
▪ All attributes of dataset are identified and defined as per BI.

▪ Process Modeling: Data object transforms to information flow necessary to implement business.

▪ Construction : It highlights the use of pre-existing software component.

▪ Coding by developers with the help of CASE tools to convert process into prototype.
▪ Testing 47

▪ Deployment : Integration of modules developed by parallel teams, delivery of integrated software and feedback comes under deployment
phase.
 Rapid Application Development Model (RAD)
Advantages Disadvantages
▪ For large but scalable projects, RAD
▪ Reduced development time. requires sufficient human resources.
▪ Increases reusability of components. ▪ Projects fail if developers and
▪ Quick initial reviews occur. customers are not committed in a much
▪ Encourages customer feedback. shortened time-frame.
▪ Problematic if system can not be
▪ Integration from very beginning solves a lot of modularized.
integration issues. ▪ Not appropriate when technical risks
▪ This model is flexible for changes. are high (heavy use of new technology).
▪ Require highly skilled designers.
▪ Customer involvement throughout
development.
When to use
▪ There is a need to create a system that can be modularized in 2-3 months of time.
▪ High availability of designers and budget for modeling along with the cost of automated code
generating tools. 48

▪ Resources with high business knowledge are available.

COMPONENT BASED DEVELOPMENT
 It is a specialized process model, incorporates many characteristics of the spiral model and It is
evolutionary in nature..
 Software products are built by identifying and reusing components those already exist.
 This model is based on concept of reusability.
 Modeling and construction activities begin with the identification of components and then constructs
applications from prepackaged software components.
 Commercial off the shelf (COTS , it is not custom developed) software components are offered as
product.
 COTS provides set of functionality with well defined interfaces that enables component to be
integrated into software.
 It is used when focus is on buying components rather than building them or assembling components49
rather than developing them.
COMPONENT BASED DEVELOPMENT MODEL
COTS components
 products are ready-to-use
upon installation and are
designed to easily integrate
with an existing system.
 It is not custom made.
 Easy to install, need no
customization.
 Eg:
 OS, Database, MS Office,
Gmail & other google apps.50
COMPONENT BASED DEVELOPMENT MODEL

 Component based development incorporates the following steps:

1. Available component-based products are researched & evaluated for software development.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.
Advantages
▪ It leads to software reuse.
▪ It reduces development cycle time.
▪ Reduction in project cost.

51
OBJECT-ORIENTED MODEL

 Software development process for object-oriented model.

 Also known Unified Process Model.
 Reduces unexpected development cost and prevent wastage of resources.
 5 phases:
 Inception
 Elaboration
 Construction
 Transition
 Production

52
53
54
55
56
 AGILE PROCESS MODEL
 The Agile Model is an incremental and iterative process of software
development.
 It divides tasks/project down into several dynamic phases, commonly
known as sprints to provide delivery of specific functionality early for
the release/build, which mostly lasts from two to four weeks.
 After every sprint, teams reflect and look back to see if there was
anything that could be improved so they can adjust their strategy for
the next sprint.
 Each sprint is incremental in terms of functionality, with the final
sprint containing all the attributes.
 It defines each iteration’s number, duration, and scope in advance.
 The division of the entire project into small parts helps minimize the
project risk and the overall project delivery time.
 The agile basic purpose is to be rapid in all activities.
 Agile manifesto is set of 4 values and 12 principles. 57
HOW DOES AGILE PROCESS MODEL WORK? 58
 AGILE PROCESS MODEL

Product released Testing

User feedback and Implementation

Suggestion
Refinement

Requirement gathering Release

59
Feasibility study Requirement gathering
Defining requirements Feasibility study
Defining requirements
60
1. Customer satisfaction.
2. Changing requirements
3. Frequent delivery
4. Work together
5. Motivated individuals
6. Sustainable development
7. Working software
8. Face-to-face conversation
9. Continuous enhancement
10. Simplicity
11. Self-organizing team
12. Frequent reflection

61
HOW IS AGILE DIFFERENT?

 Agile prioritizes flexibility and continuous improvement over following a strict plan.
 Agile emphasizes collaboration between teams, customers, and stakeholders and
encourages open communication and transparency throughout the project lifecycle.
 Agile uses short iterations called sprints to manage and track progress, with regular reviews
and assessments to ensure that the project stays on track.
 Agile encourages the delivery of working software early and often rather than waiting until
the end of the project to deliver a final product.
 Overall, Agile approaches focus on continuous delivery and improvement, adaptability and
customer involvement. In contrast, traditional project management approaches focus more
on following a plan and sticking to a budget and schedule. 62
63
ADVANTAGES OF OTHER PROCESS MODEL IN TO AGILE

64
 Agile Model
Advantages Disadvantages
▪ Supports customer involvement and customer ▪ Lack of documentation
satisfaction ▪ Software maintenance difficult in case
▪ Strong communication of the software team with of frequently changing team
the customer. ▪ Senior and highly paid developers are
▪ Focus on user and customer required
▪ Rapid development ▪ No full support for documentation and
▪ Allows changes easily design
▪ Cost-saving ▪ risk of the ever-lasting project
▪ Promotes team works ▪ resource requirement and effort are
▪ Fast delivery difficult to estimate for complex
▪ Little planning required projects
▪ difficult to predict the expected result if
When to use requirement is not very clear
▪ ongoing projects and projects with unclear details
▪ Project needs continuous delivery, iteration, adaptability, and short time frames, among others.
▪ Project lacking precise constraints, deadlines, or resources. 65