COM 125 Introduction to System Analysis and Design Lecture Note 5

System Development Methodology or Models

A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and
deliverables). There are many different systems development methodologies, and each one is
unique, based on the order and focus it places on each SDLC phase. Some methodologies are
formal standards used by government agencies, whereas others have been developed by
consulting firms to sell to clients. Many organizations have internal methodologies that have been
honed over the years, and they explain exactly how each phase of the SDLC is to be performed in
that company.

Ways of categorize methodologies

There are many ways to categorize methodologies, these include:
Process-centered methodology
Data-centered methodologies
Object-oriented methodologies
Process-centered methodology: This emphasizes the process models as the core of the system
concept. For example, process-centered methodologies would focus first on defining the
processes [e.g., assemble sandwich ingredients].

Data-centered methodologies: This emphasizes data models as the core of the system concept. It
focuses first on defining the contents of the storage areas [e.g. refrigerator] and how the contents
would be organized.

Object-oriented methodologies: This attempt to balance the focus between process and data by
incorporating both into one model.

Structured Design
The first category of systems development methodologies is called structured design. These
methodologies became dominant in the 1980s, replacing the previous, ad-hoc, and undisciplined
approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC

Page 1 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

that moves logically from one phase to the next. Numerous process-centered and data-centered
methodologies follow the basic approach of the two structured design categories.

Waterfall Development or Model: The original structured design methodology (still used today) is
waterfall development. With waterfall development–based methodologies, the analysts and users
proceed in sequence from one phase to the next. The key deliverables for each phase is typically
very long (often hundreds of pages in length) and are presented to the project sponsor for
approval as the project moves from phase to phase. Once the sponsor approves the work that was
conducted for a phase, the phase ends and the next one begins. This methodology is referred to as
waterfall development because it moves forward from phase to phase in the same manner as a
waterfall. Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it
is extremely difficult (imagine yourself as a salmon trying to swim upstream against a waterfall, as
shown below.

Fig 1: showing the diagram of Waterfall Model

Advantages of waterfall Approach or Model

It identifies system requirement long before programming begins.
It minimizes changes to the requirements as the project proceeds.

Disadvantages of waterfall Approach or Model

The design must be completely specified before programming begins.
There is a long time elapses between the completion of the system proposal in the analysis
phase and the delivery of the system [usually many months or years].
Page 2 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Parallel Development: Parallel development methodology attempts to address the problem of

long delays between the analysis phase and the delivery of the system. Instead of doing design
and implementation in sequence, it performs a general design for the whole system and then
divides the project into a series of distinct subprojects that can be designed and implemented in
parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and
the system is delivered.

Advantage of Parallel Development Methodology

It reduces the schedule time to deliver a system; thus, there is less chance of changes in
the business environment causing rework.

Disadvantage of Parallel Development Methodology

It suffers from problems caused by paper documents.

It also adds a new problem: Sometimes the subprojects are not completely independent;
design decisions made in one subproject may affect another, and the end of the project
may require significant integration efforts.

Fig 2: showing the diagram of Parallel Development Methodology

Page 3 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Iterative and Incremental Development Model

Iterative and Incremental Development Model
Iterative and Incremental development is the heart of a cyclic software development process
developed in response to the weaknesses of the waterfall model. It starts with an initial planning
and ends with deployment of cyclic interactions in between. Iterative and incremental
development is essential parts of the:
Rational Unified Process
Extreme Programming and
Generally the various active software development frameworks

Fig 3: showing the diagram of an iterative development model

Incremental Development Model

Incremental development shares the system functionality into increments (portions). In each
increment, a slice of functionality is delivered through cross-discipline work, from the
requirements to the deployment. The unified process groups increments/iterations into phases
which are:
Inception
Elaboration
Construction
Page 4 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Transition
Inception: identifies project scope, risks, and requirements (functional and non-functional) at a
high level but in enough detail that work can be estimated.
Elaboration: This delivers a working architecture that mitigates the top risks and fulfills the non-
functional requirements.
Construction: This incrementally fills-in the architecture with production-ready code produced
from analysis, design, implementation, and testing of the functional requirements.
Transition: This delivers the system into the production operating environment

Fig 4: showing the diagram of Iterative/Incremental Development

Extreme Programming
Extreme Programming [XP] is a software development methodology which is intended to improve
software quality and responsiveness to changing customer requirements. As a type of active
software development, it advocates frequent "releases" in short development cycles (time
boxing), which is intended to improve productivity and introduce checkpoints where new
customer requirements can be adopted.
Page 5 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Rules for Extreme Programming:

Planning
Managing
Coding
Designing
Testing

Goals of Extreme Programming Model

Extreme Programming is a software development discipline that organizes people to produce
higher quality software more productively. In traditional system development methods (such as
SSADM or the waterfall model) the requirements for the system are determined at the beginning
of the development project and often fixed from that point on. This means that the cost of
changing the requirements at a later stage (a common feature of software engineering projects)
will be high. Like other agile software development methods, XP attempts to reduce the cost of
change by having multiple short development cycles, rather than one long one. In this doctrine
changes are a natural, unavoidable and desirable aspect of software development projects, and
should be planned for instead of attempting to define a stable set of requirements.

RAD MODEL
This is Rapid Application development model. Rapid Application Development [RAD] refers to a
type of software development methodology that uses minimal planning in favour of rapid
prototyping. The planning of software developed using RAD is enclosed with writing the software
itself. The lack of extensive pre-planning generally allows software to be written much faster, and
makes it easier to change requirements. Rapid Application Development is a software
development methodology that involves techniques like iterative development and software
prototyping. According to Whitten (2004), it is a merger of various structured techniques,
especially data-driven Information Engineering, with prototyping techniques to accelerate
software systems development.

Page 6 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Practical Application of RAD Model

When organizations adopt rapid development methodologies, care must be taken to avoid role
and responsibility confusion and communication breakdown within the development team, and
between the team and the client. In addition, especially in cases where the client is absent or not
able to participate with authority in the development process, the system analyst should be
endowed with this authority on behalf of the client to ensure appropriate prioritization of non-
functional requirements. Furthermore, no increment of the system should be developed without a
thorough and formally documented design phase.

Advantages of the RAD methodology

Flexible and adaptable to changes.
Prototyping applications give users a tangible description from which to judge whether
critical system requirements are being met by the system. Report output can be compared
with existing reports. Data entry forms can be reviewed for completeness of all fields,
navigation, data access (drop down lists, checkboxes, radio buttons, etc.).
RAD generally incorporates short development cycles – users see the RAD product quickly.
RAD involves user participation thereby increasing chances of early user community
acceptance.
RAD realizes an overall reduction in project risk.
Pareto's 80 - 20 Rule usually results in reducing the costs to create a custom system

Disadvantages of RAD methodology

Unknown cost of product. This problem can be alleviated by the customer agreeing to a
limited amount of rework in the RAD process.
It may be difficult for many important users to commit the time required for success of the
RAD process.

Phased Development
A phased development–based methodology breaks an overall system into a series of versions,
which are developed sequentially. The analysis phase identifies the overall system concept, and

Page 7 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

the project team, users, and system sponsor then categorize the requirements into a series of
versions. The most important and fundamental requirements are bundled into the first version of
the system. The analysis phase then leads into design and implementation but only with the set of
requirements identified for version 1. Once version 1 is implemented, work begins on version 2.
Additional analysis is per- formed based on the previously identified requirements and combined
with new ideas and issues that arose from the users’ experience with version 1. Version 2 then is
designed and implemented, and work immediately begins on the next version. This process
continues until the system is complete or is no longer in use.

Fig 5: showing the diagram of Phased Development–based Methodology

Prototyping
A prototyping-based methodology performs the analysis, design, and implementation phases
concurrently, and all the three phases are performed repeatedly in a cycle until the system is
completed. With these methodologies, the basics of analysis and design are performed, and work
immediately begins on a system prototype, a quick-and-dirty program that provides a minimal
amount of features. The first prototype is usually the first part of the system that is used. This is
shown to the users and the project sponsor, who provide comments. These comments are used to
reanalyze, redesign, and re-implement a second prototype, which provides a few more features.
This process continues in a cycle until the analysts, users, and sponsor agree that the prototype
Page 8 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

provides enough functionality to be installed and used in the organization. After the prototype
[now called the system] is installed, refinement occurs until it is accepted as the new system.

Fig 6: showing the diagram of Prototyping

Unified Process Model

The Unified Software Development Process or Unified Process is a popular iterative and
incremental software development process framework. The best-known and extensively
documented refinement of the Unified Process is the Rational Unified Process (RUP).

Fig 7: showing the diagram of Profile of a typical project showing the relative sizes of the four phases of the Unified Process

The Unified Process is not simply a process, but rather an extensible framework which should be
customized for specific organizations or projects. The Rational Unified Process is, similarly, a
customizable framework. As a result it is often impossible to say whether a refinement of the
process was derived from UP or from RUP, and so the names tend to be used interchangeably.
Page 9 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Characteristics of Unified Process Model

The Unified Process is an iterative and incremental development process. The Elaboration,
Construction and Transition phases are divided into a series of time boxed iterations. (The
Inception phase may also be divided into iterations for a large project.) Each iteration results in an
increment, which is a release of the system that contains added or improved functionality
compared with the previous release. Although most iterations will include work in most of the
process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and
emphasis will change over the course of the project.

Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define
the contents of the iterations. Each iteration takes a set of use cases or scenarios from
requirements all the way through implementation, test and deployment.

Architecture Centric
The Unified Process insists that architecture sit at the heart of the project team's efforts to shape
the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process
supports multiple architectural models and views. One of the most important deliverables of the
process is the executable architecture baseline which is created during the Elaboration phase. This
partial implementation of the system serves to validate the architecture and act as a foundation
for remaining development.

Risk Focused
The Unified Process requires the project team to focus on addressing the most critical risks early in
the project life cycle. The deliverables of each iteration especially in the Elaboration phase, must
be selected in order to ensure that the greatest risks are addressed first.
The Unified Process divides the project into four phases:
Inception
Elaboration
Construction

Page 10 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Transition

Inception Phase: Inception is the smallest phase in the project, and ideally it should be quite
short. If the Inception Phase is long then it may be an indication of excessive up-front
specification, which is contrary to the spirit of the Unified Process.
The following are typical goals for the Inception phase.
Establish a justification or business case for the project
Establish the project scope and boundary conditions
Outline the use cases and key requirements that will drive the design tradeoffs
Outline one or more candidate architectures
Identify risks
Prepare a preliminary project schedule and cost estimate
The Lifecycle Objective Milestone marks the end of the Inception phase.

Elaboration Phase: During the Elaboration phase the project team is expected to capture a
healthy majority of the system requirements. However, the primary goals of Elaboration are to
address known risk factors and to establish and validate the system architecture. Common
processes undertaken in this phase include:
The creation of use case diagrams
Conceptual diagrams (class diagrams with only basic notation) and
Package diagrams (architectural diagrams).
The architecture is validated primarily through the implementation of an Executable Architecture
Baseline. This is a partial implementation of the system which includes the core, most
architecturally significant, components. It is built in a series of small, Time boxed iterations. By the
end of the Elaboration phase the system architecture must have stabilized and the executable
architecture baseline must demonstrate that the architecture will support the key system
functionality and exhibit the right behaviour in terms of performance, scalability and cost.
The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the
Construction phase. At this point the plan should be accurate and credible; since it should be

Page 11 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

based on the Elaboration phase experience and since significant risk factors should have been
addressed during the Elaboration phase.
The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase: Construction is the largest phase in the project. In this phase the remainder
of the system is built on the foundation laid in Elaboration. System features are implemented in a
series of short, time boxed iterations. Each iteration results in an executable release of the
software. It is customary to write full text use cases during the construction phase and each one
becomes the start of a new iteration. Common UML (Unified Modeling Language) diagrams used
during this phase include:
Activity
Sequence
Collaboration
State (Transition) and
Interaction Overview diagrams.
The Initial Operational Capability Milestone marks the end of the Construction phase.

Transition Phase: The final project phase is Transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may result in further
refinements to be incorporated over the course of several Transition phase iterations. The
Transition phase also includes system conversions and user training.

The Spiral Model

The Spiral Model is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the Linear Sequential Model. A Spiral
Model, combines the iterative nature of prototyping with the controlled and systematic aspects of
the Waterfall Model, therein providing the potential for rapid development of incremental
versions of the software. A Spiral Model is divided into a number of framework activities, also
called task regions. These task regions could vary from 3-6 in number and they are:

Page 12 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Customer Communication: This task requires to establish effective communication between the
developer and customer.

Planning: This task requires defining resources, timelines and other project related
information/items.

Risk Analysis - tasks required to assess the technical and management risks.

Engineering - tasks required to build one or more representation of the application.

Construction & Release - tasks required to construct, test and support (eg. Documentation and
training)

Customer evaluation - tasks required to obtain periodic customer feedback so that there are no
last minute surprises.

Advantages of the Spiral Model

Realistic approach to the development because the software evolves as the process
progresses. In addition, the developer and the client better understand and react to risks
at each evolutionary level.

The model uses prototyping as a risk reduction mechanism and allows for the
development of prototypes at any stage of the evolutionary development.
It maintains a systematic stepwise approach, like the classic waterfall model, and also
incorporates into it an iterative framework that more reflect the real world.

Disadvantages of the Spiral Model

One should possess considerable risk-assessment expertise
It has not been employed as much proven models (e.g. the Waterfall Model) and hence
may prove difficult to ‘sell’ to the client.

Page 13 of 14
COM 125 Introduction to System Analysis and Design Lecture Note 5

Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering.
The concurrent process model can be represented schematically as a series of major technical
activities, tasks, and their associated states. For example, the engineering activity defined for the
spiral model is accomplished by invoking the following tasks: prototyping and/or analysis
modeling, requirements specification, and design. The activity-analysis-may be in any one of the
states noted at any given time. Similarly, other activities (e.g., design or customer communication)
can be represented in an analogous manner. All activities exist concurrently but reside in different
states.

Assignment
1. Define the term System Development Methodology.
2. Highlights the advantages and disadvantages of the Spiral Model.
3. What are the task regions in Spiral Model?
4. What is extreme programming and its rules?
5. With the aid of diagram only explain iterative development model.

Page 14 of 14