Chapter 1.

Introduction to Software Engineering and Process Models

Definition of Software
Software is defined as
1. Instructions (computer programs) that when executed provide desired function and performance.
2. Data structures that enable the programs to adequately manipulate information.
3. Documents that describe the operation and use of the programs.

Software Engineering Process Paradigms

I. Software Engineering Definition

Software Engineering is the study and application of engineering to the design, development, and
maintenance of software. Software engineering can be divided into ten sub disciplines. They are:
1. Software Requirements: The elicitation, analysis, specification, and validation of requirements for software.
2. Software Design: The process of defining the architecture, components, interfaces, and other
characteristics of a system or component. It is also defined as the result of that process.
3. Software Construction: The detailed creation of working, meaningful software through a combination of
coding, verification, unit testing, integration testing, and debugging.
4. Software Testing: The dynamic verification of the behavior of a program on a finite set of test cases,
suitably selected from the usually infinite executions domain, against the expected behavior.
5. Software Maintenance: The totality of activities required to provide cost-effective support to software.
6. Software Configuration Management: The identification of the configuration of a system at distinct points
in time for the purpose of systematically controlling changes to the configuration, and maintaining the
integrity and traceability of the configuration throughout the system life cycle.
7. Software Engineering Management: The application of management activities—planning, coordinating,
measuring, monitoring, controlling, and reporting—to ensure that the development and maintenance of
software is systematic, disciplined, and quantified.
8. Software Engineering process: The definition, implementation, assessment, measurement, management,
change, and improvement of the software life cycle process itself.
9. Software Engineering Tools and Methods: The computer-based tools that are intended to assist the
software life cycle processes see Computer Aided Software Engineering, and the methods which impose
structure on the software engineering activity with the goal of making the activity systematic and ultimately
more likely to be successful.
10. Software Quality: The degree to which a set of inherent characteristics fulfills requirements.
The Process Framework

A process framework establishes the foundation for a complete software engineering process by identifying a
small number of framework activities that are applicable to all software projects, regardless of their size or
complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable
across the entire software process. A generic process framework for software engineering encompasses five
activities:

Communication: Before any technical work can commence, it is critically important to communicate and
collaborate with the customer (and other stakeholders). 3 The intent is to understand stakeholders’ objectives
for the project and to gather requirements that help defi ne software features and functions.

Planning: Any complicated journey can be simplified if a map exists. A software project is a complicated
journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The
map—called a software project plan—defines the software engineering work by describing the technical tasks
to be conducted, the risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule.

Modeling: Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an

architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big
picture—what it will look like architecturally, how the constituent parts fi t together, and many other
characteristics. If required, you refine the sketch into greater and greater detail in an effort to better
understand the problem and how you’re going to solve it. A software engineer does the same thing by
creating models to better understand software requirements and the design that will achieve those
requirements.

Construction: What you design must be built. This activity combines code generation (either manual or
automated) and the testing that is required uncovering errors in the code.

Deployment: The software (as a complete entity or as a partially completed increment) is delivered to the
customer who evaluates the delivered product and provides feedback based on the evaluation.
SEI-CMM
1. The generic process framework gives significance emphasis on “process maturity”.
2. The Software Engineering Institute (SEI) has developed predictive set of capabilities that should be present
as organization s reaches different levels of process maturity.
3. The grading scheme determines compliance with a capability maturity model (CMM) that defines key
activities required at different levels of process maturity.
4. The five levels of CMMI are described below
Level 0: Incomplete. The process area (e.g., requirements management) is either not performed or does not
achieve all goals and objectives defined by the CMMI for level 1 capability for the process area.
Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few processes
are defined, and success depends on individual effort.
Level 2: Managed. An organization has achieved all the specific and generic goals of the maturity level 2
process areas. In other words, the projects of the organization have ensured that requirements are managed
and that processes are planned performed, measured, and controlled.
Level 3: Defined. The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process. All projects use a documented and
approved version of the organization's process for developing and supporting software. This level includes all
characteristics defined for level 2.
Level 4: Quantitatively Managed. Quantitative objectives for quality and process performance are established
and used as criteria in managing processes. Quantitative objectives are based on the needs of the customer,
end users, organization, and process implementers. Quality and process performance is understood in
statistical terms and is managed throughout the life of the processes.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process
and from testing innovative ideas and technologies. This level includes all characteristics defined for level 4.
A GENERIC PROCESS MODEL

Process is defined as a collection of work activities, actions, and tasks that are performed when some work
product is to be created. Each of these activities, actions, and tasks resides within a framework or model that
defines their relationship with the process and with one another.
A generic process framework for software engineering defines five framework activities— communication,
planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking
and control, risk management, quality assurance, configuration management, technical reviews, and others—
are applied throughout the process.
A linear process flow executes each of the five framework activities in sequence, beginning with
communication and culminating with deployment. An iterative process flow repeats one or more of the
activities before proceeding to the next. An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more complete version of the software. A parallel
process flow executes one or more activities in parallel with other activities (e.g., modeling for one aspect of
the software might be executed in parallel with construction of another aspect of the software).
Umbrella Activities of Software Engineering
Umbrella Activities: Umbrella activities are independent of any one framework activity and occur throughout
the process.
1. Software Project Management
2. Formal Technical Reviews
3. Software Quality Assurance
4. Software Configuration Management
5. Re-usability Management
6. Risk Management
7. Measurement and Metrics
8. Document Preparation and Production
Waterfall Model
1. Also known as the classic life cycle or the waterfall model, the linear sequential model suggests a
systematic, sequential approach to software development that begins at the system level and progresses
through analysis, design, coding, testing, and support.
2. Figure 1.8 illustrates the linear sequential model for software engineering.
3. Modeled after a conventional engineering cycle, the linear sequential model encompasses the following
activities:

4. System/information engineering and modeling. Because software is always part of a larger system (or
business), work begins by establishing requirements for all system elements and then allocating some subset
of these requirements to software.
5. Phases of waterfall model:
i. Software Requirements Analysis: The requirements gathering process is intensified and focused specifically
on software.
ii. Design Software: Design is actually a multistep process that focuses on four distinct attributes of a program:
data structure, software architecture, interface representations, and procedural (algorithmic) detail. The
design process translates requirements into a representation of the software that can be assessed for quality
before coding begins. Like requirements, the design is documented and becomes part of the software
configuration.
iii. Code Generation: The design must be translated into a machine-readable form. The code generation step
performs this task. If design is performed in a detailed manner, code generation can be accomplished
mechanistically.
iv. Testing: Once code has been generated, program testing begins. The testing process focuses on the logical
internals of the software, ensuring that all statements have been tested, and on the functional externals; that
is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with
required results.
Advantages
i. Organized approach provides robust separation of phases.
ii. Reflects common engineering practice.
iii. A schedule can be set with deadlines for each stage of development and a product can proceed through the
development process model phases one by one.
iv. Development moves from concept, through design, implementation, testing, installation, troubleshooting,
and ends up at operation and maintenance.
v. Each phase of development proceeds in strict order.

Disadvantages
i. Doesn’t cope well with changes the client makes in the requirements.
ii. Development required by teams might wait for each other.

iii. A working version of the product is available only late.

iv. No working software is produced until late during the life cycle.
v. High amounts of risk and uncertainty.
vi. Not a good model for complex and object-oriented projects.
vii. Poor model for long and ongoing projects.
viii. 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.
ix. It is difficult to measure progress within stages.
Application
i. When requirements are well known and few changes are likely to be needed.
ii. Can be used also for parts of larger software systems.
iii. This model is used only when the requirements are very well known, clear and fixed.
iv. Product definition is stable.
v. Technology is understood.
vi. There are no ambiguous requirements
vii. Ample resources with required expertise are available freely.
viii. The project is short.
V-Model

1. The V - model is SDLC model where execution of processes happens in a sequential manner in V-shape.
2. It is also known as Verification and Validation model.
3. V - Model is an extension of the waterfall model and is based on association of a testing phase for each
corresponding development stage.
4. This means that for every single phase in the development cycle there is a directly associated testing phase.

6. This is a highly disciplined model and next phase starts only after completion of the previous phase.
7. Like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.
8. Each phase must be completed before the next phase begins.
9.Testing of the product is planned in parallel with a corresponding phase of development.

The various phases of the V-model are as follows:

1. Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this model before
development is started, a system test plan is created. The test plan focuses on meeting the functionality specified
in the requirements gathering.
2. High-Level Design (HLD) phase focuses on system architecture and design. It provide overview of solution,
platform, system, product and service/process. An integration test plan is created in this phase as well in order to
test the pieces of the software systems ability to work together.
3. Low-Level Design (LLD) phase is where the actual software components are designed. It defines the actual logic
for each and every component of the system. Class diagram with all the methods and relation between classes
comes under LLD. Component tests are created in this phase as well.
4. Implementation phase is, where all coding takes place. Once coding is complete, the path of execution continues
up the right side of the V where the test plans developed earlier are now put to use.
5. Coding: This is at the bottom of the V-Shape model. Module design is converted into code by developers.

Verification Phases
Following are the Verification phases in V-Model:
1. Business Requirement Analysis: This is the first phase in the development cycle where the product requirements
are understood from the customer perspective. This phase involves detailed communication with the customer to
understand his expectations and exact requirement. This is a very important activity and need to be managed well,
as most of the customers are not sure about what exactly they need. The acceptance test design planning is done
at this stage as business requirements can be used as an input for acceptance testing.

2. System Design: Once you have the clear and detailed product requirements, it’s time to design the complete
system. System design would comprise of understanding and detailing the complete hardware and communication
setup for the product under development. System test plan is developed based on the system design. Doing this at
an earlier stage leaves more time for actual test execution later.

3. Architectural Design: Architectural specifications are understood and designed in this phase. Usually more than
one technical approach is proposed and based on the technical and financial feasibility the final decision is taken.
System design is broken down further into modules taking up different functionality. This is also referred to as High
Level Design (HLD).The data transfer and communication between the internal modules and with the outside world
(other systems) is clearly understood and defined in this stage. With this information, integration tests can be
designed and documented during this stage.

4. Module Design: In this phase the detailed internal design for all the system modules is specified, referred to as
Low Level Design (LLD). It is important that the design is compatible with the other modules in the system
architecture and the other external systems. Unit tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage. Unit tests can be designed at this stage based on the
internal module designs.
Coding Phase
1. The actual coding of the system modules designed in the design phase is taken up in the Coding phase.
2. The best suitable programming language is decided based on the system and architectural requirements.
3. The coding is performed based on the coding guidelines and standards.
4. The code goes through numerous code reviews and is optimized for best performance before the final build is
checked into the repository.

Validation Phases
Following are the Validation phases in V-Model:
1. Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation
phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot
be uncovered by unit testing.
2. Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are
performed to test the coexistence and communication of the internal modules within the system.
3. System Testing: System testing is directly associated with the System design phase. System tests check the entire
system functionality and the communication of the system under development with external systems. Most of the
software and hardware compatibility issues can be uncovered during system test execution.
4. Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and involves
testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems
available in the user environment. It also discovers the non-functional issues such as load and performance defects
in the actual user environment.

Advantages
i. Simple and easy to use.
ii. Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher
chance of success over the waterfall model.
iii. Proactive defect tracking – that is defects are found at early stage.
iv. Avoids the downward flow of the defects.
v. Works well for small projects where requirements are easily understood.
vi. This is a highly disciplined model and Phases are completed one at a time.
vii. Works well for smaller projects where requirements are very well understood.
viii. Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.

Disadvantages
i. Very rigid and least flexible.
ii. Software is developed during the implementation phase, so no early prototypes of the software are produced.
iii. If any changes happen in midway, then the test documents along with requirement documents has to be
updated.
iv. High risk and uncertainty.
v. Not a good model for complex and object-oriented projects.
vi. Poor model for long and ongoing projects.
vii. Not suitable for the projects where requirements are at a moderate to high risk of changing.
viii. Once an application is in the testing stage, it is difficult to go back and change functionality
ix. No working software is produced until late during the life cycle.

Application
i. The V-shaped model should be used for small to medium sized projects where requirements are clearly defined
and fixed.
ii. The V-Shaped model should be chosen when ample technical resources are available with needed technical
expertise.
iii. High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are
produced, there is a very high risk involved in meeting customer expectations.
Incremental Model

1. The incremental model combines elements of the linear sequential model with the iterative philosophy of
prototyping.
2. In incremental model the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases.
3. Each subsequent release of the module adds function to the previous release. The process continues till the
complete system is ready as per the requirement.
4. The incremental model applies linear sequences in a staggered fashion as calendar time progresses.
5. Each linear sequence produces a deliverable “increment” of the software.
6. For example, word-processing software developed using the incremental paradigm might deliver basic file
management, editing, and document production functions in the first increment; more sophisticated editing and
document production capabilities in the second increment; spelling and grammar checking in the third increment;
and advanced page layout capability in the fourth increment.
7. It should be noted that the process flow for any increment can incorporate the prototyping paradigm.

8. The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature.

9. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each
increment.
10. Early increments are stripped down versions of the final product, but they do provide capability that serves the
user and also provide a platform for evaluation by the user.
 Advantages
i. Provides better support for process iteration.
ii. Reduces rework in the software construction process.
iii. Some decisions on requirements may be delayed.
iv. Allows early delivery of parts of the system.
v. Supports easier integration of sub-systems.
vi. Lower risk of project failure.
vii. Delivery priorities can be more easily set.

Disadvantages
i. Increments need be relatively small
ii. Mapping requirements to increments may not be easy.
iii. Common software facilities may be difficult to identify.
iv. More resources may be required.
v. Although cost of change is lesser but it is not very suitable for changing requirements.
vi. System architecture or design issues may arise because not all requirements are gathered in the beginning of
the entire life cycle.
vii. Defining increments may require definition of the complete system.
viii. Management complexity is more.
ix. Highly skilled resources are required for risk analysis.
x. Project’s progress is highly dependent upon the risk analysis phase.

Application
i. When it is possible to deliver the system “part-by-part”.
ii. This model can be used when the requirements of the complete system are clearly defined and understood.
iii. Major requirements must be defined; however, some details can evolve with time.
iv. There is a need to get a product to the market early.
v. A new technology is being used
vi. Resources with needed skill set are not available
vii. There are some high risk features and goals.
Evolutionary Process Models
Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly
more complete versions of the software. In the paragraphs that follow, we present two common evolutionary
process models.

Prototyping Model
1. The prototyping paradigm begins with requirements gathering.
2. Developer and customer meet and define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory.
3. A "quick design" then occurs. The quick design focuses on a representation of those aspects of the software
that will be visible to the customer/user (e.g., input approaches and output formats).

4. The quick design leads to the construction of a prototype.

5. The prototype is evaluated by the customer/user and used to refine requirements for the software to be
developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same
time enabling the developer to better understand what needs to be done.
Prototyping can also be problematic for the following reasons:
1. The customer sees what appears to be a working version of the software, unaware that the prototype is
held together “with chewing gum and baling wire,” unaware that in the rush to get it working no one has
considered overall software quality or long-term maintainability.
2. When informed that the product must be rebuilt so that high levels of quality can be maintained, the
customer cries foul and demands that "a few fixes" be applied to make the prototype a working product.

3. Too often, software development management relents.

4. The developer often makes implementation compromises in order to get a prototype working quickly.
5. An inappropriate operating system or programming language may be used simply because it is available and
known; an inefficient algorithm may be implemented simply to demonstrate capability.
6. After a time, the developer may become familiar with these choices and forget all the reasons why they
were inappropriate.
7. The less-than-ideal choice has now become an integral part of the system.
Advantages
i. Increased user involvement in the product even before implementation
ii. Since a working model of the system is displayed, the users get a better understanding of the system being
developed.
iii. Reduces time and cost as the defects can be detected much earlier.
iv. Quicker user feedback is available leading to better solutions.
v. Missing functionality can be identified easily
vi. Confusing or difficult functions can be identified

Disadvantages
i. Risk of insufficient requirement analysis owing to too much dependency on prototype
ii. Users may get confused in the prototypes and actual systems.
iii. Practically, this methodology may increase the complexity of the system as scope of the system may
expand beyond original plans.
iv. Developers may try to reuse the existing prototypes to build the actual system, even when it’s not
technically feasible
v. The effort invested in building prototypes may be too much if not monitored properly.

Application
i. Prototype model should be used when the desired system needs to have a lot of interaction with the end
users.
ii. Typically, online systems, web interfaces have a very high amount of interaction with end users, are best
suited for Prototype model. It might take a while for a system to be built that allows ease of use and needs
minimal training for the end user.

iii. 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.
Spiral Model

A spiral model is divided into a number of framework activities, also called task regions. Typically, there are
between three and six task regions. spiral model that contains six task regions:
1. Customer Communication—tasks required to establish effective communication between developer and
customer.
2. Planning—tasks required to define resources, timelines, and other project related information.
3. Risk Analysis—tasks required to assess both technical and management risks.
4. Engineering—tasks required to build one or more representations of the application.
5. Construction and Release—tasks required to construct, test, install, and provide user support (e.g.,
documentation and training).

Phase Name Activities performed Deliverables / Output

Planning Requirements are studied and gathered. Requirements understanding
Feasibility study document
Reviews and walkthroughs to streamline the Finalized list of requirements.
requirements
Risk Analysis Requirements are studied and brain storming Document which highlights all
sessions are done to identify the potential risks. the risks and its mitigation
Once the risks are identified , risk mitigation strategy plans.
is planned and finalized

Engineering Actual development and testing if the software takes Code

place in this phase Test cases and test result.
Test summary report and
 defect report.

Evaluation Customers evaluate the software and provide their Features implemented
feedback and approval document

Advantages
i. Risk reduction mechanisms are in place.
ii. Spiral Life Cycle Model is one of the most flexible SDLC models in place.
iii. Development phases can be determined by the project manager, according to the complexity of the
project.
iv. Project monitoring is very easy and effective. Each phase, as well as each loop, requires a review from
concerned people. This makes the model more transparent.
v. Risk management is one of the in-built features of the model, which makes it extra attractive compared to
other models.
vi. Changes can be introduced later in the life cycle as well. And coping with these changes isn’t a very big
headache for the project manager.
vii. Project estimates in terms of schedule, cost etc. become more and more realistic as the project moves
forward and loops in spiral get completed.
viii. It is suitable for high risk projects, where business needs may be unstable.
ix. A highly customized product can be developed using this.
x. Systematic approach.

Disadvantages
i. Requires expertise in risk evaluation and reduction.
ii. Complex, relatively difficult to follow strictly.
iii. Cost involved in this model is usually high.
iv. It is a complicated approach especially for projects with a clear SRS.
v. Skills required, evaluating and reviewing project from time to time, need expertise.
vi. Rules and protocols should be followed properly to effectively implement this model. Doing so, through-out
the span of project is tough.
vii. Due to various customizations allowed from the client, using the same prototype in other projects, in
future, is difficult.
viii. It is not suitable for low risk projects.
ix. Meeting budgetary and scheduling requirements is tough if this development process is followed.
x. Amount of documentation required in intermediate stages makes management of project very complex
affair.
xi. Applicable only to large systems.

Application
i. Internal development of large systems.
ii. This model can be used when the requirements of the complete system are clearly defined and understood.
iii. Major requirements must be defined; however, some details can evolve with time.
iv. There is a need to get a product to the market early.
v. A new technology is being used.
vi. Resources with needed skill set are not available.
vii. There are some high risk features and goals.

Concurrent Models
The concurrent development model, sometimes called concurrent engineering, allows a software team to
represent iterative and concurrent elements of any of the process models described in this chapter. For
example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the
following software engineering actions: prototyping, analysis, and design. An activity— modeling —may be in
any one of the states 7 noted at any given time. Similarly, other activities, actions, or tasks (e.g.,
communication or construction) can be represented in an analogous manner. All software engineering
activities exist concurrently but reside in different states. For example, early in a project the communication
activity (not shown in the figure) has completed its first iteration and exists in the awaiting changes state. The
modeling activity (which existed in the none state while initial communication was completed) now makes a
transition into the under development state. If, however, the customer indicates that changes in
requirements must be made, the modeling activity moves from the under development state into the
awaiting changes state. Concurrent modeling defines a series of events that will trigger transitions from state
to state for each of the software engineering activities, actions, or tasks. For example, during early stages of
design (a major software engineering action that occurs during the modeling activity), an inconsistency in the
requirements model is uncovered. This generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes state.

Concurrent modeling is applicable to all types of software development and provides an accurate picture of
the current state of a project. Rather than confining software engineering activities, actions, and tasks to a
sequence of events, it defines a process network. Each activity, action, or task on the network exists
simultaneously with other activities, actions, or tasks. Events generated at one point in the process network
trigger transitions among the states associated with each activity.
Agile Methodology

1. The Agile movement proposes alternatives to traditional project management.

2. Agile approaches are typically used in software development to help businesses respond to unpredictability.
3. It’s easy to the problems with “waterfall” methodology.
4. It assumes that every requirement of the project can be identified before any design or coding occurs.
5. At the end of a project, a team might have built the software it was asked to build, but, in the time it took to
create, business realities have changed so dramatically that the product is irrelevant.
6. Today very view organizations openly admit to doing waterfall or traditional command and control. But those
habits persist.

Advantages
i. Customer satisfaction by rapid, continuous delivery of useful software.
ii. People and interactions are emphasized rather than process and tools. Customers, developers and testers
constantly interact with each other.
iii. Working software is delivered frequently (weeks rather than months).
iv. Face-to-face conversation is the best form of communication.
v. Close, daily cooperation between business people and developers.
vi. Continuous attention to technical excellence and good design.
vii. Regular adaptation to changing circumstances.
viii. Even late changes in requirements are welcomed.

Disadvantages

i. In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the
beginning of the software development life cycle.
ii. There is lack of emphasis on necessary designing and documentation.
iii. The project can easily get taken off track if the customer representative is not clear what final outcome that
they want.
iv. Only senior programmers are capable of taking the kind of decisions required during the development process.
Hence it has no place for newbie programmers, unless combined with experienced resources.
v. It can be difficult to keep the interest of customers who are involved in the process.
vi. Team members may be unsuited to the intense involvement that characterizes agile method.
vii. Prioritizing changes can be difficult where there are multiple stakeholders.
viii. Maintaining simplicity requires extra work.
ix. Contracts may be a problem as with other approaches to iterative development.

Agility Principles
12 agility principles for those who want to achieve agility:

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. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to
the shorter timescale.
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.
6. The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
SCRUM Framework for Agile Methodology
1. Scrum is one of the most popular frameworks for implementing agile.
2. With scrum, the product is built in a series of fixed-length iterations called sprints that give teams a
framework for shipping software on a regular cadence. Milestones–i.e., the end of a sprint–come frequently,
bringing with them a feeling of tangible progress with each cycle that focuses and energizes everyone. Short
iterations also reinforce the importance of good estimation and fast feedback from tests–both recurring
struggles in waterfall projects.
4. During a sprint, visual artifacts like task boards and burn down charts, visible to the team and spectators
alike, are powerful motivators. They drive a spirit of "we're doing this!" Having the opportunity to show off
new work at the sprint demo is equally motivating, and the consistent, incremental feedback the team gets
from stakeholders at each demo creates a powerful way to develop products.

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.

Sprint: consist of work units that are required to achieve a requirement defined in the backlog that must be fi t
into a predefined time-box 10 (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.

Scrum meeting: 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?
5. Scrum done well–which is to say, not "waterfall with stand-ups"–can be a massive catalyst for improving
team productivity and morale, and the product development process as a whole.

6. Three essential roles for scrum success- A scrum team has a slightly different composition than a traditional
waterfall project, with three specific roles: product owner, scrum master, and the development team. And
because scrum teams are cross-functional, "the development team" includes testers, designers, and ops
engineers in addition to developers.
• The Product Owner: Product owners are the champions for their product. They are focused on
understanding business and market requirements, then prioritizing the work to be done by the
engineering team accordingly. Effective product owners:
 Build and manage the product backlog
 Closely partner with the business and the team to ensure everyone understands the work items in the
product backlog
 Give the team clears guidance on which features to deliver next
 Decide when to ship the product with the predisposition towards more frequent delivery.
• The Scrum Master: Scrum masters are the champion for scrum within their team. They coach the
team, the product owner, and the business on the scrum process and look for ways to fine-tune their
practice of it. An effective scrum master deeply understands the work being done by the team and can
help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed
resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint
retrospective.
• The Scrum Team: Scrum teams are the champions for sustainable development practices. The most
effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have
differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of
work. Strong scrum teams approach their project with a clear "we" attitude. All members of the team
help one another to ensure a successful sprint completion.
Extreme Programming
Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
1. New versions may be built several times per day;
2. Increments are delivered to customers every 2 weeks;
3. All tests must be run for every build and the build is only accepted if tests run successfully.
4. The extreme programming release cycle
CPMCD
5. Extreme programming practices
1. Principle or practice
2. Incremental planning
3. Small releases
4. Simple design
5. Test-first development
6. Refactoring
Description
Requirements are recorded on story cards and the
stories to be included in a release are determined by
the time available and their relative priority. The
developers break these stories into development
‘Tasks’.
The minimal useful set of functionality that provides
business value is developed first. Releases of the
system are frequent and incrementally add
functionality to the first release.
Enough design is carried out to meet the current
requirements and no more.
An automated unit test framework is used to write
tests for a new piece of functionality before that
functionality itself is implemented.
All developers are expected to refactor the code
continuously as soon as possible code improvements
are found. This keeps the code simple and
maintainable.
Kanban Model
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). Kanban has been used in Lean Production
for over `half-century.

Kanban - Benefits
Kanban has the following commonly observed benefits −
• Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the whole
value chain rather than just their part.
• Useful for situations where operations and support teams have a high rate of uncertainty and
variability.
• Tends to spread throughout the organization naturally, including sales and management. This
increases visibility of everything that is going on at the company.
• Since all segments/states in the workflow are visually organized, the required items, reducing the wait
times and ensuring speed, continually support all the tasks in the workflow.
• Overproduction of inventory is avoided, thereby saving resources and time as well. This is termed as
eliminating waste.
Agile Kanban is Agile Software Development with Kanban approach. In Agile Kanban, the Kanban board is
used to visualize the workflow. The Kanban board is normally put up on a wall in the project room. The status
and progress of the story development tasks is tracked visually on the Kanban board with flowing Kanban
cards.
Kanban Board

Kanban board is used to depict the flow of tasks across the value stream. The Kanban board −
• Provides easy access to everyone involved in the project.
• Facilitates communication as and when necessary.
• Progress of the tasks is visually displayed.
• Bottlenecks are visible as soon as they occur.

Advantages of Kanban board

The major advantages of using a Kanban board are −
• Empowerment of Team − This means −
o Team is allowed to take decisions as and when required.
o Team collaboratively resolves the bottlenecks.
o Team has access to the relevant information.
o Team continually communicates with customer.
• Continuous Delivery − This means −
o Focus on work completion.
o Limited requirements at any point of time.
o Focus on delivering value to the customer.
o Emphasis on whole project.
The tasks and stories are represented by Kanban cards. The current status of each task is known by displaying
the cards in separate columns on the board. The columns are labeled as To Do, Doing, and Done. Each task
moves from To Do to Doing and then to Done.
Kanban Board is updated on a daily basis as the team progresses through the development.
WIP Limit
The label in the Doing column also contains a number, which represents the maximum number of tasks that
can be in that column at any point of time. i.e., the number associated with the Doing column is the WIP
(Work-In-Progress) Limit.

Pull Approach
Pull approach is used as and when a task is completed in the Doing column. Another card is pulled from the
To Do column.

Self-directing
In Agile Development, the team is responsible for planning, tracking, reporting and communicating in the
project. Team is allowed to make decisions and is accountable for the completion of the development and
product quality. This is aligned to the characteristic of empowerment of the team in Kanban.
Continuous Flow
In Agile development, there is no gate approach and the work flows across the different functions without
wait-time. This contributes in minimizing the cycle time characteristic of Kanban.

Visual Metrics
In Agile Kanban, the metrics are tracked visually using −

• Kanban Board
• Burndown Chart

Uses of Kanban board

Kanban Board is used to −

• Measure the cycle times that can be used to optimize average cycle time.
• Track WIP limit to eliminate waste.
• Track resource utilization to eliminate waste.

Uses of Burndown chart

Burndown chart is used to capture −
• The current status of the tasks and stories.
• The rate of progress of completing the remaining tasks.
As Kanban Board is updated daily, it contains all the information that is required by the Burndown charts.