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

32
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

33
 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 34

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

units.
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 35
PROTOTYPING MODEL

 Communicates with stockholders 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.
36
 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. 37

▪ 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. 38

 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. 39
 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. 40

▪ 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
41
 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.
42
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.
43
RAPID APPLICATION DEVELOPMENT MODEL (RAD)

44
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 45

▪ 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. 46

▪ 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 components47
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.48
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.

49
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

50
 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. 51
HOW DOES AGILE PROCESS MODEL WORK? 52
 AGILE PROCESS MODEL

Product released Testing

User feedback and Implementation

Suggestion
Refinement

Requirement gathering Release

53
Feasibility study Requirement gathering
Defining requirements Feasibility study
Defining requirements
54
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

55
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. 56
57
ADVANTAGES OF OTHER PROCESS MODEL IN TO AGILE

58
 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. 59
DIFFERENT AGILE METHODOLOGY

Extreme Programming (XP)

Scrum
Crystal
Agile Modeling (AM)
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)
60
EXTREME PROGRAMMING (XP)

 One of the most important software development frameworks of Agile (flexible)models, introduced
by Kent beck.
 Extreme programming is, in a nutshell, about good practices taken to an extreme.
 It is lightweight, efficient, low-risk, flexible, predictable, scientific, fun oriented way to develop a
software.
 It targets speed and simplicity with short development cycles and less documentation.
 It is used to improve software quality and responsiveness to customer requirements.
 XP roles (Customers, Programmer, Testers, Tracker, Coach )
 The process structure is determined by five guiding values, five rules, and 12 XP practices
61
 A variant of XP, Industrial XP(IXP) refines XP for large organization.
CONCEPTUALIZATION

 Help small teams work with changing requirements

 Introduce idea of writing tests before coding
 It is better to pair while coding
 Build something simple that works and then enhance further
 All team members should collaborate
 Imbibe values such as communication, simplicity, feedback, courage and respect
 It incorporates Object Oriented Approach.
62
5 VALUES

 Simplicity : Start developing the important and needed features first without worrying about
future requirements, we should move to the problematic and extra functionalities later on.
Keep the design of the system as simple as possible so that it is easier to maintain, support,
and revise.
 Communication : It focuses on excellent communication and collaboration with stakeholders
and within team members. It bridges the gaps between what the developer is making and
the customer requirement.
 Feedback : Constant feedback, from system , customer, and team members, about previous
efforts, can identify areas for improvement and make necessary adjustments to processes.
Frequent releases gains early and often insights.
 Respect : Everyone respects each other.
 Courage : Giving and accepting feedback, providing realistic estimates, even if stakeholders
don't like the truth, requires courage. 63
EXTREME PROGRAMMING PROCESS MODEL

64
PLANNING
 Planning activities or planning game
 Listening(requirement gathering)
 User stories (Users describes required functionalities of the software that is to be built)
 Values(Users will also assign priority number) and place in Index card.
 Cost(measured in development weeks)
 High cost → Split the stories, re-assignment of values and costs.
 Commitment(agreement by Customer and developers on stories to be included, release date and other project
matter)
 Release(s/w increment that cover a small part of the functionality or features required ),
 XP team then orders stories that are to be develop.
 Story development Ordering (All stories immediately, Higher value stories first, riskiest stories first)
 Iteration plan (plans about what functionalities to be completed in how much time in every iteration and total number
of iterations)
 Project velocity (Computes number of customer stories implemented in first release)
 Acceptance test (Eligibility criteria for acceptance of software during deployment).
65
 Stories can be added ,change in values assigned to existing stories, split stories or eliminate some stories
 Reconsideration and modification of plan accordingly
Planning activities or planning game
Listening(requirement gathering)
Team members will communicate and collaborate with stakeholders to get
user stories (Users describes required functionalities of the software that is to be built).
Users will also assign values(priority number) to the user stories and will be placed into index card.
XP Team will then assess each stories and assign some cost(measured in development weeks) after
examining the user stories.
In case of higher cost, customers are requested to split the stories, re-assignment of values and costs.
After basic commitment(agreement by Customer and developers on stories to be included, release
date and other project matter) for a release(s/w increment that cover a small part of the functionality
or features required ), XP team then orders stories that are to be develop.
Team generates Iteration plan (plans about What functionalities to be completed in how much time in
every iteration and total number of iterations) from user stories.
After releasing s/w , computes project velocity (number of customer stories implemented in first
release) that helps in deciding delivery date and schedule plan for the subsequent releases,
modification in planning if there is over commitment.
They will also plan acceptance test (Eligibility criteria for acceptance of software during deployment).
As the process progress, user may go on adding new stories and they may also keep changing the
assigned values of the existing stories, split stories or eliminate some stories
66
DESIGN

 Simplicity without compromising performance, accuracy or efficiency and without excluding core
functionality.
 CRC card Class Responsibility Collaborator(to think about your project in terms of object-oriented
context and tries to identify and organize the classes that are related to current software increment)
 CRC cards are the only design work product produced as a part of process.
 Spike solutions (operational prototype for that much portion of design is to created immediately in
case of difficult design problem)
 It helps in performing risk analysis, exploring different aspects before implementation starts.
 Refactoring (trying to optimize the design by improving internal structure of the design without
affecting its external behavior or functionalities, minimizes the chances of introducing bugs)
67
XP value of simplicity will be rigorously followed.
Simple design (Keep It Simple) without compromising performance, accuracy or efficiency and
without excluding core functionality.
Most immediate or prioritized requirements are to be implemented first in simplest possible way
by eliminating extra functionality which are not needed right now.
CRC card Class Responsibility Collaborator(to think about your project in terms of object-
oriented context and tries to identify and organize the classes that are related to current software
increment) is like a card with class(has some objects who have to perform assigned tasks ),
responsibilities (task assigned) and collaborator (to work together with other objects to perform
assigned task or complete the responsibilities).
CRC cards are the only design work product produced as a part of process.
In case of difficult design problem, spike solutions (operational prototype for that much portion of
design is to created immediately) are created, implemented and evaluated.
It helps in performing risk analysis, exploring different aspects before implementation starts.
Refactoring (trying to optimize the design by improving internal structure of the design without
affecting its external behavior or functionalities)

68
CODING
 Unit tests (every individual units gets tested for their functionality and feedback)
 Developing unit tests → coding (code must pass that respective unit test to meet the user stories.)
 Pair programing (One person tries to do the proper coding and other member ensures coding
standards, examines the code to provide the assurance that it will pass the unit test, successful
implementation of user stories.)
 Provides real-time problem solving and real-time quality assurance.
 Continuous integration(combing work done by different teams) to avoid compatibility interfacing
problems.
 Smoke testing (helps to uncover error early)
 Applying developed unit tests after coding provides immediate response from software to developer
 Collective Code Ownership (Each team member can change or refactor any part of the code) 69

 40-Hour Work Week (No overtime) , Design occurs both before and after coding.
Before start with the coding, XP team develops a series of unit tests(every individual units gets
tested for their functionality and feedback) to validate the code against the stories included in that
release.
After developing unit tests, team start coding with keeping in mind that the code must pass that
respective unit test to meet the user stories.
Pair programing : One person tries to do the proper coding and other member examines the code
to provide the assurance that it will pass the unit test, successful implementation of user stories. So,
it does real time problem solving and quality assurance.
Continuous integration(combing work done by different teams) will help to avoid combability
interfacing problems.
Applying already developed unit tests after coding will provide immediate response from software to
developer
XP encourages Refactoring : a design technique that improves the internal structure of the code by
removing some complexities, but external behaviors remains unaffected minimizes the chances of
introducing bugs.
Design occurs both before and after coding.

70
TESTING

 Automated Unit test

 Continuous integration testing (After integrating all units, do they interact properly)
 System testing
 Regression testing strategy
 Acceptance testing or customer test (derived form the user stories and specified by the customer
only, focuses on overall features and functionalities of the system and to check for users'
requirements get fulfilled or not.)
 Integration and validation testing on daily basis.
 Fixing small problems every hour, will take less time than fixing huge problem just before deadline.
71
Continuous integration testing: After integrating all units, do they integrate properly
System testing
Unit test created should be automated which encourages regression testing strategy whenever code is
modified on daily basis.
Acceptance testing or customer test : derived form the user stories and specified by the customer
only, focuses on overall features and functionalities of the system and to check for users requirements
get fulfilled or not.
Fixing small problems every hour, will take less time then fixing huge problem just before deadline.
After getting users feedback software will be ready for next increment.

72
EXTREME PROGRAMMING
Advantages
 Fewer documents
 Collaboration with customers Disadvantages
 Flexibility to developers  Depend heavily on customer interaction
 Easy to manage  Transfer of technology to new team is
 Faster release of working software quite complected due to lack of
documents.
 Visible and accountable
 Code overcomes design
 Less risky
 Constant feedback
 Employee satisfaction and retention
 Supports teamwork 73

 Small team (4-8 people)

SCRUM

 One of the frameworks using which we can implement agile is SCRUM.

 The name has been derived from an activity that occurs during a rugby match, like wise a scrum can be
characterized by developers putting their heads together to address complex problems.
 Lightweight, iterative and incremental model
 Used not only in IT sector but also in research, sales, marketing, banking, pharmaceutical sector also.
 Widely used or adopted model at present.
 Breaks down the development phases into stages or cycle called “sprint”. (to complete work in limited time
duration of 2 weeks to 1 month)
 Once a sprint gets complete, it will get reviewed by stakeholder through meetings, all the suggestions and changes
to be included in next sprint.
 5 core values are commitment, courage, focus, openness, respect. 74
Product
backlog
refinement

1 scrum team

Potentially
Iterative-Incremental shippable product
Development & delivery increment

75
SCRUM ARTIFACTS

 Scrum Teams use tools called Scrum artifacts to solve problems and manage projects.
 The Product Backlog is dynamic and prioritized list of features, requirements, enhancements, and fixes that
must be completed for project success. It is essentially the team’s to-do list, which is constantly revisited and
reprioritized to adapt to market changes. The product owner maintains and updates the list, removing irrelevant
items or adding new requests from customers.
 The Sprint Backlog is the list of items to be completed by the development team in the current Sprint cycle.
Before each Sprint, the team chooses which items it will work on from the Product Backlog. A Sprint Backlog is
flexible and can evolve during a Sprint.
 The Increment is a step towards a goal or vision. It is the usable end product from a Sprint. Teams can adopt
different methods to define and demonstrate their Sprint Goals. It produces potentially Shippable product
increment.

76
SCRUM ROLES

 A Scrum Team needs three specific roles: a Product Owner, Scrum leader, and development team.
 The Product Owner gathers the requirements form customers and provides it to developers.
 focuses on ensuring the development team delivers the most value to the business.
 They understand and prioritize the changing needs of end users and customers.
 Effective product owners do the following:
• Give the team clear guidance on which features to deliver next.
• Bridge the gap between what the business wants and what the team understands.
• Decide when and how frequently releases should happen.

77
SCRUM ROLES

 Scrum masters are responsible for managing entire scrum working.

 Also responsible for doing the following:
• Schedule the resources needed for each Sprint.
• Facilitate other Sprint events and team meetings.
• Lead digital transformation within the team.
• Facilitate any team training when adopting new technologies.
• Communicate with external groups to solve any challenges the team might be facing.

78
SCRUM ROLES

 The Scrum Team (6-8 people) consists of testers, designers, UX specialists, Ops engineers, and developers.
 Team members have different skill sets and cross-train each other, so no one person becomes a bottleneck
in delivering work.
 Scrum development teams do the following:
• Work collaboratively to ensure a successful Sprint completion.
• Champion sustainable development practices.
• Self-organize and approach their projects with an evident we attitude.
• Drive the planning and estimating for how much work they can complete for each Sprint.

79
SCRUM EVENTS

 Scrum events or Scrum ceremonies are a set of sequential meetings that Scrum Teams perform regularly.
 Sprint Planning
 In this event, the team estimates the work to be completed in the next Sprint. Members define Sprint Goals that
are specific, measurable, and attainable. At the end of the planning meeting, every Scrum member knows how
each Increment can be delivered in the Sprint.
 Sprint
 A Sprint is the actual time period when the Scrum Team works together to finish an Increment. Two to four weeks
is the typical length for a sprint. The more complex the work and the more unknowns, the shorter the Sprint
should be.

80
SCRUM EVENTS

 Daily Scrum or stand-up

 A Daily Scrum is a short meeting in which team members check in and plan for the day. They report on work
completed and voice any challenges in meeting Sprint Goals. It is called a stand-up because it aims to keep the
meeting as short as practical—like when everybody is standing.
 Sprint Review
 At the end of the Sprint, the team gets together for an informal session to review the work completed and
showcase it to stakeholders. The Product Owner might also rework the Product Backlog based on the current
Sprint.
 Sprint Retrospective
 The team comes together to document and discuss what worked well and what didn’t work during the Sprint,
what could be improved and what we will commit to include in the next sprint. These Ideas generated are used
to improve future Sprints.

81
82
SCRUM
Advantages Disadvantages

 Freedom and adaptation

 High-quality, low-risk product  Efficient for small size team only

 Reduced development time up-to 40%  No changes in current sprint

 High rate of Customer satisfaction

83
4P OF MANAGEMENT IN SOFTWARE DEVELOPMENT

 People
 Product
 Process
 Project

84