ASSIGNMENT NO.

CSE 314

PRINCIPLES OF SOFTWARE ENGINEERING

SUBMITTED TO:

MR. MUNISH MITTAL

SUBMITTED BY:

KULWINDER KAUR

ROLL NO RB1801A03

SECTION B1801

REG NO. 10801437

QUES 1: “A common process framework is established by defining a small number of
framework activities that are applicable to all software projects, regardless of their size
or complexity.” Justify this statement by comparing at least four SDLC models.
ANS: 1) Waterfall Model

The best-known and oldest process is the waterfall model, where

developers follow these steps in order. They state requirements, analyze them, design a
solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. It
suggests a systematic, sequential approach5 to software development that begins at the
system level and progresses through analysis, design, coding, testing, and support.
Advantages: Easy to understand, easy to use, Provides structure to inexperienced staff,
Works well when quality is more important than cost or schedule.
Drawbacks: In waterfall model, linear structure is followed But Real projects rarely follow
the sequential flow that the model proposes. Although the linear model can accommodate
iteration, it does so indirectly. As a result, changes can cause confusion as the project team
proceeds.
2) Prototype Model

1) Developers build a prototype during the requirements phase

2) Prototype is evaluated by end users
3) Users give corrective feedback
4) Developers further refine the prototype
5) When the user is satisfied, the prototype code is brought up to the standards needed for a
final product

Advantages: Can be used when customer is not sure about what he wants, Faster way of
finalizing the requirements, Useful for new technologies and domains

Drawbacks: A prototype if used in a production environment may lack quality, Overall

maintainability may be overlooked, and the customer may want the prototype delivered.

3) Iterative Model

In this software is divided into different modules. It is a combination of

waterfall model and prototype model.
Advantages: Changes can be made module wise and client knows these changes time to
time.

4) Spiral Model

1) An evolutionary software process model that couples the iterative nature of prototyping
with the controlled and systematic aspects of the linear sequential model.

2) Software is developed in a series of incremental releases.

3) At final stages, more complete versions of the engineered system are produced.

4) The project manager adjusts the planned number of iterations required to complete the
software.

It is an example of Iterative model.

Advantages: Avoidance of Risk is enhanced, Strong approval and documentation control,

Implementation has priority over functionality and Additional Functionality can be added at a
later date.

Drawbacks: Highly customized limiting re-usability, Applied differently for each

application, Risk of not meeting budget or schedule, Possibility to end up implemented as the
Waterfall framework

QUES 2: “Deep Dive Analysis of Business Processes of an organization is necessary

before implementing them in software “. Justify with a suitable example?

ANS: Software analysis. The requirements gathering process is intensified and focused
specifically on software. To understand the nature of the program or process to be built, the
software engineer ("analyst") must understand the information domain for the software,
necessary before implementing them in software. Requirements engineering
activities result in the specification of software’s operational
characteristics (function, data, and behavior), indicate software's interface
with other system elements, and establish constraints that software must
meet. Requirements analysis allows the software engineer (sometimes
called analyst in this role) to refine the software allocation and build
models of the data, functional, and behavioral domains that will be
treated by software. Requirements analysis provides the software
designer with a representation of information, function, and behavior that
can be translated to data, architectural, interface, and component-level
designs. Finally, the requirements specification provides the developer
and the customer with the means to assess quality once software is built. The study
understanding of several needs of the client and the users so that the software can be built in
away that all the needs shall be known as analysis. The analyst, who is responsible for the
specifications of the software, must be totally aware of the business processes of the
organization. This is an important factor because if the analyst has the knowledge about the
business processes only then he can change them into the specified requirements or we can
say the required features of the software and the designers can get the same in the software
The analyst is supposed to have knowledge about the questions the clients has and users to
know about how the business processes are going in the organization

QUES 3 Suppose you are a software engineer and a customer defines a set of general
objectives for software but does not identify detailed input, processing, or output
requirements. In other cases, you may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human/machine interaction should
take. Which software model, you should use to fulfill the customer requirement.
Elaborate the model properly.

ANS: Prototype Model fulfills the requirements of the customer. The prototyping paradigm
begins with requirements gathering. Developer and customer meet and define the overall
objectives for the software, identify whatever requirements are known, and outline areas
where further definition is mandatory i.e. make a rough prototype. A quick design then
occurs i.e. design and implementation will occur after making the rough prototype. The
quick design focuses on a representation of those aspects of the software that will be visible
to the customer/user like input approaches and output formats. The quick design leads to the
construction of a prototype. The prototype is evaluated by the customer/user and used to
refine requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, while at the same time enabling the developer to
better understand what needs to be done.
Prototyping is the process of quickly putting together
a working model in order to test various aspects of a design, illustrate ideas or features and
gather early user feedback. Prototyping is often treated as an integral part of the system
design process, where it is believed to reduce project risk and cost.
1) Developers build a prototype during the requirements phase
2) Prototype is evaluated by end users
3) Users give corrective feedback
4) Developers further refine the prototype
5) When the user is satisfied, the prototype code is brought up to the standards needed for a
final product.

Part B

QUES 4: “Fixing a requirements error after delivery may cost up to 100 times the cost
of fixing an implementation error”. This statement is either true or false. If it is false,
modify this statement. If it is true, explain it with proper example.

ANS: Cost of Fixing the Requirement Error

Phase Cost(person-hour)
Requirement 2
Design 5
Coding 15
Testing 50
Maintenance 150

By investing additional 100 person hours in the requirement phase, an average of 50 errors
can be detected and removed.

If there are 50 errors in a project, then

65% errors are detected in Design phase.

2% errors are detected in Coding phase

30% errors are detected in Testing phase

3% errors are detected in Maintenance phase

If the error is not solved at the requirement phase then cost of fixing the error after the later
phases is given as:

32.5 * 5 + 1 * 15 + 15 * 50 + 1.5 * 150 = 1152 person hours

In other words by investing additional 100 person hours in the requirement phase the
development cost can be reduced by 1152 person hours- a net reduction in cost of 1052
person hours

QUES 5: “Validation of requirements is a mandatory practice while requirement

engineering”. Support this term with appropriate examples.

ANS: Requirements analysis in software engineering encompasses those tasks that go into
determining the needs or conditions to meet for a new or altered product, taking account of
the possibly conflicting requirements of various holders such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirement must

be actionable, measurable, testable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. Requirements can
be functional and non-functional
Conceptually, requirements analysis includes three types of activity:

1) Eliciting requirements: The task of communicating with customers and users to

determine what their requirements are. This is sometimes also called requirements gathering.
2) Analyzing requirements: determining whether the stated requirements are unclear,
uncomplete, ambiguous, or contradictory, and then resolving these issues.

3) Recording requirements: Requirements might be documented in various forms, such as

natural-language documents, use cases, user stories or process specifications.
Requirements analysis can be a long and arduous process during which many delicate
psychological skills are involved. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all their
needs and ensure they understand the implications of the new systems. Analysts can employ
several techniques to elicit the requirements from the customer. Historically, this has included
such things as holding interviews, or holding focus groups (more aptly named in this context
as requirements workshops) and creating requirements lists. More modern techniques
include prototyping, and use cases where necessary, the analyst will employ a combination
of these methods to establish the exact requirements of the stakeholders, so that a system that
meets the business needs is produced.
Systematic requirements analysis is also known as requirements engineering. It is sometimes
referred to loosely by names such as requirements gathering, requirements capture,
or requirement specification. The term requirements analysis can also be applied specifically
to the analysis proper, as opposed to elicitation or documentation of the requirements, for
instance.
Requirement engineering according to Laplante is "a sub discipline of software engineering
that is concerned with determining the goals, functions, and constraints of hardware and
software systems." In some life cycle models, the
requirement engineering process begins with a feasibility study activity, which leads to a
feasibility report. If the feasibility study suggests that the product should be developed, then
requirement analysis can begin. If requirement analysis precedes feasibility studies, which
may foster outside the box thinking, then feasibility should be determined before
requirements are finalized.

QUES 6 “Nobody can express the customer’s requirement in a graphical

representation. It can be only in textual format.” Do you support the statement? Justify
your answer with proper example.

ANS: No, I do not support the statement. The graphical methods have their own advantages
over the textual methods. The customer requirements are what the customer needs and how
the project will serve those needs. Requirements represent a detailed breakdown of the
customer’s expectations for the project, as well as how the project organization will serve
those requirements.
The two graphical methods are:

Data flow diagrams (dfd) and Entity –Relationship (ER) diagram are the validated methods.
The textual forms such as SRS etc acts as legal documents but to give better presentations
and understanding to the clients by the Software developers of the companies these two
method can be used.

The two methods are explained below.

DATA FLOW DIAGRAM

Data flow diagrams show the flow of data through the system. It views the system as a
function that transforms from input to desired output. These transformations can’t be done in
one step.DFD capture these transformations. Data flow diagrams can be used to provide a
clear representation of any business function. The technique starts with an overall picture of
the business and continues by analyzing each of the functional areas of interest. This analysis
can be carried out to precisely the level of detail required. The technique exploits a method
called top-down expansion to conduct the analysis in a targeted way. Data Flow Diagrams

The result is a series of diagrams that represent the business activities in a way that is clear
and easy to communicate. A business model comprises one or more data flow diagrams (also
known as business process diagrams). Initially a context diagram is drawn, which is a simple
representation of the entire system under investigation. This is followed by a level 1 diagram;
which provides an overview of the major functional areas of the business. Identifying the
existing business processes, using a technique like data flow diagrams, is an essential
precursor to business process re-engineering, migration to new technology, or refinement of
an existing business process. Data flows and resource flows are allowed between external
entities and processes. Data flows are also allowed between different external entities.
However, data flows and resource flows are not allowed between external entities and data
stores.

ER DIAGRAM
An entity-relationship (ER) diagram is a specialized graphic that illustrates the
interrelationships between entities in a database. ER diagrams often use symbols to represent
three different types of information. Boxes are commonly used to represent entities.
Diamonds are normally used to represent relationships and ovals are used to represent
attributes.