MOSHI CO-OPERATIVE UNIVERSITY (MoCU)

FACULTY : FBIS

PROGRAME : BSc.BICT

COURSE NAME : SOFTWARE QUALITY ASSURANCE

COURSE INSTRUCTOR : Mr G. Sizya

TASK : GROUP ASSGNMENT

SUBMISSION DATE : 3 JULY 2020

COURSE ANTE : CIT 307

QUESTION :

1. Discuss about structured-based model in software

development.

GROUP NAMES:

NO. NAMES: REG NO:

0.1 EMMANUEL N. MASINDIKE MoCU/BSC.BICT/151/17
0.2 TYRANNUS N. MASINDIKE MoCU/BSC.BICT/108/17
0.3 MAJID M. HAJI MoCU/BSC.BICT/155/17
0.4 YONA L. MAKWAIA MoCU/BSC.BICT/105/17
0.5 SHUHULI MASHAURI MoCU/BSC.BICT/180/17
0.6 RODRICK S. SWAI MoCU/BSC.BICT/144/17
INTRODUCTION

Structured Model
Aims to provide a formal mathematical framework and computer-based environment conceiving,
representing, and manipulating a wide variety of models.

Software development process

Is the process of dividing software development work into distinct phases to improve design,
product management, and project management? It is also known as a software development life
cycle (SDLC). The methodology may include the pre-definition of specific deliverables and
artifacts that are created and completed by a project team to develop or maintain an application.

Software development life cycle (SDLC) models

It shows the ways to navigate through the complex and demanding process of software building.
A project’s quality, timeframes, budget, and ability to meet the stakeholders’ expectations
largely depend on the chosen model.

All SDLC models can be structured into several groups depending on how they approach
workflow organization – linearly or iteratively – and what kind of relationships is established
between the development team and the customer.

Most software development

 Waterfall model
 V model
 Incremental model
 RAD model
 Iterative model
 Spiral model

Types of SDLC models and what projects each supports best

Waterfall
Through all development stages (analysis, design, coding, testing, deployment), the process
moves in a cascade mode. Each stage has concrete deliverables and is strictly documented. The
next stage cannot start before the previous one is fully completed. Thus, for example, software
requirements cannot be re-evaluated further in development. There is also no ability to see and
try software until the last development stage is finished, which results in high project risks and
unpredictable project results. Testing is often rushed, and errors are costly to fix.

Phases of Waterfall Model

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.

Requirements Gathering and Analysis

In this phase the requirements are gathered by the business analyst and they are analyzed by the
team.
Going through the requirements and analyzing them has revealed that the project team needs
answers to the following questions which were not covered in the requirements document –

i. Will the new banking application be used in more than one country?
ii. Do we have to support multiple languages?
iii. How many users are expected to use the application? etc

System Design

The architect and senior members of the team work on the software architecture, high level and
low level design for the project.

It is decided that the banking application needs to have redundant backup and failover
capabilities such that system is accessible at all times.

Implementation

The development team works on coding the project.

They take the design documents / artifacts and ensure that their solution follows the design
finalized by the architect.

Testing

The testing team tests the complete application and identifies any defects in the application.

These defects are fixed by the developers and the testing team tests the fixes to ensure that the
defect is fixed.

Deployment

The team builds and installs the application on the servers which were procured for the banking
application.

Maintenance

During the maintenance phase, the team ensures that the application is running smoothly on the
servers without any downtime.
Issues that are reported after going live are fixed by the team and tested by the testing team.

Examples of Waterfall Model

In the olden days, Waterfall model was used to develop enterprise applications like Customer
Relationship Management (CRM) systems, Human Resource Management Systems (HRMS),
Supply Chain Management Systems, Inventory Management Systems, Point of Sales (POS) \

Advantages of waterfall model

i. This model is simple and easy to understand and use.

ii. It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
iii. In this model phases are processed and completed one at a time. Phases do not overlap.
iv. Waterfall model works well for smaller projects where requirements are clearly defined
and very well understood.

Disadvantages of waterfall model

i. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
ii. No working software is produced until late during the life cycle.
iii. High amounts of risk and uncertainty.
iv. Not a good model for complex and object-oriented projects.
v. Poor model for long and ongoing projects.
vi. Not suitable for the projects where requirements are at a moderate to high risk of
changing.

When to use the waterfall model

i. This model is used only when the requirements are very well known, clear and fixed.
ii. Product definition is stable.
iii. Technology is understood.
iv. There are no ambiguous requirements
v. Ample resources with required expertise are available freely
vi. The project is short.

Weaknesses of waterfall model are:

i. It is Inflexible.
ii. Accommodating changes is very hard.
iii. Longest tangible delivery time. The customer does not see anything but the whole
product when it's ready.
iv. Unsuitable for large projects and where requirements are not clear.
v. There is no working software produced until the last the late life cycle.
vi. Amounts of risk and uncertainty are high.
vii. It can be considered as a poor model for the long and ongoing projects.

V-MODEL (Validation and Verification model)

The V-model is a type of SDLC model where process executes in a sequential manner in V-
shape. It is also known as Verification and Validation model. It is based on the association of a
testing phase for each corresponding development stage. Development of each step directly
associated with the testing phase. The next phase starts only after completion of the previous
phase i.e. for each development activity, there is a testing activity corresponding to it.

Verification: It involves static analysis technique (review) done without executing code. It is the
process of evaluation of the product development phase to find whether specified requirements
meet.

Validation: It involves dynamic analysis technique (functional, non-functional), testing done by

executing code. Validation is the process to evaluate the software after the completion of the
development phase to determine whether software meets the customer expectations and
requirements.
So V-Model contains Verification phases on one side of the Validation phases on the other side.
Verification and Validation phases are joined by coding phase in V-shape. Thus it is called V-
Model.

Design Phase:

1. Requirement Analysis: This phase contains detailed communication with the customer to
understand their requirements and expectations. This stage is known as Requirement
Gathering.
2. System Design: This phase contains the system design and the complete hardware and
communication setup for developing product.
3. Architectural Design: System design is broken down further into modules taking up
different functionalities. The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly understood.
4. Module Design: In this phase the system breaks dowm into small modules. The detailed
design of modules is specified, also known as Low-Level Design (LLD).

Testing Phases:

1. Unit Testing: Unit Test Plans are developed during module design phase. These Unit Test
Plans are executed to eliminate bugs at code or unit level.
2. Integration testing: After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested. Integration testing
is performed on the Architecture design phase. This test verifies the communication of
modules among themselves.
3. System Testing: System testing test the complete application with its functionality, inter
dependency, and communication. It tests the functional and non-functional requirements
of the developed application.
4. User Acceptance Testing (UAT): UAT is performed in a user environment that resembles
the production environment. UAT verifies that the delivered system meets user’s
requirement and system is ready for use in real world.
Principles of V-Model:

1. Large to Small: In V-Model, testing is done in a hierarchical perspective, For example,

requirements identified by the project team, create High-Level Design, and Detailed
Design phases of the project. As each of these phases is completed the requirements, they
are defining become more and more refined and detailed.
2. Data/Process Integrity: This principle states that the successful design of any project
requires the incorporation and cohesion of both data and processes. Process elements
must be identified at each and every requirement.
3. Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity or duration.
4. Cross Referencing: Direct correlation between requirements and corresponding testing
activity is known as cross-referencing.
5. Tangible Documentation: This principle states that every project needs to create a
document. This documentation is required and applied by both the project development
team and the support team..

Advantages:

i. This is a highly disciplined model and Phases are completed one at a time.
ii. V-Model is used for small projects where project requirements are clear.
iii. Simple and easy to understand and use.
iv. This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.
v. It enables project management to track progress accurately.

Disadvantages:

i. High risk and uncertainty.

ii. It is not a good for complex and object-oriented projects.
iii. It is not suitable for projects where requirements are not clear and contains high risk of
changing.
iv. This model does not support iteration of phases.
v. It does not easily handle concurrent events.
Strengths of V-Shaped model:

i. Simple and easy to use model.

ii. Every phase has clear and fixed deliverables.
iii. Higher chances of success as test planning starts early in the SDLC cycle.
iv. Quickest for project where requirements are fixed and clearly defined.
v. Testing activities such as the planning and designing are done well in advance which
helps in saving a lot of time.
vi. Some of the defects are found at an early stage.
vii. Downward flow of defects is avoided.

Weaknesses of V-Shaped model:

i. It is inflexible.
ii. Changes in requirements are very hard to accommodate
iii. No early prototypes are available
iv. Needs ample skilled resources.
INCREMENTAL MODEL:

Advantages of Incremental model:

i. Generates working software quickly and early during the software life cycle.
ii. This model is more flexible – less costly to change scope and requirements.
iii. It is easier to test and debug during a smaller iteration.
iv. In this model customer can respond to each built.
v. Lowers initial delivery cost.
vi. Easier to manage risk because risky pieces are identified and handled during it’d
iteration.

Disadvantages of Incremental model:

i. Needs good planning and design.

ii. Needs a clear and complete definition of the whole system before it can be broken down
and built incrementally.
iii. Total cost is higher than waterfall.
When to use the Incremental model:

i. This model can be used when the requirements of the complete system are clearly defined
and understood.
ii. Major requirements must be defined; however, some details can evolve with time.
iii. There is a need to get a product to the market early.
iv. A new technology is being used
v. Resources with needed skill set are not available
vi. There are some high risk features and goals.

Strengths of incremental model are:

i. Develop high risk business features first

ii. Every increment delivers an operational product
iii. Customer’s confidence is high as they validate every increment and provide feedback
iv. Low initial delivery cost
v. Changes in requirements can be accommodated for easily.
vi. More flexible than waterfall.

Weaknesses of incremental model are:

i. Needs good planning and design.

ii. Needs a clear and complete definition of the complete system before it can be broken
down and built incrementally.
iii. Integration needs are very high
iv. Total cost is higher than waterfall.
v. The project should be complete and concise.
ITERATIVE MODEL:

With Iterative development software changes on each iteration, evolves and grows. As each
iteration builds on the previous one, software design remains consistent.

An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which can
then be reviewed in order to identify further requirements. This process is then repeated,
producing a new version of the software for each cycle of the model.
Advantages of Iterative model:

In iterative model we can only create a high-level design of the application before we actually
begin to build the product and define the design solution for the entire product. Later on we can
design and built a skeleton version of that, and then evolved the design based on what had been
built.

i. In iterative model we are building and improving the product step by step. Hence we can
track the defects at early stages. This avoids the downward flow of the defects.
ii. In iterative model we can get the reliable user feedback. When presenting sketches and
blueprints of the product to users for their feedback, we are effectively asking them to
imagine how the product will work.
iii. In iterative model less time is spent on documenting and more time is given for
designing.

Disadvantages of Iterative model:

i. Each phase of iteration is rigid with no overlaps

ii. Costly system architecture or design issues may arise because not all requirements are
gathered up front for the entire lifecycle

When to use iterative model:

i. Requirements of the complete system are clearly defined and understood.

ii. When the project is big.
iii. Major requirements must be defined; however, some details can evolve with time.
SPIRAL MODEL

The Spiral model puts focus on thorough risk assessment. Thus, to reap the benefits of the
model to the fullest, you’ll need to engage people with a strong background in risk evaluation.
This is the model where intensive customer involvement appears. They can be involved in the
exploration and review stages of each cycle. At the development stage, the customer’s
amendments are not acceptable
Planning Phase: Requirements are gathered during the planning phase. Requirements like
‘BRS’ that is ‘Business Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’

Risk 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.

Advantages of Spiral model:

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

ii. Good for large and mission-critical projects.
iii. Strong approval and documentation control.
iv. Additional Functionality can be added at a later date.
v. Software is produced early in the software life cycle.

Disadvantages of Spiral model:

i. Can be a costly model to use.

ii. Risk analysis requires highly specific expertise.
iii. Project’s success is highly dependent on the risk analysis phase.
iv. Doesn’t work well for smaller projects.

When to use Spiral model:

i. When costs and risk evaluation is important

ii. For medium to high-risk projects
iii. Long-term project commitment unwise because of potential changes to economic
priorities
iv. Users are unsure of their needs
 v. Requirements are complex
vi. New product line
vii. Significant changes are expected (research and exploration)

Strengths of the Spiral model:

i. Early identification of potential risk areas.

ii. Customer sees a prototype very early in the SDLC.
iii. Critical and risky features are built first for risk mitigation and clarifying requirements.
iv. Design can evolve with iterations.
v. Feedback from users helps maintain their expectations.
vi. Cost is assessed frequently, hence better planning.

Weaknesses of Spiral model are:

i. Not suitable for smaller or low budget projects as cost is high for identifying risks.
ii. Time spent on risks, planning, and prototyping may not be as efficient
iii. It is complex
iv. Spiral may continue indefinitely.
v. Hard to define clear milestones, which allow the SDLC to move to the next phase.
vi. Developers must have other work during non-development phases.
 RAD MODEL

RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype.

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.

Data modeling: Information gathered from business modeling is used to define data objects that
are needed for the business.

Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and the
actual system.

Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

i. Reduced development time.

ii. Increases reusability of components
iii. Quick initial reviews occur
iv. Encourages customer feedback
v. Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

i. Depends on strong team and individual performances for identifying business

requirements.
ii. Only system that can be modularized can be built using RAD
iii. Requires highly skilled developers/designers.
iv. High dependency on modeling skills
v. Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.

When to use RAD model:

i. RAD should be used when there is a need to create a system that can be modularized in
2-3 months of time.
ii. It should be used if there’s high availability of designers for modeling and the budget is
high enough to afford their cost along with the cost of automated code generating tools.
iii. RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).

Weaknesses of RAD:

i. Depends on strong team and individual performances for identifying business

requirements.
 ii. Only system that can be modularized can be built using RAD
iii. Requires highly skilled developers/designers.
iv. High dependency on modeling skills
v. Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high for cheaper budgeted projects to befit.

PROTOTYPE MODEL

The basic idea in Prototype model is that instead of freezing the requirements before a design or
coding can proceed, a throwaway prototype is built to understand the requirements. This
prototype is developed based on the currently known requirements. Prototype model is a
software development model. By using this prototype, the client can get an “actual feel” of the
system, since the interactions with prototype can enable the client to better understand the
requirements of the desired system.

Advantages of Prototype model:

i. Users are actively involved in the development

ii. Since in this methodology a working model of the system is provided, the users get a
better understanding of the system being developed.
iii. Errors can be detected much earlier.
iv. Quicker user feedback is available leading to better solutions.
v. Missing functionality can be identified easily
vi. Confusing or difficult functions can be identified
vii. Requirements validation, Quick implementation of, incomplete, but functional,
application.

Disadvantages of Prototype model:

i. Leads to implementing and then repairing way of building systems.

ii. Practically, this methodology may increase the complexity of the system as scope of the
system may expand beyond original plans.
iii. Incomplete application may cause application not to be used as the full system was
designed
iv. Incomplete or inadequate problem analysis.

When to use Prototype model:

i. Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
ii. Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
iii. Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

Strengths of prototype model are:

i. Gains customer’s confidence as developers and customers are in sync with each other’s
expectations continuously.
ii. Ideal for online systems where high level of human computer interaction is involved.
iii. Very flexible, as changes in requirements can be accommodated much more easily with
every new review and refining.
iv. Helps the developers and users both understand the system better.
v. Software built through prototyping needs minimal user training as users get trained using
the prototypes on their own from the very beginning of the project.
 vi. Integration requirements are very well understood and deployment channels are decided
at a very early stage.

Weaknesses of the Prototype model are:

i. Focusing on the prototype can mislead developers from understanding the actual desired
system.
ii. End users get confused, believing the prototype to be the complete system
iii. Developers might misunderstand end users objectives.
iv. Developer might get too involved in prototype and deviate from the actual system that
the prototype must be converted into.
v. Expensive as prototypes need a lot of effort and time. It may take a lot of work to be done
for very less needed work to be achieved.

AGILE DEVELOPMENT MODEL

Agile development model is also a type of Incremental model. Software is developed in

incremental, rapid cycles. This results in small incremental releases with each release building on
previous functionality. Each release is thoroughly tested to ensure software quality is maintained.
It is used for time critical applications.
Advantages of Agile model:

i. Customer satisfaction by rapid, continuous delivery of useful software.

ii. People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.
iii. Working software is delivered frequently (weeks rather than months).
iv. Face-to-face conversation is the best form of communication.
v. Close daily cooperation between business people and developers.
vi. Continuous attention to technical excellence and good design.

Disadvantages of Agile model:

i. In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle.
ii. There is lack of emphasis on necessary designing and documentation.
iii. The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
iv. Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined
with experienced resources.

When to use agile model:

i. When new changes are needed to be implemented. The freedom agile gives to change is
very important. New changes can be implemented at very little cost because of the
frequency of new increments that are produced.
ii. To implement a new feature the developers need to lose only the work of a few days, or
even only hours, to roll back and implement it.
iii. Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users’ needs are ever changing in a dynamic
business and IT world.
iv. Both system developers and stakeholders alike, find they also get more freedom of time
and options than if the software was developed in a more rigid sequential way.
REFERENCES

 Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209.
ISBN 9780805300918. Retrieved 18 August 2014.

Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systems Analysis and Design Methods.
6th edition. ISBN 0-256-19906-X.

Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM
SIGSOFT Software Engineering Notes(ACM) 11(4):14-24, August 1986

Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project

management. Computer Society Press of the IEEE. p.130

Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und

Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.

Conrad Weisert, Waterfall methodology: there's no such thing!

Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven
Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117.

Jump up to:a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated
systems approach. Pearson Education. p.87.

Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE
Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.