0% found this document useful (0 votes)
70 views127 pages

SE Module 1

The document describes an introduction to software engineering module that covers the following topics: 1. The nature of software engineering and different types of software like system, application, embedded, etc. 2. Software processes and maturity models like CMM that help manage software development. 3. Common software development life cycle models like waterfall, agile which prescribe activities from requirements gathering to maintenance. 4. Generic process models involving key activities like communication, planning, modeling, construction and deployment that are part of any software development process.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
70 views127 pages

SE Module 1

The document describes an introduction to software engineering module that covers the following topics: 1. The nature of software engineering and different types of software like system, application, embedded, etc. 2. Software processes and maturity models like CMM that help manage software development. 3. Common software development life cycle models like waterfall, agile which prescribe activities from requirements gathering to maintenance. 4. Generic process models involving key activities like communication, planning, modeling, construction and deployment that are part of any software development process.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 127

Software Engineering

-Mrudul Arkadi
Module 1 Introduction to Software Engineering

Module 2 Requirement Analysis

Module 3 Software Estimation and Scheduling

Module 4 Design Engineering

Module 5 Software Risk, Configuration Management

Module 6 Software Testing and Maintenance


Module 1 Introduction to Software Engineering

• Nature of Software, Software Engineering, Software Process,


Capability Maturity Model (CMM)
• Generic Process Model, Prescriptive Process Models: The Waterfall
Model, V-model, Incremental Process Models, Evolutionary Process
Models, Concurrent Models, Agile process, Agility Principles, Extreme
Programming (XP), Scrum, Kanban model
What is software
Software encompasses:
(1) instructions (computer programs): that when executed
provide desired features, function, and performance
(2) data structures: that enable the programs to adequately
store and manipulate information
(3) documentation: that describes the operation and use of
the programs.
Changing Nature of Software
• System Software: collection of programs which are written to service other programs.
• Application Software: programs that solve a specific business need.
• Engineering and Scientific Software: facilitate the engineering function and task.
• Embedded Software:
Embedded software resides within the system or product and is used to implement and control
feature and function for the end-user and for the system itself.
• Product-line Software:
Designed to provide a specific capability for use by many different customers, Addresses the mass
consumer market.
• Web Application:
It is a client-server computer program which the client runs on the web browser.
• Artificial Intelligence Software: makes use of a nonnumerical algorithm to solve a complex
problem that is not straightforward analysis.
Changing Nature of Software/ Software Applications
• System software: such as compilers, editors, file management utilities

• Application software: stand-alone programs for specific needs. (Ms office)

• Embedded software resides within a product or system. E.g. digital function of dashboard display
in a car.

• Product-line software : specific capability for use by many different customers (word processing,
graphics, database management)

• WebApps (Web applications) WordPress, Gmail

• AI software uses non-numerical algorithm to solve complex problem. Robotics, speech


recognition.
Why Software is Important?

• The economies of ALL developed nations are dependent on software.

• More and more systems are software controlled ( transportation, medical,


telecommunications, military, industrial, entertainment,)

• Software engineering is concerned with theories, methods and tools for


professional software development.
Features of Software

• Software is developed or engineered, it is not manufactured.

• Software doesn't "wear out.”

• Although the industry is moving toward component-based assembly, most software


continues to be custom built.

{Modern reusable components encapsulate data and processing into software parts
to be reused by different programs. E.g. graphical user interface, pull-down menus
etc.}

10
Software Engineering is required
• To manage Large software
• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management
Software Engineering definition
The IEEE definition:

Software Engineering: The application of a systematic, disciplined, quantifiable


approach to the development, operation, and maintenance of software; {that is, the
application of engineering to software.}
What is a software process?

A set of activities whose goal is the development of software.

Generic activities in all software processes are:

• Specification - what the system should do and its development constraints


• Development - production of the software system
• Validation - checking that the software is what the customer wants
• Evolution - changing the software in response to changing demands
Capability Maturity Model (CMM)

• The Capability Maturity Model (CMM) is a procedure used to


develop and refine an organization's software development
process.
• CMM was developed and is promoted by the Software
Engineering Institute (SEI)
• Quality will improve when you will focus on process.
• Focus on Process than Product
Capability Maturity Model (CMM)

Level 1 : Initial

• No engineering management , everything done on adhoc basic


• Unpredictable w.r.t. time and cost
• Depends on current staff , as staff changes so does process
Capability Maturity Model (CMM)

Level 2 : Repeatable

• Basic project management


• Planning and managing of new project based on experience
with similar projects
• Performance based on previous projects
Capability Maturity Model (CMM)

Level 3 : Defined

• Process standardization
• Proper documentation, SOP including engineering and
management process
• Training program for new staff
• Basic risk management
Capability Maturity Model (CMM)

Level 4 : Managed

• Quantitative measurement
• Ensuring following defined SOP’s
• Predicable time and cost
Capability Maturity Model (CMM)

Level 5 :Optimizing

• Continuous process improvement


• Organization analyzes defect and determine their causes and
goal is to prevent of occurrence of that defect
Capability Maturity Model (CMM)

Ref: OER
Software process model
• Process models prescribe a distinct set of activities, actions, tasks,
milestones, and work products required to engineer high quality
software.
Build and Fix Model
• Product is constructed without specification or any attempt at design.
• developers simply build a product that is reworked as many times as
necessary to satisfy the client.
• Maintenance is high.

Problems :
scheduled time and cost exceeded
user expectations not met
poor quality

Solution :
Models
Generic Process Model

• Communication
– Involves communication among the customer and other stake holders;
encompasses requirements gathering
• Planning
– Establishes a plan for software engineering work; addresses technical tasks,
resources, work products, and work schedule
• Modeling (Analyze, Design)
– Encompasses the creation of models to better under the requirements and the
design
• Construction (Code, Test)
– Combines code generation and testing to uncover errors
• Deployment
– Involves delivery of software to the customer for evaluation and feedback
18 july
framework activities
• carried out
irrespective of the
process model chosen
by the organization.

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
software development life cycle
• A life cycle model maps the various activities performed on a software
product from its inception to retirement.
• describes entry and exit criteria for each phase
• Need ?
– s/w development process should be systematic and disciplined
– To avoid chaos and project failure
– Without software life cycle models, it becomes tough for software
project managers to monitor the progress of the project.
Stage1: Planning and requirement analysis

• The senior members of the team perform it with inputs from all the
stakeholders and domain experts in the industry.

• Planning for the quality assurance requirements and identifications of the


risks associated with the projects is also done at this stage.

• Business analyst and Project organizer set up a meeting with the client to
gather all the data like what the customer wants to build, who will be the
end user, what is the objective of the product.

• Before creating a product, a core understanding or knowledge of the product


is very necessary.
Cont..
• For Example, A client wants to have an application which concerns money
transactions. In this method, the requirement has to be precise like what
kind of operations will be done, how it will be done, in which currency it
will be done, etc.

• In case of any ambiguity, a signal is set up for further discussion.

• Once the requirement is understood, the SRS (Software Requirement


Specification) document is created.
• The developers should thoroughly follow this document and also should be
reviewed by the customer for future reference.
Stage2: Defining Requirements

• represent and document the software requirements and get


them accepted from the project stakeholders.
• This is accomplished through "SRS"- Software Requirement
Specification document which contains all the product
requirements to be constructed and developed during the
project life cycle.
Stage3: Designing the Software

• bring down all the knowledge of requirements analysis and


design the software project.
• This phase is the product of the last two stages, like inputs
from the customer and requirement gathering.
Stage4: Developing the project

• the actual development begins, and the programming is built.


• The implementation of design begins concerning writing code.
• Developers have to follow the coding guidelines described by
their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and
implement the code.
Stage5: Testing

• After the code is generated, it is tested against the


requirements to make sure that the products are solving the
needs addressed and gathered during the requirements stage.
• During this stage, unit testing, integration testing, system
testing, acceptance testing are done.
Stage6: Deployment

• Once the software is certified, and no bugs or errors are


stated, then it is deployed.

• Then based on the assessment, the software may be released


as it is or with suggested enhancement.
Stage7: Maintenance

• Once when the client starts using the developed systems,


then the real issues come up and requirements to be solved
from time to time.
• This procedure where the care is taken for the developed
product is known as maintenance.
SDLC ..cont..
• SDLC is the process of planning, writing, modifying, and
maintaining software.

• it helps ensure that the right people are involved in the right
activities at the right times.

• a structured approach to developing software helps ensure that


your project will be successful.
Benefits of SDLC

• Understanding your requirements and the goal of the software


• Identify risks at an early stage
• Plan how you will deliver your solution in stages
• Measure your progress relative to your goals and ensure
everything is on track
Prescriptive Model
• Organize framework activities in a certain order
• The name 'prescriptive' is given because the model prescribes a set
of activities, actions, tasks, quality assurance and change the
mechanism for every project.
• types of prescriptive process models

1. The Waterfall Model


2. Incremental Process model
3. RAD model
framework activities(CPMCD)
The Waterfall Model
The Waterfall Model or Classic Life Cycle
• Oldest software lifecycle model
• Used when requirements are well understood and risk is low
• Work flow is in a linear (i.e., sequential) fashion
• This means that any phase in the development process begins only if
the previous phase is complete. In waterfall model phases do not
overlap.
• Used for Small to medium sized project
• Used when technology and tools are well known and stable
• Used when minimal changes are expected
The Waterfall Model (Problems)
• Doesn't support iteration, not suitable to accommodate any
change once the development has begun
• Difficult for customers to state all requirements explicitly and
up front
• Requires customer patience because a working version of the
program doesn't occur until the final phase
• High amount of risk and uncertainty
Pros and Cons of Waterfall Model
• Pros • Cons
• Simple and easy to understand • Poor model for long and ongoing
and use projects.
• Works well for smaller projects • It is difficult to measure progress
where requirements are very within stages.
well understood. • Cannot accommodate changing
• Clearly defined stages. requirements.
• Well understood milestones. • No working software is produced
• Easy to arrange tasks. until late in the life cycle.
• Process and results are well • Adjusting scope during the life
documented cycle can end a project.
Sequential phases in Waterfall model

• 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 system
design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
• Implementation:
With inputs from 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.

43
Cont..
• 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 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

44
The Waterfall Model with feedback

Problems can be somewhat


alleviated in the model through
the addition of feedback loops
V Model (variation in the representation of the waterfall model)
• Also known as the Verification and Validation Model.
• Testing of the device is planned in parallel with a corresponding stage of
development.
• Verification: It involves a static analysis method (review) done without executing
code. It is the process of evaluation of the product development process to find
whether specified requirements meet.
• Validation: It involves dynamic analysis method (functional, non-functional), testing
is done by executing code. Validation is the process to classify the software after the
completion of the development process to determine whether the software meets
the customer expectations and requirements.
• So V-Model contains Verification phases on one side of the Validation phases on the
other side. Verification and Validation process is joined by coding phase in V-shape.
Thus it is known as V-Model.
phases of Verification Phase
• Business requirement analysis: This is the first step where product
requirements understood from the customer's side. This phase contains
detailed communication to understand customer's expectations and exact
requirements.
• System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements
document.
• Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief
functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. The integration
testing model is carried out in a particular phase.
phases of Verification Phase
• Module Design: In the module design phase, the system breaks
down into small modules. The detailed design of the modules is
specified, which is known as Low-Level Design
• Coding Phase: After designing, the coding phase is started. Based
on the requirements, a suitable programming language is
decided. There are some guidelines and standards for coding.
Before checking in the repository, the final build is optimized for
better performance, and the code goes through many code
reviews to check the performance.
phases of Validation Phase
• Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed
during the module design phase. These UTPs are executed to
eliminate errors at code level or unit level. A unit is the smallest
entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly
when isolated from the rest of the codes/ units.
• Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created
and tested independently can coexist and communicate among
themselves.
phases of Validation Phase
• System Testing: System Tests Plans are developed during System
Design Phase. Unlike Unit and Integration Test Plans, System Tests
Plans are composed by the client’s business team. System Test
ensures that expectations from an application developer are met.
• Acceptance Testing: Acceptance testing is related to the business
requirement analysis part. It includes testing the software product
in user atmosphere. Acceptance tests reveal the compatibility
problems with the different systems, which is available within the
user atmosphere. It conjointly discovers the non-functional
problems like load and performance defects within the real user
atmosphere.
When to use V-Model?

• When the requirement is well defined and not ambiguous.


• The V-shaped model should be used for small to medium-sized
projects where requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical
resources are available with essential technical expertise.
Advantages of V-Model:

• Easy to Understand.
• Testing Methods like planning, test designing happens well before
coding.
• This saves a lot of time. Hence a higher chance of success over the
waterfall model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily
understood.
Disadvantages of V-Model:

• Very rigid and least flexible.


• Not a good for a complex project.
• Software is developed during the implementation stage, so no
early prototypes of the software are produced.
• If any changes happen in the midway, then the test documents
along with the required documents, has to be updated.
Incremental Process Models
• Combines the elements of waterfall model and they are applied in
an iterative fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer
for any suggested modifications.
• The next increment implements on the customer's suggestions and
add additional requirements in the previous increment.
• This process is repeated until the product is finished.
Incremental Process Model
Each linear sequence
produces a deliverable
“increment” of the
software
Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment
Incremental Process Model

For example,
1. word-processing software developed using the incremental paradigm might deliver
basic file management, editing, and document production functions in the first
increment;

2. More sophisticated editing and document production capabilities in the second


increment;

3. spelling and grammar checking in the third increment;

4. Advanced page layout capability in the fourth increment.


Incremental Process Model-RAD Model
• emphasizes an extremely short development cycle.

• The RAD model is a “high-speed” adaptation.

• If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a “fully functional system” within very short time
periods (e.g., 60 to 90 days)

59
Cont..

60
Phases in RAD model

• Business modeling: The information flow is identified between various business functions.

• Data modeling: Information gathered from business modeling is used to define data objects that
are needed for the business.

• Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective.

• Application generation: Automated tools are used to convert process models into code and the
actual system.

• Testing and turnover: Test new components and all the interfaces.

61
RAD Features

• Rapid application

• Communication: Understand business requirements

• Planning : To work in parallel

• Modeling: Data, Business, Process

• Construction : Use of preexisting s/w components


Advantages of RAD Model

• Reduced development time.

• Increases reusability of components

• Quick initial reviews occur

• Encourages customer feedback

• Integration from very beginning solves a lot of integration issues.

63
Disadvantages of RAD Model
• Depends on strong team and individual performances for identifying business
requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modelling skills
• Inapplicable to cheaper projects as cost of modeling and automated code
generation is very high.

64
When to use RAD model:

• RAD should be used when there is a need to create a system that can be modularized
in 2-3 months of time.

• It should be used if there’s high availability of designers for modeling and the budget is
high enough to afford their cost along with the cost of automated code generating
tools.

65
Evolutionary Process Model
• Produce an increasingly more complete version of the software with
each iteration.

• Evolutionary Models are iterative.

• Evolutionary models are:


Prototyping
Spiral Model
Concurrent Development Model
Evolutionary Process Model : Prototype Model
• Prototype model is that instead of freezing the requirements before a
design or coding can proceed, a throwaway prototype is built to
understand the requirements.

• This prototype is developed based on the currently known requirements.

• By using this prototype, the client can get an “actual feel” of the system.

• Prototyping is an attractive idea for complicated and large systems for which
there is no manual process or existing system to help determining the
requirements.
67
Cont..

68
Cont..

69
Advantages of Prototype model:

• Users are actively involved in the development


• Since in this methodology a working model of the system is provided,
the users get a better understanding of the system being developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily

70
Disadvantages of Prototype model:

• Leads to implementing and then repairing way of building systems.

• Practically, this methodology may increase the complexity of the


system as scope of the system may expand beyond original plans.

• Incomplete application may cause application not to be used as the


full system was designed Incomplete or inadequate problem analysis.

71
When to use Prototype model:

• Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.

• Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model.

• Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system.

• They are excellent for designing good human computer interface systems.

72
Quick recap - SDLC Models
• Prescriptive model
1. Waterfall ( with feedback)
2. V model (modified waterfall model)
3. Incremental model
3.1 RAD model

• Evolutionary
1. Prototype
2. Spiral Model
3. Concurrent Development Model
Evolutionary Process Model : Spiral Model
• The spiral model is similar to the incremental model, with more
emphasis placed on risk analysis.

• The spiral model has six phases.(customer communication, planning,


risk analysis, engineering , construction& release, customer
evaluation)

• A software project repeatedly passes through these phases in


iterations (called Spirals in this model).

74
Cont..

75
Spirals
• Customer communication: tasks required to establish effective communication
between developer and customer.
• Planning: tasks required to define resources, timelines, and other project related
information. Requirements are gathered during the planning phase.
• Risk analysis: tasks required to assess both technical and management risks. If any
risk is found during the risk analysis then alternate solutions are suggested and
implemented.
• Engineering: In this phase software is developed, along with testing at the end of
the phase.
• Construction and release: tasks required to construct, test, install, and provide user
support (e.g., documentation and training).
• Customer evaluation: This phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.
76
Advantages of Spiral model:

• High amount of risk analysis hence, avoidance of Risk is enhanced.


• Good for large and mission-critical projects.
• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

77
Disadvantages of Spiral model

• Time spent for evaluating risks too large for small or low-risk
projects.
• Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive.
• The model is complex .
• Risk assessment expertise is required.
• Spiral may continue indefinitely.

78
When to use Spiral model:

• When costs and risk evaluation is important


• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to
economic priorities
• Users are unsure of their needs
• Requirements are complex
• Significant changes are expected (research and exploration)

79
Evolutionary Process Model : Concurrent Process Model

• The term concurrent mean “done at the same time”. It is used in all s/w process
models

• If we take waterfall model as an example, we dont know state of each phase, only
after the phase is over, you get a work product or a document.

• Suppose we want to know the state of activities of the design phase and at the
same time we want to know about testing phase activities. Then we need
concurrent engineering.

• The concurrent process model shows the current state of activities, tasks and their
associated states that remain in different phases.

80
Cont..
• ‘Design Phase’ may be at an ‘awaiting state’ and ‘customer communication’ is in
‘under revision’ state. The customer wants some changes to the design, then
‘communication’ goes to ‘awaiting changes’ and ‘design’ goes to the under-
development stage again.

• The benefit of this model is that project managers know each phase is what state
and why.

• Main Point – Maintain information about each phase at the activity level.

• The concurrent model is appropriate for system engineering project where different
engineering teams are involved.

81
Cont..

82
Advantages of concurrent process model

• It’s flexible – the number incremental releases can be determined by


the project team
• Immediate feedback from testing
• New features can be added late in the project
• No surprises during formal validation because testing has been
continuous

84
Disadvantages of concurrent process model

• The SRS must be continually updated to reflect changes.


• It requires discipline to avoid adding too many new features too late in
the project.
• It needs better communication between the team members.
• It requires to remember the status of the different activities.

85
20jul
What is Agility?
• Agile is ability to move quickly and easily.
• Swift or versatile

86
Lets compare

If we are following waterfall model


We will get product after completion
of all steps (SDLC)

And if we are following agile model


1st model after completing high
priority requirements (eg. 1st 3 ) then
after feedback 2nd model with next
requirements (eg. 1st 6 )
Agile process

• Agile process -> based on iterative development.


• Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning.
• The project scope and requirements are laid down at the beginning
of the development process. Plans regarding the number of
iterations, the duration and the scope of each iteration are clearly
defined in advance.
• Each iteration is considered as a short time "frame" in the Agile
process model, which typically lasts from one to four weeks.
Agile process

• The division of the entire project into smaller parts helps to


minimize the project risk and to reduce the overall project
delivery time requirements.
• Each iteration involves a team working through a full software
development life cycle including planning, requirements
analysis, design, coding, and testing before a working product
is demonstrated to the client.
Agile model phases

Requirements gathering
Design the requirements
Construction/ iteration
Testing/ Quality assurance
Deployment
Feedback
Agile model phases
1. Requirements gathering:
• define the requirements.
• explain business opportunities
• plan the time and effort needed to build the project.
• evaluate technical and economic feasibility.

2. Design the requirements:


• work with stakeholders to define requirements.
• use the user flow diagram or the high-level UML diagram to show the work of
new features and show how it will apply to your existing system.

3. Construction/ iteration:
• Designers and developers will now start working on their project, which aims to
deploy a working product.
• The product will undergo various stages of improvement.
Agile model phases
4. Testing:
• Quality Assurance team examines the product's performance
• looks for the bug if any.
5. Deployment:
• team issues a product for the user's work environment.
6. Feedback:
• the team receives feedback about the product and works through the
feedback
When to use agile model?
• Project size is large
• Frequent changes are required
• Highly qualified team in available
• Customer is ready to have meeting with software team all the
time
• If project is with flexible time and budget
Agile Principles
The following principles are based on the Agile .

1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

2. Welcome changing requirements, even late in development.

3. Deliver working software frequently, from a couple of weeks to a couple of


months, with a preference to the shorter timescale.

96
Cont..
4. Business people and developers must work together daily throughout

the project.

5. Build projects around motivated individuals. Give them the environment


and support they need, and trust them to get the job done. (Better
Productive environment )

6. The most efficient and effective method of conveying information to and


within a development team is face-to-face conversation.

97
Cont..

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. (development that meets the needs
of the present without compromising the ability of future generations to meet their own
needs.)

9. Continuous attention to technical excellence and good design enhances agility.

98
Cont..

• 10. Simplicity--the art of maximize result and less hard work by removing
unnecessary tasks and prioritizing activities

• 11. The best architectures, requirements, and designs emerge from self-organizing
and experienced teams.

• 12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.

99
Difference between Traditional & Agile Method

Traditional Agile

Control Mechanism Process Oriented Customer Oriented

Management Style Command & Control Leadership & collaboration

Role assignment Fixed Dynamic

Communication Formal Informal

Development Model Waterfall Model Evolutionary Model

100
Extreme Programming (XP)
• “Agile Development” is an umbrella term for several iterative and
incremental software development methodologies.

The most popular agile methodologies include:

1. Extreme Programming (XP)


2. Scrum
3. Dynamic Systems Development Method (DSDM)
4. Feature-Driven Development (FDD)
Extreme Programming (XP)

• Need :- to improve software quality and responsiveness to changing


customer requirements.
• XP turns the traditional software development process sideways. Rather
than planning, analyzing, and designing in a linear fashion, XP
programmers do all such activities a little at a time throughout the
development phase.
• The approach bears resemblance to a jigsaw puzzle with the
development of many small pieces or iterations that make no sense
individually, but making for a complete package when combined.
Extreme Programming (XP)

• advantage - allowing easy incorporation of changes.


• XP software development process starts with planning, and all
iterations consist of four basic phases in its life cycle: designing, coding,
testing, and listening.
• keypoint :- continual communication with the customer and amongst
the team, minimalist solution, frequent feedback through unit and
acceptance testing, and the courage to take on problems proactively
and integrate testing and changes in the development phase.
Extreme Programming (XP)
Extreme Programming (XP)
Planning
• customers or users meet with the development team to create ‘user stories’ or
requirements. The development team converts user stories into iterations that
cover a small part of the functionality or features required. A combination of
iterations provides the customer with the final fully functional product.

Designing
• using Software Class Responsibilities and Collaboration (CRC) Cards that allow
for a departure from the traditional procedural mindset and make possible
object oriented technology. Such cards allow all members of the project team
to contribute ideas, and collate the best ideas into the design.
Extreme Programming (XP)
Coding
• gives priority to the actual coding over all other tasks such as documentation to
ensure that the customer receives something substantial in value at the end of the
day.
• Standards related to coding include:
● Developing the code based on the agreed metaphors and standards, and adopting a
policy of collective code ownership.
● Pair programming or developing code by two programmers working together on a
single machine, aimed at producing higher quality code at the same or less cost.
● Strict adherence to 40-hour workweeks with no overtime. This ensures the
developers work in the peak of their mental and physical faculties.
● Frequent integration of the code to the dedicated repository, with only one pair
integrating at a time to prevent conflicts, and optimization at the end.
Extreme Programming (XP)
Testing
• Extreme program integrates testing with the development phase rather
than at the end of the development phase.
• All codes have unit tests to eliminate bugs, and the code passes all such
unit tests before release.
• Another key test is customer acceptance tests, based on the customer
specifications. Acceptance test run at the completion of the coding, and
the developers provide the customer with the results of the acceptance
tests along with demonstrations.
Extreme Programming (XP)
Listening
a continuous mechanism of customer involvement through feedback
during the development phase. Apart from the customer, the developer
also receives feedback from the project manager.
The basis of feedback is the customer acceptance tests. Each feedback of
the customer that specifies revised requirement becomes the basis of a
new design, and the process of design-coding-tests-listening repeats itself.
If the customer remains satisfied with the test results the iteration ends
there, and the design for the new iteration starts, which again follows the
design-coding-testing-listening cycle.
Scrum
• An agile software product development strategy that
organizes software developers as a team to reach a common
goal — creating a ready-for-market product
• Product Backlog: list of prioritized features and its completion
status to keep the product is organized.

• Sprints are periods of time when software development is


actually done. is a time-box of one month or less.

• Sprint Backlog: is divided into two parts complete product with


assigned features to sprint (refinement)and Sprint planning
meeting.(daily scrums)
Scrum
• Sprint Review: If the product still have some non-achievable
features then it will be checked in this stage and then the
product is passed to the Sprint Retrospective stage.

• Sprint Retrospective: In this stage quality or status of the


product is checked.
Scrum
• emphasizes self-
organization.
• help the team to
work together.
Scrum
Advantages

● Scrum framework is fast moving and money efficient.


● Scrum framework works by dividing the large product into small sub-
products.
● In Scrum customer satisfaction is very important.
● Scrum is adaptive in nature because it have short sprint.
● As Scrum framework rely on constant feedback therefore the quality of
product increases in less amount of time
Scrum
Disadvantage

● Scrum framework do not allow changes into their sprint.


● not fully described. need to fill in the framework with your own details
like Extreme Programming(XP), Kanban, DSDM.
● It can be difficult for the Scrum to plan, structure and organize a
project that lacks a clear definition.
● The daily Scrum meetings and frequent reviews require substantial
resources.
Scrum software development process
1. starts with a wish list of features — a product backlog.
2. The team meets to discuss: The backlog, What still needs to be completed., How long it will
take.
3. Scrum relies on an agile software development concept called sprints:
i. Sprints are periods of time when software development is actually done.
ii. A sprint usually lasts from one week to one month to complete an item from the backlog.
iii. The goal of each sprint is to create a saleable product.
iv. Each sprint ends with a sprint review.
v. When team chooses another piece of backlog to develop — which starts a new sprint.
vi. Sprints continue until the project deadline or the project budget is spent.
4. In daily scrums, teams meet to discuss their progress since the previous meeting and make
plans for that day.
i. The meetings should be brief — no longer than 15 minutes.
ii. Each team member needs to be present and prepared.
iii. The ScrumMaster keeps the team focused on the goal.
Kanban model
• Kanban is a management method for teams and organizations
to visualize their work identify and eliminate bottlenecks

• Kanban term came into existence using the flavors of “visual


card,” “signboard,” or “billboard” , signaling system” to indicate
a workflow that limits Work In Progress (WIP)

• Used to Control Incremental Development.


It is critical to understand the visualization of
workflow stages in the task execution pipeline.
Visualize Workflow Kanban board provides a simple way to
understand the process.

118
Kanban Process
1. Every request received is put on the Kanban board.
2. A column on the board represents a stage(Received, Acknowledged, In-progress ,Done )
3. The received stage could be called a “Backlog” also.
4. Kanban board could be a simple whiteboard on which sticky notes could be used with
ticket details or an electronic Kanban board could be used.
5. The board can give a signal in case the bugs/ tickets are stuck in one stage for a long.
6. For electronic boards, one can configure the Kanban board in a way that tickets/ user
stories along with the time stamp are visible.
7. For whiteboards that are maintained manually, the team can enter the date/ time.
8. Lead time is what customer sees, it starts when request is made and ends when it is
actually delivered.
Principles of Kanban
• Start with the existing process -Unlike Scrum, there’s no
specific process or roles defined in Kanban.
• Agree to continue evolutionary and incremental changes
• Admire current roles, processes, responsibilities & titles
• Leadership at all levels
Kanban Practices
• Limit WIP
• Visualize: Visualizing the workflow and making it visible is
important so as to know how work proceeds.
• Manage flow :By managing the flow vigorously, the incremental,
continuous, and evolutionary modifications to the system can be
assessed to have negative or positive effects on the system.
• Implement Feedback Loops
• Make Policies Explicit:Until the mechanism of a process is not
made clear, it is difficult to hold a debate and discuss ways to
improve it
Cont..

122
Limit WIP (work in progress)

Bottlenecks
become
clearly visible
in real time.

123
Kanban Board Example
• Thank you

You might also like