Page |1

COMPARATIVE ANALYSIS OF DEVELOPMENT

METHODOLOGIES

SAJJAD HUSSAIN QURESHI

SOFTWARE ENGEERING PART-II (MORNING)

2k19/SWE/93

FACULTY OF ENGINEEING AND TECHNOLOGY

DR. MUHAMMAD ALI NIZAMANI

23-02-2021
 Page |2

COMPARATIVE ANALYSIS OF DEVELOPMENT

METHODOLOGIES

Abstract
Models for software development, also known as the Life Cycle of Software
Development. There are now too many models of software development, mostly
waterfall, spiral, Fast Action Development, etc.; now Scrum, Kanban and Extreme
Programming are widely used for days in the Agile Family, by the software industries.
There are both benefits and drawbacks of these prototypes. We will address waterfall,
Scrum, Kanban and Extreme Programming in this paper; the main objective of this
review is to symbolize various software development models and make a decision
among them to demonstrate the functionalities of each model separately and
thoroughly. And we hope that this study will help the software industry make the right
choices about software development models before new software is developed.

Introduction
In software engineering, software development strategies and life cycles are
referred to as describing the shapes through which software evolves. Attention to the
production of the product. The process in which a software authorization is launched
is established. It has to be accomplished as software joins processes and is ultimately
implemented. An abstract demonstration of the design, or explanation of the software
process, is a software process model. Process models are used in software
enhancement to achieve different concerns related to price, time period, and quality
and fluctuating customer requirements, etc. Project implementation teams, dealers,
consumers and other stakeholders may be the reasons for project failure; but the most
common causes of project failure are rooted in the process of project management
itself and the compatibility of information technology with institutional ideologies. A
literature review of innovations in software development reveals that most software
activities are deliberated as partial failures due to difficulties increasing from software
development techniques and schemes, regardless of the actual method models used,
given for the software process to be successful. To create an effective program, we
will review the process models based on some parameters.
 Page |3

Background study
In the last several years, many common software development methodologies
have been presented, such as Agile development is called for as an inventive and
responsive attempt to address the needs of users based on the prerequisite for faster
and cheaper delivery of relevant working business applications. Typically, the
program is given in a gradual or iterative manner. Usually, the agile expansion
methods are concerned with ongoing user engagement through the application of
design teams and special workspaces. In order to confirm rapid end, the given
increases are likely to be small and insufficient to small supply stages. The technique
used by the company relies on the imposition of time boxing, the strict supply to the
target that defines the possibilities, the selection of performances to be given and the
adjustments to the objectives. In circumstances that progressively alter and perform
challenges with minimal outcomes, agile development is often convenient. Agile
approaches encourage the conception within an overall intentional system of
simultaneous increase and delivery. Based on the success and provision of very
insignificant output improvements, it is a method of change. It relies on continuous
improvement of code, user contribution to the development team and sensible
programming for pairs. Maintaining the interest of customers who are participating in
the process may be troublesome. Team members can be incompatible with the
penetrating involvement that distinguishes agile methods. Where there are many
stakeholders, stressing fluctuations can be troublesome. Agreements can be difficult
for continuous growth, as with other approaches. The Scrum is known by an
overwhelming number of journalists and academic journals as the greatest technique
for software creation. The original Scrum process, however, is not acceptable for
successive work in network management in an agile environment. As a result, the
Scrum-based model and the Kanban approach are long-standing for researchers to
make the most of both and find a more suitable framework for operating in a strongly
distributed agile setting for software development.
An abstract representation to describe the process from a certain point of view is a
Software Process Model. For software creation, there are different types of general
models. The following four versions will be used in this study:
1. The Waterfall model
2. Scrum
3. Kanban
4. XP
Prescriptive software process models have been applied for many years in an effort to
bring order and structure to soft-ware development. Each of these conservative
prototypes suggests a slightly dissimilar procedure flow, but all accomplish the similar
set of common framework actions –
 Communication
 Planning
 Modeling
 Construction
 Page |4

 Deployment

SOFTWARE PROCESS MODELS

1. The Waterfall Model

The Waterfall model, also referred to as the classic life cycle, indicates an
unorganized, progressive process for software development, the primogenital pattern
for software engineering. Initiate one process when another finishes. In circumstances
where criteria are well-defined and constant, and work must proceed to achievement
in a direct mode, useful process model.

Fig. 1. General Overview of the Waterfall Model

Communication: Project Initiation, Requirements Gathering and Analysis.

Planning: Estimating, Scheduling, and Following.
Modeling: System Analysis and Design.
Construction: Coding and Testing.
Deployment: Delivery, Support and regular Maintenance, Feedback.
Advantages of the Waterfall Model
 Identifies systems requirements long before programming begins
 Minimized changes to the requirements as the project proceeds.
 Easy to recognize and appliance.
 Generally cast-off and acknowledged.
 Categorizes deliverables and indicators.
 Mechanisms fit on advanced produces and feeble developer teams.
 Page |5

Disadvantage of the Waterfall Model

 It is often difficult for the customer to state all requirements explicitly
 The customer must be patient
 Idealized, doesn’t match reality well.
 Problematic and exclusive to make variations to papers.
 Significant clerical upstairs, expensive for small teams and ventures.

Agile Process Models

Agile software creation, in contrast to the waterfall model, is iterative or
cumulative. Requirements and solutions in agile software development (ASD) are said
to progress through the project's development.
 An agile process must be flexible
 It must adapt cumulatively
 Involves customer feedback
 An effective substance for customer feedback is a working prototype or
a portion of a functioning coordination
 Software augmentations must be provided in short time episodes
 Assists the customer to assess the software augmentation frequently
 Deliver basic feedback to the software team

This study will view the following Agile Process models:

 Scrum
 Kanban
 XP

2. Scrum
Scrum was founded in 1993 by Jeff Sutherland and its goal is to be a
methodology for change and organization that follows the concepts of agile
methodology. The Scrum team is compiled by: Team: the production project team,
consisting of up to ten developers with a precise ability for each member. Members,
however, are not forbidden from performing activities that are separate from their
skills. The team will therefore become more combined, and team members will better
grasp the software, mitigating the effect of the sacking of another member.
 Product owner. He is the one responsible for the specification of software
features and addressing any doubts that may occur during development. He is
the representative of the client who must closely watch the project and assist in
the development of a software that fully responds to the needs of the client.
 Scrum master. He is responsible for leading the team and preventing any
dashes that may occur during development.
 Page |6

 An obstacle is something that could prevent a participant from accomplishing

his job. For illustration, requests for non-project-related incidents, test server
issues, technology difficulties and unplanned pre-requisites may be examples
of sprints that could cause sprint problems. Scrum is focused on behaviors that
are represented by –
 Daily meetings,
 Sprint planning meetings,
 Sprint review meeting,
 Backlog sorting and
 Release presentation

Advantages of Scrum Methodology

 It is easier to distribute quality software in a planned time.
 Due to tiny sprints and continual response, it suits easier to handle with the
variations.
 Daily scrum meetings make it promising to measure specific production.
 Alike any other agile approach, this is also iterative in nature. It needs constant
response from the customer.

Disadvantages of Scrum Methodology

 If the development team members are not dedicated, the project will either
never complete or fail.
 It is good for small, fast moving developments as it works well only with
trivial development team.
 This approach needs qualified team members merely. If the team contains of
people who are beginners, the project cannot be accomplished in deadline.
 Page |7

 If any of the members leave during a development it can have a massive

inverse consequence on the project development.
3. Kanban
In reality, Kanban fulfills the Lean theory and is one of the main operational
management methods in Lean Manufacturing. It pushes project teams to envision the
workflow, to restrict work in progress (WIP) at each point of the workflow, and to
measure the cycle time.
Advantages of Kanban Methodology
 Improve portfolio and decrease product undesirability.
 Diminishes surplus and clash.
 Delivers tractability in manufacture.
 Intensifications productivity.
 Condenses total price.
 Progresses stream.
 Avoids failure.
Disadvantages of Kanban Methodology
 It is less operative in shared-resource circumstances.
 Flows in blend or mandate cause problems because Kanban accept sun
changing monotonous manufacture policies.
 Kanban in itself doesn't reject inconsistency, so changeable and lifelong down
times could dislocate the system; poor quality in terms of clash and rephrase
also mark its good running. Kanban systems are not suitable for industrial
locations with short manufacture runs.
 An interruption in the Kanban system cans consequence in the complete line
end.

4. XP-Extreme Programming:

One of the famous Agile methods is Extreme Programming. In many

organizations of all distinct sizes and productions worldwide, it has already been
proven to be very successful. Extreme Programming advances the development of
software in five fundamental respects.
 Communication
 Effortlessness
 Feedback
 Respect and
 Courage

Advantages of XP Methodology
 Client priority increase the chance that the software manufactured will actually
encounter the requirements of the consumers.
 Page |8

 The focus on minor, incremental relief declines the risk on development.

 By presenting that a method works.
 By setting functionality in the hands of the customers.
 Incessant testing and combination assistances to raise the superiority of
development.
 XP is friendly to programmers who usually are grudging accepting a software
method.

Disadvantages of XP Methodology
 XP is geared to a solo development, established and sustained by a sole team.
 XP is incompetent in surroundings where a client or administrator claims on a
complete requirement or strategy earlier, they start programming.
 XP is incompetent in surroundings where programmers are disconnected
geologically.

XP is incompetent to work with arrangements that have expandable matters.

RELATED WORK

Job design has an optimistic alliance with worker well-being alongside job
management, according to Holman (2002). Moreover, while the author hypothesizes
that a worker in an organization may facilitate job monitoring, a high degree of
monitoring has an unenthusiastic impact on interests (Chalykoff & Kochan, 1989;
Holman, 2002). In order to better repro-duce supervisory dimensions in the
administrative center, human resources activities and team mentor support variables
are planned. A primary problem in manipulating employee well-being is high-level
administration help with greater control of job design (Holman, 2002; Kular, Gatenby,
Rees, Soane, & Truss, 2008). Organizational behavioral research has also shown that
the stages of employee well-being have a total effect on the satisfaction of individual
jobs (Wright & Bonett, 2007).
Staff and creators are satisfied when their job distinctiveness equals their own
attributes in the workplace (Warr, 2007). Precedent research has shown that agile
practices can effectively promote and amplify developers' job fulfillment (Melnik &
Maurer, 2006; Sharp & Robinson, 2008; Tessem & Maurer, 2007), as they are
designed to meet the requirements of ensemble citizens. For example, small dollops of
functionality are frequently shared with customers by using user story cards for the
duration of preparing game activity, enabling team members to maintain their
sensitivity of passion (Syed-Abdullah et al., 2006). In addition, programmers are
expected to solve programming tribulations in pairs and habitually substitute
associates during pair programming, all of which support collaboration and a sense of
project tenure surrounded by other team members, and thus improve their well-being.
Agile work distinctiveness is able to diminish hopelessness among staff and
developers, provided that they place emphasis on the significance of unremitting
 Page |9

criticism and multiple liberates. This is because the activities support the community
climate, which allows members to have a clear path towards achieving goals for
growth. It is also hypothesized that a higher range of well-being assessed by non-agile
teams would be practiced by agile teams. Some metrics have been chosen by them to
calculate the efficacy of these software development methodologies. Unfortunately,
however, they did not acknowledge the effects of the time needed for software
development.

PROBLEM STATEMENT
There are a few software methodologies that many software development
companies use extensively. However, organizations, especially new businesses, often
face the problem of selecting the software methodology for a particular software
project. An incorrect collection of methodologies for software development also
makes such projects fail. There are a variety of works that have been proposed for
comparative analysis of software methodologies, as we see in section III (related
work). But we find some shortcomings or vulnerabilities in testing the program
methodologies in our study. For example, we find that several essential criteria are not
taken into account in their study for instances of communication, requirement
requirements, cost, resource management, simplicity, risk analysis, user feedback,
customer priority, precondition, elasticity, practicality, implementation, usability, etc.
So often their recommendation for choosing the methodologies for software
development might not be successful in this regard. Moreover, their method of
calculating the evaluation parameters is not accurate, because the relevant values of
those parameters have not been specified. In addition, how these values come from the
related parameters is not explicitly specified. Therefore, for a proper comparative
analysis of the methodologies of software development, missing parameters need to be
considered.

PROPOSAL FOR COMPARING SOFTWARE

DEVELOPMENT METHODOLOGIES
In our study, we will consider which process to select the best approach for
providing the customer with quality apps. We should get solutions to certain questions
before deciding the method to be used.
1. How steady are the requirements?
2. Who is the ultimate consumer for the software?
3. What is the opportunity of the product?
4. Where are the Development teams placed?
For the prerequisite provided by the client, our creation is to discuss which
methodology to be used. Let us have a comparative analysis of the mechanism that
will be involved in the processes below and the model selection advantages &
 P a g e | 10

disadvantages. We have chosen four types of methodologies, which are The Waterfall
Model, Scrum, Kanban and XP, for this study and comparative studies between
different software methodologies. We have chosen these methodologies, since most
software development industries regularly adopt these four models. Waterfall is well
known to all in these process models, and now Agile is very popular internationally,
and Scrum, Kanban and XP are the Agile Software Development family members
(ASD). Another name for the longer-established approach to software development is
the Waterfall Model. As this development group is always designed using a Gantt
map, it is called 'waterfall' since developers complete one section before touching on
the next segment. In Waterfall, when it's finished, it's rarely intended to return to a
section. As a consequence, whatever you do right gets better the first time. This
method is highly precarious, frequently more costly, and generally less skilled than
other Agile strategies. The Scrum approach carries much less risk than the processes
in Waterfall. It focuses on the provision of fully-tested, separate, precious, tiny
functionality. As a result, the risk is diversified; if one feature goes wrong, it does not
come into contact with a new feature. With that said, developers are still preparing to
run in iterations and will still be released at the end of the iteration. As a
subcomponent of the Toyota Development System, Kanban refined it. The method is
visualized in Kanban: work is ruined into small, disconnected objects and written on a
card that is spellbound to a section; the board has singular columns and the card is
consequently shifted as the work progresses through various stages. The quantity of
items in Kanban that can be in progress at any time is totally imperfect. An object is
tracked and configured for the normal time it takes to complete, so that the process
becomes as efficient and consistent as possible. The eradication of misuse is
overriding.
Some other important points that differentiate XP from Scrum in combination with
shorter iterations are: XP teams operate on items classified in an oppressive
precedence, while a Scrum can’t inevitably discuss each item once in sprint in
precedence order. If the user selects a new precedence, XP teams will fetch new
objects of effort into iteration and swap out objects of the corresponding size. The
responsibility of the customer in XP is somewhat parallel to that of the product owner
in Scrum in terms of relationships, in that they help write user stories, prioritize them
and are still available to developers, despite the fact that they are less well
differentiated. Mutually Scrum and XP maintain a daily stand-up meeting. The
parameters we have identified for distinguishing these methodologies are:
 Communication
 Requirement Specifications
 Cost
 Resource Control
 Simplicity
 Risk Analysis
 Feedback from User
 Customer Priority
 Precondition
 Elasticity
 Practicality Implementation
 P a g e | 11

 Usability
We have selected these parameter sets to optimize a model solution to a target
solution. By these parameters we can evaluate a better methodology of software
development for industries and software development firms.

DISCUSSION AND ANALYSIS OF THE STUDY

ABC is an insignificant corporation that wanted to turn its entire development
team to Agile. It was an informal adjustment for the people of the apps, harder for the
maintenance people (until they know about Kanban). The mainframe developers were
the ones in the Centre. This company is in insurance, an industry that has plenty of
legacy backend programs. In our Agile explorations, our team encountered mainframe
developers until they were impervious to an Agile strategy. The specifics are various
but generally focused on the constraint that legacy systems take longer to change and
individual mainframe systems are not adaptable to the Agile environment. In this
particular case, our team was happily astonished to see attention, eagerness, at the
beginning of a project using the agile process, even though COBOL, CICS and RPG
were complicated systems. Here, by relating what agile activities we conducted, what
experiments we experienced and what successes we saw, we want to abstract the
knowledge.
Standard Agile Performs
 The development team was small, 3 programmers and a QA also playing the
Scrum Master character. There was an enthusiastic Product Owner who was a
Business Analyst acquainted with the problem to be solved. The sponsor, a
Product Manager, was also exceedingly convoluted.
 The development team choses a 3-weeks Sprint span based on unusualness
with Agile in overall, the remark that tasks and stories might be bigger than in
other developments and the understanding that development team members
could not protection for separately well due to concentration.
 Complete system policy was incremental.
 Functionalities were prioritized and done in priority mandate.
 The Product Owner and end-users were convoluted on a daily basis.

Challenges to Standard Agile Performs

 The programmers were extremely focused in their technologies.
 Cross-training was inadequate by a vertical learning curve.
 Automated testing was measured to be unbearable. Our team thought this at
inordinate length. At the unit phase, well – what is unit in COBOL? It is a
structured programming language. Programs are enormous, massive.
Accumulates yield an extended period. It is dangerous to run just portion of the
code. Testing is done by moving through a debugger and trifling with
capricious principles in recollection. This does not loan itself to
computerization. Our team observed into screen footage and repetition, which
 P a g e | 12

is conceivable, but the subsequent writings are tremendously friable. In the

termination, the competent cost of enquiry was too high for the little project
timeline.
 Consuming a small development team did reason some postponements when
individuals were absentminded.

What We Got

 Throughout the estimation of the backlog, describing a story was short-

circuited when it became disappointing that the company was asking for
something that was technically unbearable inside the downstream host
organism. The story, estimated primarily to be moderately big, was simply
written. Given the fundamentally limitless expense of the story, the Product
Owner was not bothered by the loss of the features even though it had initially
been protuberant in the creative project budget. Investment costs were
calculated at approximately BDT 100000.
 While Sprint 2 was designed, another fantastic, high-priority feature vaporized
when the Product Owner realized that the work performed in Sprint 1 caused
the floor box to be adequately clarified. The feature was a real-time data update
from one backend device to an external system front end. The first sprint
product consumer testing showed that batch explanations had a satisfactory
price and were very confident with gadgets. The Fairy saved another 100K
BDT.
 The growth team stroked that in an old-style project technique these
investments would not have been recognized. In a design text, the
specifications would have been overheated and implemented as well as
potentially without any discussion with the expert.
 Variations in other requirements resulted from nonstop review by the Product
Owner and were not a subject for the programmers.
 The project was small, but still accomplished so rapidly compared to pre-Agile
potentials that the team stayed together to implement another set of
functionalities out of the possibility of the original budget.
 The development team, some of who were incredulous, had pleasurable and
appreciated the attainment. The Professional was very satisfied as fine.
 The pre-Agile approximation of work was 2 years gone time in this extremely
multi-tasked situation. The Agile project was completed in less than 3 months
thanks to an absorbed determination. Time worth of currency, which one?
 Cheers to administrative story trimming by the Product Owner and Sponsor,
the product conveyed formerly than even the original agile estimated release
date.
 Management had a superior familiarity of status without having status
intelligences modestly by attending the daily stand-up meetings.

Our Statements
So, did Agile work out well for this all-mainframe project? Indeed, it did. Even
though it was not full Extreme Programming in methodological performs, using a
 P a g e | 13

Scrum approach and agile principles resulted in both previous Return on In-vestment
and minor cost. Oh, and everybody had great doing it – always a respectable signal.
A software process model is a streamlined demonstration of a software process,
presented from a specific perception. A software process model is an intellectual
illustration of a soft-ware process. Problems solving in software contain of these
activities:
 Finding the problem
 Determining a plot for solution
 Code generating the intended solution
 Testing the authentic program

Each movement can be incredibly composite on behalf of large structures, and

procedures and procedures are required to complete it professionally and
appropriately. In addition, each of the undertakings itself is capable of being so large
that it cannot be regulated in a single phase and must be divided into smaller phases.
For example, the design of a large software framework is often fragmented into many
segments of distinct design, initially from a very high-level design that recognizes
only the system mechanisms to a detailed project where the mechanisms' logic is
recognized. For the creation of a software structure, the fundamental undertakings or
segments to be carried out are-

 Purpose of System’s Requirements

 System Analysis & Design
 Developing or coding of the software
 System Testing as an end user
 System deployment and regular maintenance

Comparison table on Various Process Models

Parameters Process waterfall Scrum Kanban XP

models
Communication Initial level Frequently Frequently Initial level
Requirement specifications Initial level Frequently Frequently change Initial level
change
Cost Low Much Much Expensive High
Expensive
Resource control Yes No No Yes
Simplicity Simple Complex Complex Intermediate
Risk Analysis Only at Yes Yes Yes
 P a g e | 14

beginning
Feedback from user No No No Yes
Customer priority Nil High High Intermediate
precondition Requirement No No No
clearly defined
Elasticity No Very High Very High Medium
Practically Implementation No High High High
Usability Basic Most use Most use now a Medium
now a days days

FUTURE WORK

1. To define an appropriate mechanism for the exchange of information when

user-centered design in a startup is achieved.
2. To test other available software development processes in a startup such as V-
Model, RUP etc. and see how well it can be applied in a solo developer startup
environment.

CONCLUSION

This paper discussed what software process model is and various process
models, also compare them with different para-meter and highlight the factors for
choosing them. This paper presents the chart based on usage. However, the existing
model still can be improving and modified based on less cost, time and highly
efficient. The developer should find out following aspects-

1. Find out market analysis that why Agile Models [Scrum, Kanban & XP] are
Popular now a day.
2. How can improve efficiency of given model?

As we discussed on Waterfall, Scrum, Kanban & XP’s advantages and disadvantages,

it depends upon the organization which model to choose.
 If requirement changes frequently and smaller projects, deliver product
in short period time with skilled resources then we can choose “Agile
model [Scrum, Kanban & XP]”.
 If requirement is clear, larger project then we choose “Waterfall model”.

PART 2
 P a g e | 15

Q1. Giving reasons for your answer based on the type of system being
developed,
suggest the most appropriate generic software process model that might be
used as a
basis for managing the development of the following systems:
 A system to control anti-lock braking in a car
 A virtual reality system to support software maintenance
 A university accounting system that replaces an existing system
 An interactive travel planning system that helps users plan journeys with
the lowest environmental impact.

Ans:

 A system to control anti-lock braking in a car

 Waterfall + formal transformations

 A virtual reality system to support software maintenance

 Incremental development

 A university accounting system that replaces an existing system

 Reuse-based approach can be the best choice, because the requirements are
well-known and will be used in conjunction with lots of other systems.

 An interactive travel planning system that helps users plan journeys

with the lowest environment impact
 Incremental

Q2. Describe RUP process model.

Ans:
RUP stands for “Rational Unified Process”. RUP is a software development process
from rational, a division of IBM. It divides the development process into four distinct phases
that each involve business modeling, analysis and design, implementation, testing and
deployment. The four phases are:
1. Inception – The idea for the project is stated. The development team determines
if the project is worth pursuing and what resources will be needed.
2. Elaboration – The project’s architecture and required resources are further
evaluated. Developers consider possible applications of the software and costs
associated with the development.
3. Construction – The project is developed and completed. The software is
designed, written and tested.
4. Transition – The software is released to the public. Final adjustments or
updates are made based on feedback from end users.
 P a g e | 16

The RUP development methodology provides a structured way for companies to

envision create software programs. Since it provides a specific plan for each
step of the development process, it helps prevent resources from being wasted
and reduces unexpected development costs.

Q3. (A) Explain why incremental development is the most effective

approach for developing business software systems?

Ans:
First, incremental development allows early access to the most valuable functionality.
Early access not gains value early, but also gives the most important component of the system
the most testing.
Second, incremental development can handle requirement changes well, which is
necessary for business software systems whose requirements have to change when the
business changes. Incremental development reduces rework on analysis and documentation
when change happens.
Third, incremental development doesn’t need a complete specification in advance.
This is important to business software because the detailed requirement may not be spotted
until part of the functionalities are implemented.

(B) Why is this model less appropriate for real-time systems engineering?

Ans:
This is because computing time may suffer without a complete plan for the whole
system. Real-time system is time-critical, therefore can not start without a complete plan.

Q4. Explain why change is inevitable in complex systems and give examples
(apart from prototyping and incremental delivery) of software process
activities that help predict changes and make the software being developed
more resilient to change.

Ans:
The requirements may change due to the change of the market/environment.
Sometimes a better solution to the old requirements is also necessary.
Develop software interactively can help predict changes because the experts can have
better insight about the possible changes on the business domain in the future.
Use component-based architecture can restrict the impact of many changes within
some components but not the entire system.

More from the solution manual:

 Recording of requirement rationale so that the reasons behind the requirements is
known. This helps with future change.
 Requirements traceability that shows the dependencies between the requirements.
 P a g e | 17

 Design modeling helps the structure of the software remain clear even after
changes.
 Code refactoring that improves code quality and organization and so makes it
robust enough to take few more changes.
Q5. Explain why Boehm’s spiral model is an adaptable model that can
support both change avoidance and change tolerance activities.

Ans:
This is because of the explicit risk management of Boehm’s spiral model. By spotting
and handling the risks between planning and developing, many changes can be avoided in
advance and plans for future changes can be made to improve change tolerance.
Spiral model can be over expensive for most cases, that may be the reason why it is
not widely used. The other reason is that just like incremental development, lacking a
complete specification before the end of the process makes it hard to work with management
systems.

Q6. Consider the reuse-based process model shown in Figure 2.3. Explain
why it is essential to have two separate requirements engineering activities
in the process.
Ans:
Requirements specification is about determine the user and system requirements of
the software system. Requirements modification is to modify the requirement specification
based on the reusable components. The modification is necessary because we usually don’t
have full control over reusable components, therefore some work around is necessary.

THE END