Prescriptive

Process Models
and Agile
methodology
Personal and Team Process Models (PSP
& TSP )
PSP TSP

• The Personal Software Process (PSP) is a • The Team software process (TSP) provides a defined
structured software development process that is designed to operational process framework that is designed to help
help software engineers better understand and improve their teams of managers and engineers organize projects and
performance by bringing discipline to the way they develop produce software for products that range in size from small
software and tracking their predicted and actual projects of several thousand lines of code to very large
development of the code. projects greater than half a million lines of code.

• PSP has two review phases : Design review , Code review •TSP has two principal components: team-building and
team-working
•It works on 2 stages : PSP0 – and progresses in process
maturity to the final level – PSP2.1. •
 Prescriptive Process Models
• The Waterfall Model :
i. It is simple but idealistic.
ii. In fact, it is hard to put this model into use in any non-trivial software development project.
One might wonder if this model is hard to use in practical development projects, then why
study it at all? The reason is that all other life cycle models can be thought of as being
extensions of the classical waterfall model.
iii. Therefore, to first understand the classical waterfall model, in order to be able to develop a
proper understanding of other life cycle models. Besides, we shall see later in this text that
this model though not used for software development; is implicitly used while documenting
software.
Phases of Waterfall Model –
i. Feasibility Study :

The main focus of the feasibility study stage is to determine whether it would be financially and
technically feasible to develop the software.

feasibility study involves carrying out several activities such as collection of basic information
relating to the software such as the different data items that would be input to the system, the
processing required to be carried out on these data, the output data required to be produced by the
system, as well as various constraints on the development.
ii. Requirement Analysis and Specification :

The aim of the requirements analysis and specification phase is to understand the exact
requirements of the customer and to document them properly.

This phase consists of two distinct activities, requirements gathering and analysis, and
requirements specification.
Iii. Design :

The goal of the design phase is to transform the requirements specified in the SRS document into
a structure that is suitable for implementation in some programming language.

Two approaches are present –procedural design approach and Object oriented approach.

▪Procedural design approach -This traditional design technique is based on the data flow-oriented
design approach. It includes – structured analysis and structured design.

▪ Object oriented approach – It has lower development time and effort, and better maintainability
of the software.
iv . Coding and Unit testing :

The purpose of the coding and unit testing phase is to translate a software design into source code
and to ensure that individually each function is working correctly. The coding phase is also
sometimes called the implementation phase, The main objective of unit testing is to determine the
correct working of the individual modules. The specific activities carried out during unit testing
include designing test cases, testing, debugging to fix problems, and management of test cases.
v . Integration and System testing –

Integration of different modules is after they have been coded and unit tested. During the
integration and system testing phase, the different modules are integrated in a planned manner.
Finally, after all the modules have been successfully integrated and tested, the full working
system is obtained. System testing is carried out on this fully working system.

System testing usually consists of three different kinds of testing activities: -

Testing, testing , Acceptance testing:

vi . Maintenance :

The total effort spent on maintenance of a typical software during its operation phase is much
more than that required for developing the software itself.

Maintenance is required in the following three types of situations:

•Corrective maintenance:

•Perfective maintenance:

•Adaptive maintenance
 Weakness :

• Requirements must be known prior

• Inhibits flexibility.

• No problem solving nature

• Little opportunity for customer to preview the system

• Integration at the end is a major bang

• Can give false impression of progress.

 Example of waterfall model :

Automobile industry , Car or bike production – Requirements are drafted. Once they are
finalized then design phase starts. Now requirements do not change unless the car or bike is
completely ready .
 Strengths :

• Easy to understand

• Provides basic structure

• Sets requirement stability

• Good for management control

• Works well when quality is more important than cost or schedule

 • V Model

i. V-model is a variant of the waterfall model. This model gets its name from its visual
appearance .

ii. In this model verification and validation activities are carried out throughout the
development life cycle, and therefore the chances bugs in the work products considerably
reduce.

iii. This model is therefore generally considered to be suitable for use in projects concerned with
development of safety-critical software that are required to have high reliability.
• There are two main phases—development and validation phases. The left half of the model
comprises the development phases and the right half comprises the validation phases.

• Development phase :

Along with the development of a work product, test case design and the plan for testing the
work product are carried out, whereas the actual testing is carried out in the validation phase.

• Validation phase :

Testing is carried out in three steps—unit, integration, and system testing. The purpose of these
three different steps of testing during the validation phase is to detect defects that arise in the
corresponding phases of software development requirements analysis and specification, design,
and coding respectively.
Phases of V model :
 Strengths :

• this model usually leads to a shorter testing phase and an overall faster product development as
compared to the iterative model.

• quality of the test cases are usually better.

• the test team is associated with the project from the beginning. Therefore they build up a good
understanding of the development artifacts, and this in turn, helps them to carry out effective
testing of the software.
 Weakness :

• Requirements must be known prior

• Inhibits flexibility.

• No problem solving nature

 • Incremental Process Model

i. Sometimes also referred to as successive versions model.

ii. In this life cycle model, first a simple working system implementing only a few basic
features is built and delivered to the customer. Over many successive iterations successive
versions are implemented and delivered to the customer until the desired system is realized.

iii. When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed, but many supplementary features (some known, others
unknown) remain undelivered. The core product is used by the customer (or undergoes
detailed review). As a result of use and/or evaluation, a plan is developed for the next
increment. The plan addresses the modification of the core product to better meet the needs
of the customer and the delivery of additional features and functionality. This process is
repeated following the delivery of each increment, until the complete product is produced.
 Strengths

• Reduces chances of errors in the core modules of the final product, leading to greater reliability
of the software.

• This model obviates the need for the customer to commit large resources at one go for
development of the system. It also saves the developing organisation from deploying large
resources and manpower for a project in one go.
 Weakness

• Total cost is high

• Needs clear view of the entire system before it can be broken down and built incrementally

• Needs good planning and design

 • Evolutionary model : Prototyping

i. The prototyping paradigm begins with requirements gathering.

ii. 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. 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).

iii. 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.
 Strengths

• User gets a chance to experiment with a partially developed software much before the complete
requirements are developed. As a result, the change requests after delivery of the complete
software gets substantially reduced.

• In this model, handling change requests is easier as no long term plans are made. Consequently,
reworks required due to change requests are normally much smaller compared to the sequential
models
 Weakness

• It is difficult to divide the required features into several parts that can be incrementally
implemented and delivered.

• Since at a time design for only the current increment is done, the design can become ad hoc
without specific attention being paid to maintainability and optimality.
Agile Software Methodology
Agile Methodology
• The agile software development model was proposed in the mid-1990s to overcome the serious
shortcomings of the waterfall model of development identified above.
• The agile model was primarily designed to help a project to adapt to change requests quickly. Thus, a
major aim of the agile models is to facilitate quick project completion.
• Agility is achieved by fitting the process to the project, i.e. removing activities that may not be
necessary for a specific project. Also, anything that that wastes time and effort is avoided.
• In the agile model, the requirements are decomposed into many small parts that can be incrementally
developed. The agile model adopts an iterative approach. Each incremental part is developed over an
iteration.
• At a time, only one increment is planned, developed, and then deployed at the customer site. No
long-term plans are made. The time to complete an iteration is called a time box. The implication
of the term time box is that the end date for an iteration does not change

• Agile model emphasise face-to-face communication over written documents. It is recommended

that the development team size be deliberately kept small (5–9 people) to help the team members
meaningfully engage in face-to-face communication and have collaborative work environment. It
is implicit then that the agile model is suited to the development of small projects.
 Agility Principles

• Working software over comprehensive documentation.

•Frequent delivery of incremental versions of the software to the customer in intervals of few
weeks.

•Requirement change requests from the customer are encouraged and are efficiently incorporated.

• Having competent team members and enhancing interactions among them is considered much
more important than issues such as usage of sophisticated tools or strict adherence to a
documented process. It is advocated that enhanced communication among the development team
members can be realised through face-to-face communication rather than through exchange of
formal documents.
• Continuous interaction with the customer is considered much more important rather than
effective contract negotiation. A customer representatives is required to be a part of the
development team, thus facilitating close, daily co-operation between customers and developers.
 Agile Testing Methodology

Early Testing focuses on :

• Writing test cases to express the behavior of the system .

• Early defect Prevention, Detection and removal.

• Ensuring that right test types are run at the right time.

Common Testing Methodologies are :

• Test driven development (TDD): Based on coding guided by tests.

• Acceptance test driven development (ATDD ) : Based on communication between customers ,

developers , and testers and driven by predefined Acceptance criteria and Acceptance test cases.
• Behavior Driven Development (BDD) : Based on the expected behavior of the software being
developed .
 Strengths

•The agile methods derive much of their agility by relying on the tacit knowledge of the team
members about the development project and informal communications to clarify issues, rather
than spending significant amounts of time in preparing formal documents and reviewing them.
 Weakness

•Lack of formal documents leaves scope for confusion and important decisions taken during
different phases can be misinterpreted at later points of time by different team members.

•In the absence of any formal documents, it becomes difficult to get important project decisions
such as design decisions to be reviewed by external experts.

•When the project completes and the developers disperse, maintenance can become a problem.
Agile Process Models

•Crystal

•Atern (formerly DSDM)

•Feature-driven development

• Scrum

•Extreme programming (XP)

• Lean development

•Unified process
 Scrum :
• Scrum advocates Whole Team approach , in the sense that every team member has to take part in every
project activity.
• The whole team works together on Test Strategy, Test Planning, Test Specification, Test Execution, Test
Evaluation, and Test Results Reporting.
• This approach also encourages proper use of the team talent instead of restricting to one activity. Testers
also participate in all the project and development activities contributing their expertise in testing.
• In the scrum model, a project is divided into small parts of work that can be incrementally developed and
delivered over time boxes that are called sprints.
• The software therefore gets developed over a series of manageable chunks. Each sprint typically
takes only a couple of weeks to complete.

•At the end of each sprint, stakeholders and team members meet to assess the progress made and
the stakeholders suggest to the development team any changes needed to features that have
already been developed and any overall improvements that they might feel necessary.

•In the scrum model, the team members assume three fundamental roles— software owner, scrum
master, and team member. The software owner is responsible for communicating the customers
vision of the software to the development team. The scrum master acts as a liaison between the
software owner and the team, thereby facilitating the development work.
Scrum Process Flow
•Sprint:
A Sprint is a time-box of one month or less. A new Sprint starts immediately after the completion
of the previous Sprint.

• Release:
When the product is completed then it goes to the Release stage.

•Sprint Review:
If the product still have some non-achievable features then it will be checked in this stage and
then the product is passed to the Sprint Retrospective stage.

•Sprint Retrospective:
In this stage quality or status of the product is checked.
•Product Backlog:
According to the prioritize features the product is organized.

•Sprint Backlog:
Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning
meeting.
 Agile tools : IceScrum

• IceScrum is an online Scrum tool that offers Dashboard and Timeline views, Product Backlog,
Release, and Sprint Plans, as well as Actors and Team functionality.

•It facilitates visual management with the help of virtual sticky notes.

•IceScrum is free for one team with an unlimited number of people, but the number of public
projects is limited to just one in the free version.

• The software is a Java web application and requires Java container to run.
 DevOps

•DevOps is the combination of cultural philosophies, practices, and tools that increases an
organization’s ability to deliver applications and services at high velocity: evolving and
improving products at a faster pace than organizations using traditional software development
and infrastructure management processes.

•This speed enables organizations to better serve their customers and compete more effectively in
the market.

• DevOps is a new term emerging from the collision of two major related trends. The first was
also called “agile infrastructure” or “agile operations”; it sprang from applying Agile and Lean
approaches to operations work. The second is a much expanded understanding of the value of
collaboration between development and operations staff throughout all stages of the development
lifecycle when creating and operating a service, and how important operations has become in our
increasingly service-oriented world .

• DevOps is a set of practices that combines software development (Dev) and IT operations (Ops).
It aims to shorten the system development life cycle and provide continuous delivery with
high software quality.

• Agile and DevOps serve complementary roles: several standard DevOps practices such as
automated build and test, continuous integration, and continuous delivery originated in the Agile .

• Agile can be viewed as addressing communication gaps between customers and developers,
while DevOps addresses gaps between developers and IT operations / infrastructure.Also,
DevOps has focus on the deployment of developed software, whether it is developed via Agile or
other methodologies.
PRESCRIPTIVE MODEL AGILE MODEL

• Also known as classical model , It is a set • It is evolved over the period of time.
of predefined steps .
• Focuses on deliverables that fulfils user
• Focuses on every activity equally. requirements.

• Takes more time that may not be realistic. • Takes much less time .

• Software configuration management is • Software configuration management is

difficult. manageable.

• Results are produced with delay. • Quick results are produced.

• If a project being developed using • Even if a project is cancelled midway, it
waterfall model is cancelled mid-way still leaves the customer with some
during development, then there i s worthwhile code, that might possibly have
nothing to show from the abandoned already been put into live operation.
project beyond several documents.
• Progress is measured in terms of the
• Progress is generally measured in developed and delivered functionalities.
terms of the number of completed and
reviewed artifacts such as requirement
specifications, design documents, test
plans, code reviews, etc. for which
review is complete.
Extreme Programming Model (XP)
• This model is based on a rather simple philosophy: ”If something is known to be beneficial, why
not put it to constant use?” Based on this principle, it puts forward several key practices that need
to be practiced to the extreme.

• XP is based on frequent releases (called iteration ), during which the developers implement “user
stories”. User stories are similar to use cases, but are more informal and are simpler. A user story
is the conversational description by the user about a feature of the required.

• For example, a user story about a library software can be:

A library member can issue a book.

A library member can query about the availability of a book.

A library member should be able to return a borrowed book.

 XP Activities :

• Coding

• Testing

• Listening

• Designing

• Feedback

• Simplicity