“SOFTWARE ENGINEERING”

SOFTWARE PROCESS MODELS:

SYED AMAN
BUSHRA KHAN

IT(21-25)

DEPARTMENT OF INFORMATION TECHNOLOGY,

THE ISLAMIA UNIVERSITY OF BAHAWALPUR
LAYERED TECHNOLOGY:
The Institute of Electrical and Electronics Engineers (IEEE) defines software engineering as:
“The application of a systematic, disciplined, quantifiable approach to the development, operation,
and maintenance of software; that is, the application of engineering to software.”

4 LAYERS OF SOFTWARE ENGINEERING:

1. Quality Focus.
2. Process.
3. Methods.
4. Tools

QUALITY FOCUS:
● Every organization rests on its commitment to quality.
● Total quality management, Six Sigma, or similar continuous improvement culture and it is this
culture ultimately leads to development of increasingly more effective approaches to software
engineering.
● The bedrock that supports software engineering is a quality focus.

PROCESS:
● It’s a foundation layer for software engineering.
● Processes define a framework that must be established for effective delivery of software
engineering technology.
● The processes define the tasks to be performed and in which order they are to be performed.

METHODS:
● It provides the technical how-to's for building software.
● Among the tasks covered by methods are requirements analysis, design, program construction,
testing, and support.
● There could be more than one method to perform a task and different techniques could be used in
different situations.

TOOLS:
● Provide automated or semi-automated support for the process, methods and quality control.
● When tools are integrated so that information created by one tool can be used by another, a
system for the support of software development, called computer-aided software engineering
(CASE)
WHAT ARE THE 5 GENERIC FRAMEWORK ACTIVITIES?

COMMUNICATION:
By communication, customer requirement gathering is done. Communication with consumers
and stakeholders to determine the system’s objectives and the software’s requirements.

PLANNING:
Establish an engineering work plan, describe technical risk, list resources requirements, work
produced, & define work schedule.

MODELING:
Modeling consists of complete requirement analysis and the design of the software like
algorithm, flowchart, etc
Help developers and customers to understand requirements (Analysis of requirements) & Design of
software.

CONSTRUCTION:
combines code generation (either manual or automated) and the testing that is required to fix
errors in the code.

DEPLOYMENT:
Once testing is done; deliver the product to the customer & take feedback from them.
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC):
A software life cycle model is a diagrammatic representation of the software life cycle.
A life cycle model represents all the methods required to make a software product.
The SDLC aims to produce high-quality software that meets customer expectations and completes
within time and cost estimates.

A typical Software Development Life Cycle consists of 7 stages −

REQUIREMENT ANALYSIS:
In the Requirement Analysis Phase, understand the exact requirements of the customer,
analyze the product, and identify the risk, & system's functional requirements are to be understood.

SPECIFICATIONS:
Once the requirement analysis is done, a Software Requirement Specification (SRS)
document is made, it contains all the software requirements to be developed during the project life
cycle, & get them accepted from the project stakeholders.

DESIGN:
On the basis that the customer gives us requirements, the system design is prepared. It
includes high-level and detailed design as well as the overall software architecture. All this effort is
documented in a software design document (SDD).

CODING:
In this stage of SDLC, the actual development starts, and the product is built.
The implementation of design begins, writing code in a language. Developers must follow the
coding guidelines defined by their organization. Different high-level programming languages such
as, C++, Java, and PHP are used for coding. Programming languages are selected based on the type
of software being developed.

VERIFICATION & VALIDATION:

After the Coding phase, Testing is done, To ensure that each function works correctly. In the
testing phase, software errors are reported, tracked, fixed, and re-tested, until the product reaches
the quality standards defined in the SRS.

DEPLOYMENT:
When Testing is done, no bugs or errors remain. then it is deployed in a customer
environment.

MAINTENANCE & SUPPORT:

When the client starts using the developed systems, the real issues come up in the client
environment. To fix those issues, patches are released. To enhance the product, some better versions
are released.
WATERFALL MODEL:

The waterfall model, sometimes called the classic life cycle, suggests a systematic sequential
approach to software development that begins with customer specification of requirements and
progresses through planning, modeling, construction, and deployment, providing maintenance &
support of the completed software.

SEQUENTIAL PHASES OF WATERFALL:

The sequential phase in Waterfall Model is:

COMMUNICATION:
The aim of this phase is to understand the exact requirements of the customer, analyze the
product, and identify the risk, & system's functional requirements are to be understood.

PLANNING:
Establish an engineering work plan, describe technical risk, & define work schedule.
Software Requirement Specification (SRS) document is made, it contains all the software requirements
to be developed during the project life cycle, & get them accepted from the project stakeholders.

MODELING:
On the basis that the customer gives us requirements, the system design is prepared. It includes
high-level and detailed design as well as the overall software architecture. All this effort is documented
in a software design document (SDD).

CONSTRUCTION:
Convert the requirement of software gathered from customers that can be coded in a
programming language and features are developed and verified through testing. As each feature is
tested, it is integrated into the system. The modules are tested for their interactions with each other and
with the system. The entire system is tested for errors and failures.

DEPLOYMENT OF SYSTEM:
When Testing is done, no bugs or errors are remaining, functional and non-functional testing is
done; the product is deployed in the customer environment or released into the market.
There are some issues that come up in the client environment. To provide maintenance to
software, patches are released. Also to enhance the product, some better versions are released.
LIMITATIONS OF WATERFALL:

● Not suitable for projects where requirements are changed frequently.

● In Waterfall, a new phase can start only after the completion of the previous phase. However, this
cannot be maintained in real projects. To increase efficiency and reduce cost, phases may overlap.
● Some teams sit idols for other teams to finish.
● The model implies that once the product is finished, everything else is maintenance.
● Therefore, this model is only appropriate when the requirements are well-understood.

ADVANTAGES OF WATERFALL:

● The requirements are simple and completely declared; they remain unchanged during the entire
project development.
● It gives customer control and clarity.
● One Phase is completed at a time.
● Simple and easy to understand and use.
● Release date of the software and final cost can be determined before development.

PROBLEMS WHEN WATERFALL MODEL APPLIED:

● Real projects rarely follow the sequential model. To increase efficiency and reduce cost, phases
may overlap.
● Difficult for the customer to explain all the requirements completely.
● Assuming patience from the customer, a working version of the program will not be available
until the program is not getting developed fully.
● Clients feedback cannot be included in on-going development phase.

WHY WATERFALL MODEL SOMETIMES FAIL?

● Waterfall models fail because once requirements are declared they cannot be changed during
entire project development.
● Error can be fixed only during the phase.
● Once the phase is completed the mistakes are improved in maintenance.
● The risk factor is higher, so this model is not suitable for complex and object-oriented projects
where customer feedback is necessary and requirements are changed frequently.
INCREMENTAL PROCESS MODEL:

Incremental Model is a process of software development where requirements are divided into
multiple standalone modules of the software development cycle. In this model, each module goes
through the requirements, design, testing phases, & implementation.
In every new release of the module, new functionality is added. The process continues until the
complete product is produced.

CHARACTERISTICS:

● The first increment is often a core product that includes basic requirements, and further essential
features are added in the next increments.
● User requirements are prioritized.
● The highest priority requirements are included in early increments.
● Once the core product is analyzed by the client, A plan for the next increment is prepared.
❖ Modifications of the first increment.
❖ Additional features will also be provided in the next increment.

● Early increments act as a prototype to help obtain requirements for later increments.

PHASES:

COMMUNICATION:
Requirements are gathered from the customer and analyze the product and identify the
requirement, & system's functional requirements are to be understood.

PLANNING:
Establish an engineering work plan, describe technical risk, & define work schedule.
Software Requirement Specification (SRS) document is made, it contains all the software requirements
to be developed during the project life cycle, & get them accepted from the project stakeholders.

MODELING:
The requirement specifications from the first phase are re-studied in this phase and the system
design is prepared. It includes high-level and detailed design as well as the overall software architecture.
All this effort is documented in a software design document (SDD).

CONSTRUCTION:
Convert the requirement of software gathered from customers that can be coded in a
programming language and features are developed and verified through testing. As each feature is
tested, it is integrated into the system. The modules are tested for their interactions with each other and
with the system. The entire system is tested for errors and failures.
DEPLOYMENT:
When Testing is done, no bugs or errors are remaining, functional and non-functional testing is
done; the product is deployed in the customer environment or released into the market.
There are some issues that come up in the client environment. To provide maintenance to
software, patches are released. Also to enhance the product, some better versions are released.

WHEN WE USE INCREMENTAL MODEL?

● Requirements of the system are superior & clearly understood.
● When a project has a lengthy development schedule.
● When the customer demands a quick release of the product.
● When high-risk features and goals are involved.

ADVANTAGES OF INCREMENTAL MODEL:

● Errors are easily identified.

● Easier to test and debug.
● The Client gets important functionality early.
● Easier to manage risks.
● Customers can respond to each build.
● Lower risk for overall project failure.

DISADVANTAGES OF INCREMENTAL MODEL:

● Need for good planning.

● Well-defined module interfaces are needed.
● Correcting a problem in one unit requires correction in all the units and consumes a lot of time.
RAPID APPLICATION DEVELOPMENT:

Rapid Application Development model is a linear sequential software development process

based on prototyping without any specific planning. In the RAD model, there is less attention paid to
planning and more priority is given to the development tasks. Its target is to develop software in a short
duration of time.

CHARACTERISTICS:

● It focuses on the input-output source and destination of the information.

● It emphasizes delivering projects in small pieces; the larger projects are divided into a series of
smaller projects.
● It focuses on the reuse of templates, tools, processes, and code.

PHASES:

COMMUNICATION:
Requirements are gathered from the customer to understand the business problem & system's
functional requirements are to be understood.

PLANNING:
Multiple software teams working in parallel on different systems. Establish an engineering work
plan, & define work schedule.

MODELING:
Modeling phase is further divided into 3 parts:
BUSINESS MODELING:
A product is developed based on the flow of information between various channels of business.

DATA MODELING:
Information is refined into a set of data objects that are needed to support business.
PROCESS MODELING:
In the process modeling phase, data objects are transformed into information flows so that
business functions can be implemented.

CONSTRUCTION:
It highlights the use of pre-existing software components. Automated code is used for the
construction of the software, to convert process & data models. The modules are tested for their
interactions with each other and with the system. The entire system is tested for errors and failures.

DEPLOYMENT:
Deliver to customer basis for subsequent iteration.

WHEN TO USE RAD TECHNOLOGY:

● When a system needs to be produced in a short span of time (2-3 months)

● When the requirements are known
● When the customer is involved throughout the software development life cycle
● When the technical risk is less.
● When a budget is high enough to afford designers.
ADVANTAGES OF RAD:

● Changing requirements can be accommodated.

● Productivity with fewer people in a short time.
● Due to prototyping in nature, there is a possibility of lesser defects
● Reduced development time.
● Encourages customer feedback.

DISADVANTAGES OF RAD:
● Dependency on technically highly skilled members for identifying business requirements.
● Suitable for projects that are component-based and scalable, & requiring shorter development
times.
● The system that can be modularized can be built using RAD.
● Requires highly skilled developers/designers.
● Requires customer involvement throughout the software development life cycle.
EVOLUTIONARY PROCESS MODELS:
● Evolutionary models are iterative-type models.
● They allow developers to develop more complete versions of the software.

PROTOTYPING MODEL:
A Prototyping Model is a software development model in which a prototype is developed, tested,
and refined based on customer feedback until an acceptable prototype is achieved, from which the final
product can be developed.

COMMUNICATION:
Prototyping starts with communication between a customer and software engineer to define the
overall objective, identify requirements and make a boundary.

QUICK DESIGN:
A quick design focuses on a representation of those aspects of the software that will be visible to
end users (e.g., human interface layout or output display formats).
It gives a brief idea of the system to the user. The quick design helps in developing the prototype

BUILD A PROTOTYPE:
In this phase, an actual prototype is developed based on the information gathered from quick
design. It is a small working model of the required system.

DELIVERY & FEEDBACK:

The prototype is presented to the client for an initial evaluation. It helps to find out the strengths
and weaknesses of the working model.
If the client is not happy with the current prototype, you need to refine the prototype according to
the user’s feedback and suggestions.
The process of refining the prototype is repeated until all the requirements of users are met.
When the user is satisfied with the developed prototype, a system is developed based on the final
prototype.
IMPLEMENT PRODUCT AND MAINTAIN:
Once the final system is developed based on the final prototype, it goes through testing and is
deployed to production. The system undergoes routine maintenance for minimizing downtime and
preventing large-scale failures.

WHY PROTOTYPES SHOULD BE DISCARDED?

Prototypes should be discarded after development as prototypes are not a good base for a production
system:
● It may be impossible to tune the system to meet non-functional requirements.
● Prototypes are normally undocumented.
● The prototype structure is usually degraded through rapid change.
● The prototype probably will not meet normal organizational quality standards.

THROWAWAY PROTOTYPE:
With 'throw-away' prototyping a small part of the system is developed and then given to the end
user to try out and evaluate.
The client provides feedback which can quickly be added to the development of the main system.
The prototype is then discarded or thrown away.
The throw-away prototype is NOT considered part of the final system. The purpose of it is to understand
and reduce the risk of poorly defined requirements.

PROTOTYPING CAN BE PROBLEMATIC:

● Client cries foul and demands that “a few fixes” be applied to make the prototype a working
product, due to that software quality suffers as a result.
● Developers often make implementations in order to get a prototype working quickly without
considering other factors in mind like OS, Programming language, etc.
SPIRAL MODEL:
Is an evolutionary software process model.
A combination of the iterative development process model and sequential linear development model.
It provides potential for rapid development of increasingly more complete versions of the software.
Using the spiral model, the software is developed in a series of evolutionary releases.
● During the early iterations, the release might be on paper or prototype.
● During later iterations, more and more complete versions of the software are produced.

CHARACTERISTICS:
❖ Each loop in the spiral represents a phase in the process.
❖ No fixed phases such as specification or design - loops in the spiral are chosen depending on
what is required.
❖ Risks are explicitly assessed and resolved throughout the process.
❖ Divided into framework activities(communication, planning, modeling, construction,
deployment). Each activity represents one segment.
❖ The evolutionary process begins in a clockwise direction, beginning at the center of risk.
❖ First circuit around the spiral might result in the development of a product specification.
Subsequently, develop a prototype and then a progressively more sophisticated version of
software.
❖ Unlike other process models that end when software is delivered. It can be adapted to apply
throughout the life of the software.
Spiral Model is divided into 4 phases:

OBJECTIVES DETERMINATION:
Requirements are gathered from the customers and the objectives are identified, and analyzed, the
identification of system requirements.

IDENTIFY & RESOLVE RISK:

The possible solutions are evaluated to select the best possible solution. The risks associated with
the solution are identified and resolved by using the best possible strategy. The Prototype is built for the
best possible solution.

DEVELOPMENT & TEST:

The identified features are developed and verified through testing. When Testing is done, no bugs
or errors remain. then it is deployed in a customer environment.

PLAN THE NEXT ITERATION:

The Customers evaluate the so-far developed version of the software and provide feedback. In the
end, planning for the next phase is started.

SPIRAL MODEL CAN BE PROBLEMATIC IF:

● It may be difficult to convince customers (particularly in contract situations) that the evolutionary
approach is controllable.
● If a major risk is not uncovered and managed, problems will undoubtedly occur.