SOFTWARE

DEVELOPMENT
LIFE CYCLE (SDLC)
 WHAT IS SDLC?
 SDLC is a systematic process for building software that ensures the quality and correctness of
the software built , which meets requirements of the customer and gets completed in
predefined time and cost.
 SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software.
 Every phase of the SDLC life Cycle has its own process and deliverables that feed into the
next phase.
 SDLC stands for Software Development Life Cycle and is also referred to as the Application
Development life-cycle
SDLC PHASES
 REQUIREMENT COLLECTION AND ANALYSIS
 The requirement collection and analysis is the first stage in the SDLC process.
 It is conducted by the senior team members with inputs from all the stakeholders and
domain experts in the industry.
 Planning for the quality assurance requirements and recognition of the risks involved is also
done at this stage.
 This stage gives a clearer picture of the scope of the entire project and the anticipated
issues, opportunities, and directives which triggered the project.
 Requirements Gathering stage need teams to get detailed and precise requirements. This
helps companies to finalize the necessary timeline to finish the work of that system.
 PHASE 2: FEASIBILITY STUDY
 Next SDLC phase is to define and document software needs.
 This process is conducted with the help of 'Software Requirement Specification'
document also known as 'SRS' document.
 There are mainly five types of feasibilities checks:
• Economic: Can we complete the project within the budget or not?
• Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
• Operation feasibility: Can we create operations which is expected by the client?
• Technical: Need to check whether the current computer system, technologies can
support the software
• Schedule: Decide that the project can be completed within the given schedule or not.
PHASE 3: DESIGN
 the system and software design  High-Level Design (HLD)
documents are prepared as per the - Brief description and name of each module
requirement specification document.
- An outline about the functionality of every
 This helps define overall system module
architecture.
- Interface relationship and dependencies
 This design phase serves as input for the
between modules
next phase of the model.
- Database tables identified along with their
 There are two kinds of design documents
key elements
developed in this phase:
- Complete architecture diagrams along with
technology details
PHASE 3 : DESIGN CONTD..
 Low-Level Design(LLD)

- Functional logic of the modules

- Database tables, which include type and size
- Complete detail of the interface
- Addresses all types of dependency issues
-Listing of error messages
-Complete input and outputs for every module
PHASE 4: CODING
 Once the system design phase is over, the next phase is coding.
 In this phase, developers start building the entire system by writing code using the chosen
programming language.
 In the coding phase, tasks are divided into units or modules and assigned to the various
developers. It is the longest phase of the Software Development Life Cycle process.
 In this phase, Developer needs to follow certain predefined coding guidelines.
PHASE 5: TESTING
 Once the coding is complete, it is deployed in the testing environment.
 The testing team starts testing the functionality of the entire system.
 This is done to verify that the entire application works according to the customer
requirement.
 During this phase, quality assurance (QA) and testing team may find some bugs/defects
which they communicate to developers.
 The development team fixes the bug and send back to QA for a re-test.
 This process continues until the software is bug-free, stable, and working according to the
business needs of that system.
PHASE 6: INSTALLATION/DEPLOYMENT

 Once the software testing phase is over and no bugs or errors left in the system then the
final deployment process starts.
 Based on the feedback given by the project manager, the final software is released and
checked for deployment issues if any.
PHASE 7: MAINTENANCE
 Once the system is deployed, and customers start using the developed system, following 3
activities occur
• Bug fixing - bugs are reported because of some scenarios which are not tested at all
• Upgrade - Upgrading the application to the newer versions of the Software
• Enhancement - Adding some new features into the existing software
THE WATERFALL MODEL
 It is also referred to as a linear-sequential life cycle model.
 It is very simple to understand and use.
 In a waterfall model, each phase must be completed before the next phase can begin
and there is no overlapping in the phases.
 The Waterfall model is the earliest SDLC approach that was used for software
development.
•Requirement Gathering and analysis − All possible requirements of the system to be developed are captured
in this phase and documented in a requirement specification document.

•System Design − The requirement specifications from first phase are studied in this phase and the system
design is prepared. This system design helps in specifying hardware and system requirements and helps in
defining the overall system architecture.

•Implementation − With inputs from the system design, the system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is
referred to as Unit Testing.

•Integration and Testing − All the units developed in the implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is tested for any faults and failures.

•Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the
customer environment or released into the market.

•Maintenance − There are some issues which come up in the client environment. To fix those issues, patches
are released. Also to enhance the product some better versions are released. Maintenance is done to deliver
these changes in the customer environment.
 WATERFALL MODEL - APPLICATION
 Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors.
 Some situations where the use of Waterfall model is most appropriate are −
• Requirements are very well documented, clear and fixed, no ambiguous requirements
• Technology is understood and is not dynamic.
• Ample resources with required expertise are available to support the product.
• The project is short.
MAJOR ADVANTAGES OF THE
WATERFALL MODEL
 Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
 DISADVANTAGES OF THE WATERFALL
MODEL
• No working software is produced until late during the life cycle.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
ITERATIVE MODEL
ITERATIVE MODEL
 Iterative process starts with a simple implementation of a subset of the software
requirements and iteratively enhances the evolving versions until the full system is
implemented.
 At each iteration, design modifications are made and new functional capabilities are
added.
 ITERATIVE MODEL - APPLICATION

• Requirements of the complete system are clearly defined and understood.

• Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
• A new technology is being used and is being learnt by the development team while
working on the project.
• Resources with needed skill sets are not available and are planned to be used on
contract basis for specific iterations.
• There are some high-risk features and goals which may change in the future.
ITERATIVE MODEL- ADVANTAGES AND DISADVANTAGES
 The advantage of this model is that there is a working model of the system at a very
early stage of development, which makes it easier to find functional or design flaws.
 Finding issues at an early stage of development enables to take corrective measures
in a limited budget.
 The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software
system into further small serviceable increments/modules.
INCREMENTAL PROCESS
MODEL
 Incremental process model is also know as Successive version model.
 First, a simple working system implementing only a few basic features is built and then that is
delivered to the customer.
 Then thereafter many successive iterations/ versions are implemented and delivered to the
customer until the desired system is released.
INCREMENTAL PROCESS
MODEL
INCREMENTAL PROCESS
MODEL
 Eg. Word processing software:
 1st increment- basic file management, editing, and document production functions
 2 nd increment- more sophisticated editing and document production capabilities
 3 rd increment-spelling and grammar checking
 4 th increment - advanced page layout capability
INCREMENTAL PROCESS
MODEL
 the first increment is often a core product. (basic requirements are addressed )but many
supplementary features remain undelivered.
 The core product is used by the customer (or undergoes detailed evaluation). As a result of use
and/ or evaluation, a plan is developed for the next increment.
 The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
 This process is repeated following the delivery of each increment, until the complete product
is produced.
 WHEN TO USE THE INCREMENTAL MODEL:

• There is a need to get a product to the market early.

• A new technology is being used
• Resources with needed skill set are not available
• There are some high risk features and goals.
ADVANTAGES OF INCREMENTAL MODEL:

• Generates working software quickly and early during the software life cycle.
• This model is more flexible – less costly to change scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Easier to manage risk because risky pieces are identified and handled during
iteration.
EVOLUTIONARY PROCESS
MODEL
 Software, evolves over a period of time. Business and product requirements often change as
development proceeds
 tight market deadlines make completion of a comprehensive software product impossible, but
a limited version must be introduced to meet competitive or business pressure;
 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 these and similar situations, you need a process model that has been explicitly designed to
accommodate a product that grows and changes.
 Evolutionary models are iterative. They enables you to develop increasingly more complete
versions of the software.
EVOLUTIONARY PROCESS
MODEL- PROTOTYPING
STEPS OF THE PROTOTYPING MODEL
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the
departments or aspects of the existing system.

2. A preliminary, simple design is created for the new system.

3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation
of the characteristics of the final product.

4. The users thoroughly evaluate the first prototype and note its strengths and weaknesses, what needs to be added and what should to be removed. The
developer collects and analyzes the remarks from the users.

5. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.

6. The second prototype is evaluated in the same manner as was the first prototype.

7. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.

8. The final system is constructed, based on the final prototype.

9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures .
ADVANTAGES OF THE PROTOTYPING
MODEL

• Customers get a say in the product early on, increasing customer satisfaction.
• Missing functionality and errors are detected easily.
• Prototypes can be reused in future, more complicated projects.
• It emphasizes team communication and flexible design practices.
• Users have a better understanding of how the product works.
• Quicker customer feedback provides a better idea of customer needs.
DISADVANTAGES OF THE PROTOTYPING
MODEL
 it is more costly in terms of time and money when compared to alternative
development methods, such as the spiral or Waterfall model.
 Since in most cases the prototype is discarded, some companies may not see the
value in taking this approach.
 Additionally, inviting customer feedback so early on in the development lifecycle
may cause problems.
 One problem is that there may be an excessive amount of change requests that
may be hard to accommodate.
 Another issue could arise if after seeing the prototype, the customer demands a
quicker final release or becomes uninterested in the product.
SPIRAL MODEL-
(EVOLUTIONARY MODEL)
 Spiral model is one of the most important Software Development Life Cycle models, which
provides support for Risk Handling.
 In its diagrammatic representation, it looks like a spiral with many loops.
 The exact number of loops of the spiral is unknown and can vary from project to project. Each
loop of the spiral is called a Phase of the software development process.
 The exact number of phases needed to develop the product can be varied by the project
manager depending upon the project risks.
 As the project manager dynamically determines the number of phases, so the project manager
has an important role to develop a product using the spiral model.
 SPIRAL MODEL
 Each phase of the Spiral Model is divided into four quadrants.

1.Objectives determination and identify alternative solutions: Requirements are gathered from
the customers and the objectives are identified, elaborated, and analyzed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.
2.Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated
to select the best possible solution. Then the risks associated with that solution are identified and
the risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is
built for the best possible solution.
3.Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
4.Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.
SPIRAL MODEL
 The Radius of the spiral at any point represents the expenses(cost) of the project so far, and the
angular dimension represents the progress made so far in the current phase.
SPIRAL MODEL
RISK HANDLING IN SPIRAL
MODEL
 The spiral model supports coping up with risks by providing the scope to build a prototype at
every phase of the software development.
 The Prototyping Model also supports risk handling, but the risks must be identified
completely before the start of the development work of the project.
 But in real life project risk may occur after the development work starts, in that case, we
cannot use the Prototyping Model.
 In each phase of the Spiral Model, the features of the product dated are analyzed, and the risks
at that point in time are identified and are resolved through prototyping. Thus, this model is
much more flexible compared to other SDLC models.
WHY SPIRAL MODEL IS CALLED META
MODEL?

 Because it subsumes all the other SDLC models. For example, a single loop spiral represents
the Iterative Waterfall Model.
 The spiral model uses the approach of the Prototyping Model by building a prototype at the
start of each phase as a risk-handling technique.
 Also, the spiral model can be considered as supporting the Iterative model – the iterations
are performed along the spiral till the complete system is built.
ADVANTAGES OF SPIRAL
MODEL:
1. Risk Handling: useful in case of the projects with many unknown risks that occur as the
development proceeds, Spiral Model is the best development model to follow due to the risk
analysis and risk handling at every phase.

2. Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.

3. Flexibility in Requirements: Change requests in the Requirements at later phase can be

incorporated accurately by using this model.

4. Customer Satisfaction: Customer can see the development of the product at the early phase
of the software development and thus, they habituated with the system by using it before
completion of the total product.
 DISADVANTAGES OF SPIRAL MODEL:

1. Complex: The Spiral Model is much more complex than other SDLC models.

2. Expensive: Spiral Model is not suitable for small projects as it is expensive.

3. Too much dependability on Risk Analysis: The successful completion of the project is very
much dependent on Risk Analysis. Without very highly experienced experts, it is going to be a
failure to develop a project using this model.

4. Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
 RAD MODEL OR RAPID APPLICATION DEVELOPMENT MODEL

 It is a software development process based on prototyping without any specific planning.

 in RAD model, there is less attention paid to the planning and more priority is given to the
development tasks.
 It targets at developing software in a short span of time.
 SDLC RAD modeling has following phases

1) Business Modeling
2) Data Modeling
3) Process Modeling
4)Application Generation
5) Testing and Turnover
RAD MODEL
 it focuses on source and destination of the information.
 It emphasizes on delivering projects in small pieces; the larger
projects are divided into a series of smaller projects.
 The main features of RAD modeling are that it focuses on the
reuse of templates, tools, processes, and code.
 DIFFERENT PHASES OF RAD MODEL
RAD Model Phases Activities performed in RAD Modeling

Business Modeling •On basis of the flow of information and distribution between various business
channels, the product is designed

Data Modeling •The information collected from business modeling is refined into a set of data objects
that are significant for the business

Process Modeling •The data object that is declared in the data modeling phase is transformed to achieve
the information flow necessary to implement a business function

Application •Automated tools are used for the construction of the software, to convert process and
Generation data models into prototypes

Testing and •As prototypes are individually tested during every iteration, the overall testing time is
Turnover reduced in RAD.
WHEN TO USE RAD METHODOLOGY?
• When a system needs to be produced in a short span of time (2-3 months)
• When technical risk is less
• When there is a necessity to create a system that can be modularized in 2-3 months of time
• When a budget is high enough to afford designers for modeling along with the cost of
automated tools for code generation
 ADVANTAGES OF THE RAD MODEL
•AS the RAD model uses CASE tools to automate major processes of the RAD lifecycle,
the quick delivery of the product is possible.

•RAD process uses skilled and efficient people that results in quick delivery and high-
quality product.

• As the RAD model focuses on constructing prototypes, these prototypes can be reused
later in the same project or for some other project.

 There is a dedicated team called ‘User Review Board’ to review the prototype that helps
both users and developers to review the prototype before the final product.
 ADVANTAGES OF RAD MODEL
• The prototypes can also help in identifying any potential risk factors.
• RAD model encourages customer satisfaction as customers are involved from the
beginning in the lifecycle; most importantly they can see the working prototype and
provide their feedback.
• RAD process can be cost-effective as it uses fewer developers.
DISADVANTAGES OF RAD MODEL

• Lack of scalability in the final product which would have been achieved if it had been designed as a full
application from the beginning rather than a prototype.

• RAD process uses timeboxing. certain features are postponed in future versions to develop the product in a
short time frame. Due to this, it is possible that the product is less featured than the products developed using
traditional models.

• RAD model is not suitable for all the projects; the RAD model suits small and medium-sized (development
time) projects.

• RAD process encourages a small team (around 2 to 6 developers); at the same time, it demands high quality
and high speed in the developed product. To achieve this, it is very crucial that all the members of the team
should be highly skilled and familiar with the tools being used.
• As RAD process involves customers from the beginning of the product lifecycle. If the customers are not
available at the important decision-making moments or cannot make the decisions quickly, it might affect the
quality and speed of the product development.
 DISADVANTAGES OF RAD MODEL
• There is too much dependency on the people involved in the RAD project; if even one
of them is not able to perform his/her task adequately, it might affect product
development.

• RAD process demands high team collaboration between all the parties involved in the
project; most importantly, the management’s role becomes crucial.

• RAD model does not suit the systems that cannot be broken down into modules.
GENERIC PROCESS MODEL – FRAMEWORK
ACTIVITY, TASK SET, PROCESS PATTERNS

 Software Process
 The software process comprises activities performed to create a software product. It deals with
the technical and management aspects of software development.
 Software process includes :
• Tasks – focus on a small, specific objective.
• Action – set of tasks that produce a major work product.
• Activities – group of related tasks and actions for a major objective.
 PROCESS FRAMEWORK
ACTIVITIES
• Communication – Communicate with stakeholders and customers to obtain objectives of the
system and requirements for the software.
• Planning – Software project plan has details of resources needed, tasks and risk factors likely
to occur, schedule.
• Modelling – Architectural models and design to better understand the problem and for work
towards the best solution.
• Construction – Generation of code and testing of the system to rectify errors and ensuring all
specified requirements are met.
• Deployment – Entire software product or partially completed product is delivered to the
customer for evaluation and feedback.
 Umbrella activities

Activities that occur throughout a software process for better management and tracking of the project are called Umbrella activities
 Software project tracking and control – Compare the progress of the project with the plan and take steps to maintain a planned
schedule.
 Risk management – Evaluate risks that can affect the outcome and quality of the software product.

 Software quality assurance (SQA) – Conduct activities to ensure the quality of the product.

 Technical reviews – Assessment of errors and correction done at each stage of activity.

 Measurement – All the measurements of the project and product features.

 Software configuration management (SCM) – Controlling and tracking changes in the software.

 Reusability management – Back up work products for reuse and apply the mechanism to achieve reusable software components.

 Work product preparation and production – Project planning and other activities used to create work product are documented.
DEFINING A FRAMEWORK ACTIVITY
 Consider communication activity.
 For small project, this can be defined as having tasks set:
• Making a phone call with stakeholder.
• Discuss requirements and note them down.
• Organize requirements.
• Mail stakeholder for review and approval.
• For large projects, this may have extended actions such as feasibility study, elicitation of
requirements, elaboration of requirements, specification documents, validation etc.
 IDENTIFYING A TASK SET
 Task set is the actual work to be done to achieve an objective of engineering action. For small
project, consider elicitation (extraction) action in communication activity, this may
include :
• Prepare a list of stakeholders of the project.
• Organize a meeting for stakeholders.
• Discuss requirements.
• Finalize requirements list.
• Make a list of issues raised.
• For large projects extraneous steps may be added to elicitation such as interviewing each
stakeholder separately before the group meeting, more techniques are applied in discussing
requirements…etc.
 PROCESS FLOW

PROCESS FLOW DETERMINES HOW ACTIVITIES, ACTIONS AND TASKS ARE ARRANGED
WITH RESPECT TO SEQUENCE AND TIME.

1)Linear process flow

Linear process flow executes each activity in sequence.
2) Iterative process flow
Iterative process flow repeats one or more activities before starting next.
3)Evolutionary process flow
Evolutionary process flow carry out activities in a circular way.
4) Parallel process flow
Parallel process flow execute one or more activities in parallel with each other.
 CAPABILITY MATURITY
MODEL (CMM)
 Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software
process.
 CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1987.
• It is not a software process model. It is a framework that is used to analyze the approach and techniques
followed by any organization to develop software products.
• Describes an evolutionary improvement path for software organizations from an ad hoc, immature process to a
mature, disciplined one.
• Provides guidance on how to gain control of processes for developing and maintaining software and how to
evolve toward a culture of software engineering and management excellence.
• It also provides guidelines to further enhance the maturity of the process used to develop those software
products.
• It is based on profound feedback and development practices adopted by the most successful organizations
worldwide.
• This model describes a strategy for software process improvement that should be followed by moving through 5
different levels.
• Each level of maturity shows a process capability level. All the levels except level-1 are further described by
Key Process Areas (KPA’s).
PROCESS MATURITY CONCEPTS

 Software Process
 set of activities, methods, practices, and transformations that people use to
develop and maintain software and the associated products (e.g., project
plans, design documents, code, test cases, user manuals)
 Software Process Capability
 describes the range of expected results that can be achieved by following a
software process
 means of predicting the most likely outcomes to be expected from the next
software project the organization undertakes
PROCESS MATURITY CONCEPTS
 Software Process Performance
 actual results achieved by following a software process

 Software Process Maturity

 extent to which a specific process is explicitly defined, managed, measured,
controlled and effective
 implies potential growth in capability
 indicates richness of process and consistency with which it is applied in
projects throughout the organization
LEVEL 1 INITIAL
 At level 1, the process is usually chaotic and ad hoc
 A capability is characterized on the basis of the individuals and not of the organization
 Progress not measured
 Products developed are often off schedule and over budget
 Wide variations in the schedule, cost, functionality, and quality targets
 KPA- None. A project is Total Chaos
 LEVEL-2: REPEATABLE –
• Focuses on establishing basic project management policies.
• Experience with earlier projects is used for managing new similar natured projects.
• Basic process management processes are established to track cost, schedule, and functionality. The
necessary process discipline is in place to repeat earlier successes on projects with similar
applications.
• Project Planning- It includes defining resources required, goals, constraints, etc. for the project. It
presents a detailed plan to be followed systematically for the successful completion of good quality
software.
• Configuration Management- The focus is on maintaining the performance of the software product,
including all its components, for the entire lifecycle.
• Requirements Management- It includes the management of customer reviews and feedback which
result in some changes in the requirement set. It also consists of accommodation of those modified
requirements.
• Subcontract Management- It focuses on the effective management of qualified software contractors
i.e. it manages the parts of the software which are developed by third parties.
• Software Quality Assurance- It guarantees a good quality software product by following certain rules
and quality standard guidelines while developing.
 LEVEL-3: DEFINED –
• The software process for both management and engineering activities is documented, standardized,
and integrated into a standard software process for the organization. All projects use an approved,
tailored version of the organization’s standard software process for developing an maintaining
software.
• Peer Reviews- In this method, defects are removed by using a number of review methods like
walkthroughs, inspections, buddy checks, etc.
• Intergroup Coordination- It consists of planned interactions between different development teams
to ensure efficient and proper fulfillment of customer needs.
• Organization Process Definition- Its key focus is on the development and maintenance of the
standard development processes.
• Organization Process Focus- It includes activities and practices that should be followed to improve
the process capabilities of an organization.
• Training Programs- It focuses on the enhancement of knowledge and skills of the team members
including the developers and ensuring an increase in work efficiency.
LEVEL-4: MANAGED
• At this stage, quantitative quality goals are set for the organization for software products as
well as software processes.
• The measurements made help the organization to predict the product and process quality
within some limits defined quantitatively.

• Software Quality Management- It includes the establishment of plans and strategies to

develop quantitative analysis and understanding of the product’s quality.
• Quantitative Management- It focuses on controlling the project performance in a
quantitative manner.
 LEVEL-5: OPTIMIZING –
• This is the highest level of process maturity in CMM and focuses on continuous process
improvement in the organization using quantitative feedback.
• Use of new tools, techniques, and evaluation of software processes is done to prevent
recurrence of known defects.
• Process Change Management- Its focus is on the continuous improvement of the
organization’s software processes to improve productivity, quality, and cycle time for the
software product.
• Technology Change Management- It consists of the identification and use of new
technologies to improve product quality and decrease product development time.
• Defect Prevention- It focuses on the identification of causes of defects and prevents them from
recurring in future projects by improving project-defined processes.
INTERNAL STRUCTURE TO MATURITY LEVELS
 Except for level 1, each level is decomposed into key process areas
(KPA)
 Each KPA identifies a cluster of related activities that, when
performed collectively, achieve a set of goals considered important
for enhancing software capability.
 commitment
 ability
 activity
 measurement
 verification
 WHY USE CMM?
 CMM act as a "seal of approval" in the software industry. It helps in various ways to improve
the software quality.
• It guides towards repeatable standard process and hence reduce the learning time on how
to get things done
• Practicing CMM means practicing standard protocol for development, which means it not
only helps the team to save time but also gives a clear view of what to do and what to
expect
• It acts as a commuter between the project and the team
• CMM efforts are always towards the improvement of the process
AGILE MODEL OF SOFTWARE DEVELOPMENT

 Agile means ‘ability to move quickly and easily’ and responding swiftly to change – this is a key
aspect of Agile software development.
 The difficulties faced while using waterfall model are handling change requests from customers during
project development and the high cost and time required to incorporate these changes.
 To overcome these drawbacks of Waterfall model, in the mid-1990s the Agile Software Development
model was proposed.
 The Agile model was primarily designed to help a project to adapt to change requests quickly.
 So, the main aim of the Agile model is to facilitate quick project completion.
 The agile software development emphasizes on four core values.
1. Individual and team interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Note: Contract negotiation is the process of give and take the parties go through to reach an
agreement.
AGILE MODEL
• At a high level, non-Agile projects allocate extensive periods of time for
Requirements gathering, design, development, testing and User Acceptance
Testing, before finally deploying the project.
• In contrast to this, Agile projects have Sprints or iterations which are shorter in
duration (Sprints/iterations can vary from 2 weeks to 2 months) during which pre-
determined features are developed and delivered.
• Agile projects can have one or more iterations and deliver the complete product
at the end of the final iteration.
AGILE MODEL

Example of Agile software development

Example: Adobe is working on project to come up with a competing product for
Microsoft Word, that provides all the features provided by Microsoft Word and
any other features requested by the marketing team. The final product needs to
be ready in 10 months of time. Let us see how this project is executed in
traditional and Agile methodologies.
In traditional Waterfall model –
At a high level, the project teams would spend 15% of their time on gathering
requirements and analysis (1.5 months)
20% of their time on design (2 months)
40% on coding (4 months) and unit testing
20% on System and Integration testing (2 months).
 AGILE MODEL
In this approach, the customer does not get to see the end product until the end of the project, when it
becomes too late to make significant changes.
AGILE MODEL

 With Agile development methodology –

• In the Agile methodology, each project is broken up into several ‘Iterations’.
• All Iterations should be of the same time duration (between 2 to 8 weeks).
• At the end of each iteration, a working product should be delivered.
• In simple terms, in the Agile approach the project will be broken up into X number of
releases
• Rather than spending 1.5 months on requirements gathering, in Agile software
development, the team will decide the basic core features that are required in the
product and decide which of these features can be developed in the first iteration.
• Any remaining features that cannot be delivered in the first iteration will be taken up
in the next iteration or subsequent iterations, based on priority.
• At the end of the first iterations, the team will deliver a working software with the
features that were finalized for that iteration.
• There will be X iterations and at the end of each iteration the customer is delivered a
working software that is incrementally enhanced and updated with the features that
were shortlisted for that iteration
AGILE MODEL
AGILE EXAMPLE(ADOBE )
STEPS INVOLVE IN AGILE
SDLC MODELS ARE:
• Requirement gathering
• Requirement Analysis
• Design
• Coding
• Unit testing
• Acceptance testing
 PRINCIPLES OF AGILE MODEL

• Agile project usually includes a customer representative on the team.

• At the end of each iteration stakeholders and the customer representative review, the progress
made and re-evaluate the requirements.
• Agile model relies on working software deployment rather than comprehensive documentation.
• Frequent delivery of incremental versions of the software to the customer representative in
intervals of few weeks.
• Requirement change requests from the customer are encouraged and efficiently incorporated.
• Enhanced communication among the development team members can be achieved through face-
to-face communication rather than through the exchange of formal documents.
• It is recommended that the development team size should be kept small (5 to 9 people) to help
the team members meaningfully engage in face-to-face communication and have collaborative
work environment.
 Agile development process usually deploy Pair Programming. In Pair programming, two
programmers work together at one work-station. One does coding while the other reviews the
code as it is typed in. The two programmers switch their roles every hour or so.
 ADVANTAGES AND DISADVANTAGES OF AGILE MODEL

 Advantages:
• Working through Pair programming produce well written compact programs which has fewer errors as
compared to programmers working alone.
• It reduces total development time of the whole project.
• Customer representatives get the idea of updated software products after each iteration. So, it is easy for
him to change any requirement if needed.
 Disadvantages:
• Due to lack of formal documents, it creates confusion and important decisions taken during different
phases can be misinterpreted at any time by different team members.
• Due to the absence of proper documentation, when the project completes and the developers are assigned
to another project, maintenance of the developed project can become a problem.
 Parameters Agile Model Non-Agile Models

Approach of this methodology This methodology is very This methodology is not as

flexible and adjustable and can flexible as Agile model and it’s
adapt to the project needs. tough to accommodate changes
in the project.
Measurement of Success The success of the project in In this methodology the
Agile model is measured by the success of the project is
Business value delivered. measured by the Conformation
to plan.
Size of the Project The Project size is usually The project size is Large in
small in Agile model. However non- Agile models.
larger projects can also be
handled using the Scaled Agile
Framework (SAFe).

Style of Management The style of management in The management style in the

Agile model is not centralized. non-Agile models is dictatorial.
It is distributed among the team Only one person is the decision
members. maker and rest of the people
follows him.
 Parameters Agile Model Non-Agile Models
Ability to adapt to change In Agile model the changes are But in non-Agile models the
accepted and adapted as per the changes are not accepted easily in
project needs. the later stages of the
development.

Documentation required Less documentation is required in More documentation is required

Agile. in non-Agile models.

Importance of In Agile model more emphasis is In non-Agile models the more

given to the people that means it’s importance is given to the process
People- Oriented. hence it’s Process- Oreinted.

Cycles or iterations Agile methodology has many But, in Non-Agile methodology

cycles or iterations which is also the cycles are limited.
known as Sprints.

Planning in Advance There is minimal upfront planning In Non-Agile models the planning
in Agile methodology. should be complete before the
development starts.
AGILE PROCESS
EXTREME PROGRAMMING
(XP)
 Extreme Programming (XP) is an agile software development framework that aims to
produce high-qualitative software quickly , being able to adapt to customers’ changing
requirements.
 XP is a set of engineering practices.
 Developers have to go beyond their capabilities while performing these practices.
That’s where the “extreme” in the framework’s title comes from.
THE PROCESS AND ROLES OF EXTREME
PROGRAMMING
 The XP framework normally involves 5 phases or stages of the development process that
iterate continuously:
1) Planning, the first stage, is when the customer meets the development team and presents
the requirements in the form of user stories to describe the desired result.
• The team then estimates the stories and creates a release plan broken down into iterations
needed to cover the required functionality part after part.
• If one or more of the stories can’t be estimated, so-called spikes can be introduced which
means that further research is needed.
2) Designing is actually a part of the planning process, but can be set apart to emphasize its
importance. It’s related to one of the main XP values — simplicity. A good design brings logic
and structure to the system and allows to avoid unnecessary complexities and redundancies.
3) Coding is the phase during which the actual code is created by implementing specific XP
practices such as coding standards, pair programming, continuous integration, and collective
code ownership
THE PROCESS AND ROLES OF EXTREME
PROGRAMMING
4) Testing is the core of extreme programming. It is the regular activity that
involves both unit tests (automated testing to determine if the developed feature
works properly) and acceptance tests (customer testing to verify that the overall
system is created according to the initial requirements).
5) Listening is all about constant communication and feedback. The customers
and project managers are involved to describe the business logic and value that is
expected.
ROLES ASSOCIATED WITH XP
1.Customers are expected to be heavily engaged in the development process by
creating user stories, providing continuous feedback, and making all the necessary
business decisions related to the project.
2.Programmers or developers are the team members that actually create the product.
They are responsible for implementing user stories and conducting user tests
(sometimes a separate Tester role is set apart). Since XP is usually associated with
cross-functional teams, the skill set of such members can be different.
3.Trackers or managers link customers and developers. It’s not a required role and can
be performed by one of the developers. These people organize the meetups, regulate
discussions, and keep track of important progress KPIs.
4.Coaches can be included in the teams as mentors to help with understanding the XP
practices. It’s usually an outside assistant or external consultant who is not involved in
the development process, but has used XP before and so can help avoid mistakes.
 FIVE VALUES OF XP
 Communication
o Software development relies on communication to transfer knowledge from one team member to
everyone else on the team.
o XP stresses the importance of the appropriate kind of communication – face to face discussion with
the aid of a white board or other drawing mechanism.
 Simplicity
o Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid
waste and do only absolutely necessary things such as keep the design of the system as simple as
possible so that it is easier to maintain, support, and revise. Simplicity also means address only the
requirements that you know about; don’t try to predict the future.
 Feedback
o Through constant feedback about their previous efforts, teams can identify areas for improvement
and revise their practices.
o Feedback also supports simple design. team builds something, gathers feedback on design and
implementation, and then adjust the product to move forward.
FIVE VALUES OF XP
 Courage

o courage as “effective action in the face of fear” .

oYou need courage to raise organizational issues that reduce your team’s
effectiveness. You need courage to stop doing something that doesn’t work and try
something else. You need courage to accept and act on feedback, even when it’s
difficult to accept.
 Respect

o The members of your team need to respect each other in order to communicate
with each other, provide and accept feedback that honors your relationship, and to
work together to identify simple designs and solutions.
XP PRACTICES

 The core of XP is the interconnected set of

software development practices listed below.
• Pair Programming
• While it is possible to do these practices in • Collective Ownership
isolation, many teams have found some
practices reinforce the others and should be • Continuous Integration
done in conjunction to fully eliminate the risks
you often face in software development. • 40-hour week
• The Planning Game • On-site Customer
• Small Releases
• Metaphor • Coding Standard
• Simple Design
• Testing
• Refactoring
XP PRACTICES
 The Planning Game
 This is a meeting that occurs at the beginning of an
iteration cycle.
 The development team and the customer get together
to discuss and approve a product’s features.
 At the end of the planning game, developers plan for
the upcoming iteration and release, assigning tasks for each of
them.
 XP PRACTICES
 Simple Design
 Small Releases
XP practitioners highlight that chances
 This practice suggests developing to simplify design are higher after the
the product by making small and product has been in production for
incremental updates. some time.
 Small releases allow developers to writing code for those features you
frequently receive feedback, detect plan to implement right away rather
bugs early, and monitor how the than writing it in advance for other
product works in production.. future features
XP PRACTICES
 TEST DRIVEN DEVELOPMENT-
 XP teams practice test-driven development technique (TDD) that
entails writing an automated unit test before the code itself.
 every piece of code must pass the test to be released. So,
software engineers thereby focus on writing code that can
accomplish the needed function.
That way TDD allows programmers to use immediate feedback to
produce reliable software.
 XP PRACTICES

 Continuous Integration
 Code Refactoring
 Developers always keep the system
 Refactoring is about removing fully integrated.
redundancy, eliminating  development commit code multiple
unnecessary functions, increasing times a day, which is also
code coherency, and at the same called continuous delivery.
time decoupling elements.  Programmers discuss which parts of
 Keep your code clean and simple, the code can be re-used or shared
so you can easily understand and  The policy of shared code helps
modify it when required would be eliminate integration problems.
the advice of any XP team  In addition, automated testing allows
member. developers to detect and fix errors
before deployment.
XP PRACTICES

 Pair Programming
 On-site Customer
 This practice requires two
 according to XP, the end
programmers to work jointly on
customer should fully the same code.
participate in development.
While the first developer
 The customer should be present
focuses on writing, the other one
all the time to answer team reviews code, suggests
questions, set priorities, and improvements, and fixes mistakes
resolve disputes if necessary. along the way.
Such teamwork results in high-
quality software and faster
knowledge sharing but takes
about 15 percent more time.
 XP PRACTICES
 Collective Code Ownership
 Coding Standards
 This practice declares a whole team’s
 A team must have common sets of coding
practices, using the same formats and responsibility for the design of a
styles for code writing. system.
 Each team member can review and
 This allows all team members to read,
share, and refactor code with ease, track update code.
who worked on certain pieces of code, as  The practice helps avoid code
well as make the learning faster for other duplication. The implementation of
programmers. collective code ownership
 Code written according to the same rules encourages the team to cooperate
encourages collective ownership. more and feel free to bring new
ideas.
 XP PRACTICES

 System Metaphor  40-Hour Week

 System metaphor stands for a simple design  XP projects require developers to work
that has a set of certain qualities. fast, be efficient, and sustain the
 First, a design and its structure must be product’s quality.
understandable to new people. They should  they should feel well and rested.
be able to start working on it without
spending too much time examining  Keeping the work-life balance prevents
specifications. professionals from burnout. In XP, the
optimal number of work hours must not
 Second, the naming of classes and methods
exceed 40 hours a week.
should be coherent.
 One overtime a week is possible only if
 Developers should aim at naming an object as
if it already existed, which makes the overall
there will be none the week after.
system design understandable.
SCRUM- AGILE FRAMEWORK
 Scrum (the name is derived from an activity that occurs during a rugby match) is an agile
software development method that was conceived by Jeff Sutherland and his development
team in the early 1990s.
 In recent years, further development on the Scrum methods has been performed by Schwaber
and Beedle
 Scrum principles are consistent with the agile manifesto.
 and are used to guide development activities within a process that incorporates the following
framework activities: requirements, analysis, design, evolution, and delivery.
SCRUM- AGILE FRAMEWORK
 Within each framework activity, work tasks occur within a process pattern called a sprint.
 The work conducted within a sprint (the number of sprints required for each framework
activity will vary depending on product complexity and size) is adapted to the problem at hand
and is defined and often modified in real time by the Scrum team.
 SCRUM ROLES:
 product owner, scrum master and the development team members.

 1) developmentteam- > the development team can be comprised of all kinds of people
including designers, writers, programmers, testers.
The development team’s responsibilities include:
 Delivering the work through the sprint.
 To ensure transparency during the sprint they meet daily at the daily
scrum ( sometimes called a standup).
 The daily scrum provides a dedicated place for team members to seek help,
talk about success and highlight issues and blockers.
• The scrum master might facilitate the daily scrum, but ultimately it is the responsibility of
the development team to run this meeting.
• Scrum meeting help them, as a group, to inspect and adapt the work they are doing and
work in a more effective way.
 THE PRODUCT OWNER: SETTING CLEAR DIRECTION

 The product owner should not only understand the customer, but also have a vision for the
value the scrum team is delivering to the customer.
 The product owner must take inputs from all stake holders and prioritize the work
 Managing the scrum backlog - The product owner should know about everything that is in the
backlog and other people that add items to the product backlog should ensure that they
communicate with the product owner.
 Backlog—a prioritized list of project requirements or features that provide business value for
the customer.
->Items can be added to the backlog at any time (this is how changes are introduced).
The product manager assesses the backlog and updates priorities as required.
 Release management –It is important for the product owner to know when things can and
should be released.
 Stakeholder management- The product owner will have to work with all these people to
effectively ensure that the development team is delivering value.
SCRUM- AGILE FRAMEWORK
 Sprints—consist of work units that are required to achieve a requirement defined in the
backlog that must be fit into a predefined time-box (typically 30 days).
-> Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short-term, but stable environment.
Sprint planning
Meeting
 SCRUM
TASK
BOARD
EXAMPLE
THE SCRUM MASTER: HOLDING IT ALL
TOGETHER

 The scrum master is the role responsible for gluing everything together and ensuring that
scrum is being done well. I
 in practical terms, that means they help the product owner define value, the development team
deliver the value, and the scrum team to get to get better.
 The scrum master is a servant leader which not only describes a supportive style of leadership
but describes what they do on a day-to-day basis.
SCRUM- AGILE FRAMEWORK
 Scrum meetings—are short (typically 15-minute) meetings held daily by the Scrum team.
Three key questions are asked and answered by all team members
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting
SCRUM- AGILE FRAMEWORK
 Scrum Master:>A team leader, called a Scrum master, leads the meeting and assesses the
responses from each person.
-> The Scrum meeting helps the team to uncover potential problems as early as possible.
Also, these daily meetings lead to “knowledge socialization” and thereby promote a self-
organizing team structure.
 Demos—deliver the software increment to the customer so that functionality that has been
implemented can be demonstrated and evaluated by the customer.
->It is important to note that the demo may not contain all planned functionality, but
rather those functions that can be delivered within the time-box that was established
Scrum Process flow
KANBAN-AGILE FRAMEWORK
 Kanban is a framework that falls under the Agile methodology.
 It was developed in the late 1940s by a Japanese engineer named Taiichi Ohno.
 Agile Kanban Framework focuses on visualizing the entire project on boards in order to
increase project transparency and collaboration between team members.
 Kanban is one of the simplest frameworks used as it allows project managers to efficiently
manage and keep track of their projects.
 A distinguishing feature of the Kanban framework among different agile methodologies is its
compatibility with the existing organizational setting.
KANBAN-AGILE FRAMEWORK
 the Kanban methodology adapts the JIT(just in time ) concept used in manufacturing industry.
In software development , JIT means ensuring that the amount of required work is the same as
the work capabilities of the team.
 How does Kanban work?
KANBAN-AGILE FRAMEWORK
 Kanban method revolves around the kanban board.
 It is a tool that visualizes the entire project to track the flow of their project.
 Through this graphical approach of Kanban boards, a new member or an external entity can
understand what’s happening right now, tasks completed and future tasks.
 Kanban board indicates

->the current tasks that are being performed

-> the tasks to do in the future
-> the tasks that are completed
KANBAN BOARD
 The divided columns are interconnected
and tasks are gradually pulled from the
leftmost column (future tasks) to the
rightmost column (completed tasks).
 Kanban system measures the work cycle
being completed through the principle of
Work in Progress (WIP).
KANBAN-AGILE FRAMEWORK
 The divided columns are interconnected and tasks are gradually pulled from the leftmost
column (future tasks) to the rightmost column (completed tasks).
 Kanban system measures the work cycle being completed through the principle of Work in
Progress (WIP).
KANBAN IS A PULL SYSTEM
 A pull system is a Lean technique that controls the flow of work by replacing what’s
completed.
 A vending machine is a perfect example of a pull system–products will be restocked only
when existing products have run out. Kanban precisely fits this definition.
 Kanban is about work states unlike Scrum or Agile which focus on sprints and iterations.
 Kanban focuses on breaking down work into small tasks, visualizing them, and getting
few items in any given work state.
 In the Kanban board, work always moves from left to right. And, you pick work from the
column to your left when you have completed all your existing work items or when an
urgent task surfaces.
 The work-in-progress limits help you enforce this
WHEN SHOULD YOU USE
KANBAN?
 The versatility of Kanban lies in its simplicity. It fits into your current workflows and
respects the existing roles and responsibilities. It can be used irrespective of the industry.
 Kanban can be used in any knowledge work setting and is particularly applicable in
situations where work arrives in an unpredictable fashion and/or when you want to deploy
work as soon as it is ready, rather than waiting for other work items.
 If your priorities change on the fly, and ad hoc tasks can happen anytime, Kanban is best
suited as you can add tasks to any work stage.
 It can also be used when there are no iterations.
CORE PRINCIPLES OF KANBAN METHODOLOGY

1. Initiate with the existing workflow:

-> Kanban framework emphasizes on making small and gradual changes. Therefore, the team
must start with the existing workflow and continuously improve the process.
2. Limit the existing tasks:
-> It is important for the team to realize its own limits and cap the WIP accordingly. Taking on more
than you can handle will only waste time and negatively affect the project.
3. Respect existing roles and responsibilities:
-> it does not require organizations to completely overhaul the existing work culture. Many
organizations resist modern methodologies because they don’t feel comfortable with change.
-> With Kanban, efficiency is improved while staying in the confines of the existing setup.
4. Encourage leadership at all levels:
 Project management methodologies such as the traditional method require approval from the
project manager for even the smallest tasks. Kanban gives the freedom of making decisions to the
individual working on the task. This grooms future leaders who continuously learn from their mistakes
and improve their work.
 CORE PRACTICES OF KANBAN METHODOLOGY

1. Visualization of workflow:
->The whole concept of Kanban revolves around proper visualization of the entire
project. Kanban board software is used throughout the industry for this purpose.
2. Reduction of WIP:
->WIP in the case of Kanban is supposed to be according to the capability of the team.
-> A cap is applied to WIP in order to ensure maximum efficiency. On the Kanban board,
a limit is applied to the number of tasks that can be performed at once.
 No new task can be pulled as long as the limit is achieved, this ensures that the whole team
works together and completes all related tasks around the same time
 CORE PRACTICES OF KANBAN METHODOLOGY

3. Efficient workflow management:

Measuring lead time and cycle time where lead time, the time spent on completing a task is an important
parameter that project teams must reduce as much as possible.
Managing Flow, pivots on all aspects of people, process, technology, and organization to evaluate if one should start
doing things to improve flow, stop things that are not adding to the flow, and keep doing things differently to augment
flow. These learnings come from the daily meetings, lessons learned or retrospective sessions, or review sessions.
4. Make Explicit Process policies:
As the organization identifies opportunities to improve the system, this knowledge is “written in” to the Kanban board
itself. This allows us to capture and preserve organizational learning by building it into the system we use to manage our
work – the Kanban board.
5. Take feedback:
 At the end of the day, the most important entity for any business is the client and implementing an effective feedback
system is extremely important.
 On the Kanban boards, a column can be assigned for feedback from either an external evaluator or the customers
themselves. In this way, the quality of the delivered work can be constantly maintained.
 KANBAN VS SCRUM: WHAT’S THE
DIFFERENCE?
 Scrum revolves around a fixed-length ‘sprint’, and work is completed in small batches.
 In contrast to that, Kanban focuses on the continuous improvement process and tasks are performed
in an orderly manner.
 changes can be easily made anytime in Kanban as it is task-based while Scrum requires the
completion of a single sprint plan before any changes can be made.
->This makes Kanban a suitable option for projects that are extremely versatile while
Scrum is better for projects that require work to be completed in batches.
-> Kanban also does not have any prescribed roles and no individual is responsible for the team
or a task. Scrum, on the other hand, has pre-defined roles of Scrum Master, Product Owner,
and Team members.
 BENEFITS OF USING KANBAN FRAMEWORK

 it significantly improves the way you can handle your projects without changing the organizational
structure.
 Some of the benefits Kanban methodology offers are:
• Enhanced flexibility
• Continuous improvement
• Increased collaboration
• Employee empowerment
• Smoother workflow
• Better inventory management
• Improved quality control