Software Processes

The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program and how
they are to be used.

A software process is the set of activities and associated outcome that produce a
software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities are:

1. Software specifications: The functionality of the software and constraints on its

operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it does what
the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.

The Software Process Model

A software process model is a specified definition of a software process, which is
presented from a particular perspective. Models, by their nature, are a simplification, so
a software process model is an abstraction of the actual process, which is being
described. Process models may contain activities, which are part of the software process,
software product, and the roles of people involved in software engineering. Some
examples of the types of software process models that may be produced are:

1. A workflow model: This shows the series of activities in the process along with
their inputs, outputs and dependencies. The activities in this model perform
human actions.
2. 2. A dataflow or activity model: This represents the process as a set of
activities, each of which carries out some data transformations. It shows how the
input to the process, such as a specification is converted to an output such as a
design. The activities here may be at a lower level than activities in a workflow
model. They may perform transformations carried out by people or by
computers.
 3. 3. A role/action model: This means the roles of the people involved in the
software process and the activities for which they are responsible.

There are several various general models or paradigms of software development:

1. The waterfall approach: This takes the above activities and produces them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on. After each stage is defined, it is "signed off"
and development goes onto the following stage.
2. Evolutionary development: This method interleaves the activities of
specification, development, and validation. An initial system is rapidly developed
from a very abstract specification.
3. Formal transformation: This method is based on producing a formal
mathematical system specification and transforming this specification, using
mathematical methods to a program. These transformations are 'correctness
preserving.' This means that you can be sure that the developed programs meet
its specification.
4. System assembly from reusable components: This method assumes the parts
of the system already exist. The system development process target on
integrating these parts rather than developing them from scratch.

Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the
consumer product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products
defects after putting into use due to ineffective testing technique. For example,
Software testing typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop and
the money involved. For example, Development of the FAA's Advanced
Automation System cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the
software takes longer than the estimated time to develop, which in turn leads to
 cost shooting up. For example, one in four large-scale development projects is
never completed.

Program vs. Software

Software is more than programs. Any program is a subset of software, and it
becomes software only if documentation & operating procedures manuals are
prepared.

There are three components of the software as shown in fig:

1. Program: Program is a combination of source code & object code.

2. Documentation: Documentation consists of different types of manuals. Examples

of documentation manuals are: Data Flow Diagram, Flow Charts, ER diagrams, etc.
4. Operating Procedures: Operating Procedures consist of instructions to set up
and use the software system and instructions on how react to the system failure.
Example of operating system procedures manuals is: installation guide,
Beginner's guide, reference guide, system administration guide, etc.
Software Development Life Cycle
(SDLC)
A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures
the structure in which these methods are to be undertaken.

In other words, a life cycle model maps the various activities performed on a software
product from its inception to retirement. Different life cycle models may plan the
necessary development activities to phases in different ways. Thus, no element which life
cycle model is followed, the essential activities are contained in all life cycle models
though the action may be carried out in distinct orders in different life cycle models.
During any life cycle stage, more than one activity may also be carried out.

Need of SDLC
The development team must determine a suitable life cycle model for a particular plan
and then observe to it.
Without using an exact life cycle model, the development of a software product would
not be in a systematic and disciplined manner. When a team is developing a software
product, there must be a clear understanding among team representative about when
and what to do. Otherwise, it would point to chaos and project failure. This problem can
be defined by using an example. Suppose a software development issue is divided into
various parts and the parts are assigned to the team members. From then on, suppose
the team representative is allowed the freedom to develop the roles assigned to them in
whatever way they like. It is possible that one representative might start writing the code
for his part, another might choose to prepare the test documents first, and some other
engineer might begin with the design phase of the roles assigned to him. This would be
one of the perfect methods for project failure.

A software life cycle model describes entry and exit criteria for each phase. A phase can
begin only if its stage-entry criteria have been fulfilled. So without a software life cycle
model, the entry and exit criteria for a stage cannot be recognized. Without software life
cycle models, it becomes tough for software project managers to monitor the progress
of the project.

SDLC Cycle
SDLC Cycle represents the process of developing software. SDLC framework includes the
following steps:
The stages of SDLC are as follows:
Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

The senior members of the team perform it with inputs from all the stakeholders and
domain experts or SMEs in the industry.

Planning for the quality assurance requirements and identifications of the risks
associated with the projects is also done at this stage.

Business analyst and Project organizer set up a meeting with the client to gather all the
data like what the customer wants to build, who will be the end user, what is the
objective of the product. Before creating a product, a core understanding or knowledge
of the product is very necessary.
For Example, A client wants to have an application which concerns money transactions.
In this method, the requirement has to be precise like what kind of operations will be
done, how it will be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility
of the growth of a product. In case of any ambiguity, a signal is set up for further
discussion.

Once the requirement is understood, the SRS (Software Requirement Specification)

document is created. The developers should thoroughly follow this document and also
should be reviewed by the customer for future reference.

Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project
stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document

which contains all the product requirements to be constructed and developed during
the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and
design of the software project. This phase is the product of the last two, like inputs from
the customer and requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow
the coding guidelines described by their management and programming tools like
compilers, interpreters, debuggers, etc. are used to develop and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that the
products are solving the needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are
done.
Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up
and requirements to be solved from time to time.

This procedure where the care is taken for the developed product is known as
maintenance.

waterfall model
What is the waterfall model?
The waterfall model is a linear, sequential approach to the software
development lifecycle (SDLC) that is popular in software engineering and
product development.

The waterfall model uses a logical progression of SDLC steps for a project,
similar to the direction water flows over the edge of a cliff. It sets distinct
endpoints or goals for each phase of development. Those endpoints or goals
can't be revisited after their completion.

Dr. Winston W. Royce at the Lockheed Software Technology Center

introduced the concept in a paper published in 1970 on his experience
developing software for satellites. However, Royce didn't use the
term waterfall; instead, he referred to the downstream value of documentation.

The waterfall model continues to be used in industrial design applications. It's

often cited as the first software development methodology. The model is also
used more generally as a high-level project management methodology for
complicated, multifaceted projects.

https://youtu.be/bNLcRdrSQAU

Who uses the waterfall model?

Project teams and project managers use the waterfall model to achieve goals
based on the needs of their business. The model is used in many different
project management contexts, such as in construction, manufacturing, IT and
software development.

In the waterfall method, each step is dependent on the output of the previous
step. There's a linear progression to the way these projects unfold.

waterfall model doesn't include a project's end user or client as much as other
development methodologies. Users are consulted during the initial stages of gathering
and defining requirements, incorporating client feedback after that. By leaving the
client out of the main part of the waterfall process, the development team moves
quickly through the phases of a project.

This methodology is good for teams and projects that want to develop a project
according to fixed or unchanging requirements set forth at the beginning of the
project. Waterfall projects have a high degree of process definition with little or no
output variability. Waterfall is also a good choice if the project is constrained by cost
or time.

Projects based on the waterfall model are well defined, predictable and have specific
documentation. They also have the following characteristics:

 fixed requirements;

 ample resources;

 an established timeline;
  well-understood technology; and

 unlikely to require significant changes.

In software development, if an application needs to work on the first try at the risk of
losing customers, waterfall is a suitable method because it sets out to achieve that
goal. Contrast that with Agile project management and development methodology.
Agile methods use ongoing reiteration, which is an iterative approach that involves
designing, developing and testing software in repeated cycles that build upon each
other.

Phases of the waterfall model

When used for a software development process, the waterfall methodology has seven
stages:

Feasibility Study
The feasibility study is based on the needs of the project, where many people (human
resource, business analyst, architecture) evaluate whether the project can be done or
not. To develop a good project, we should follow the various characteristics, which are
based on the customer requirements:

Aspects Description

Legal Can the company handle the project as cyber law and other monitoring
agreements?

Technical Check whether the available machine supports the software or not?

Operation The company should able to generate operation that is given by the clients?
feasibility

Economic Should the company able to complete the product within given budget or
not?

Schedule The project should be done within the given schedule or not.
1. Requirements. Potential requirements, deadlines and guidelines for the
project are analyzed and placed into a formal requirements document, also
called a functional specification. This stage of development defines and
plans the project without mentioning specific processes.

2. Analysis. The system specifications are analyzed to generate product

models and business logic to guide production. This is also when financial
and technical resources are audited for feasibility.

3. Design. A design specification document is created to outline technical

design requirements, such as the programming language, hardware, data
sources, architecture and services.

4. Coding and implementation. The source code is developed using the

models, logic and requirement specifications designated in the prior phases.
Typically, the system is coded in smaller components, or units, before being
put together.

5. Testing. This is when quality assurance, unit, system and beta tests identify
issues that must be resolved. This may cause a forced repeat of the coding
stage for debugging. If the system passes integration and testing, the
waterfall continues forward.

6. Operation and deployment. The product or application is deemed fully

functional and is deployed to a live environment.

7. Maintenance. Corrective, adaptive and perfective maintenance is carried

out indefinitely to improve, update and enhance the product and its
functionality. This could include releasing patch updates and new versions.
What are the feasibility criteria for a ‘Library System’?
 High performance and scalability to handle large amounts of data
 Data security and protection to ensure the privacy and confidentiality of library
patrons and their information
 Compatibility with various operating systems and devices
 A server running Windows Server/Linux OS
 A multi-threading capable backend language like Java
 Front-end frameworks like Angular/React/Vue for the client
 Relational DBMS like MySQL, PostgreSQL, etc
 Containers and orchestration services like Kubernetes (for a large setting like a
national library)
 The overall objective of the organization is covered and contributed by the system or
not
 The implementation of the system can be done using current technology or not
 Can the system be integrated with the other system which are already exist

Advantages of the waterfall model

Today, Agile methodology is often used in place of the waterfall model. However,
there are advantages to the waterfall approach, such as the following:

 enables large or changing teams to move toward a common goal that's been
defined in the requirements stage;

 forces structured, disciplined organization;

 simplifies understanding, following and arranging tasks;

 facilitates departmentalization and managerial control based on the schedule

or deadlines;

 reinforces good coding habits to define before implementing design and

then code;
  enables early system design and specification changes to be easily done;
and

 clearly defines milestones and deadlines.

Disadvantages of the waterfall model

Disadvantages of the waterfall model typically center around the risk
associated with a lack of revision and flexibility. Specific issues include the
following:

 Design isn't adaptive; when a flaw is found, the entire process often
needs to start over.

 Method doesn't incorporate midprocess user or client feedback, and

makes changes based on results.

 Waterfall model delays testing until the end of the development

lifecycle.

 It doesn't consider error correction.

 The methodology doesn't handle requests for

changes, scope adjustments and updates well.

 Waterfall doesn't let processes overlap for simultaneous work on

different phases, reducing overall efficiency.

 No working product is available until the later stages of the project

lifecycle.

 Waterfall isn't ideal for complex, high-risk ongoing projects.

Waterfall Model - javatpoint

When to use Iterative Waterfall Model
 The requirement of the defined and clearly understood.
 New technology is being learned by the development team.
 There are some high risk features and goals which might in the future.

Application of Iterative Waterfall Model

 Major requirements are defined but the minor details might involve when time
goes.
 New technologies are being used and there is a learning curve for the
programmers to learn.
 Resource are limited to do a huge project as if a small project automates are in
contact rather than permanent.
 Very high risk as a goal of the project might change from time to time.

Advantages of Iterative Waterfall Model

 Feedback Path: iterative waterfall allows the mechanism of error connection
because there is a feedback path from one phase to its preceding phase which it
lacks in the Waterfall Model.
 Simple: iterative waterfall model is simple to understand and use. It is the most
widely used software development model evolved so far.
 Parallel development: can be done.


Disadvantage of Iterative Waterfall Model

 More resource: may be required to implement the iterative waterfall model.
 Difficult to include change requests: In the iterative waterfall model, all the
requirements must be clearly defined before starting of the development phase
but sometimes customer requirement changes which is difficult to incorporate
change requests that are made after development phase starts.
 Not support Intermediate delivery: Project has to be fully completed before it
delivered to the customer.
 Risk handling: Project is prone to many types of risk but there is no risk
handling mechanism.
 Not suitable for a small project.