Model Questions and Answers

Sub- Software Engineering BTech(CSE) 5th Semester

Objective Questions:
1) What is the first step in the software development lifecycle?
a) System Design
b) Coding
c) System Testing
d) Preliminary Investigation and Analysis

Answer: d) Preliminary Investigation and Analysis

2) What does the study of an existing system refer to?

a) Details of DFD
b) Feasibility Study
c) System Analysis
d) System Planning

Answer: c) System Analysis

3) Which of the following is involved in the system planning and designing phase of the Software Development
Life Cycle (SDLC)?
a) Sizing
b) Parallel run
c) Specification freeze
d) All of the above
Answer: d) All of the above
4) What does RAD stand for?
a. Rapid Application Document
b. Rapid Application Development
c. Relative Application Development
d. None of the above
Answer: b) Rapid Application Development
5) Which of the following prototypes does not associated with Prototyping Model?
a. Domain Prototype
b. Vertical Prototype
c. Horizontal Prototype
d. Diagonal Prototype
Answer: d) Diagonal Prototype
6) The major drawback of RAD model is __________.
a. It requires highly skilled developers/designers.
b. It necessitates customer feedbacks.
c. It increases the component reusability.
d. Both (a) & (c)
Answer: d) Both (a) & (c)
7) Which of the following does not relate to Evolutionary Process Model?
a. Incremental Model
b. Concurrent Development Model
c. WINWIN Spiral Model
d. All of the above
Answer: d) All of the above
8) What is the major drawback of the Spiral Model?
a. Higher amount of risk analysis
b. Doesn't work well for smaller projects
c. Additional functionalities are added later on
d. Strong approval and documentation control
Answer: b) Doesn't work well for smaller projects
9) Model selection is based on __________.
a. Requirements
b. Development team & users
c. Project type & associated risk
d. All of the above
Answer: d) All of the above
10) Which of the following option is correct?
a. The prototyping model facilitates the reusability of components.
b. RAD Model facilitates reusability of components
c. Both RAD & Prototyping Model facilitates reusability of components
d. None
Answer: c) Both RAD & Prototyping Model facilitates reusability of components
11) Which of the following models doesn't necessitate defining requirements at the earliest in the lifecycle?
a. RAD & Waterfall
b. Prototyping & Waterfall
c. Spiral & Prototyping
d. Spiral & RAD
Answer: c) Spiral & Prototyping
12) When the user participation isn't involved, which of the following models will not result in the desired output?
a. Prototyping & Waterfall
b. Prototyping & RAD
c. Prototyping & Spiral
d. RAD & Spiral
Answer: b) Prototyping & RAD
13) The __________ model helps in representing the system's dynamic behavior.
a. Object Model
b. Context Model
c. Behavioral Model
d. Data Model
Answer: c) Behavioral Model

14) Which of the following word correctly summarized the importance of software design?
a. Quality
b. Complexity
c. Efficiency
d. Accuracy
Answer: a) Quality
15) What does a directed arc or line signify?

a. Data Flow
b. Data Process
c. Data Stores
d. None of the above
Answer: a) Data Flow

Subjective questions
Ques:
1) What is Software Engineering? Write the need of Software Engineering. Write the characteristics of a good
software engineer.
Ans.
Software Engineering is an engineering branch related to the evolution of software product using well-defined
scientific principles, techniques, and procedures. The result of software engineering is an effective and reliable
software product.
Need of Software Engineering
The necessity of software engineering appears because of a higher rate of progress in user requirements and the
environment on which the program is working.
 o Huge Programming: It is simpler to manufacture a wall than to a house or building, similarly, as the
measure of programming become extensive engineering has to step to give it a scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering ideas, it would be
simpler to re-create new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let down the
cost of computer and electronic hardware. But the cost of programming remains high if the proper
process is not adapted.
o Dynamic Nature: The continually growing and adapting nature of programming hugely depends upon
the environment in which the client works. If the quality of the software is continually changing, new
upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development provides a better and quality software
product.
Characteristics of a good software engineer
The features that good software engineers should possess are as follows:

• Exposure to systematic methods, i.e., familiarity with software engineering principles.

• Good technical knowledge of the project range (Domain knowledge).
• Good programming abilities.
• Good communication skills. These skills comprise of oral, written, and interpersonal skills.
• High motivation.
• Sound knowledge of fundamentals of computer science.
• Intelligence.
• Ability to work in a team
• Discipline, etc.

Ques:
2) What do you mean by SDLC Model? Write the types of SDLC model.Describe water fall model.
Ans:
SDLC Models:
There are different software development life cycle models specify and design, which are followed during the
software development phase. These models are also called "Software Development Process Models." Each
process model follows a series of phase unique to its type to ensure success in the step of software development.

Waterfall Model
Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC
will function one after another in linear manner. That is, when the first phase is finished then only the second
phase will start and so on.
This model assumes that everything is carried out and taken place perfectly as planned in the previous stage and
there is no need to think about the past issues that may arise in the next phase. This model does not work smoothly
if there are some issues left at the previous step. The sequential nature of model does not allow us go back and
undo or redo our actions.
This model is best suited when developers already have designed and developed similar software in the past and
are aware of all its domains.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short
o The situation is calm
o Where the tools and technology used is consistent and is not changing
o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the entire project
development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.
o The release date for the complete product, as well as its final cost, can be determined before
development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more significant and complex
projects.
o This model cannot accept the changes in requirements during development.
o It becomes tough to go back to the phase. For example, if the application has now shifted to the coding
phase, and there is a change in requirement, It becomes tough to go back and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and risks in the
earlier phase, so the risk reduction strategy is difficult to prepare.

Ques:
3) Describe the different issues that are analyzed before selecting a suitable life cycle model

Ans:
Selection of appropriate life cycle model for a project:
Selection of proper lifecycle model to complete a project is the most important task. It can be selected by
keeping the advantages and disadvantages of various models in mind. The different issues that are analyzed
before selecting a suitable life cycle model are given below :
 • Characteristics of the software to be developed: The choice of the life cycle model largely depends on
the type of the software that is being developed. For small services projects, the agile model is favored.
On the other hand, for product and embedded development, the Iterative Waterfall model can be
preferred. The evolutionary model is suitable to develop an object-oriented project. User interface part
of the project is mainly developed through prototyping model.
• Characteristics of the development team: Team member’s skill level is an important factor to deciding
the life cycle model to use. If the development team is experienced in developing similar software, then
even an embedded software can be developed using the Iterative Waterfall model. If the development
team is entirely novice, then even a simple data processing application may require a prototyping
model.
• Risk associated with the project: If the risks are few and can be anticipated at the start of the project,
then prototyping model is useful. If the risks are difficult to determine at the beginning of the project
but are likely to increase as the development proceeds, then the spiral model is the best model to use.
• Characteristics of the customer: If the customer is not quite familiar with computers, then the
requirements are likely to change frequently as it would be difficult to form complete, consistent and
unambiguous requirements. Thus, a prototyping model may be necessary to reduce later change
requests from the customers. Initially, the customer’s confidence is high on the development team.
During the lengthy development process, customer confidence normally drops off as no working
software is yet visible. So, the evolutionary model is useful as the customer can experience a partially
working software much earlier than whole complete software. Another advantage of the evolutionary
model is that it reduces the customer’s trauma of getting used to an entirely new system.

Ques:

4) What is cohesion and coupling? Differentiate between Coupling and Cohesion

Ans:

Cohesion: It measures the relative function strength of a module. In computer programming, cohesion defines to
the degree to which the elements of a module belong together. Thus, cohesion measures the strength of
relationships between pieces of functionality within a given module. For example, in highly cohesive systems,
functionality is strongly related.Cohesion is an ordinal type of measurement and is generally described as "high
cohesion" or "low cohesion."

Coupling: It measures the relative interdependence among modules. In software engineering, the coupling is the
degree of interdependence between software modules. Two modules that are tightly coupled are strongly
dependent on each other. However, two modules that are loosely coupled are not dependent on each
other. Uncoupled modules have no interdependence at all within them.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module Binding.

Binding.

Coupling shows the relationships Cohesion shows the relationship within the module.
between modules.

Coupling shows the Cohesion shows the module's relative functional strength.
relative independence between the
modules.
 While creating, you should aim for low While creating you should aim for high cohesion,
coupling, i.e., dependency among i.e., a cohesive component/ module focuses on a single function
modules should be less. (i.e., single-mindedness) with little interaction with other modules
of the system.

In coupling, modules are linked to the In cohesion, the module focuses on a single thing.
other modules.

Ques: 5) What is risk management? Explain types of risk.Write the Principle of Risk Management.How to
control the risk?

Ans:
Risk Management

A software project can be concerned with a large variety of risks. In order to be adept to systematically identify
the significant risks which might affect a software project, it is essential to classify risks into different classes.
The project manager can then check which risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-
related problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to
monitor and control a software project. It is very tough to control something which cannot be identified. For any
manufacturing program, such as the manufacturing of cars, the plan executive can recognize the product taking
shape.

2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and
maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing
specification, technical uncertainty, and technical obsolescence. Most technical risks appear due to the
development team's insufficient knowledge about the project.

3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing
budgetary or personnel commitments, etc.

Other risk categories

1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the
business and technical environment in which the plan is being developed, and more reliable data
sources (e.g., unrealistic delivery date)
2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past
turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.

Principle of Risk Management

1. Global Perspective: In this, we review the bigger system description, design, and implementation. We
look at the chance and the impact the risk is going to have.
2. Take a forward-looking view: Consider the threat which may appear in the future and create future
plans for directing the next events.
 3. Open Communication: This is to allow the free flow of communications between the client and the
team members so that they have certainty about the risks.
4. Integrated management: In this method risk management is made an integral part of project
management.
5. Continuous process: In this phase, the risks are tracked continuously throughout the risk management
paradigm.

Risk Control

It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are
determined; the project must be made to include the most harmful and the most likely risks. Different risks need
different containment methods. In fact, most risks need ingenuity on the part of the project manager in tackling
the risk.

There are three main methods to plan for risk management:

1. Avoid the risk: This may take several ways such as discussing with the client to change the
requirements to decrease the scope of the work, giving incentives to the engineers to avoid the risk of
human resources turnover, etc.
2. Transfer the risk: This method involves getting the risky element developed by a third party, buying
insurance cover, etc.
3. Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a
risk that some key personnel might leave, new recruitment can be planned.

Ques 6) What is Project Scheduling. Explain the task of project manager for Project Scheduling.

Ans:
Project Scheduling

Project-task scheduling is a significant project planning activity. It comprises deciding which functions
would be taken up when. To schedule the project plan, a software project manager wants to do the following:

1. Identify all the functions required to complete the project.

2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the duration of the
project.

The first method in scheduling a software plan involves identifying all the functions required to complete the
project. A good judgment of the intricacies of the project and the development process helps the supervisor to
identify the critical role of the project effectively. Next, the large functions are broken down into a valid set
of small activities which would be assigned to various engineers. The work breakdown structure formalism
supports the manager to breakdown the function systematically after the project manager has broken down
the purpose and constructs the work breakdown structure; he has to find the dependency among the activities.
Dependency among the various activities determines the order in which the various events would be carried
out. If an activity A necessary the results of another activity B, then activity A must be scheduled after
activity B. In general, the function dependencies describe a partial ordering among functions, i.e., each
service may precede a subset of other functions, but some functions might not have any precedence ordering
 describe between them (called concurrent function). The dependency among the activities is defined in the
pattern of an activity network.

Once the activity network representation has been processed out, resources are allocated to every activity.
Resource allocation is usually done using a Gantt chart. After resource allocation is completed, a PERT chart
representation is developed. The PERT chart representation is useful for program monitoring and control. For
task scheduling, the project plan needs to decompose the project functions into a set of activities. The time
frame when every activity is to be performed is to be determined. The end of every action is called a milestone.
The project manager tracks the function of a project by audit the timely completion of the milestones. If he
examines that the milestones start getting delayed, then he has to handle the activities carefully so that the
complete deadline can still be met.

Ques: 7) Write the Role and Responsibilities of a Project Manager. Write the the list of activities in project
management.

Ans:

Role of a Project Manager:

1. Leader

A project manager must lead his team and should provide them direction to make them understand what is
expected from all of them.

2. Medium:

The Project manager is a medium between his clients and his team. He must coordinate and transfer all the
appropriate information from the clients to his team and report to the senior management.

3. Mentor:

He should be there to guide his team at each step and make sure that the team has an attachment. He provides a
recommendation to his team and points them in the right direction.

Responsibilities of a Project Manager:

1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.

Activities

Software Project Management consists of many activities, that includes planning of the project, deciding the
scope of product, estimation of cost in different terms, scheduling of tasks, etc.

The list of activities are as follows:

1. Project planning and Tracking

2. Project Resource Management
3. Scope Management
 4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management

Ques: 9) What is SRS? Write the Characteristics of good SRS

Ans:
The production of the requirements stage of the software development process is Software Requirements
Specifications (SRS) (also called a requirements document). This report lays a foundation for software
engineering activities and is constructing when entire requirements are elicited and analyzed. SRS is a formal
report, which acts as a representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to be
perfect if it covers all the needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design, constraints, attributes, or
external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all available categories
of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms and
units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another as textual.

(b) One condition may state that all lights shall be green while another states that all lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For example,

(a) One requirement may determine that the program will add two inputs, and another may determine that the
program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms for that object. For
example, a program's request for user input may be called a "prompt" in one requirement's and a "cue" in
another. The use of standard terminology and descriptions promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This
suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if each requirement in it
has an identifier to indicate either the significance or stability of that particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential, especially for life-
critical applications, while others may be desirable. Each element should be identified to make these differences
clear and explicit. Another way to rank requirements is to distinguish classes of items as essential, conditional,
and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain changes
to the system to some extent. Modifications should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-effective system to
check whether the final software meets those requirements. The requirements are verified with the help of
reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the
referencing of each condition in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its source in earlier
documents.

2. Forward Traceability: This depends upon each element in the SRS having a unique name or reference
number.

The forward traceability of the SRS is especially crucial when the software product enters the operation and
maintenance phase. As code and design document is modified, it is necessary to be able to ascertain the
complete set of requirements that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple design alternatives for the final
system. More specifically, the SRS should not contain any implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate test cases and test plans
from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit domain but might not be
trained in computer science. Hence, the purpose of formal notations and symbols should be avoided too as much
extent as possible. The language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the details should be
explained explicitly. Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of abstraction
modifies according to the objective of the SRS.

Ques 10)
What is Software Configuration Management? Why do we need Configuration Management? Describe SCM
Process.

Ans:

When we develop software, the product (software) undergoes many changes in their maintenance phase; we
need to handle these changes effectively.
Several individuals (programs) works together to achieve these common goals. This individual produces several
work product (SC Items) e.g., Intermediate version of modules or test data used during debugging, parts of the
final product.

The elements that comprise all information produced as a part of the software process are collectively called a
software configuration.

As software development progresses, the number of Software Configuration elements (SCI's) grow rapidly.

Why do we need Configuration Management?

Multiple people are working on software which is consistently updating. It may be a method where multiple
version, branches, authors are involved in a software project, and the team is geographically distributed and
works concurrently. It changes in user requirements, and policy, budget, schedules need to be accommodated.

SCM Process

It uses the tools which keep that the necessary change has been implemented adequately to the appropriate
component. The SCM process defines a number of tasks:

o Identification of objects in the software configuration

o Version Control
o Change Control
o Configuration Audit
o Status Reporting

Identification
o Basic Object: Unit of Text created by a software engineer during analysis, design, code, or test.
o Aggregate Object: A collection of essential objects and other aggregate objects. Design Specification is
an aggregate object.
o Each object has a set of distinct characteristics that identify it uniquely: a name, a description, a list of
resources, and a "realization."
o The interrelationships between configuration objects can be described with a Module Interconnection
Language (MIL).

Version Control
o Version Control combines procedures and tools to handle different version of configuration objects that
are generated during the software process.
o Clemm defines version control in the context of SCM: Configuration management allows a user to
specify the alternative configuration of the software system through the selection of appropriate
versions. This is supported by associating attributes with each software version, and then allowing a
configuration to be specified [and constructed] by describing the set of desired attributes.

Change Control
o James Bach describes change control in the context of SCM is: Change Control is Vital. But the forces
that make it essential also make it annoying.
o We worry about change because a small confusion in the code can create a big failure in the product.
But it can also fix a significant failure or enable incredible new capabilities.
o We worry about change because a single rogue developer could sink the project, yet brilliant ideas
originate in the mind of those rogues, and
o A burdensome change control process could effectively discourage them from doing creative work.
o A change request is submitted and calculated to assess technical merit; potential side effects, the
overall impact on other configuration objects and system functions, and projected cost of the change.
o The results of the evaluations are presented as a change report, which is used by a change control
authority (CCA) - a person or a group who makes a final decision on the status and priority of the
change.
o The "check-in" and "check-out" process implements two necessary elements of change control-access
control and synchronization control.
o Access Control governs which software engineers have the authority to access and modify a particular
configuration object.
o Synchronization Control helps to ensure that parallel changes, performed by two different people, don't
overwrite one another.

Configuration Audit
o SCM audits to verify that the software product satisfies the baselines requirements and ensures that
what is built and what is delivered.
o SCM audits also ensure that traceability is maintained between all CIs and that all work requests are
associated with one or more CI modification.
o SCM audits are the "watchdogs" that ensures that the integrity of the project's scope is preserved.

Status Reporting
o Configuration Status reporting (sometimes also called status accounting) providing accurate status and
current configuration data to developers, testers, end users, customers and stakeholders through admin
guides, user guides, FAQs, Release Notes, Installation Guide, Configuration Guide, etc.