SOFTWARE ENGINEERING ( 22413 )

IMP QUESTION
1. Define software. Draw the failure curve for software { 2marks }
Ans:
Definition of Software : Software is 1. Instructions (computer programs) that when
executed provide desired features, function, and performance; 2. Data structures that
enable the programs to adequately manipulate information, and 3. Descriptive
information (documents) in both hard copy and virtual forms that describes the
operation and use of the programs.

2. State two characteristics of Software.{ 2 marks }

Ans: Characteristics of software :
o Software is developed or engineered; it is not manufactured in the classical
sense
o Software doesn’t “wear out.” But it does deteriorate!
o Although the industry is moving toward component-based construction, most
software continues to be custom built.

3. Name two cost estimation approaches. { 2 marks }

Ans:
o Heuristic Estimation Approach
o Analytical Estimation Approach
o Empirical Estimation Approach

1
 4. Define Quality control and Quality Assurance { 2 marks }
Ans:
o Quality Control:
Software quality control is the set of procedures used by organizations to
ensure that a software product meets its quality goals at the best value to the
customer, and to continually improve the organization's ability to produce
software products in the future

o Quality Assurance:
Conformance to explicit stated functional andperformance requirements,
explicitly documented. It is also thedevelopment of standards and implicit
characteristic that are expectedof all professionally developed software.

5. Explain Software Engineering as layered technology approach. ( 4 marks }

Ans: Software engineering is a layered technology. The layers of software
engineering as shown in the above diagram are:-

o A Quality Focus:
Any engineering approach (including software engineering) must rest on
an organizational commitment to quality. Total quality management, six
sigma and similar philosophies foster a continuous process improvement
culture, and it is this culture that ultimately leads to the development of
increasingly more effective approaches to software engineering. The
bedrock that supports software engineering is a quality focus.

o Process Layer:
The foundation for software engineering is the process layer. Software
Engineering process is the glue that holds the technology layers together

2
 and enables rational and timely development of computer software.
Process defines a framework that must be established for effective delivery
of software engineering technology. The software process forms the basis
for management control of software projects and establishes the context in
which technical methods are applied, works products (models, documents,
data, reports, forms etc.) are produced, milestones are established, quantity
is ensured and change is properly managed.

o Methods:
Software Engineering methods provide the technical ―how to building
software. Methods encompass a broad array of tasks that include
communication, requirements analysis, design modeling, program
construction, testing and support.

o Tools:
Software Engineering tools provide automated or semi-automated support
for the process and the methods. When tools are integrated so that
information created by one tool can be used by another, a system for the
support of software development, called computer–aided software
engineering is established.

6. Explain following elements of management spectrum: { 4 marks }

i. People
ii. Process
iii. Product
iv. Project
Ans: The management Spectrum: 4p’s Effective software project management
focuses on the four P’s: people, product, process, and project.
o The People:
The “people factor” is so important that the Software Engineering Institute
has developed a People Capability Maturity Model (People CMM) to
continually improve its ability to attract, develop, motivate, organize, and
retain the workforce needed to accomplish its strategic business objectives.

o The people capability maturity model defines the following key practice areas
for software people:
a. Staffing b.
b. communication and coordination
c. work environment

3
 d. performance management
e. Training, compensation, competency analysis and development, career
development, workgroup development, team/culture development and
others.

o Organizations that achieve high levels of People-CMM maturity have higher

likelihood of implementing effective software project management practices.

7. List and explain basic principles of project scheduling. { 4 marks }

Ans: Basic Principles
o Compartmentalization: The project must be compartmentalized into a number
of manageable activities and tasks.
o Interdependency: The interdependency of each compartmentalized activity or
task must be determined.
o Time allocation: Each task to be scheduled must be allocated some number of
work units.
o Effort validation: Every project has a defined number of staff members.
o Defined responsibilities: Every task that is scheduled should be assigned to a
specific team member.
o Defined outcomes: Every task that is scheduled should have a defined
outcome.
o Defined milestones: Every task or group of tasks should be associated with a
project milestone. A milestone is accomplished when one or more work
products has been reviewed for quality.

8. Distinguish between perspective process model and agile process model.

{ 4 marks }
Ans:
Prescriptive process model agile process mode
Prescriptive process models stress detailed
Agile process models emphasize project
definition, identification, and application of
“agility” and follow a set of principles that
process activates and tasks lead to a more informal approach to
software process.
It is Process oriented It is people oriented
It follows Life cycle model (waterfall, It follows Iterative and Incremental
spiral) development model. development model.
Predictive planning is required Adaptive planning is required.
Customers role is important. Customers role is critical.
Formal communication is required. Informal communication is required.
4
 9. Describe CMMI. Give significance of each level. { 4 marks }
Ans:
The Capability Maturity Model Integration (CMMI), a comprehensive process meta-
model that is predicated on a set of system and software engineering capabilities that
should be present as organizations reach different levels of process capability and
maturity. The CMMI represents a process meta-model in two different ways: ( 1)
Continuous model and (2) Staged model. The continuous CMMI meta-model
describes a process in two dimensions. Each process area (e.g. project planning or
requirements management) is formally assessed against specific goals and practices
and is rated according to the following capability

Level 1: Initial. The software process is characterized as ad hoc and occasionally

even chaotic. Few processes are defined, and success depends on
individual effort.
Level 2: Repeatable. Basic project management processes are established to track
cost, schedule, and functionality. The necessary process discipline is in
place to repeat earlier successes on projects with similar applications.
Level 3: Defined. The software process for both management and engineering
activities is documented, standardized, and integrated into an
organization wide software process. All projects use a documented and
approved version of the organization's process for developing and
supporting software. This level includes all characteristics defined for
level 2
Level 4: Managed. Detailed measures of the software process and product quality
are collected. Both the software process and products are quantitatively

5
 understood and controlled using detailed measures. This level includes
all characteristics defined for level 3
Level 5: Optimizing. Continuous process improvement is enabled by quantitative
feedback from the process and from testing innovative ideas and
technologies. This level includes all characteristics defined for level 4.

10. Describe any four principles of communication for software engineering { 4

Marks }
Ans:
o Try to focus on the speaker‘s words, rather than formulating your response to
those words.
o Ask for clarification if something is unclear, but avoid constant interruptions.
o Never become contentious in your words or actions (e.g., rolling your eyes or
shaking your head) as a person is talking.

Principle 2 Prepare before you communicate:

o Spend the time to understand the problem before you meet with others. If
necessary, perform some research to understand business domain.
o If you have responsibility for conducting a meeting, prepare an agenda in
advance of the meeting.
Principle 3 someone should facilitate the activity:
o Every communication meeting should have a leader (a facilitator)
o To keep the conversation moving in a productive direction,
o To mediate any conflict that does occur, and
o To ensure that other principles are followed.
Principle 4 Face-to-face communication is best:
o It usually works better when some other representation of the relevant
information is present.
o For example, a participant may create a drawing /document that serve as a
focus for discussion.
Principle 5 Take notes and document decisions:
o Someone participating in the communication should serve as a recorder and
write down all important points and decisions.
Principle 6 Strive for collaboration:
6
 o Collaboration occurs when the collective knowledge of members of the team
is used to describe product or system functions or features.
o Each small collaboration builds trust among team members and creates a
common goal for the team.
Principle 7 Stay focused; modularize your discussion:
o The more people involved in any communication, the more likely that
discussion will bounce from one topic to the next.
o The facilitator should keep the conversation modular; leaving one topic only
after it has been resolved.
Principle 8 If something is unclear, draw a picture:
o Verbal communication goes only so far.
o A sketch or drawing can often provide clarity when words fail to do the job.
Principle 9
(a) Once you agree to something, move on.
(b) If you can’t agree to something, move on.
(c) If a feature or function is unclear and cannot be clarified at the
moment,
move on.
o The people who participate in communication should recognize that many
topics require discussion and that moving on is sometimes the best way to
achieve communication agility.

Principle 10 Negotiation is not a contest or a game: It works best when both

parties win.
o There are many instances in which you and other stakeholders must negotiate
functions and features, priorities, and delivery dates.
o If the team has collaborated well, all parties have a common goal. Still,
negotiation will demand compromise from all parties.

7
 11. Draw DFD 0 and DFD 1 diagram for Library Management System. { 4 Marks
}

Ans:

12. State and describe two metrics of project size estimation { 4 Marks }
Ans:
Metrics for project Size Estimation
1. Line of Code
2. Function Point
1. Lines of Code (LOC)
LOC is the simplest among all metrics available to estimate project size. This metric
is very popular because it is the simplest to use. Using this metric, the project size is
estimated by counting the number of source instructions in the developed program
while counting the number of source instructions, lines used for commenting the
code and the header lines should be ignored. Estimation is dependent on
programming language. For different programming language lines of code will vary.

2. Function Point metric

8
In this method, the number and type of function supported by the software are
utilized to find FPC (Function point count).
The steps in function point analysis are:
o Count the number of functions of each proposed type
o Compute the unadjusted function point (UFP)
o Find total degree of influence (TDI)
o Compute value adjustment factor (VAF)
o Find the function point count (FPC)
Count the number of functions of each proposed type:
Functions belonging to the following types:
o External Input: Functions related to data entering the system.
o External Outputs: Functions related to data existing from the system.
o External Enquires: They lead to data retrieval from the system.
o Internal Files: Logical files maintained within the system.
o External interface files: These are logical files of other application used by our
application.
Compute the unadjusted function point (UFP)
o Categories each of the function types like simple, average or complex based
on their complexity. Multiply the count of each function type with its
weighing factor and find the weighted sum.
Function Type Simple Average Complex
External Inputs 3 4 6
External Outputs 4 5 7
External Inquries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10
Find total degree of influence (TDI)
o Use the 14 general characteristics of system to find the degree of influence of
each of them. The sum of all 14 degree of influence will give TDI. The range
of TDI is 0 to 70.
Compute value adjustment factor (VAF)
o VAF=(TDI*0.01)+0.65
Find the function point count (FPC)
FPC=UFP*VAF

9
 13. Distinguish between Black Box and White Box testing. (Write any four
points) { 4 Marks }
Ans:
White box Testing Black Box Testing
The tester need to have a knowledge of This technique is used to without
internal code or program code knowledge of internal coding
Its aim of Structure of testing the item Its aim for functionally of software
being tested
Can be based on Detailed Design Can be based required documentation
documents required
Statement coverage branch coverage Equivalents Partition
and path coverage are white box testing

14. Describe RMMM Strategy. { 4 Marks }

Ans: Risk mitigation, monitoring, and management (RMMM) plan. A risk
management strategy can be included in the software project plan or the risk
management steps can be organized into a separate Risk Mitigation,
Monitoring and Management Plan. The RMMM plan documents all work
performed as part of risk analysis and is used by the project manager as part
of the overall project plan. Once RMMM has been documented and the project
has begun, risk mitigation and monitoring steps commence. Risk mitigation
is a problem avoidance activity.
Risk monitoring is a project tracking activity with three primary objectives:
o To assess whether predicted risks do, in fact, occur;
o To ensure that risk aversion steps defined for the risk are being properly
applied; and
o To collect information that can be used for future risk analysis. In many cases,
the problems that occur during a project can be traced to more than one risk.
Another job of risk monitoring is to attempt to allocate origin (what risk(s)
caused which problems throughout the project).
An effective strategy must consider three issues:
o Risk avoidance
o Risk monitoring
o Risk management and contingency planning.
o If a software team adopts a proactive approach to risk, avoidance is always
the best strategy. This is achieved by developing a plan for risk mitigation. To

10
 mitigate this risk, project management must develop a strategy for reducing
turnover. Among the possible steps to be taken are
o Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, and competitive job market).
o Mitigate those causes that are under our control before the project starts.
o Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
o Organize project teams so that information about each development activity
is widely dispersed.
o Define documentation standards and establish mechanisms to be sure that
documents are developed in a timely manner.
o Conduct peer reviews of all work (so that more than one person is "up to
speed).
o Assign a backup staff member for every critical technologist. As the project
proceeds, risk monitoring activities commence. The project manager monitors
factors that may provide an indication of whether the risk is becoming more
or less likely. In the case of high staff turnover, the following factors can be
monitored:
o General attitude of team members based on project pressures.
o The degree to which the team has jelled.
o Interpersonal relationships among team members.
o Potential problems with compensation and benefits.
o The availability of jobs within the company and outside it.
In addition to monitoring these factors, the project manager should monitor the
effectiveness of risk mitigation steps. RMMM steps incur additional project cost.
Part of risk management, therefore, is to evaluate when the benefits accrued by the
RMMM steps are outweighed by the costs associated with implementing them. In
essence, the project planner performs a classic cost/benefit analysis.
15.Enlist core principles of software engineering practice.{2 marks }
Ans:
1) Reason it all exists. Provide value to the user
2) Keep it simple stupid
3) Maintain the vision
4) What you reproduce, someone else will have to consume. (implement
knowing someone else will have to understand what you are doing)
5) Be open to the future 6. Plan ahead for reuse Plan ahead for reuse Think!

11
 16.Define proactive and reactive risk strategy.{ 4Marks }
Ans:
Reactive risk strategies
o Reactive risk strategy follows that the risks have to be tackled at the time of
their occurrence.
o No precautions are to be taken as per this strategy.
o They are meant for risks with relatively smaller impact.
o More commonly, the software team does nothing about risks until something
goes wrong.
o Then, the team flies into action in an attempt to correct the problem rapidly.
This is often called a fire-fighting mode
Proactive risk strategies
o It follows that the risks have to be identified before start of the project.
o They have to be analysed by assessing their probability of occurrence, their
impact after occurrence, and steps to be followed for its precaution.

17. Name four software quality assurance activities. {4 marks}

Ans:These activities are performed (or facilitated) by an independent SQA group
that:
o Prepares an SQA plan for a project.
o Participates in the development of the project’s software process
description.
o Reviews software engineering activities to verify compliance with the
defined software process.
o Audits designated software work products to verify compliance with those
defined as part of the software process.

12