Chapter 2

Software development processes

Objectives

The focus of this chapter is software development life cycle and different methodologies that
could be adopted in software development. To achieve this, you are to read this chapter to
understand the following:

✓ software development life cycle

✓ software development methodologies
✓ agile methodology and principles

Software development process defines the processes from which a software product evolves, and it
is categorised into software development life cycle (SDLC) and software methodologies. The SDLC is
generic, i.e., it is not attached or dependent on any method or methodology. Thus, it is compatible to
every chosen methodology, and always considered before deciding on the methodology to be
adopted for the development process. Software engineers use a schematic diagram to present the
phases of the SDLC, which is the foundation of the software development process. On the other hand,
methodology is the framework that must be adopted to develop software product with an acceptable
level of quality. Over the years, research efforts have yielded different types of methodologies aimed
at developing software product with the best acceptable level of quality. Thus, in this section, SDLC
and software development methodologies are explained.

2.0 Software processes

Software process defines the different stages of software application development. In software
engineering organisations, the focus of the process is to develop a software product with an
acceptable level of quality, delivered in time, and meets or exceeds user expectations. This process is
called Software Development Life Cycle (SDLC) and supported with the ISO/IEC/IEEE 12207 standard.
The standardization of SDLC documentation is provided by the Institute of Electrical and Electronic
Engineering (IEEE). According to the IEEE standard, SDLC is a composite of 7 phases, which must be
independently executed to complete the software development life circle. In Figure 2.1, there are six
phases of SDLC that include feasibility study, analysis, design, coding, testing, and delivery and
maintenance.

1
[email protected]
 Figure 2.1: Software Development Life Cycle

1. Feasibility Study: This phase involves the study of the environment where the software
product would be used to understand the business goals and clients’ requirements. At this
phase, the input document is the business requirement provided by the client. The Business
Analyst considers all the user’s requirements under different categories of feasibility studies.
These categories are represented with the acronym STOLE:
i. Schedule feasibility clearly states the delivery of the software that would fulfil clients’
requirements within a stipulated timeline. Irrespective of the software development
methodology adopted in the development process, the development company must
work within the deadline to deliver just-in-time delivery.
ii. Technical feasibility considers the human resources, hardware, software, and
requisite skills requirement. These are the dependent variables that would provide
the platform for the software provide when delivered.
iii. Operational feasibility identifies specific user requirements that the client expects the
software to provide. It is noted that all the functional requirements are included in
the operational feasibility.
iv. Legal feasibility provides the legal framework for the usage of software product. It
considers the data protection, the cyber laws within the environment the software is
to be used, licensing and copyright issues.
v. Economic feasibility looks at the cost of completing the SLDC. The cost of the human
resources, hardware, software, and the software product.

The product of feasibility studies is the Business Design Document (BDD), which is the input in
the next phase of the cycle.

2. Analysis: The System Analyst accepts the BDD and converts it to a technical requirement
document. This document is called System Requirement Specification (SRS). The SRS is a
crucial document that details the business and technical requirements. The SRS document is
the input product of the design phase.

2
[email protected]
 3. Design: Software architects are entrusted with the design phase. This phase is divided into
two key phases: the high-level design (HLD) group headed by a project manager (PM) and the
low-level design group (LLD) headed by a project leader (PL). In the HLD, modules are
development while LLD focuses on the development of sub-modules and child modules. The
product of this phase is the project development document (PDD) or the technical
development document (TDD).
4. Coding: In line with the PDD, the dedicated software development team adopts a specific
programming language (C++, Python, Java, etc.) to write the software source code. Coding at
this level involves the white box testing, for example, unit testing. Developed modules are
integrated to form a unified program known at this level as “build”. It is the product of this
phase.
5. Testing: This phase is divided into six phases and every test undertaken is called a black box
testing. Each phase is targeted at a segment of the user requirement for verification and
validation. The software testing life cycle (STLC) is an integral part of SDLC, but it focused only
on black box testing. Figure 2.2 presents the six phases of STLC.

Figure 2.2: Software testing life cycle

i. Requirement analysis: The test team requests for Requirement document for any
clarification on the SRS and identify functional requirements to be tested.
Stakeholders might be invited to validate the users’ requirements and expected
outputs.
ii. Test planning: The dedicated team members would produce a testing document that
outlines the testing strategy, required tools, roles assigned to members, a structured
testing step. Similarly, the timeline for testing, risk, and cost analysis are defined
within the document.
iii. Test case design: In the design or development case phase, test cases are created to
test the inputs, procedures, execution, and expected outputs. To ensure transparency
in the testing process, testing team could invite the stakeholders during the exercise.
The test cases are developed based on the user’s requirement.
iv. Test environment setup: The testing environment or platform where the software
product will be tested is installed, configured, and deployed. Testing tools, such as

3
[email protected]
 selenium, TestComplete, and Katalon studio, are installed in the test server. To verify
that the created environment and all the functionalities are working properly smoke
tests are done at the end of the deployment.
v. Test execution: Modules and features are tested using the created cases. The results
are compared with the expected result, documented, and sent to the development
team for validation and comment. Through the documentation, every detected bug is
reported to the development for troubleshooting.
vi. Test closure: Once the testing is completed, the final document containing the test
results and all reports is prepared.
User acceptance testing: in this phase, the focus is the customer, and it comprises of two
phases called Alpha and Beta testing.

Alpha testing. The customer is invited to the organisation and series of test are performed in
the customer’s presence. Feedback is requested from the customer and corrections, if any,
are referred to the development team for prompt action. On completion of Alpha, it is
documented as part of the acceptance test report.

Beta testing. This is the second phase of user acceptance test, and it is performed outside of
the software development company. The software product is handed over to the customer
for testing in their organisation. At the customer’s organisation, testing could be performed
as follows: in-house testing using their in-house experts; outsourcing to a third-party tester.
These are done without the involvement of the software development company. The
customer records their feedback and submits to the software development company. Positive
report initiates the delivery and maintenance phase.

6. Delivery and maintenance: On the closeup of the delivery, maintenance agreement is

discussed based on customers’ requirements. The agreement includes free maintenance, paid
maintenance, sharing the maintenance fee into two equal parts, or as stipulated by both
parties within the rules and standards in the documentation.

2.2 Software development methodology. The software development methodology is a compound of

methods used in the development phase. It implies that methodology is a group of methods, while
method is a subset of methodology. Methodology details the step-by-step processes in software
development and popular methodologies applied over the years include waterfall, spiral, incremental,
and agile models.

2.2.1 Waterfall model

Waterfall model is part of the prescriptive model. Others include Incremental model, and RAD model.
Prescriptive model is a guideline that defines distinct steps in the development process and how the
development process should follow in a linear form.

Waterfall methodology is a linear sequential structured model introduced in 1970 by Winston Royce.
The period it was first applied suggests that it is the oldest methodology used in software
development. The sequence of events show that the output of the first phase is the input of the second
and so forth. It implies that the first phase must be completed before the second phase would start.
4
[email protected]
However, the development team must come up with a mechanism to evaluate and certify the output
and input of each phase, end ensures that it falls within the requirements. The sequence of activities
in waterfall development includes requirement analysis, system design, implementation, testing,
deployment, and maintenance. These stages are presented in Figure 2.3. A successful implementation
of each phase is expected to translate to a software product that fulfils the user requirements.

Figure 2.3: The waterfall development model

1. Requirement analysis
The Project manager, and Business analysts meet the products owners or sponsors, users,
and other stakeholders to gather all the requirements. The intention is to define the scope
of the software and know exactly what the software should do. The entire discussion
translates to a requirement document, which is the input of the second phase.
2. System design: The architects study the requirement specification document and produces
the system design. The design would contain the hardware and software requirements,
physical and logical design, and the overall system design. The product in this stage is the
design diagram.
3. Implementation: The coding team accepts design document and translate it into a working
program using one of the adopted programming languages. The program is developed in
batches called units and subsequently subjected to unit testing to ensure that it conforms
to the design document relating to functionality.
4. Integration and Testing: All the developed units are integrated and tested as a whole
software product. The functional and non-functional requirements are tested. If there is any
error, deviation from the user’s requirement, it is referred to the development team at the
implementation level.
5. Deployment: Once the testing and verification is complete and approved, the software
product is deployed to the owner. It is the actual release of the product to the information
technology environment at the users’ end.
6. Maintenance: Deployment phase ushers in the maintenance phase. Patches are frequently
provided as a solution to issues of malfunction of the product. Future user requirements
could be required to meet business challenges. Maintenance, therefore, becomes a
continuous process.
5
[email protected]
 Advantages Disadvantages

1. It provides total departmentalization 1. It is difficult to accommodate

of the process and total control by changes in user’s requirements
the team. 2. The model is a document driven
2. It provides a structured and rigid process which requires lots of
system that is strictly followed. resources.
3. Each preceding phase is the input of 3. Testing is undertaken towards the
the next phase. tail end of the process. Any detected
4. Requirements are clearly defined error at this stage would wreak
and suitable for smaller projects. havoc to the entire program.
5. All events within the process are 4. Not suitable for complex systems
properly documented. where there are frequent changes in
6. The entire steps are easy to follow requirements.
with less interference from the 5. The entire process is full of risk and
project owners. uncertainty because of excessive
documentation and late testing

2.2.2 Incremental model

Incremental model is a software development process that enforces strict clarity of requirements
before commencement. That is, it only applied where the requirements are well understood before
the development process. The process maintains a linear flow approach. The process is divided into
independent modules that are developed independently. Each released module adds a function to the
previous increment, and it continues in this form until a deliverable product is achieved. There are
four developmental stages each module must undergo to be delivered as a finished product. These
are communication, planning and requirement, modelling, construction, and deployment. In Figure
2.4, there are three independent increments that follows the same process. In the first increment, the
development team initiates the process by communicating with the owner and completes the first
process. While the first team is working in the requirement and planning stage, the second team
initiates the second module by communicating with the owner. It goes on with every increment until
the complete modules are developed and integrated. When can we apply incremental model?

Figure 2.4: Incremental model

6
[email protected]
Communication

At this stage, the development team is communicating with the owner of the project and elucidating
the goal and the environment where the application would be used. This communication would form
the foundation for the next stage.

Requirement and planning

The development team uses the input from the communication stage to initiate the planning,
develop the requirements, and sign service level agreements.

Modelling

Modelling includes the design of the software architecture, the implementation of the SDLC and the
adoption of the development methodology. Each increment is subjected to the modelling phase

Construction

The increment again is subjected to the coding phase - in this case called construction using an agreed
programming language. The constructed codes are integrated and tested. Testing includes testing the
performance of the existing function and the additional functionality.

Deployment

The deployment or implementation phase uses developed and tested modules that is integrated and
shipped to the owner.

Advantages Disadvantages
1. The process requires good
1. During the SLDC, the final product is planning
generated quickly 2. Troubleshooting a bug in one
2. Changes in user requirements are easily increment leads to changes in the
accommodated preceding increment
3. It is cost effective 3. The level of independency of each
4. The development process is flexible module constitutes rigidity of the
5. Risks are easily managed process
6. Errors are easily detected and corrected 4. Total costs distributed per
increment is high

2.2.3 Agile methodology

In this section, the basic understandings of Agile and Agile methodology are presented.
Literally, Agile means to move swiftly or quick with ease. In software development, the
application of agile, i.e., to move swiftly or quick with ease is termed Agile methodology or
model.

7
[email protected]
 Principles of agile methodology are deigned to improve the software process and enhance the
software quality. The manifesto or principles include:

✓ Individuals and interactions over processes and tools.

✓ Working software over comprehensive documentation.
✓ Customer collaboration over contract negotiation.
✓ Responding to change over following a plan.

Agile methodology breaks down the process of development into smaller iterations and each
iteration is termed a module, component, increment or an iteration. The team plans the
development process and prioritises each iteration by performing short term planning. The
plan defines how many iterations would complete the project, the duration of each iteration
or module, and the scope of each iteration. The first module or iteration is completed and
tested before starting module 2.

Figure 2.5 (a): Agile development methodology

Figure 2.5 (b): Agile development methodology

Figure 2.5a and b, represents two modules: module 1 and module 2. In module 1, the team starts in
the order of requirement, design, development, testing and deployment. Each iteration takes a
minimum of two weeks and a maximum of four weeks. There is an early feedback from the customer
because completed iteration is sent to client for a feedback before starting the next iteration. Through
this mechanism, there is reduced risk and overall project time to delivery. At the completion of all
the iterations, the modules are integrated and tested.

Agile methodology comprises of the following phases:

Requirement

Communication with the project owner or the customer will lead to detailed elucidation to determine
the viability of the project. The role of the Business Analyst (BA) is central to this determination. The

8
[email protected]
user requirements, duration of the development – time to delivery, efforts and cost are discussed at
this level.

Design
Adopt a design tool such as data flow diagram (DFD) or unified modelling language (UML) translate
the concept of the requirements and system components into an understandable diagram. The figure
should depict the interactions between different components that make up the system.

Development
The developers aim to develop a working product by using a programming language. Each developed
module is tested and sent to the owner for a feedback. Specific functionalities as captured in the user
requirement document are developed in each module.

Testing
The testing team adopts a testing technique that would ensure that an acceptable level of quality is
built into product. Bugs are tracked and referred to the development team for correction, and each
line of code is properly commented.

Deployment
In line with the series of feedbacks received from the customer at each level, the final product that is
suited for the customer’s environment is deployed and implemented. Frome here, the software
maintenance is initiated depending on the agreement the developing company and the owner.

2.3.4 Types of methods in Agile methodology

Lean

Lean originated from the Toyota Production System (TPS) and adapted by software engineering. It
focuses on minimizing waste, optimizing time to delivery and resources. Lean development amplifies
learning and empowers the development team.

Scrum

Scrum team: Scrum focuses on the management of a team-based project. There is full involvement of
the project owner from the start to the finish. Key participants in a Scrum process are the Scrum Team,
Scrum Master, and the Product Owner. The development of an iteration is centred on a sprint. A sprint
is “a short, time-boxed period when a scrum team works to complete a set amount of work.”

The Scrum Team: The team is made of a minimum of 3 members and a maximum of 7. Depending on
the project size, it could grow to 9 members.

The Scrum Master: This is the project manager who organises the entire process development, sets
up the sprint to address backlog of activities and ensures that the duration of the development and
delivery are not exceeded.

The Product Owner: The product owner represents the customer and ensures that all requirements
are built-in in the software, prioritises activities, provides funds where necessary, accountable for the
success or failure of the product, provides sustained direction and maximises the value of the product.

Kanban

9
[email protected]
Kanban is an agile software development method used for the management of the development
process and product delivery. Its key advantages include transparency, elimination of bottlenecks,
transparency, continuous delivery, faster feedback from the customer, and accommodation changes
in user requirements. Kanban uses “sign boards” in the form of cards and columns to visually represent
backlog activities and completed tasks. Kanban is a Japanese word that means “Signboard” and it is
popular in Toyota manufacturing system.

Crystal

It is a lightweight agile method that focuses on people over processes. The team comprises of 20-50
people. The process empowers the team to seek for solution based on the size and complexity of the
project rather than sticking with a rigid stereotype. The three core values of Crystal method include
technology change techniques, cultures change norms, and distances change communication. Crystal
is designed for a short-term project.

Feature driven development (FDD)

FDD is a feature development method that is client-centric, architecture-centric, and pragmatic. In

FDD, client referrers to all stakeholders. The focus is on developing features that are added to the
increments. For example, the login module could be a feature within an iteration. It is designed to
follow five steps: develop a model for the project development, build a list of features, plan the
feature, design the feature, and build the feature.

Xtreme programming (XP)

It is an agile development method that focuses on improving the development process, increased
customer satisfaction, and enhanced software quality. The motivation for the development of XP is to
mitigate the vague and changing requirements witnessed in client’s project. XP incorporates five core
values: communication between team members and customer; courage to speak up when wrong
applications a been made; devising the simplest way of reducing waste and finding solution; each team
member must respect each other; and quick feedback from the customer. XP is a lightweight, easy to
apply, efficient, predictable, scientific, and low-risk method.

Dynamic software development (DSDM)

Dynamic software development method derives its approach from Rapid Application Development
(RAD). It is one of the earliest methods of agile methodology. The key elements in DSDM are customers
satisfaction, team members ability to take decisions that positively affect the final product, and
continuous delivery.

2.2.4 Spiral model

It is an incremental risk-oriented life cycle model that consists of four phases, namely,
determining objective, identify and resolve risk, development, and test, and plan the next
iteration. A software project would undergo through these phases before the final product
evolves. This approach combines the concept of iterative software development and the
methodical linear driven waterfall model. Each incremental release is refined during the next

10
[email protected]
iteration around the spiral. Spiral model was developed by Barry Boehm in 1988. As the name
suggests, the activities are represented in the form of a spiral that has many cycles. The
process involves continuous reviewing and releasing of the new software. Spiral model is
recommended for complex systems with high level of risks, long term project with critical
timeline, project that requires new technology, and involves research. Figure 4 presents the
four sections of the spiral model that must be completed to have a software product. The first
or the innermost spiral is the concept development, second is the system development, the
third spiral is the system enhancement while the fourth or outer spiral is the system
maintenance.

Figure 4: Spiral model

1. Determine objectives: Discussion with stakeholders focus on the project planning,
requirements gathering, and enhancement of the project objectives, identifying the
functionalities, cost, and performance measurement. Each of these is analysed to determine
best option that will help in realising the user requirements.
2. Identify and resolve risks: All potential processes are evaluated to identify risk associated with
each of them. The solution with the least risk is chosen and resolved. The risk analysis includes
the technical feasibility, project management and scheduling. Towards the end of this phase,
or the third dimension, proof of concept or the prototype is developed and shown to the
owner before the next iteration.
3. Development and test: The development is initiated with writing the codes and integration of
the modules. Then the software is tested and prepared for deployment at the owner’s
environment.
4. Plan the next iteration: The software product is evaluated and the plan for the next phase is
initiated.

11
[email protected]
 Strengths Weaknesses
1. Software emerges at a very early stage 1. The entire life cycle very is
of the life cycle complex.
2. Suitable for large and high-risk 2. Requires expert inputs throughout
projects the process.
3. Provides flexible requirements and 3. It is expensive to manage
new functionalities 4. Sometimes, it is difficult to define
4. Clients are involved at early stage of objectives and demonstrable
the life cycle. milestones
5. It allows the introduction of protypes 5. Not suitable for smaller and less
at every stage. complex projects

12
[email protected]