Unit 2: Software Model

1.0 Introduction
2.0 Intended Learning Outcomes (ILOs)
3.0 Main Contents
3.1 Software Process
3.2 Traditional Waterfall Model
3.3 Iterative Model
3.4 Spiral Model
3.5 Rational Unified Process (RUP)
4.0 Conclusion
5.0 Summary

1.0 INTRODUCTION
An abstraction of the software development process is a software process model. The models
outline the steps and chronological order of a process. The order of the process's activities and
the order in which they are carried out are thus represented by this.

2.0 INTENDED LEARNING OUTCOMES (ILOS)

Students should know what a Software process is and the different software process models
used in building software.

3.0 MAIN CONTENTS

3.1 Software Process
Software process is a set of activities whose goal is the development or evolution of software.
The activities in all software processes include Specification, Development and
implementation, Validation and Evolution. The development team must choose and follow a
life cycle model that is appropriate for the specific project. The creation of a software product
would not be systematic and disciplined without the use of a specific life cycle model. Each
member of the team must have a clear grasp of when and what to do when creating a software
product. Otherwise, anarchy and project failure would result.
Every phase's entry and departure requirements of a Software Process are laid out in a software
life cycle model. Only when the phase-entry requirements have been met can a phase begin.
Therefore, it is impossible to distinguish a phase's entry and departure requirements without a
software life cycle model. Software project managers find it challenging to track the project's
development in the absence of software life cycle models.
Dr. Stephen Akuma Page 1
3.2 Traditional Waterfall Model
In terms of simplicity, developing software using the traditional waterfall paradigm is the best
option. The traditional waterfall model is attractive and intuitively clear, but it cannot be
applied to real software development projects, making it not a practical model. As a result, this
model may be viewed as a theoretical approach to software development. However, the
conventional waterfall model is the main source of guidance for all other life cycle models.
Therefore, knowledge of the traditional waterfall model is required in order to understand other
life cycle models. The phases are presented in the diagram below:

The processes as outlined in the diagram above include:

1. Gathering Requirements: Product requirement documents contain all conceivable
requirements.
2. Review Read the specification and, based on your analysis, define the business rules,
models, and schemas.
3. System Design — Create the software architecture based on the analysis.
4. Application small-scale software development using functional testing.
5. Testing and Integration integrating each unit created in the earlier step and testing the
complete system for bugs after integration.
6. System deployment - Once all functional and nonfunctional testing is finished, the
product is made live in a production environment.
7. Maintenance Whenever necessary, bugs are fixed and new versions with the issue
patches are released.

10 Guidelines for the Traditional Method

a) Use a higher-order programming language.
b) Complete unit testing before integration.
c) Maintain detailed traceability among all artifacts.
d) Freeze requirements before design.

Dr. Stephen Akuma Page 2

 e) Assess quality with an independent team.
f) Inspect everything.
g) Plan everything early and with high fidelity.
h) Rigidly control source code baselines.
i) Document and maintain the design
j) Avoid coding before a detailed design review

Why Traditional Model Fail

a) Late delivery – delay affecting operations
b) Over budget – soaring costs drain resources elsewhere
c) Poor quality – not fully meeting sponsor or user needs
d) Expensive to maintain, difficult to extend

How to Improve the Traditional Model

a) Complete program design before analysis and coding begins.
b) Maintain current and complete documentation.
c) Do the job twice, if possible.
d) Plan, control, and monitor testing.
e) Involve the customer.

3.3 Iterative Model

Iterative waterfall model was developed to address the primary drawbacks of the classical
waterfall paradigm. Therefore, it is possible to think of the iterative waterfall model as adding
essential modifications to the traditional waterfall model to make it applicable to real-world
software development projects. With a few adjustments to boost the effectiveness of software
development, it is nearly identical to the traditional waterfall paradigm.
The primary distinction between the iterative waterfall model and the traditional waterfall
model is the provision of feedback channels from each step to its predecessor phases. The
image below depicts the feedback pathways that the iterative waterfall paradigm introduced.

Dr. Stephen Akuma Page 3

Here, we offer feedback routes for error repair as and when they are found at a later stage. Even
though mistakes are unavoidable, it is preferable to find them as soon as they happen. If so,
fixing the bug might take less work.
This model has the benefit of being a functioning representation of the system at a very early
stage of development, which makes it simpler to identify any functional or design faults.
Finding problems early on allows for the implementation of solutions with a constrained
budget.
This SDLC model's drawback is that it can only be used for large, complex software
development projects. This is due to the difficulty of subdividing a tiny software system into
smaller, more manageable units.

3.4 Spiral Model

One of the most significant models for the Software Development Life Cycle that supports risk
handling is the spiral model. In diagrammatic form, it resembles a spiral with several loops.
The spiral's precise number of loops is unclear and varies from project to project. A phase of
the software development process is referred to as each spiral loop. The project manager can
alter the precise number of phases required to develop the product depending on the project's
risks. The project manager plays a crucial role in the spiral model of product development
because they dynamically determine the number of phases. The phases of the Spiral Model are
shown in the diagram below.

Dr. Stephen Akuma Page 4

First quadrant (Objective Setting)
Identifying the phase's goals is necessary during the first quadrant.
Evaluate the dangers involved with achieving these goals.

Second Quadrant (Risk Assessment and Reduction)

Each identified project risk is given a thorough study.
Risks are minimized by action. A prototype system might be created, for instance, if there is a
chance that the requirements are incorrect.

Third Quadrant (Development and Validation)

After addressing the highlighted risks, create and evaluate the following iteration of the
product.

Fourth Quadrant (Review and Planning)

With the customer, go over the results so far and then design the following iteration around the
spiral.

Dr. Stephen Akuma Page 5

With each spiral-shaped iteration, a version of the software that is progressively more
comprehensive is created.

Advantages of Spiral Model

Some benefits of the spiral model are listed below.
a) Risk management: The Spiral Model is the best development model to use in projects
with numerous unknown hazards that arise as the development process moves along
because it incorporates risk analysis and risk management at each stage.
b) Good for big projects: The Spiral Model is suggested for big, complicated projects.
c) Flexibility in requirements: By employing this paradigm, change requests made in the
requirements at a later stage can be accurately implemented.
d) Customer satisfaction: Customers can observe the product's progress throughout the
early stages of software development, and by utilizing the system before the whole thing
is finished, they become accustomed to it.

Disadvantages of Spiral Model

The spiral model has a few major drawbacks, which are listed below.
a) Complex: Compared to other SDLC models, the Spiral Model is significantly more
complex.
b) Costly: Due to its high cost, the spiral model is inappropriate for minor projects.
c) Too much reliance on risk analysis: Risk analysis is crucial to the project's successful
completion. The development of a project employing this strategy will be a failure
without extremely highly experienced specialists.
d) Time management is challenging because it is difficult to estimate how many phases
there will be at the beginning of the project.

Rational Unified Process (RUP)

The Rational Unified Proces Methodology (RUP) is an agile software development approach
that divides a project's life cycle or the software development process into four phases.
Modelling, analysis, design, implementation, testing, and application are just a few of the
activities that happen during these phases. RUP is agile and iterative, which means repeating.
Iterative because the entire project repeats the process' fundamental steps.
The Rational Unified Process (RUP) has four phases:
Inception phase
Elaboration phase
Construction phase
Transition phase

Dr. Stephen Akuma Page 6

Phase 1: Inception
The project's fundamental concept and structure are decided upon in the first stage. The team
meets frequently throughout this phase to assess the project's requirements as well as its
viability and suitability. The anticipated expenditures and the tools required to finish the project
after approval are additional factors in viability and appropriateness. The outcome of the first
phase could vary depending on the project and include:
An objective statement
The initial use case is 20% complete.
Results of market research
Financial outlook
Risk evaluation
Project schedule
Business or corporate model
Prototypes

Phase 2: Elaboration
The system's requirements and the required architecture are evaluated and analyzed during the
elaboration phase. The project starts to take shape at this point. The elaboration phase's goal is
to analyze the products and lay the groundwork for future architecture. The elaboration phase's
outcomes include:
The use case is 80% finished.
An explanation of the potential architecture
Plan for developing a project
Models for addressing risks
User guide

Phase 3: Construction
The complete software system is built during the construction stage of the Rational Unified
Process (RUP). The system's components and other features are being developed with a focus
on this.
Additionally, the bulk of the coding happens during this stage. In this production process,
managing resources and expenses is just as important as guaranteeing quality. The following
are the outcomes of the production phase:

Dr. Stephen Akuma Page 7

Completed software system
User manual

Phase 4: Transition
Transferring the product to its new user is the aim of the transition phase. Problems that
necessitate system modifications nearly always surface as soon as the user begins using the
system. However, the objective is to provide a favourable and seamless transition for the user.
Results and actions from the previous phase:
Beta testing
Database conversion for current users
Training of new users
The project's launch into marketing and distribution

The figure below shows the phases of RUP and the processes involved.

Dr. Stephen Akuma Page 8

Conclusion
Software process model is a simplified representation of a software process, presented from a
specific perspective. The models include Waterfall. Spiral, Iterative and RUP.

Summary
Software process was defined along with Software process model. The different Models used
for software development were explained. These include Waterfall. Spiral, Iterative and RUP.

Dr. Stephen Akuma Page 9