Chapter 1.

Introduction to Software Engineering and Process

Models

Syllabus Content

1.1 Software Engineering-process framework, the Capability Maturity Model (CMM),

Advanced Trends in Software Engineering

1.2 Prescriptive Process Models: The Waterfall, Incremental Process Models, Evolutionary
Process Models: RAD & Spiral

1.3 Agile process model: Extreme Programming (XP), Scrum, Kanban

Exam Question : Define Software and its application

What is Software?

• The product that software professionals build and then support over the long
term.

• 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 and

(3) documentation that describes the operation and use of the programs.

Software Product

• Generic products

Stand-alone systems that are marketed and sold to any customer who wishes to buy
them.

Examples – PC software such as editing, graphics programs, project management tools;

CAD software; software for specific markets such as appointments systems for dentists.

• Customized products

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Software that is commissioned by a specific customer to meet their own needs.

Examples – embedded control systems, air traffic control software, traffic monitoring
systems.

Essential attributes of good software

Product characteristic Description

Maintainability Software should be written in such a way

so that it can evolve to meet the changing

needs of customers. This is a critical

attribute because software change is an

inevitable requirement of a changing

business environment.

Dependability and security Software dependability includes a range

of characteristics including reliability,

security and safety. Dependable software

should not cause physical or economic

damage in the event of system failure.

Malicious users should not be able to

access or damage the system.

Efficiency Software should not make wasteful use of

system resources such as memory and

processor cycles. Efficiency therefore

includes responsiveness, processing time,

memory utilisation, etc.

Acceptability Software must be acceptable to the type

of users for which it is designed. This

means that it must be understandable,

usable and compatible with other systems

that they use.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Software applications

1. System software: such as compilers, editors, file management utilities

2. Application software: stand-alone programs for specific needs.

3. Engineering/scientific software: Characterized by “number crunching”algorithms. such

as automotive stress analysis, molecular biology, orbital dynamics etc

4. Embedded software resides within a product or system. (key pad control of a

microwave oven, digital function of dashboard display in a car)

5. Product-line software focus on a limited marketplace to address mass consumer

market. (word processing, graphics, database management)

6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database

and business applications.

7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert

system, pattern recognition game playing

Open world computing—pervasive, ubiquitous, distributed computing due to wireless

networking. How to allow mobile devices, personal computer, enterprise system to

communicate across vast network.

Netsourcing—the Web as a computing engine. How to architect simple and

sophisticated applications to target end-users worldwide.

Open source—”free” source code open to the computing community (a blessing, but

also a potential curse!)

Also Data mining,Grid computing, Cognitive machines & Software for nanotechnologies

Exam Question-: Explain characteristics of Software

Characteristics Of Software

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Characteristics 1-: Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.

Characteristic 2-: Software doesn't "wear out.”

Characteristic 3-: Most Software are custom built rather than being assembled from

existing component

Wear vs. Deterioration

Exam Question: Define Software Engineering

Software Engineering Definition

The seminal definition:

[Software engineering is] the establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works efficiently on real

machines.

The IEEE definition:

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Software Engineering: (1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the

application of engineering to software. (2) The study of approaches as in (1)

Layered Approach of Software Engineering

Tools

Methods

Process Models

Quality Focus

• Any engineering approach must rest on organizational commitment to quality

which fosters a continuous process improvement culture.

• Process layer as the foundation defines a framework with activities for effective

delivery of software engineering technology. Establish the context where products

(model, data, report, and forms) are produced, milestone are established, quality is

ensured and change is managed.

• Method provides technical how-to’s for building software. It encompasses many

tasks including communication, requirement analysis, design modeling, program

construction, testing and support.

• Tools provide automated or semi-automated support for the process and methods.

Software Process

• A process is a collection of activities, actions and tasks that are performed when
some work product is to be created.

• It is not a rigid prescription for how to build computer software. Rather, it is an

adaptable approach that enables the people doing the work to pick and choose the

appropriate set of work actions and tasks.

• Purpose of process is to deliver software in a timely manner and with sufficient

quality to satisfy those who have sponsored its creation and those who will use it.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • A framework for the activities, actions, and tasks that are required to build high-
quality software.

• SP defines the approach that is taken as software is engineered.

• Is not equal to software engineering, which also encompasses technologies that

populate the process– technical methods and automated tools.

Exam Question: Explain process of CMM

Capability Maturity Models

• 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 which is used to analyse the

approach and techniques followed by any organization to develop a software

product.

• It also provides guidelines to further enhance the maturity of those software

products.

• It is based on profound feedback and development practices adopted by the most

successful organizations worldwide.

• This model describes a strategy 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).

• Key Process Areas (KPA’s):

Each of these KPA’s defines the basic requirements that should be met by a

software process in order to satisfy the KPA and achieve that level of maturity.

• Conceptually, key process areas form the basis for management control of the
software project and establish a context in which technical methods are applied,
work products like models, documents, data, reports, etc. are produced, milestones

are established, quality is ensured and change is properly managed.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
5 Levels of CMM
Level-1: Initial

• No KPA’s defined.

• Processes followed are adhoc and immature and are not well defined.

• Unstable environment for software dvelopment.

• No basis for predicting product quality, time for completion, etc.

Level-2: Repeatable –

• Focuses on establishing basic project management policies.

• Experience with earlier projects is used for managing new similar natured projects.

• KPA’s: Project Planning- It includes defining resources required, goals, constraints,

etc. for the project. Configuration Management- 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 development.

Level-3: Defined –

• At this level, documentation of the standard guidelines and procedures takes place.

• It is a well defined integrated set of project specific software engineering and

management processes.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• KPA’s: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 fulfilment of customer needs.

• Organization Process Definition- It’s 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.

• Organization Process Definition- It’s 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.

• KPA’s:Software Quality Management- It includes the establishment of plans and

strategies to develop a quantitative analysis and understanding of the product’s

quality.

• Quantitative Management- It focuses on controlling the project performance in a

quantitative manner.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • 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.

• KPA’s:Process Change Management- Its focus is on the continuous improvement

of organization’s software processes to improve productivity, quality and cycle time

for the software product.

• Technology Change Management- It consists of identification and use of new

technologies to improve product quality and decrease the product development

time.

• Defect Prevention- It focuses on identification of causes of defects and to prevent

them from recurring in future projects by improving project defined process.

Generic Process Model

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Five Activities of Generic Process Framework

1. Communication: communicate with customer to understand objectives and gather

requirements

2. Planning: creates a “map” defines the work by describing the tasks, risks and
resources, work products and work schedule.

3. Modeling: Create a “sketch”, what it looks like architecturally, how the constituent
parts fit together and other characteristics.

4. Construction: code generation and the testing.

5. Deployment: Delivered to the customer who evaluates the products and provides
feedback based on the evaluation.

Umbrella Activities

• Software project tracking and control: assess progress against the plan and take

actions to maintain the schedule.

• Risk management: assesses risks that may affect the outcome and quality.

• Software quality assurance: defines and conduct activities to ensure quality.

• Technical reviews: assesses work products to uncover and remove errors before

going to the next activity.

• Measurement: define and collects process, project, and product measures to

ensure stakeholder’s needs are met.

• Software configuration management: manage the effects of change throughout

the software process.

• Reusability management: defines criteria for work product reuse and establishes
mechanism to achieve reusable components.

• Work product preparation and production: create work products such as models,

documents, logs, forms and lists.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Process Flow

• Linear process flow executes each of the five activities in sequence.

• 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 leads to a more complete version of the software.

• A parallel process flow executes one or more activities in parallel with other
activities ( modeling for one aspect of the software in parallel with construction

of another aspect of the software.

What / who / why is Process Models?

• What: It is a road map that helps you create a timely, high-quality results.

• Who: Software engineers and their managers, clients also. People adapt the
process to their needs and follow it.

• Why: Provides stability, control and organization to an activity

• What Work products: Programs, documents, and data

• What are the steps: The process you adopt depends on the software that you
are building. One process might be good for aircraft avionic system, while an

entirely different process would be used for website creation.

• How to ensure right: A number of software process assessment mechanisms

that enable us to determine the maturity of the software process. However, the
quality, timeliness and long-term viability of the software are the best

indicators of the efficacy of the process you use.

Prescriptive Models

• Originally proposed to bring order to chaos.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Prescriptive process models advocate an orderly approach to software
engineering. However, will some extent of chaos (less rigid) be beneficial to

bring some creativity?

Exam Question-: Explain Waterfall Model

Difference between Waterfall Model & Spiral Model

Waterfall Model

• The Waterfall Model was the first Process Model to be introduced.

• 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 illustrates the software development process in a linear

sequential flow. This means that any phase in the development process begins

only if the previous phase is complete. In this waterfall model, the phases do not
overlap.

The sequential phases in Waterfall model are −

1.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.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 2.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.

3.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
4.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.

5.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.
6.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.

Applications of Waterfall Model

• Requirements are very well documented, clear and fixed.

• Product definition is stable.

• Technology is understood and is not dynamic.

• There are no ambiguous requirements.

• Ample resources with required expertise are available to support the product.

• The project is short.

Advantages

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

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• 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

• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.

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

• It is difficult to measure progress within stages.

• Cannot accommodate changing requirements.

• Adjusting scope during the life cycle can end a project.

• Integration is done as a "big-bang. at the very end, which doesn't allow identifying
any technological or business bottleneck or challenges early.

V-Model

• The V-model is an SDLC model where execution of processes happens in a

sequential manner in a V-shape.

• It is also known as Verification and Validation model.

• The V-Model is an extension of the waterfall model and is based on the

association of a testing phase for each corresponding development stage.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • This means that for every single phase in the development cycle, there is a
directly associated testing phase.

• This is a highly-disciplined model and the next phase starts only after completion
of the previous phase.

1.Business Requirement Analysis-:

• This is the first phase in the development cycle where the product requirements are
understood from the customer’s perspective.

• This phase involves detailed communication with the customer to understand his

expectations and exact requirement.

• 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 is time to design the
complete system.

• The system design will have the understanding and detailing the complete hardware
and communication setup for the product under development.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • The system test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for the actual test execution later.

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.

• The 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.

Module Design

In this phase, the detailed internal design for all the system modules is specified, referred

to as Low Level Design (LLD). The unit tests are an essential part of any development
process and helps eliminate the maximum faults and errors at a very early stage..

Coding Phase

• The actual coding of the system modules designed in the design phase is taken up
in the Coding phase.

• The best suitable programming language is decided based on the system and

architectural requirements.

• The coding is performed based on the coding guidelines and standards.

• The code goes through numerous code reviews and is optimized for best

performance before the final build is checked into the repository.

Validation Phases

Unit Testing

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • 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

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.

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 this system test execution.

Acceptance Testing

• Acceptance testing is associated with the business requirement analysis phase and

involves testing the product in user environment.

• Acceptance tests uncover the non functional issues & compatibility issues with the
other systems available in the user environment.

Applications of V-Model

• Requirements are well defined, clearly documented and fixed.

• Product definition is stable.

• Technology is not dynamic and is well understood by the project team.

• There are no ambiguous or undefined requirements.

• The project is short.

Advantages

• This is a highly-disciplined model and Phases are completed one at a time.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Works well for smaller projects where requirements are very well understood.

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

Disadvantages

• High risk and uncertainty.

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

• Once an application is in the testing stage, it is difficult to go back and change a

functionality.

• No working software is produced until late during the life cycle.

Exam Question-: Discuss incremental model for software

development with merits and demerits

Incremental Model

• In the incremental model, starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the

complete system is implemented and ready to be deployed.

• Model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software,

which is then reviewed to identify further requirements.

• This process is then repeated, producing a new version of the software at the end

of each iteration of the model.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• In this 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.

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

• The key to a successful use of an iterative software development lifecycle is rigorous

validation of requirements, and verification & testing of each version of the software

against those requirements within each cycle of the model. As the software evolves
through successive cycles, tests must be repeated and extended to verify each

version of the software.

• In this 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.

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

Applications of Incremental Model

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • The key to a successful use of an iterative software development lifecycle is rigorous
validation of requirements, and verification & testing of each version of the software

against those requirements within each cycle of the model. As the software evolves
through successive cycles, tests must be repeated and extended to verify each

version of the software.

Advantages

• Some working functionality can be developed quickly and early in the life cycle.

• Results are obtained early and periodically.

• Parallel development can be planned.

• Progress can be measured.

• Less costly to change the scope/requirements.

• Testing and debugging during smaller iteration is easy.

• Risks are identified and resolved during iteration; and each iteration is an easily
managed milestone.

• Easier to manage risk - High risk part is done first.

• With every increment, operational product is delivered.

• Issues, challenges and risks identified from each increment can be utilized/applied
to the next increment.

• Risk analysis is better.

• It supports changing requirements.

• Initial Operating time is less.

• Better suited for large and mission-critical projects.

Disadvantages

• More resources may be required.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Although cost of change is lesser, but it is not very suitable for changing
requirements.

• More management attention is required.

• System architecture or design issues may arise because not all requirements are

gathered in the beginning of the entire life cycle.

• Defining increments may require definition of the complete system.

• Not suitable for smaller projects.

• Management complexity is more.

• Highly skilled resources are required for risk analysis.

• Projects progress is highly dependent upon the risk analysis phase.

Rapid Application Development (RAD) model

• The RAD (Rapid Application Development) model is based on prototyping and

iterative development with no specific planning involved.

• Rapid Application Development focuses on gathering customer requirements

through workshops or focus groups, early testing of the prototypes by the customer
using iterative concept, reuse of the existing prototypes (components), continuous

integration and rapid delivery.

Applications of RAD Model

• Rapid application development is a software development methodology that uses

minimal planning in favor of rapid prototyping. A prototype is a working model that

is functionally equivalent to a component of the product.

• In the RAD model, the functional modules are developed in parallel as prototypes
and are integrated to make the complete product for faster product delivery

• RAD projects follow iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Prototypes developed are reusable.

Following are the various phases of the RAD Model −

1) Business Modeling:-

• The business model for the product under development is designed in terms of
flow of information and the distribution of information between various business

channels. A complete business analysis is performed to find the vital information

for business, how it can be obtained, how and when is the information processed

and what are the factors driving successful flow of information.

2)Data Modeling

• The information gathered in the Business Modeling phase is reviewed and

analyzed to form sets of data objects vital for the business.

• The attributes of all data sets is identified and defined. The relation between these
data objects are established and defined in detail in relevance to the business

model.

3)Process Modeling

• The data object sets defined in the Data Modeling phase are converted to
establish the business information flow needed to achieve specific business
objectives as per the business model.
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • The process model for any changes or enhancements to the data object sets is
defined in this phase. Process descriptions for adding, deleting, retrieving or

modifying a data object are given.

4)Application Generation

The actual system is built and coding is done by using automation tools to convert
process and data models into actual prototypes.

5)Testing and Turnover

• The overall testing time is reduced in the RAD model as the prototypes are
independently tested during every iteration.

• However, the data flow and the interfaces between all the components need to be
thoroughly tested with complete test coverage. Since most of the programming

components have already been tested, it reduces the risk of any major issues.

RAD Model Vs Traditional SDLC

• The traditional SDLC follows a rigid process models with high emphasis on
requirement analysis and gathering before the coding starts.

• It puts pressure on the customer to sign off the requirements before the project
starts and the customer doesn’t get the feel of the product as there is no working

build available for a long time.

• The customer may need some changes after he gets to see the software.

• The RAD model focuses on iterative and incremental delivery of working models
to the customer.

• This results in rapid delivery to the customer and customer involvement during the
complete development cycle of product reducing the risk of non-conformance

with the actual user requirements.

Advantages

• Changing requirements can be accommodated.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Progress can be measured.

• Iteration time can be short with use of powerful RAD tools.

• Productivity with fewer people in a short time.

• Reduced development time.

• Increases reusability of components.

• Quick initial reviews occur.

• Encourages customer feedback.

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

Disadvantages

• Dependency on technically strong team members for identifying business

requirements.

• Only system that can be modularized can be built using RAD.

• Requires highly skilled developers/designers.

• High dependency on modeling skills.

• Inapplicable to cheaper projects as cost of modeling and automated code

generation is very high.

• Management complexity is more.

• Suitable for systems that are component based and scalable.

• Requires user involvement throughout the life cycle.

• Suitable for project requiring shorter development times.

Evolutionary Models

• Software system evolves over time as requirements often change as development

proceeds.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• You need a process model that has been explicitly designed to accommodate a
product that evolved over time.

• It is iterative that enables you to develop increasingly more complete version of

the software.

• Two types are introduced, namely Prototyping and Spiral models.

Exam Question-: Discuss prototype model for software development

with merits and demerits

Evolutionary Models: Prototyping

• When to use: Customer defines a set of general objectives but does not identify
detailed requirements for functions and features. Or Developer may be unsure of
the efficiency of an algorithm, the form that human computer interaction should
take.

• What step: Begins with communication by meeting with stakeholders to define the

objective, identify whatever requirements are known, outline areas where further

definition is mandatory. A quick plan for prototyping and modeling (quick design)
occur. Quick design focuses on a representation of those aspects the software

that will be visible to end users. ( interface and output). Design leads to the
construction of a prototype which will be deployed and evaluated. Stakeholder’s

comments will be used to refine requirements.

• Both stakeholders and software engineers like the prototyping paradigm. Users
get a feel for the actual system, and developers get to build something
immediately. However, engineers may make compromises in order to get a

prototype working quickly. The less-than-ideal choice may be adopted forever

after you get used to it.

• The Prototyping Model is one of the most popularly used Software Development
Life Cycle Models (SDLC models).

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • This model is used when the customers do not know the exact project
requirements beforehand.

• In this model, a prototype of the end product is first developed, tested and refined

as per customer feedback repeatedly till a final acceptable prototype is achieved

which forms the basis for developing the final product

• In this process model, the system is partially implemented before or during the

analysis phase thereby giving the customers an opportunity to see the product
early in the life cycle.

• The process starts by interviewing the customers and developing the incomplete
high-level paper model. This document is used to build the initial prototype

supporting only the basic functionality as desired by the customer.

• Once the customer figures out the problems, the prototype is further refined to
eliminate them. The process continues till the user approves the prototype and

finds the working model to be satisfactory

Quick
communication plan
Modeling
Quick design

Deployment
delivery & Construction

feedback of prototype

1. Requirements gathering and analysis: A prototyping model begins with

requirements analysis and the requirements of the system are defined in

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
detail. The user is interviewed in order to know the requirements of the
system.

2. Quick design: When requirements are known, a preliminary design or quick

design for the system is created. It is not a detailed design and includes only
the important aspects of the system, which gives an idea of the system to the
user. A quick design helps in developing the prototype.

3. Build prototype: Information gathered from quick design is modified to

form the first prototype, which represents the working model of the required
system.

4. User evaluation: Next, the proposed system is presented to the user for thorough

evaluation of the prototype to recognize its strengths and weaknesses such as what is to
be added or removed. Comments and suggestions are collected from the users and

provided to the developer.

5. Refining prototype: Once the user evaluates the prototype and if he is not satisfied, the

current prototype is refined according to the requirements. That is, a new prototype is
developed with the additional information provided by the user. The new prototype is

evaluated just like the previous prototype. This process continues until all the requirements
specified by the user are met. Once the user is satisfied with the developed prototype, a

final system is developed on the basis of the final prototype.

6. Engineer product: Once the requirements are completely met, the user accepts the final

prototype. The final system is evaluated thoroughly followed by the routine maintenance
on regular basis for preventing large-scale failures and minimizing downtime.

Applications of Prototype Model

• when the requirements of the product are not clearly understood or are unstable

• It can also be used if requirements are changing quickly.

• This model can be successfully used for developing user interfaces, high technology
software-intensive systems, and systems with complex algorithms and interfaces.
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • It is also a very good choice to demonstrate the technical feasibility of the product.

Advantages

• The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.

• New requirements can be easily accommodated as there is scope for refinement.

• Missing functionalities can be easily figured out.

• Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.

• The developed prototype can be reused by the developer for more complicated
projects in the future.

• Flexibility in design

Disadvantages

• Costly w.r.t time as well as money.

• There may be too much variation in requirements each time the prototype is
evaluated by the customer.

• Poor Documentation due to continuously changing customer requirements.

• It is very difficult for the developers to accommodate all the changes demanded by
the customer.

• There is uncertainty in determining the number of iterations that would be required

before the prototype is finally accepted by the customer.

• After seeing an early prototype, the customers sometimes demand the actual

product to be delivered soon.

• Developers in a hurry to build prototypes may end up with sub-optimal solutions.

• The customer might lose interest in the product if he/she is not satisfied with the
initial prototype.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Exam Question-: Describe Spiral Model

Compare Waterfall model with Spiral Model

Spiral Model

• The spiral model combines the idea of iterative development with the systematic,

controlled aspects of the waterfall model.

• This Spiral model is a combination of iterative development process model and

sequential linear development model i.e. the waterfall model with a very high

emphasis on risk analysis.

• It allows incremental releases of the product or incremental refinement through

each iteration around the spiral.

Phases in Spiral Model

1.Communication

• This phase starts with gathering the business requirements in the baseline spiral. In
the subsequent spirals as the product matures, identification of system

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 requirements, subsystem requirements and unit requirements are all done in this
phase.

• This phase also includes understanding the system requirements by continuous

communication between the customer and the system analyst. At the end of the
spiral, the product is deployed in the identified market.

2.Planning

After gathering the requirements detailed software plan is prepared

3. Design

• The Design phase starts with the conceptual design in the baseline spiral and

involves architectural design, logical design of modules, physical product design

and the final design in the subsequent spirals.

4.Construct or Build

• The Construct phase refers to production of the actual software product at every

spiral. In the baseline spiral, when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get

customer feedback.

• Then in the subsequent spirals with higher clarity on requirements and design

details a working model of the software called build is produced with a version
number. These builds are sent to the customer for feedback.

5.Evaluation and Risk Analysis

• Risk Analysis includes identifying, estimating and monitoring the technical

feasibility and management risks, such as schedule slippage and cost overrun.

After testing the build, at the end of first iteration, the customer evaluates the
software and provides feedback.

Applications of Spiral Model

• When there is a budget constraint and risk evaluation is important.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• For medium to high-risk projects.

• Long-term project commitment because of potential changes to economic

priorities as the requirements change with time.

• Customer is not sure of their requirements which is usually the case.

• Requirements are complex and need evaluation to get clarity.

• New product line which should be released in phases to get enough customer
feedback.

• Significant changes are expected in the product during the development cycle.

Advantages

• Changing requirements can be accommodated.

• Allows extensive use of prototypes.

• Requirements can be captured more accurately.

• Users see the system early.

• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.

Disadvantages

• Management is more complex.

• End of the project may not be known early.

• Not suitable for small or low risk projects and could be expensive for small
projects.

• Process is complex

• Spiral may go on indefinitely.

• Large number of intermediate stages requires excessive documentation.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Sr. no. Waterfall Model Spiral Model

1. Waterfall model works in sequential While spiral model works in

method. evolutionary method.

2. In waterfall model errors or risks are In spiral model errors or risks are
identified and rectified after the identified and rectified earlier.
completion of stages.

3. Waterfall model is adopted by While spiral model is adopted by

customers. developers.

4. Waterfall model is applicable for While Spiral model is used for large
small project. project.

5. In waterfall model requirements and While in spiral model requirements

early stage planning is necessary. and early stage planning is
necessary if required.

6. Flexibility to change in waterfall Flexibility to change in spiral model

model is Difficult. is not Difficult.

7. There is high amount risk in waterfall There is low amount risk in spiral
model. model.

Three Concerns on Evolutionary Processes

• First concern is that prototyping poses a problem to project planning

because of the uncertain number of cycles required to construct the

product.

• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the

process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.

• Third, software processes should be focused on flexibility and extensibility

rather than on high quality. We should prioritize the speed of the

development over zero defects. Extending the development in order to

reach high quality could result in a late delivery of the product when the

opportunity niche has disappeared.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • The concurrent development model is called as concurrent model.
• The communication activity has completed in the first iteration and exits in

the awaiting changes state.

• The modeling activity completed its initial communication and then go to

the underdevelopment state.

• If the customer specifies the change in the requirement, then the modeling

activity moves from the under development state into the awaiting change
state.

• The concurrent process model activities moving from one state to another
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 trigger transitions among the states.

Advantages
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• This model is applicable to all types of software development processes.
• It is easy for understanding and use.

• It gives immediate feedback from testing.

• It provides an accurate picture of the current state of a project.

Disadvantages

• It needs better communication between the team members. This may not be

achieved all the time.

• It requires to remember the status of the different activities.

Still Other Process Models

• Component based development—the process to apply when reuse is a

development objective ( like spiral model)

• Formal methods—emphasizes the mathematical specification of

requirements ( easy to discover and eliminate ambiguity,
incompleteness and inconsistency)

• Aspect Oriented software development (AOSD)—provides a process

and methodological approach for defining, specifying, designing, and
constructing aspects

• Unified Process—a “use-case driven, architecture-centric, iterative and

incremental” software process closely aligned with the Unified
Modeling Language (UML) to model and develop object-oriented
system iteratively and incrementally.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 elaborati
on

inception

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Unified Process Work Product

Personal Software Process

• Planning. This activity isolates requirements and develops both size

and resource estimates. In addition, a defect estimate (the number of
defects projected for the work) is made. All metrics are recorded on
worksheets or templates. Finally, development tasks are identified and
a project schedule is created.

• High-level design. External specifications for each component to be

constructed are developed and a component design is created.
Prototypes are built when uncertainty exists. All issues are recorded and
tracked.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • High-level design review. Formal verification methods (Chapter 21)
are applied to uncover errors in the design. Metrics are maintained for
all important tasks and work results.

• Development. The component level design is refined and reviewed.

Code is generated, reviewed, compiled, and tested. Metrics are
maintained for all important tasks and work results.

• Postmortem. Using the measures and metrics collected (this is a

substantial amount of data that should be analyzed statistically), the
effectiveness of the process is determined. Measures and metrics should
provide guidance for modifying the process to improve its effectiveness.

Team Software Process

• Build self-directed teams that plan and track their work, establish goals, and own
their processes and plans. These can be pure software teams or integrated product

teams (IPT) of three to about 20 engineers.

• Show managers how to coach and motivate their teams and how to help them

sustain peak performance.

• Accelerate software process improvement by making CMM Level 5 behavior normal

and expected.
• Provide improvement guidance to high-maturity organizations.

• Facilitate university teaching of industrial-grade team skills.

Exam Question:

What is Agile Methodology?

What is agility in context of Software Engineering?

What are agile processes?

Write short note on Agile Methodology?

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Write short note on Agile Process Models

Agile Software Development

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

What is ‘Agility’?

• Effective (rapid and adaptive) response to change (team members, new technology,

requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers。

• Drawing the customer into the team. Eliminate “us and them” attitude. Planning in
an uncertain world has its limits and plan must be flexible.

• Organizing a team so that it is in control of the work performed

• Eliminate all but the most essential work products and keep them lean.

• Emphasize an incremental delivery strategy as opposed to intermediate products

that gets working software to the customer as rapidly as feasible.

• The development guidelines stress delivery over analysis and design although these

activates are not discouraged, and active and continuous communication between
developers and customers

• Why? The modern business environment is fast-paced and ever-changing. It

demonstrated to deliver successful systems quickly.

• What? They morph into a minimal task set that push the team toward construction
and delivery sooner.

• The only really important work product is an operational “software increment” that
is delivered.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Agility and the Cost of Change

• Conventional wisdom is that the cost of change increases nonlinearly as

a project progresses.

• It is relatively easy to accommodate a change when a team is gathering

requirements early in a project.

• If there are any changes, the costs of doing this work are minimal. But
if the middle of validation testing, a stakeholder is requesting a major
functional change.

• Then the change requires a modification to the architectural design,

construction of new components, changes to other existing
components, new testing and so on. Costs escalate quickly.

• A well-designed agile process may “flatten” the cost of change curve by

coupling incremental delivery with agile practices such as continuous
unit testing and pair programming. Thus team can accommodate
changes late in the software project without dramatic cost and time
impact.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 An Agile Process

• Is driven by customer descriptions of what is required (scenarios). Some

assumptions:

– Recognizes that plans are short-lived (some requirements will persist, some
will change. Customer priorities will change)

– Develops software iteratively with a heavy emphasis on construction activities

(design and construction are interleaved, hard to say how much design is

necessary before construction. Design models are proven as they are created.

– Analysis, design, construction and testing are not predictable.

• Thus has to Adapt as changes occur due to unpredictability

• Delivers multiple ‘software increments’, deliver an operational prototype or portion

of an OS to collect customer feedback for adaption.

Agile Process Advantages

• Customer satisfaction by rapid, continuous delivery of useful software.

• People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.

• Working software is delivered frequently (weeks rather than months).

• Face-to-face conversation is the best form of communication.

• Close, daily cooperation between business people and developers.

• Continuous attention to technical excellence and good design.

• Regular adaptation to changing circumstances.

• Even late changes in requirements are welcomed.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 Agile Process Disadvantages

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

• There is lack of emphasis on necessary designing and documentation.

• The project can easily get taken off track if the customer representative is not clear
what final outcome that they want.

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

Agility Principles

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.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
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.

When to Use Agile Process

• When new changes need to be implemented-: New changes can be implemented

at very little cost because of the frequency of new increments that are produced.

• To implement a new feature the developers, need to lose only the work of a few
days, or even only hours, to roll back and implement it.

• Agile assumes that the end users’ needs are ever changing in a dynamic business

and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system

they want or need.

• Both system developers and stakeholders alike, find they also get more freedom of
time and options than if the software was developed in a more rigid sequential way.

Exam Question: Explain Extreme Programming with suitable

example

Extreme Programming

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Extreme Programming (XP) is an agile software development framework that aims

to produce higher quality software, and higher quality of life for the development
team.

• XP is the most specific of the agile frameworks regarding appropriate engineering

practices for software development.

Basic principles of Extreme programming:

• XP is based on the frequent iteration through which the developers implement User

Stories.

• User stories are simple and informal statements of the customer about the
functionalities needed.

• A User story is a conventional description by the user about a feature of the

required system.

• It does not mention finer details such as the different scenarios that can occur. On

the basis of User stories, the project team proposes Metaphors.

A Spike is a very simple program that is constructed to explore the suitability of a

solution being proposed. It can be considered similar to a prototype. .

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• XP Planning

– Begins with the listening, leads to creation of “user stories” that describes
required output, features, and functionality. Customer assigns a value(i.e., a

priority) to each story.

– Agile team assesses each story and assigns a cost (development weeks. If
more than 3 weeks, customer asked to split into smaller stories)

– Working together, stories are grouped for a deliverable increment next

release.

– A commitment (stories to be included, delivery date and other project

matters) is made. Three ways: 1. Either all stories will be implemented in a

few weeks, 2. high priority stories first, or 3. the riskiest stories will be

implemented first.

– After the first increment “project velocity”, namely number of stories

implemented during the first release is used to help define subsequent

delivery dates for other increments. Customers can add stories, delete

existing stories, change values of an existing story, split stories as

development work proceeds.

• XP Design ( occurs both before and after coding as refactoring is encouraged)

– Follows the KIS principle (keep it simple) Nothing more nothing less than the

story.

– Encourage the use of CRC (class-responsibility-collaborator) cards in an

object-oriented context.

– For difficult design problems, suggests the creation of “spike solutions”—a

design prototype for that portion is implemented and evaluated.

– Encourages “refactoring”—an iterative refinement of the internal program

design. Does not alter the external behavior yet improve the internal
structure. Minimize chances of bugs. More efficient, easy to read.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• XP Coding

– Recommends the construction of a unit test for a story before coding

commences. So implementer can focus on what must be implemented to

pass the test.

– Encourages “pair programming”. Two people work together at one

workstation. Real time problem solving, real time review for quality

assurance. Take slightly different roles.

• XP Testing

– All unit tests are executed daily and ideally should be automated. Regression

tests are conducted to test current and previous components.

– “Acceptance tests” are defined by the customer and executed to assess

customer visible functionality

Extreme Programming Advantages

• Slipped schedules − and achievable development cycles ensure timely deliveries.

• Cancelled projects − Focus on continuous customer involvement ensures

transparency with the customer and immediate resolution of any issues.

• Costs incurred in changes − Extensive and ongoing testing makes sure the
changes do not break the existing functionality. A running working system always

ensures sufficient time for accommodating changes such that the current
operations are not affected.

• Production and post-delivery defects: Emphasis is on − the unit tests to detect

and fix the defects early.

• Misunderstanding the business and/or domain − Making the customer a part of

the team ensures constant communication and clarifications.

• Business changes − Changes are considered to be inevitable and are

accommodated at any point of time.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • Staff turnover − Intensive team collaboration ensures enthusiasm and good will.
Cohesion of multi-disciplines fosters the team spirit.

XP Debate

Applications of Extreme Programming (XP): Some of the projects that are suitable
to develop using XP model are given below:

• Small projects: XP model is very useful in small projects consisting of small teams as
face to face meeting is easier to achieve.

• Projects involving new technology or Research projects: This type of projects face

changing of requirements rapidly and technical problems. So XP model is used to

complete this type of projects.

XP Disadvantages

• Requirements volatility: customer is an active member of XP team, changes to

requirements are requested informally and frequently.

• Conflicting customer needs: different customers' needs need to be assimilated.

Different vision or beyond their authority.

• Requirements are expressed informally: Use stories and acceptance tests are the

only explicit manifestation of requirements. Formal models may avoid

inconsistencies and errors before the system is built. Proponents said changing

nature makes such models obsolete as soon as they are developed.

• Lack of formal design: XP deemphasizes the need for architectural design. Complex
systems need overall structure to exhibit quality and maintainability. Proponents

said incremental nature limits complexity as simplicity is a core value.

Exam Question-: Short note on Scrum

Scrum

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
 • A Scrum process is distinguished from other agile processes by
specific concepts and practices, divided into the three categories of
Roles, Artifacts, and Time Boxes.

• Scrum is most often used to manage complex software and product

development, using iterative and incremental practices.

• Scrum significantly increases productivity and reduces time to benefits

relative to classic “waterfall” processes.

• Scrum processes enable organizations to adjust smoothly to rapidly-

changing requirements, and produce a product that meets evolving
business goals.

An agile Scrum process benefits the organization by helping it to

• Increase the quality of the deliverables

• Cope better with change (and expect the changes)

• Provide better estimates while spending less time creating them

• Be more in control of the project schedule and state

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Scrum is an agile process most commonly used for product
development, especially software development.

• Scrum is a project management framework that is applicable to any

project with aggressive deadlines, complex requirements and a degree
of uniqueness.

• In Scrum, projects move forward via a series of iterations called sprints.

Each sprint is typically two to four weeks long.

• Scrum team: A typical scrum team has between five and nine people,
but Scrum projects can easily scale into the hundreds. However, Scrum
can easily be used by one-person teams and often is. This team does
not include any of the traditional software engineering roles such as
programmer, designer, tester or architect. Everyone on the project
works together to complete the set of work they have collectively
committed to complete within a sprint. Scrum teams develop a deep
form of camaraderie and a feeling that “we’re all in this together.”

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Product owner: The product owner is the project’s key stakeholder
and represents users, customers and others in the process. The
product owner is often someone from product management or
marketing, a key stakeholder or a key user.

• Scrum Master: The Scrum Master is responsible for making sure the
team is as productive as possible. The Scrum Master does this by
helping the team use the Scrum process, by removing impediments to
progress, by protecting the team from outside, and so on.

• Product backlog: The product backlog is a prioritized features list

containing every desired feature or change to the product. Note: The
term “backlog” can get confusing because it’s used for two different
things. To clarify, the product backlog is a list of desired features for
the product. The sprint backlog is a list of tasks to be completed in a
sprint.

• Sprint planning meeting: At the start of each sprint, a sprint planning

meeting is held, during which the product owner presents the top
items on the product backlog to the team. The Scrum team selects the
work they can complete during the coming sprint. That work is then
moved from the product backlog to a sprint backlog, which is the list
of tasks needed to complete the product backlog items the team has
committed to complete in the sprint.

• Daily Scrum: Each day during the sprint, a brief meeting called the
daily scrum is conducted. This meeting helps set the context for each
day’s work and helps the team stay on track. All team members are
required to attend the daily scrum.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Sprint review meeting: At the end of each sprint, the team
demonstrates the completed functionality at a sprint review meeting,
during which, the team shows what they accomplished during the
sprint. Typically, this takes the form of a demonstration of the new
features, but in an informal way; for example, PowerPoint slides are
not allowed. The meeting must not become a task in itself nor a
distraction from the process.

• Sprint retrospective: Also at the end of each sprint, the team

conducts a sprint retrospective, which is a meeting during which the
team (including its ScrumMaster and product owner) reflect on how
well Scrum is working for them and what changes they may wish to
make for it to work even better.

Each of the Scrum terms has its own page within the Scrum section, so
be sure to check out all the pages in the navigation.

Kanban Model

• In a Kanban process, there are physical (or virtual) “cards” called

Kanban that move through the process from start to finish.

• The aim is to keep a constant flow of Kanban so that as inventory is

required at the end of the process, just that much is created at the
start.

• Kanban is an agile methodology that is not necessarily iterative.

Processes like Scrum have short iterations which mimic a project
lifecycle on a small scale, having a distinct beginning and end for each
iteration.

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Kanban allows the software be developed in one large development
cycle. Despite this, Kanban is an example of an agile methodology
because it fulfils all twelve of the principles behind the Agile manifesto,
because whilst it is not iterative, it is incremental.

• Visualize what you do today (workflow): seeing all the items in context
of each other can be very informative

• Limit the amount of work in progress (WIP): this helps balance the
flow-based approach so teams don€™t start and commit to too much
work at once

• Enhance flow: when something is finished, the next highest thing from
the backlog is pulled into play

• Kanban project has no defined start or end points for individual work
items, each can start and end independently from one another, and
work items have no pre-determined duration for that matter.

• Instead, each phase of the lifecycle is recognized as having a limited

capacity for work at any one time.

• A small work item is created from the prioritized and unstarted

requirements list and then begins the development process, usually
with some requirements elaboration.

• A work item is not allowed to move on to the next phase until some
capacity opens up ahead.

• By controlling the number of tasks active at any one time, developers

still approach the overall project incrementally which gives the
opportunity for Agile principles to be applied.
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
• Kanban projects have Work In Progress (WIP) limits which are the
measure of capacity that keeps the development team focused on
only a small amount of work at one time.

• It is only as tasks are completed that new tasks are pulled into the
cycle. WIP limits should be fine-tuned based on comparisons of
expected versus actual effort for tasks that complete.

• Kanban does not impose any role definition as say, Scrum does and
along with the absence of formal iterations, role flexibility makes
Kanban attractive to those who have been using waterfall-style
development models and want to change but are afraid of the initial
upheaval something like Scrum can cause while being adopted by a
development team.

Benefits:

• Shorter cycle times can deliver features faster.

• Responsiveness to Change:

• When priorities change very frequently, Kanban is ideal.

• Balancing demand against throughput guarantees that most the

customer-centric features are always being worked.

• Requires fewer organization / room set-up changes to get started

• Reducing waste and removing activities that don€™t add value to the
team/department/organization

• Rapid feedback loops improve the chances of more motivated,

empowered and higher-performing team members

Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)
Chapter 1 Introduction to Software Engineering and Process Models -Prepared by Prof .Prita Patil(VIT-CMPN)