Non-Agile

MECM15503 Software Project Development

Framework Methodology
Spiral Model
SSADM
OOAD
SSM
RAD
Object oriented
Prototyping

By:

A s s i s t a n t P ro f D r S a re r u s a e n y e
 1. To understand non agile methodology in software
engineering (continue models) Spiral model, SSADM,
Prototype model

Learning 2. Discover ‘hard’ system approach and ‘soft’ system

SSM and RAD
outcomes 3. To understand the themes: System approach and
Planning process
4. To understand the modelling: data and object oriented
Spiral model
Systems development lifecycle (SDLC) method used for risk management that combines
the iterative development process model with elements of the Waterfall model.

The spiral model is used by software engineers and is favored for large, expensive and
complicated projects.

The spiral model looks like a coil with many loops. The number of loops
varies based on each project and is often designated by the project
manager.

Each loop of the spiral is a phase in the software development process.

 Spiral model
The spiral model is similar to the incremental development for a system, with more emphasis placed on risk
analysis.

At the end of the spiral the product is deployed.It repeatedly passes through these phases in iterations (called
Spirals in this model).

The spiral model has four phases:

1.Planning 3. Construct

2. Design 4. Evaluation

Planning: This phase starts with the gathering of business requirements. In the subsequent spirals as the product
matures, identification of system requirements and unit requirements are done in this phase.

This also includes understanding of system requirements by continual communication between the customer and the
analyst.
 Spiral model
Design: Design phase starts with the design in the baseline spiral and involves architectural, logical design of
modules, physical product design and final design in the successive spirals.

Construct: Construct phase refers to development of the final software product at every spiral. In the spiral
when the product is just thought and the design is being developed, a Proof of Concept (POC) is developed in
this phase to get the users’ feedback. Then in the successive spirals with higher clarity on requirements and
design a working model of the software called build is developed with a version number. These versions are
sent to the users for feedback.

Evaluation and Risk Analysis: Risk analysis includes identifying, estimating, and observing technical
feasibility such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, user
evaluates the software and provides the feedback. Based on the customer assessment, development process
enters into the next iteration and afterwards follows the linear approach to implement the feedback provided by
the user. The process of iterations along the spiral carries on with throughout the life of the software.
 •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
When to use •Users are unsure of their needs
Spiral model
•Requirements are complex

•New product line

•Significant changes are expected (research

and exploration)
Real Project Example
•Gantt chart software – GanttPRO a tool for simple task handling.

•Evolution of Microsoft Windows operating system.

•NASA

notes: find more at https://standshttp.blogspot.com/2021/03/example-project-using-spiral-

model.html
 Advantages of Spiral Development Model

• Spiral Model mostly concentrates on risk analysis.

• Most useful for large and risk projects.

• Spiral Model used if requirement changing frequently.

Advantages vs
disadvantgaes Disadvantages of Spiral Development Model

• For risk analysis phase required expert person to make

analysis.

• Not useful for small projects.

• Project duration and cost could be infinite because of

spiral feature.
 SSADM is a waterfall
method for the analysis
and design of information The three most important
systems. SSADM can be techniques that are used in
thought to represent a SSADM are as follows:
pinnacle of the rigorous
document-led approach to
system design, and Logical Data Modelling.
contrasts with more The process of identifying
contemporary agile modelling.
methods such as DSDM or Documenting the data
Structured Systems  Scrum. requirements of the system
being designed.

Analysis The process of

identifying, modelling

and Design Method 
and documenting the
data requirements of
the system being

(SSADM)model designed. The result

is a data model
containing entities
(things about which
a business needs to
record information),
attributes (facts
about the entities)
and relationships
(associations
between the
entities).
Phases of SSADM model
 SSADM techniques
The three most important techniques that are used in SSADM are as follows:
Logical data modeling
The process of identifying, modeling and documenting the data requirements of the system being designed. The result is a
data model containing entities (things about which a business needs to record information), attributes (facts about the
entities) and relationships (associations between the entities).

Data Flow Modeling

The process of identifying, modeling and documenting how data moves around an information system. Data Flow Modeling examines
processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data
into a system or receives data from a system), and data flows (routes by which data can flow).

Entity Event Modeling

A two-stranded process: Entity Behavior Modeling, identifying, modeling and documenting the events that affect each entity
and the sequence (or life history) in which these events occur, and Event Modeling, designing for each event the process to
coordinate entity life histories.
Advantages of SSADM
It has distinct milestones, which allows for easier project management tracking

It is visual since it uses graphical diagrams. This makes the system easier for
users/programmers to understand

It is a mature technique

It allows one to plan, manage and control a project well. These points are essential to
deliver the product on time.

It uses a process-oriented approach which is a natural way of thinking

It provides a means of requirements validation

It is relatively simple

It does not rely on a single technique.

It ignores non-functional requirements

It requires minimal management involvement

It is Non-iterative and requires a lot of user-analyst interaction

It does not provide a communication process with users

It is hard to decide when to stop decomposing

It does not address stakeholders’ needs

It does not suitable for Object-Oriented programming languages

It assumes that the requirements do not change during the development of a project.

It can be time consuming

It may incur delay in system delivery due to the considerable delay in the analysis and design phases which could

lead to dissatisfying the business requirements at the time of delivery.

Disadvantages of SSADM
Hard System approach HSM
There are several hard systems approaches available all of which are based on a refined
version of the problem solving meta-process.

The Hard Systems Methodology (HSM) starts with a problem or opportunity, shown at the
top of figure (next page) as a hexagon.

This is something that exists in the real world and is waiting to be “processed” through the
HSM to arrived at an implemented change.

The idea is that by performing the actions in the boxes successively in a clockwise direction,
the desired end result will “pop out”.
 Hard System approach HSM
Problem definition is about answering the question “what is the problem or opportunity?”

In systems terms we are saying that there exists a system whose output(s) is demonstrating an
unwelcome deviation from an expected performance.

Analysis of situation is about defining the current “as is” state and performance level. It is at
this point the system boundary is defined in order to decide on “what’s in and what’s out”.

Identification of objectives and constraints is about defining where we would like to be and
the constraints that make affect our ability to achieve the new state.

Routes to objectives is about exploring the different ways of achieving the defined objectives.
This itself is a Divergent-Convergent Thinking activity with the divergent phase concerned with
generating as many ideas as possible then to converge on a realistic number of definite
possibilities to take forward.
 Hard System approach HSM
Measures of performance is about defining measurable means of assessing the efficacy of any definite
possibility. It’s really asking and answering the question “how will we know if the change has occurred?”

Develop Options is about developing the definite possibilities to the position where they could be
implemented. This involves doing sufficient work on each option for technical and other details to be defined,
and for costs and benefits to be assessed, while at the same time minimising the time and resources devoted
to the task.

Evaluation of options is about evaluating how well each option will work. The objective of this step is to
determine whether:

• the option will meet the operational objectives

• it is technically feasible

• it is organizationally feasible

• it will meet the financial objectives

Hard System approach HSM
Select Option is about making the choice. This is often not clear-cut and it is not unusual for
there to be iteration back to Routes to objectives to refine choice and even develop hybrids. It
is at this step that any qualitative measures of performance are brought into play.

Implementation is about the detailed design, development and installation tasks required to
get the agreed proposal operating.
 Soft System approach SSM
Soft Systems Methodology (SSM) has long been associated with information system analysis.

Its social construction perspective and management focus distinguish SSM from the software
engineering approach of information system analysis, making it a valuable candidate methodology in
highly unstructured problem settings.

As information systems became more complex, system analysts sought advanced tools to assist
them in the analysis process.

The field of system analysis has seen the emergence and prospering of many structured
methodologies.

Lifecycle/waterfall approach, CASE tools, prototype, RAD/RSD, JAD, and object-oriented

methodology are all part of the continuously expanding list.

SSM provides a mechanism to allow relevant human, social, political, and cultural factors to form
structure and act as explicit entities in the system analysis process.
Soft System approach SSM
This methodology does not seek to define the ‘best’ systems.

Instead, it aims to better meet the diverse needs of various stakeholders by exploring the
problem in a forum that encourages discussion and debate among all the parties.

The basic framework of SSM consists of seven steps that guide the analysis process moving
from the ‘real world’ to the ‘conceptual (systems) world’ and back again, but these stages are
not necessarily followed in a linear fashion. 
Stages 1 and 2: Finding out
These stages create a ‘rich’ picture of the problem situation and
identify the ‘soft’ elements within it:
· People - essentially all those have interest in the system or
who are likely to be affected by changes to it
· Culture - social roles, norms of behavior, values
· Politics - commodities of power and how they are obtained,
used, preserved and transmitted

Stage 3: Developing the root definition

At this stage, the analysis process enters the system world by
developing root definitions. Root definitions are basic descriptions
of the proposed system. 
The development of the root definition is often combined
with CATWOE analysis to answer the following questions:

C   Who are the customers/victims/beneficiaries of the system?

A   Who are the actors/participants in the system?
T    What is transformed by this system: Input --> Transformation --
> Output?
  W   Weltanschauung /worldview:
        What are the underlying assumptions of the system?
O    Who is the owner of the system? Who ultimately control
and pay for the system?
  E     What are the environmental constraints to the system?
Stage 4: Building conceptual models
 
At this stage, the root definition is converted to a conceptual
model defining how the system functions and how it achieves
its objectives.

These models are often stated using active words to describe

what is happening within the system.

It is also desirable to present the model in pictorial or flowchart

form to clarify the interlinked activities.
Stage 5: Comparing models with the real world
 
This stage is designed to provide structure and substance to an
organised debate about improving the current situation.  

At this stage, the analysis process goes back into the real world by
comparing the conceptual model with what happens in the real
world. 
Stage 6: Identifying changes
 
This stage defines the desirable and feasible changes based on the
analysis in prior stages.
In the ideal situation, the changes should cover all aspects of the
system being analyzed and the viewpoints
of all participants.
However, projects in the real world are always subject to schedule
and resource constraints.
As a result, system analysts have to make decisions to prioritize the
various requirements.
 
Stage 7: Taking action
This stage puts into practice the most appropriate changes identified
in the previous stage.
In the case of IS projects, this stage represents the development and
implementation phases.
Rapid Application Development RAD
 Rapid Application Development RAD
Rapid application development follows a continuous iteration process that enables developers
to respond to customer feedback and requests during the development process.

Rapid application development follows a continuous iteration process that enables developers
to respond to customer feedback and requests during the development process.
When it be use?

RAD should be used only when a system can be modularized to be delivered in an incremental

manner. 

It should be used if there is a high availability of designers for Modelling. 

It should be used only if the budget permits use of automated code generating tools.

 Fast Development

Speed is the primary motto of Rapid Application Development. With rapid prototyping and continuous testing, the
software development cycle takes a much shorter time than traditional models.

Cost-Effective

Advantages &
Since the product is built to the customer’s specifications, the chances of certain features being rejected in the end
product are nil. The time and resources invested in the project are not wasted in RAD, making it a cost-effective
model.   

disadvantages Satisfaction

RAD Since the client provides feedback at every step of development, the result is software that meets the client’s
expectations. A happy client leads to happy developers. 

There is also a particular joy that developers get during the development process when the client appreciates their
work. It motivates them to work harder.  

Reduced Risk

Since the requirements in RAD are not set in stone, it becomes easier to mitigate risks even when they appear after the
development has started.
 Requires Skilled Developers

The developers have to foresee the client’s requirements and spend more time understanding the needs to
eliminate too many development iterations. 

Advantages It calls for highly skilled developers with strong modeling skills. The project suffers if the developers are not
up to the mark.     

& Difficult To Implement For Large Teams

disadvantage While it is easier for a small team to collaborate, constant communication can become complicated when the
team is large.  

s Modularization Issues

RAD Rapid Application Development builds only those projects/systems that can be modularized. RAD breaks
down the software into different modules. The team then develops prototypes parallelly, based on the various
modules. Not all software requirements support modularization.

Client Participation

The success of RAD relies on active client participation. The client invests a significant amount of time in
testing the product and providing feedback. While it does guarantee a high-quality product, not all clients
will be willing to participate enthusiastically in the process. 
 System approach and Planning process
Systems can be categorized as physical and abstract systems. Physical system corresponds to
concrete operational systems made up of tangible (i.e. physically available objects) entities such as
people, materials, machines, and other physical things that may be static or dynamic in operation of a
system.

The physical systems display some activity or behavior. Elements of such system interact to achieve a
common objective. For example physical parts of a dairy plant are equipment, employees, office
establishment, furniture, building that facilitate operation of plant. 

Abstract systems are conceptual or non physical entities. These are an orderly arrangement of
interdependent ideas or constructs which may or may not have any counterpart in real world.

They may be as straight forward as formulas of relationships among sets of variables or models of an
abstract conceptualization of physical situations.
System Approach
Model is representation of a real or planned system. For example set of instructions or
procedure for manufacturing milk products (e.g. paneer, cheese, ice-cream etc.) is an
example of abstract system. 

Systems approach is used for problem solving.

This approach takes complex problems and breaks them down into small manageable
problems. It identifies problems from the top-down and then solutions are derived from the
bottom-up.
7 steps of planning
process
1. Brainstorming and planning

2. Requirements and feasibility analysis

3. Design

4. Development & coding

5. Integration and testing

6. Implementation and deployment

7. Operations and maintenance

Important Tasks

The software engineering team has to make sure their code meets the software requirements specifications, conforms to the
stakeholders’ requirements, etc. but if the previous stages of software development were carefully fulfilled, the ready-to-use
software is bound to match the requirements to the software project.
The software development release cycle proceeds from alpha, beta, release candidate to actual production build. Once the
complete architecture (DB, API, etc) and planned functionality of the solution is built, the testing stage starts.

Depending on the complexity of the project it might be a straightforward release (if the project is simple) or staggered released (in
stages) in case of a more complex project. Now system analysts and the end-users can actually see and try out the ready
application.
Object oriented development OOD
A computer system can be developed on a component basis which enables the effective re-use of
existing components and facilitates the sharing of its components by other systems.

This methodology employs international standard Unified Modeling Language (UML) from the
Object Management Group (OMG). UML is a modeling standard for OO analysis and design which
has been widely adopted in the IT industry.

The ultimate objective of OOM is application assembly where the construction of new business
solutions from existing components.

The components are combined in different ways to meet the new requirements specified by the user
community.

Only completely new functionality will have to be built to complete the solution.
Best suits IT project using OOD
Projects of medium to large scale

Departments/project teams with a planned series of developments within a similar business area

Projects with an inventory of suitable components available either in-house or in the market

Projects with development/implementation environment which provide adequate support for object
technology
The details on OOD
 Prototype Methodology
Prototyping is the rapid development and testing of working models (prototypes) of new
applications through an interaction and repetitive process that is commonly used by information
system experts and business experts.

A tool that gives ideas to potential makers and users about how the system functions in its full
form, and the process of producing a prototype called prototyping.

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..
Understand on
Prototyping
methodology
Iterative vs throw away