TRADITIONAL SW DEV’T

There is a variety of traditional systems development methodologies that can be adopted within
the organisation. They include waterfall, Spiral, V-Model, Rational Unified Process (RUP)
and Rapid Application Development.

In this model software testing starts only after the development is complete. In waterfall model
phases do not overlap.

Diagram of Waterfall model

Phases of Waterfall Model in Software Engineering

There are several phases in the waterfall model. They are briefly explained below. Let us
understand the concept of Waterfall model with example of a banking application for
illustrating the topic.
Let us assume that the Citibank is planning to have a new banking application developed and
they have approached your organization in the 1990’s.

SPIRAL MODEL

The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations (called Spirals in this
model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals.

The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations (called Spirals in this
model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is
assessed. Each subsequent spirals builds on the baseline spiral. Its one of the software
development models like Waterfall, Agile, V-Model.

Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’
that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’.

What Is Spiral ModelRisk Analysis: In the risk analysis phase, a process is undertaken to identify
risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. If any
risk is found during the risk analysis then alternate solutions are suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.

Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

High amount of risk analysis hence, avoidance of Risk is enhanced.

Good for large and mission-critical projects.

Strong approval and documentation control.

Additional Functionality can be added at a later date.

Software is produced early in the software life cycle.

Diagram of Spiral model:
Disadvantages of Spiral model:

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Project’s success is highly dependent on the risk analysis phase.

Doesn’t work well for smaller projects.

When to use Spiral model:

When costs and risk evaluation is important

For medium to high-risk projects

Long-term project commitment unwise because of potential changes to economic priorities

Users are unsure of their needs

Requirements are complex

New product line

Significant changes are expected (research and exploration)

V-shaped SDLC Model

V-shaped SDLC model is an expansion of classic waterfall model and it’s based on associated
test stage for the every development stage. This is a very strict model and the next stage is started
only after the previous phase. This is also called “Validation and verification” model. Every
stage has the current process control, to make sure that the conversion to the next stage is
possible.
 ADVANTAGES

Every stage of V-shaped model has strict results so it’s easy to control
Testing and verification take place in the early stages
Good for the small projects, where requirements are static and clear
Disadvantages :
 Lack of the flexibility
 Bad choice for the small projects
 Relatively big risks

Use cases for the V-shaped model:

  For the projects where an accurate product testing is required
 For the small and mid-sized projects, where requirements are strictly predefined
 The engineers of the required qualification, especially testers, are within easy reach.

Unified Traditional Software Development

It is a well-defined model, clearly explaining in a project what things need to be done, when and
who will do. This model works using Unified Modelling Languages (UML), which means that
all the phases, deliverables or outcomes are presented using UML diagrams (i-e: use cases, class
diagrams, etc). It is a huge model that almost supports the development of all types of software
products. This model works on three key features: 1) Incremental/Iterative, 2) Architecture
focused 3) Use Case Determined. It is a component-based design, which creates such software
systems that are easily understandable, supports software reuse and combines with Object-
Oriented programming projects. The key feature of this model is that all the information is
represented graphically. Also, the incremental feature supports the customer feedback,
minimizes the risk and helps the developers. Due to the dynamic nature of technology, new
methodologies keeps on being implemented to improve limitations encountered to its
predecessors. According to Jain and Chandrasekaran [9] in 2000, Kruchten introduced rational
unified process (RUP). It was introduced to consider the need for accommodating change

and adaptability during the system development process [26]. As a result RUP becomes
extremely flexible as it allows change to occur at any time at any stage of systems development.
RUP is made up of four stages namely inception, elaboration, construction and transition [27].
These stages are executed sequentially and iteratively throughout the systems development life
cycle. Every stage of RUP is composed of one or more iterations [28]. Any discrepancies, risks
and errors encountered in each stage are addressed in each iteration of that particular stage. The
final iteration forms part of the final system.

The aim of introducing new methodologies is to fill up the gaps encountered in the previous
methodologies. RUP has been adopted in the systems development industry as a model for the
reason that it is well defined and documented [30]. The documentation is accessible
electronically. RUP is an adaptable model allowing organisations to select elements of processes
that are most relevant to the particular project. RUP make use of unified modelling language
(UML) to emphasise object-oriented analysis and the maintenance model [31]. UML is

an industry-standard language that allows the systems development team to clearly communicate
requirements, architectures and designs visually [12]. Pictures or diagrams enable the entire
systems development team to visualise the inner workings the system to be built. It also makes it
easier for the team to explain the how the system is going to work.

The rational unified process (RUP) is a process framework that provides a disciplined approach
to define activities and responsibilities inside the organised system development [32]. The four
development stages are accompanied by the nine basic principles.
Prototyping model

Prototype Model
All Prototyping model is a process of making software that is repetitive and with rapid planning where
there is feedback that allows the occurrence of repetition and improvement of software until the
software meets the needs of the user.
Prototyping models are one simple model of making software which allows users to have an initial/basic
description of the program and carry out initial testing based on the working model concept.
The purpose of the prototype?
Prototyping models have the goal of developing the initial software model into a final system.
Prototype processes
The prototyping model processes are:
1) First communication is carried out between the customer and the software development team
regarding the specifications of the desired requirements.
2) Planning and modeling will be done quickly in the form of quick design (quick design) and then will
begin construction of the prototype.
3) The prototype will then be submitted to the stakeholders for further evaluation before being
submitted to the software makers.
4) Making software in accordance with the prototype that has been evaluated which will then be
submitted to the customer.
5) If it has not met the needs of the customer, it will return to the initial process until the needs of the
customer have been fulfilled.

The processes in the prototyping model in general are as

follows:
1) Collection of needs Developers and clients will meet first and then determine
general goals, known needs and an overview of the parts that will be needed next.
2) Designing
The design was done quickly and the design represented all known aspects of the
software, and this design became the basis for making prototypes.
3) Evaluation of the prototype
The client will evaluate the prototype made and used to clarify the software
requirements.
2.4 Data Mining Stages
To model a software it takes several stages in the development process. This stage will
determine the success of a software. Software developers must pay attention to the
stages in the prototyping method so that the final software can be accepted by its users.
The stages in the prototying are as
follows:
1) Collection of needs. Customers and developers together define the format and
overall software requirements, identify all needs, and outline the system that will be
created.
2) Building prototyping. Build prototyping by creating a temporary design centered on
presenting to customers (for example by making input and sample output).
3) Evaluation of prototyping. This evaluation is carried out by the customer whether the
prototyping that has been built is in accordance with the wishes of the customer. If it is
appropriate, the fourth step will be taken. If not, then prototyping is corrected by
repeating steps 1,,2 and 3.
4) Encoding the system. In this stage the agreed prototyping is translated into the
appropriate programming language.
5) Test the system. After the system has become a software that is ready to use, it must
be tested before use. This test is carried out with white boxes, black boxes, base paths,
architectural testing and others.
6) Evaluate the system. Customers evaluate whether the finished system is as
expected. If it is, then the seventh step is done, if not then repeat steps 4 and 5.
7) Using the system. Software that has been tested and accepted by customers is ready
to use.

Stages of prototype methodology:

1) Collection of needs and improvements. Establish all requirements for software
development.
2) Fast design. The translation phase of the needs or data that has been analyzed into
a form that is easily understood by the user.
3) Form of prototype. Translating data that has been designed into a programming
language.
4) Customer evaluation of the prototype. Programs that have already been tested by
customers, and if there are deficiencies in the program can be added.
5) Repair of prototypes. Improved program that has been made, according to consumer
needs. Then the program is re-created and evaluated by consumers until all user needs
are met.
6) Engineering products. The finished program and all user needs have been fulfilled.
7) Features that will be implemented on a system prototype can be limited to vertical or
horizontal techniques. Vertical prototypes contain detailed functions but only for a few
selected features, not for all system features. Horizontal prototypes include all user
interface features, but without the main functions, only in the form of simulations and
cannot be used to do actual work (Walker et al, 2003).
8) What is different from this prototype methodology, when compared to waterfall, is the
creation of a prototype of an application, before the application enters the design phase.
In this phase, the prototype that has been designed by the developer will be given
to the user to get evaluated. This stage will continue to be repeated until both parties
really understand the requirements of the application to be developed.
When the prototype is complete, the application stage will continue to the design stage
and return to following the steps in the waterfall model. The disadvantage of this type is
that the application developer development team must have good capabilities because
in developing this prototype there is only a short time. A prototyping is a system in
very minimal functions.

The advantages of prototyping are:

1) There is good communication between the developer and the customer.
2) Developers can work better in determining customer needs.
3) Customers play an active role in system development.
4) Save more time in system development.
5) Application becomes easier because the user knows what is expected.
While the disadvantages of prototyping are:
1) The customer does not see that the software does not reflect the overall quality of the
software and has not considered maintenance for a long time.
2) Developers usually want to quickly complete projects so that they use simple algorithms and
programming languages.
3) Customer relationships with computers may not describe good design techniques.
This development model (Prototyping Model) has several advantages, including:
o There is good communication between developers and customers
o Developers can work better in determining customer needs
o Customers play an active role in developing the system
o Save more time in developing the system
o Application becomes easier because the user knows what is expected
o make the client get the initial picture of the prototype
o Helps get better detailed needs.
 Types of Agile methods in SD process

The agile methodology is one of the easiest and uncomplicated routes to transform an idea and
varied needs into feasible software solutions. Agile method is an iterative and incremental tactic
to software design that utilizes constant planning, understanding, upgrading, team partnership,
development, and delivery. The agile process is fragmented into separate models that teams work
on, thereby encouraging flexibility to changes.

Driven by the principles of providing value and collaborating with stakeholders, the agile
methodology originates with customers defining the end uses of the final product and the kind of
problems the final product attempts to address. This exercise helps in resolving and clarifying the
customer’s anticipations and requirements for the project development team. 

The below agile methodologies list comprises of famous types of agile methodology that one
can opt from:

 1) Kanban.
 2) Scrum.
 3) Extreme Programming (XP)
 4) Crystal.
 5) Dynamic Systems Development Method (DSDM)
 2) Scrum
 One of the most popular agile methodology examples is the agile scrum development
methodology, which is depicted by various cycles of development. Similar to Kanban,
Scrum breaks down the development phases into stages or cycles called ‘sprints’. The
development time for each sprint is maximized and dedicated, thereby managing only
one sprint at a time.
 Scrum and agile methodologies focus on continuous deliverables, and thus this method
lets designers adjust priorities to ensure that any incomplete or overdue sprints get more
attention.
 Scrum Team has exclusive project roles such as a scrum master and a product owner with
constant communications on the daily scrum where the activities are harmonized to
devise the best way to implement the sprint.
 3) Extreme Programming (XP)
 Extreme Programming (XP) is a methodology that emphasizes teamwork,
communication, and feedback. It focuses on constant development and customer
satisfaction. Similar to scrum, this method also uses sprints or short development cycles.
This is developed by a team to create a productive and highly efficient environment. 
 Extreme Programming technique is very supportive in a situation of constant and varying
demands from the customers. It motivates the developers to accept changes in the
customer’s demands, even if they pop-up in an advanced phase of the development
process. 
  In Extreme Programming, the project is tested from the initial stages by collecting
feedback that progresses the output of the system. This also presents a spot check to
implement easily any customer requirements. 
 4) Crystal
 Introduced by Mr. Alistair Cockburn, one of the monumental persons in formulating the
Agile manifesto for software development, Crystal is a group of smaller agile
development methodologies comprising of Crystal Yellow, Crystal Clear, Crystal Red,
Crystal Orange, and more. Each has its peculiar and exclusive framework that is
characterized by factors such as system criticality, team size, and project priorities.
Depending on the nature of the project or system criticality such as Comfort (C),
Essential Money (E), Discretionary Money (D), and Life (L), the kind of crystal agile
methodology is chosen.
 Similar to other methodologies of Agile, Crystal also addresses prompt delivery of
software, regularity, less administration with high involvement of users, and customer
satisfaction. The Crystal family advocates that each system or project is inimitable and
necessitates the solicitation of diverse practices, processes, and policies to achieve the
best results, earning the name of the most lightweight methods of agile methodology.
 5) Dynamic Systems Development Method (DSDM)
 To address the need for a standard industry charter for the swift delivery of software, the
Dynamic Systems Development Method (DSDM) was developed. DSDM gives a
comprehensive structure that is defined and modified to create a plan, execute, manage,
and scale the procedure of software development. Based on a business-driven approach
and eight principles, the DSDM believes that modifications to the project are always
expected, and quality with timely delivery must never be negotiated. 
 Conclusion
 A dynamic approach is required in choosing the right agile methodology among the
different types of agile methodology. The advantages and disadvantages of agile
methodology must always be considered to choose the framework for one’s business to
entice talent and convey remarkable digital experiences in this aggressively competitive
market.

The first limitation of the agile methodology is that it is not suitable for government agencies,
large organizations such as banks, insurance companies, etc. or long-term maintenance of the
systems because these both involve detailed and large documentations that were highly ignored
in this methodology.