BANGALORE INSTITUTE OF TECHNOLOGY

K R ROAD, V V PURA, BANGALURU-04

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
I Internals -2023-24(EVEN)
Scheme of Evaluation

COURSE : SOFTWARE ENGINEERING & PROJECT MANAGEMENT BATCH:2021

CODE : 21CS61 SEM:6th
DATE & TIME : 04/05/2024 at 2.00 pm to 3.00 pm MAX MARKS:20
QP Marks
Solution Allocated
No.
1 a) Software is more than just a program code. A program is an executable code, which serves
some computational purpose
Software encompasses:
(1) Instructions (computer programs) that when executed provide desired features,
function, and performance;
(2) Data structures that enable the programs to adequately store and manipulate
information.
(3) Documentation that describes the operation and use of the programs.
1MARKS
Software Engineering is the discipline of designing, writing, testing, implementing and
maintaining software.it forms the basis of operational design and development of virtually
all computer system.
1MARKS
CHARACTERISTICS OF THE SOFTWARE
1. Software is developed or engineered; it is not manufactured in the classical
sense.
2. Software doesn’t “wear out.” 4MAR
3. Although the industry is moving toward component-based construction, KS
most software continues to be custom built.
2MARKS

1 b)
The 7 broad categories of computer software present continuing challenges for software
engineers:
1) System software
2) Application software
3) Engineering/scientific software
4) Embedded software
5) Product-line software
6) Web-applications
7) Artificial intelligence software.

System software: System software

is a collection of programs written
to service other programs.
 The systems software is
characterized by
heavy
interaction with computer hardware
1.

heavy usage by multiple users

2.

concurrent operation that requires

scheduling, resource sharing, and
sophisticated process
management
3.
6MARKS

2 a)
complex data structures
4.

multiple external interfaces

 System software: System software is a collection of programs written to
service other programs. The systems software is characterized by
heavy interaction with computer hardware
1. heavy usage by multiple users
2. concurrent operation that requires scheduling, resource sharing, and
 sophisticated process management
3. complex data structures
4. multiple external interfaces

E.g. compilers, editors and file

management utilities.
Application software:
Application software consists
of standalone programs that solve a
specific business need.
It facilitates business operations or
management/technical decision
making.
It is used to control business
functions in real-time
E.g. point-of-sale transaction 4MARKS

processing, real-time manufacturing

process control.
E.g. compilers, editors and file management utilities.
2 b)  Application software: Application software consists of standalone pro-
grams that solve a specific business need. It facilitates business operations
or management/technical decision making. It is used to control business
functions in real-time
E.g. point-of-sale transaction processing, real-time manufacturing
process control.
 Engineering/Scientific software: Engineering and scientific applications
range from astronomy to volcanology from automo-
tive stress analysis to space shuttle orbital dynamics from molecular biol-
ogy to automated manufacturing computer aided design, system simula-
tion and other interactive applications.
 Embedded software: Embedded software resides within a product or sys-
 tem and is used to implement and control features and functions for the
end-user and for the system itself. It can perform limited and esoteric func-
tions or provide significant function and control capability.
 Product-line software: designed to provide a specific capability for use by
many different customers. Product-line software can focus on a limited and
esoteric marketplace or address mass consumer markets.
e.g., word processing, spread sheets, computer graphics,
multimedia, entertainment, database management, and personal and
business financial applications
 Web applications: called “WebApps,” this network-centric software cate-
gory spans a wide array of applications. In their simplest form, WebApps
can be little more than a set of linked hypertext files that present informa-
tion using text and limited graphics.
 Artificial intelligence software: makes use of nonnumeric algorithms to
solve complex problems that are not amenable to computation or straight-
forward analysis. Applications within this area include robotics, expert sys-
tems, pattern recognition (image and voice), artificial neural networks, the-
orem proving, and game playing.
ANY 6 EACH=1*6 MARKS

Explain the generic process framework with the different process flow diagrams neatly.

A generic process framework for software engineering defines five framework activities—
communication, planning, modeling, construction, and deployment. . In addition, a set of
umbrella activities—project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others—are applied throughout the
process.
1MARKS
Process flow—describes how the framework activities and the actions and tasks
that occur within each framework activity are organized with respect to sequence and time
and is illustrated in Figure below 6MARKS
A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment (Figure a).
An iterative process flow repeats one or more of the activities before proceeding to
the next (Figure b).
An evolutionary process flow executes the activities in a “circular” manner. Each
circuit through the five activities leads to a more complete version of the software (Figure
3 a) c).
A parallel process flow (Figure d) executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might be executed in parallel
with construction of another aspect of the software).
 3MARKS

The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach6 to software development that begins with customer specification of
requirements and progresses through planning, modelling, construction, and deployment,
culminating in on-going support of the completed software.

Drawback:
 The main drawback of the waterfall model is the difficulty of accommodating
4MARKS
change after the process is underway. In principle, a phase has to be complete be-
fore moving onto the next phase.
 Inflexible partitioning of the project into distinct stages makes it difficult to re-
spond to changing customer requirements.
 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
 Few business systems have stable requirements.
  The waterfall model is mostly used for large systems engineering projects where a
system is developed at several sites.
 In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
3MARKS
3 b) The spiral model is an evolutionary software process model that couples the iterative
nature of prototyping with the systematic aspects of the waterfall model. It provides the
potential for rapid development of increasingly more complete versions of the software
Each of the framework activities represent one segment of the spiral path illustrated in
Figure
As this evolutionary process begins, the software team performs activities that are implied
by a circuit around the spiral in a clockwise direction, beginning at the center.
The first circuit around the spiral might result in the development of a product
specification; subsequent passes around the spiral might be used to develop a prototype
and then progressively more sophisticated versions of the software.

3MARKS

A process pattern describes a process-related problem that is encountered during software

engineering work, identifies the environment in which the problem has been encountered,
and suggests one or more proven solutions to the problem. Stated in more general terms, a
process pattern provides you with a template -a consistent method for describing problem
solutions within the context of the software process.
Patterns can be defined at any level of abstraction. In some cases, a pattern might
be used to describe a problem (and solution) associated with a complete process model
(e.g., prototyping).
A template for describing a process pattern:
Pattern Name. The pattern is given a meaningful name describing it within the
context of the software process (e.g., TechnicalReviews).
Forces. The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution.
Type. The pattern type is specified.
There are three types:
 Stage pattern—defines a problem associated with a framework activity for
the process. Since a framework activity encompasses multiple actions and
work tasks, a stage pattern incorporates multiple task patterns (see the fol-
 lowing) that are relevant to the stage (framework activity).
An example of a stage pattern might be EstablishingCommunication.
This pattern would incorporate the task pattern RequirementsGathering and
others.
 Task pattern—defines a problem associated with a software engineering
action or work task and relevant to successful software engineering prac-
tice (e.g., RequirementsGathering is a task pattern).
 Phase pattern—define the sequence of framework activities that occurs
within the process, even when the overall flow of activities is iterative in
nature. 6MARKS
An example of a phase pattern might be SpiralModel or
Prototyping.
Initial context: Describes the conditions under which the pattern applies. Prior to
the initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already exists?
4 a)
Problem: The specific problem to be solved by the pattern.
Solution: Describes how to implement the pattern successfully. This section
describes how the initial state of the process is modified as a consequence of the initiation
of the pattern. It also describes how software engineering information or project
information that is available before the initiation of the pattern is transformed as a
consequence of the successful execution of the pattern.
Resulting Context: Describes the conditions that will result once the pattern has
been successfully implemented. Upon completion of the pattern:
(1) What organizational or team-related activities must have occurred?
(2) What is the exit state for the process?
(3) What software engineering information or project information has been
developed?
Related Pattern:. Provide a list of all process patterns that are directly
related to this one. This may be represented as a hierarchy or in some other
diagrammatic form.
For example, the stage pattern Communication encompasses the task
patterns: ProjectTeam, CollaborativeGuidelines, ScopeIsolation, 4MARKS
RequirementsGathering, ConstraintDescription, and ScenarioCreation.
Known Uses and Example: Indicate the specific instances in which the
pattern is applicable.
For example, Communication is mandatory at the beginning of every
software project, is recommended throughout the software project, and is
4 b) mandatory once the deployment activity is under way
Process patterns provide an effective mechanism for addressing problems
associated with any software process.

Requirements engineering builds a bridge to design and construction. Requirements

engineering provides the appropriate mechanism for understanding what the customer
wants, analyzing need, assessing feasibility, negotiating a reasonable solution and
managing the requirements as they are transformed into an operational system
It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation,
specification, validation, and management.
 Inception:
At project inception, you establish a basic understanding of the problem, the people who
want a solution, the nature of the solution that is desired, and the effectiveness of
preliminary communication and collaboration between the other stakeholders and the
software team.
 Elicitation
. It certainly seems simple enough—ask the customer, the users and what the objectives
for the system or product are, what is to be accomplished, how the system or product fits
into the needs of the business, and finally, how the system or product is to be used on a
day-to-day basis
The number of problems that are encountered as elicitation occurs.
Problems of scope: customers/users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives
Problems of understanding.: The customers/users are not completely sure of what is
needed, have a poor understanding of the capabilities and limitations of their computing
environment, don’t have a full understanding of the problem domain, have trouble
communicating needs to the system engineer
Problems of volatility. The requirements change over time
 Elaboration:
The information obtained from the customer during inception and elicitation is expanded
and refined during elaboration. This task focuses on developing a refined requirements
model that identifies various aspects of software function, behaviour, and information.
Elaboration is driven by the creation and refinement of user scenarios that describe how
the end user (and other actors) will interact with the system
 Negotiation:
It isn’t unusual for customers and users to ask for more than can be achieved, given
limited business resources. It’s also relatively common for different customers or users to
propose conflicting requirements.
Customers, users, and other stakeholders are asked to rank requirements and then discuss
conflicts in priority. So that each party achieves some measure of satisfaction
 Specification:
In the context of computer-based systems (and software), the term specification means
different things to different people. A specification can be a written document, a set of
graphical models, a formal mathematical model, a collection of usage scenarios, a
prototype.
a “standard template” should be developed and used for a specification.
For large systems, a written document, combining natural language descriptions and
graphical models may be the best approach. However, usage scenarios may be all that are
required for smaller products
 Validation.
The work products produced as a consequence of requirements engineering are assessed
for quality during a validation step. Requirements validation examines the specification5
to ensure that all software requirements have been detected and corrected; and that the
work products conform to the standards established for the process, the project, and the
product.
The primary requirements validation mechanism is the technical review.
 Requirements management.
Requirements for computer-based systems change, and the desire to change requirements
persists throughout the life of the system
Requirements management is a set of activities that help the project team identify, control,
and track requirements and changes to requirements at any time as the project proceeds

6MARKS
Use-cases are a scenario based technique in the UML which identify the actors in an inter-
action and which describe the interaction itself.
A set of use cases should describe all possible interactions with the system.

There are many different ways to look at the requirements for a computer-based system.
Different modes of representation force you to consider requirements from different
viewpoints—an approach that has a higher probability of uncovering omissions,
inconsistencies, and ambiguity.

Scenario-based elements: The system is described from the user’s point of view using a
scenario-based approach. For example, basic use cases evolve into more elaborate
template-based use cases. Scenario-based elements of the requirements model are often
the first part of the model that is developed. As such, they serve as input for the creation of
other modeling elements. Three levels of elaboration are shown, culminating in a
scenario-based representation.
Class-based elements: Each usage scenario implies a set of objects that are manipulated
as an actor interacts with the system. These objects are categorized into classes—a
collection of things that have similar attributes and common behaviors. For example, a
UML class diagram can be used to depict a Sensor class for the SafeHome security
function

Behavioral elements: The behavior of a computer-based system can have a profound

effect on the design that is chosen and the implementation approach that is applied.
Therefore, the requirements model must provide modeling elements that depict behavior.
The state diagram is one method for representing the behavior of a system by depicting its
states and the events that cause the system to change state. A state is any externally
observable mode of behavior. In addition, the state diagram indicates actions (e.g., process
activation) taken as a consequence of a particular event.
 Flow-oriented elements: Information is transformed as it flows through a computer-
based system. The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms. Input may be a control signal
transmitted by a transducer, a series of numbers typed by a human operator, a packet of
information transmitted on a network link, or a voluminous data file retrieved from
secondary storage.

Faculty-Incharges

CouSrse Co-ordinator Module Co-ordinator IQAC Programme Co-ordinator