Unit 2

Process Models
Software Crisis:

➢ Problems associated with software development that causes impact on software

functionalities results in poor quality software are termed as software crisis.

➢ It may be due to complexity of software, use of same strategy, same workforce, same
tools and methods for all kind of projects even though demand is rapidly increasing.

➢ Poor project management, lack of proper training, lack of skilled team members can also
be the reasons for software crisis.

➢ To address these issues, a generic strategy is developed for software development called
Process Models or Software Engineering Paradigm or Software Development Lifecycle.
Software development as problem solving loop:

➢ Software development is characterized as a problem solving loop in which four distinct

stages are encountered: status quo, problem definition, technical development, and
solution integration. Diagram given below shows the phases of problem solving loop:

➢ Status quo represents the current state of affairs/projects.

➢ Problem definition identifies the specific problem to be solved.
➢ In technical development phase, identified problem is solved through the application of
proper technology.
➢ Solution integration phase delivers the results (e.g., documents, programs, data, new
business function, new product) to those who requested the solution.
➢ Software Development Lifecycle (SDLC) is the process used by software development
industry for designing, developing and testing software products.
➢ The objective of SDLC is to develop high quality software products that meet the
requirements of customers within a stipulated time period.
➢ It is an abstraction of software processes. It represents orders in which software
development activities are undertaken.
 ➢ The type of process model to be used is chosen based on the nature and application of
the project, the methods and tools to be used and deliverables required.
Personal Software Process Model:

➢ Personal Software Process (PSP) Model is related to the individual person working on a
project.
➢ PSP is the structure that assists the engineers in finding a way to measure and improve
the way of their working.
➢ It helps them in developing their respective skills at a personal level and the way of doing
planning, estimations against the plans.
➢ PSP focuses on identifying errors early and rectifying them at early stages only.
➢ Personal Software Process model shows engineer how to:
i. Manage quality of project.
ii. Make commitments that can be fulfilled.
iii. Improve estimating and planning.
iv. Reduce errors/defects in product.
➢ PSP framework includes following activities:
1. Planning: Develops project cost, size and resource estimates. The possible risks in
development are identified. All measurement metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is created.
2. High level design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built if necessary, and
errors are recorded.
3. High level design review: Formal verification methods are applied to uncover errors
in the design. Unidentified errors can be discovered.
4. Development: The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics (measurement standards) are
maintained for all important tasks and work results.
5. Postmortem: Using the results of previous stages, the effectiveness of the process is
determined. If needed, processes can be modified to improve effectiveness.
Team Software Process Model:

➢ Team software process model focuses on improving team productivity. It is designed for
groups of persons.
➢ The goal of TSP is to build a self-directed and self-motivated project team that organizes
itself to produce high quality software.
➢ Objectives of TSP:
i. Build self-directed teams that plan and track their work, establish goals and
create their own processes and plans.
ii. Shows manager how to coach and motivate team members.
iii. To accelerate the software development process.
➢ TSP framework includes following activities:
1. Launch: Review project objectives, assign roles to team members, and describe
customer’s need statements.
2. High level design: Develop modules integration plan.
3. Implementation: Writing code for modules and functions.
 4. Integration and testing: Integrate different modules together and perform testing to
ensure that product is functioning as per customer’s requirements.
5. Postmortem: Peer and team review is conducted and reports are generated.
➢ Difference between activities of PSP and TSP is, TSP has more scripts, forms and standards
that serve to guide team members in their work.
A script defines specific process activities and other related activities.

Waterfall Model:

➢ The classical waterfall model is the basic software development life cycle model
introduced by Winston Royce in 1970.
➢ It is also called a linear sequential model as it represents a sequential flow of software
development process activities.
➢ The classical waterfall model divides the life cycle into a set of predefined phases.
➢ One phase can be started after the completion of the previous phase. That is the output
of one phase will be the input to the next phase.
➢ The phases do not overlap with each other.
➢ It is not commonly in use nowadays but is very important as other software development
life cycle models are based on it.
➢ Following are the phases of waterfall model:

1. Requirement analysis and specifications:

➢ Understand the exact requirements of the customer and document them properly.
➢ Customers and software developers work together to document functions,performance
and interfacing requirements of software.
➢ The document containing a detailed description of system and software requirements is
called Software Requirement specification(SRS).
➢ This SRS document serves as a contract between software developer and customer.
➢ Any future dispute between software developer and customer can be settled by
examining SRS documents.

2. Design:
 ➢ Design process translates software requirements into representation of software that is
to be coded in a programming language.
➢ It is a multistep process that focuses on four distinct attributes of a program: data
structure, software architecture, interface representation and procedural
details(algorithms).
➢ All this work is documented as a software design document(SDD).
➢ SDD becomes a part of software configuration.

3. Code generation and unit testing:

➢ Design is translated into source code using suitable programming language.
➢ Individual module is tested to check whether it is working properly.
➢ Unit testing determines the efficiency of an individual module.
➢ If design is performed in a detailed manner, code generation can be done smoothly and
efficiently because all the information needed for development is contained in the SDD.

4. Integration and system testing:

➢ Different modules are integrated together.
➢ After successful integration of all modules, the full working system is obtained and the
entire product is tested again to ensure proper functioning.
➢ It consists of 3 different kinds of testing:
I. Alpha testing: Performed by developer team.
II. Beta testing: Performed by friendly/familiar set of customers.
III. Acceptance testing: Performed by customer after deployment/delivery of software
product.

5. Support/Maintenance:
➢ It is the most important phase of SDLC.
➢ Once software is delivered to customers, it may undergo changes.
➢ Changes may occur due to some operational errors, change in external environment(OS
or peripheral devices etc.) or customer needs some functional or performance
enhancements.
➢ Software development team must provide maintenance support in order to fulfil the
customer's changing functional needs.
➢ There are 3 basic types of maintenance:
I. Corrective maintenance:Correct errors.
II. Perfective maintenance: Enhance the functionality of system.
III. Adaptive maintenance : Make changes in software to make it functional in new
environment.

Advantages of Waterfall model:

1. This model is very simple, easy to understand and implement.
2. Each phase in the model is clearly defined.
3. Each process and results are well documented.
4. Requirements are documented before starting development, they remain unchanged
during entire product development.
5. Phases in this model are processed one at a time.

Disadvantages of Waterfall model:

1. It is not always possible for the customer to state all the requirements at once before the
start of development.
 2. The model can not accept changes during development.
3. It is not suitable for large size and complex projects.
4. Phases are not overlapping which can not be maintained in real projects. To increase
efficiency and to reduce cost, phases need to be overlapped.
5. Many times it leads to blocking states as some team members must wait for other
members to complete the dependent tasks.

When to use waterfall model:

➢ When the requirements are constant and not changing regularly.
➢ Project is small in size.
➢ Tools and technology used are consistent and are not changing.
➢ All the required resources are well prepared and are available to use.

V Model:
➢ V model is also called as verification and validation model.
➢ It is an extension to waterfall model.
➢ V model defines co-relation between development and testing/quality assurance
activities.
➢ Development and testing/review activities are conducted simultaneously.
➢ In the Verification phase static analysis(review) of work products is done without
executing code.
➢ Verification phase evaluates product development process.
➢ Validation is a dynamic analysis phase in which testing is done by executing code.
➢ Validation phase tests the software to know whether it meets all the requirements.
➢ Both verification and validation phases are connected through the coding phase. Diagram
below shows V model architecture.

➢ Verification phase includes following steps/activities:

1. Requirement gathering and Analysis: This phase contains detailed communication with
the customer to understand their requirements and expectations.
 ➢ Review of gathered requirements are taken to confirm whether all the requirements are
covered, whether requirements are understandable, whether practically possible to
implement etc.

2. System Design: This phase determines the complete hardware and communication setup
for a product.

3. Architectural Design: System design is broken down further into modules taking up
different functionalities. The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly understood.

4. Module Design: The detailed design of modules is specified, also known as Low-Level
Design (LLD).

➢ Validation/testing phase includes following steps/activities:

1. Unit Testing: Unit Test Plans are developed during module design phase. Each module is
tested independently to rectify errors if any.

2. Integration testing: In integration testing, the modules are integrated and their
communication is tested. Integration testing is performed on the Architecture design
phase. This test verifies the communication of modules among themselves.

3. System Testing: System testing test the complete system with its functionality.
Integration of hardware and software is done and interactions between them are tested.
It ensures that all user requirements are met.

4. User Acceptance Testing: Acceptance testing is performed in a user environment. It

verifies that the delivered system meets user’s requirement and system is ready for use
in real world.

Advantages of V model:

1. This model is very simple, easy to understand.

2. Enhance the probability of error-free and good quality product development.
3. Software development progress can be tracked accurately.
4. The V-Model strongly emphasises on testing, which helps to ensure the quality and
reliability of the software.
5. The V-Model provides a clear link between the requirements and the final product,
making it easier to trace and manage changes to the software.

Disadvantages of V model:

1. It is not much good for complex projects.

2. This model does not support iteration of phases.
3. The V-Model can be time-consuming, as it requires a lot of documentation and testing.

When to use V model:

1. Where requirements are clearly defined and fixed.

2. Mainly used for small to medium sized projects.
3. Sufficient technical resources are available.
Principles of V model:

1. Large to small: In V model, requirements are identified by the project team, High-Level
Design is created first and then Detailed Design(low level) is created. It goes on working
from large to small components of project.

2. Scalability: The V-Model concept has the flexibility to accommodate any IT project
irrespective of its size, complexity or duration.

3. Data/Process Integrity: The successful design of any project requires the incorporation
and linkage of both data and processes. Data must be accurate and consistent. There
should be no ambiguity and incompleteness in processes.

4. Cross Referencing: There is direct correlation between requirements(verification phase)

and corresponding testing activity(validation phase).

5. Tangible Documentation: Every project needs to create a document. Documentation

serves as a guideline for customer as well as software development team about the use
of product.