201505-Semester III-MI0033-Software Engineering

Q 1: Explain the overall agile process in detail A Process of agile

An agile process is guided by scenarios (customer portrayal of the requirements
in story-board format), acknowledges that plans are not frozen permanently and
can be changed as and when required, builds software on an iteration-basis and
delivers the final software over several software incremental deliveries, and
adjusts to the changes that is bound to happen during the entire duration of the
project.
The overall process is shown in Figure

User
Stories

Release
Planning

Iteration

Acceptance
Test

Small
Release

We will now briefly discuss the development process of XP which is by and large
a very good representation of a typical agile process.

Commences with the business analyst constructing user stories in

consultation with the customer. The agile team members analyse each
user story and estimate a cost to it.
Next, the user stories are clustered together for the first and subsequent
incremental deliveries.
The agile team estimates the effort and sets the deadline for the
incremental delivery.
Post-delivery of the first increment, estimates are worked out and
accordingly for other incremental deliveries, the delivery dates are
committed.
An XP project commences with user stories that are brief explanations of
the scenarios, which the customers and end-users want the software to
take care. This form is quite unlike the conventional requirement
specifications (explained later) mainly in explanation of the details the
user stories exclude thorough elaboration of the requirements. Such
detailing happens only at the time of construction, thereby granting more
time to the users for eliciting their requirements.
The authorised development team then makes an approximate calculation
of the time required to develop the user story into a software increment.
The estimates are expressed in weeks and are often approximate figures
that are imprecise. Once these estimates are ready along with the user
stories, the next step is to conduct release planning, a step that finalises
which of the user stories are to be incorporated in which incremental
delivery, and also delivery dates for each of these deliveries. A series of

frequent, small deliveries are preferred. The user stories are also used to
create the acceptance tests. Each incremental delivery has to pass the
acceptance test before final delivery to the customer.

Q2: a. What is software project estimation?

Software estimation is the first phase of project planning and it is the process of
judging a software product and solving the problem associated with the software
project. We follow some important steps to achieve reliable cost and effort
estimates.
Estimation models
As, software has become very expensive, large cost estimation errors will make a
huge difference between profit and loss and hence software estimation plays an
important role in a software project management activity. The different
estimation models involved in a software project are:

Empirical estimation model: The empirical estimation model uses

empirically derived formulas in order to predict the data required for
software project planning. These empirical data are derived from the
sample projects. Hence, this model is not very appropriate for all software
development environments and must be used only after analysing and
deciding wisely

The Constructive Cost Model (COCOMO): We can consider the

constructive cost model or COCOMO as a software cost estimation model.
This model uses historical data as well as the current project
characteristics. In order to estimate cost, effort and schedule in a project,
we use COCOMO model.

Delphi model: The Delphi model is based on the soft skills like collecting
information during a group discussion. This model follows a systematic
and interactive forecasting method and depends on a panel of experts. A
structured group of experts provide a more accurate solution when
compared to an unstructured group. The interaction is similar to face-to
face interviews/meetings. Hence, it is widely used for business
forecasting.

b. Explain COCOMO in a nutshell

The COCOMO cost estimation model is used by thousands of software project
managers, and is based on a study of hundreds of software projects. Unlike other
cost estimation models, COCOMO is an open model, so all of the details are
published, including:

The underlying cost estimation equations

Every assumption made in the model (e.g. "the project will enjoy good
management")

Every definition (e.g. the precise definition of the Product Design phase of
a project)

The costs included in an estimate are explicitly stated (e.g. project

managers are included, secretaries aren't)

Because COCOMO is well defined, and because it doesn't rely upon proprietary
estimation algorithms, Costar offers these advantages to its users:

COCOMO estimates are more objective and repeatable than estimates

made by methods relying on proprietary models

COCOMO can be calibrated to reflect your software development

environment, and to produce more accurate estimates

Costar is a faithful implementation of the COCOMO model that is easy to use on

small projects, and yet powerful enough to plan and control large projects.
Typically, you'll start with only a rough description of the software system that
you'll be developing, and you'll use Costar to give you early estimates about the
proper schedule and staffing levels. As you refine your knowledge of the
problem, and as you design more of the system, you can use Costar to produce
more and more refined estimates.
Costar allows you to define a software structure to meet your needs. Your initial
estimate might be made on the basis of a system containing 3,000 lines of code.
Your second estimate might be more refined so that you now understand that
your system will consist of two subsystems (and you'll have a more accurate idea
about how many lines of code will be in each of the subsystems). Your next
estimate will continue the process -- you can use Costar to define the
components of each subsystem. Costar permits you to continue this process until
you arrive at the level of detail that suits your needs.
Q3: a. Explain function oriented metrics
Function-oriented software metrics use a measure of the functionality delivered
by the application as a normalization value. Since functionality cannot be
measured directly, it must be derived indirectly using other direct measures.
Function-oriented metrics were first proposed by Albrecht [ALB79], who
suggested a measure called the function point. Function points are derived using
an empirical relationship based on countable (direct) measures of softwares
information domain and assessments of software complexity.
Extended Function Point Metrics:
The function point measure was originally designed to be applied to business
information systems applications. To accommodate these applications, the data
dimension (the information domain values discussed previously) was emphasized

to the exclusion of the functional and behavioral (control) dimensions. For this
reason, the function point measure was inadequate for many engineering and
embedded systems (which emphasize function and control). A number of
extensions to the basic function point measure have been proposed to remedy
this situation
b. How do you calculate function points?

Determine Unadjusted Function Point Count: Determining the unadjusted

function point count consists of counting the number of external inputs,
external outputs, external inquiries, internal logical files, and external
interface files, and determining the unadjusted function point count total.
Determine External Inputs: External inputs are elementary processes in
which data crosses the boundary from outside to inside. This data may
come from data input screens, electronically, or another application. The
data can be control information or business information. If the data is
business information it is used to maintain one or more internal logical
files. If the data is control information it does not have to update an
internal logical file. Multiply the count by 3, 4, or 6 for low, average, or
high.
Determine External Outputs: External outputs are elementary processes in
which derived data passes across the boundary from inside to outside.
The data creates reports or output files sent to other applications. These
reports and files are created from one or more internal logical files and
external interface files. Multiply the count by 4, 5, or 7 for low, average, or
high.
Determine External Inquiries: External inquiries are elementary processes
with both input and output components that result in data retrieval from
one or more internal logical files and external interface files. This
information is sent outside the application boundary. The input process
does not update any internal logical files and the output side does not
contain derived data. Multiply the count by 3, 4, or 6 for low, average, or
high.
Determine Internal Logical Files: Internal logical files are user identifiable
groups of logically related data that reside entirely within the application
boundary and are maintained through external inputs. - 5 - Multiply the
count by 7, 10, or 15 for low, average, or high.
Determine External Interface Files: External interface files are a user
identifiable group of logically related data that are used for reference
purposes only. The data reside entirely outside the application and are
maintained by another application. The external interface file is an
internal logical file for another application. Multiply the count by 5, 7, or
10 for low, average, or high.
Determine Unadjusted Function Point Count Total: Add the weighted
number of external inputs, external outputs, external inquiries, internal
logical files, and external interface files together. The result is the
unadjusted function points.

Q4 a. Explain the system architecture specification

We can consider a system architecture specification as a high-level design
document. This document provides details pertaining to the users requirements.
The design solutions are bifurcated into hardware and software modules, and the
interaction between these modules is also described. The system architecture
specification acts as a model for the development of detailed design.
We implement the system architecture specification in an organisation, during
the early stages of development so that the quality of the system and the
functionality are enhanced, thereby leading to increased assurance of
correctness.
When a particular component performs better than what was predicted in the
system architecture section, its details are discussed in the subsection of system
architecture section. Sometimes, the details might be specified in the design
documents. Also, discussions about the way the particular component is divided
and its interactions are mentioned. We must ensure that the design document
must always be consolidated in a proper format.
The specification documents give us a clear picture about the system
architecture, which satisfies the functions and operations of development and
also meets the business proposals. This document serves as an agreement,
which states that the system architecture meets the requirements and when
changes occur during the development phase, the change control request
process has to be adopted.
b. Explain System specification review
The term system specification review means evaluating the accuracy of the
definitions that are contained in the system specification document. Sometimes,
the review phase may be ignored during the development phase. This may lead
to problems while writing the source code for the system.
We can define review as a process of checking the details of a subject or
examining and verifying over and over, in order to ensure accuracy. A review is
generally conducted by the developer or the customer to make sure that the
following steps are adhered to:

The scope of the project must be correctly delineated/represented or

sketched.
Functions, performance and interfaces must be defined properly.
The system must be justified by analysis of environment and development
risk.
The developer and the customer must have the same perception about
the objectives of the system.

We will now briefly discuss about two segments of system specification review
shown in Figure.

Segments of System Specification Review

Management viewpoint Management viewpoint is the review that is
conducted based on management opinion, on the various business aspects
pertaining to software engineering process. The following questions are
generated for key management viewpoint:
o
o
o
o
o
o

Has a firms business need been established?

Does system justification make sense?
Does the specified environment (or market) need the system that has
been described?
What alternatives have been considered?
What is the development risk for each system element? Are resources
available to perform development?
Do cost and schedule bounds make sense?

The aforementioned questions are periodically raised and answered on a regular

basis, during the analysis phase of tasks in the system specification review.
Technical evaluation of system elements and functions Technical
evaluation review deals with the evaluation of various elements and functions
that are involved in the process of software engineering. The details gathered
during the technical stage of the system review and the details gathered during
the allocation task stage will differ from each other due to the variation in the
functions and the tasks assigned.
Let us now consider some issues that must be addressed by a typical review.
These issues are as follows:
o
o
o
o
o

Does the functional complexity of the system agree with the assessments
of development risk, cost and schedule?
Is the allocation of functions defined with the required details?
Have interfaces among system elements and also with the environment
been defined in sufficient detail?
Are performance, reliability and maintainability issues addressed in the
specification?
Does the system specification provide sufficient foundation for the
hardware and software engineering steps that follow?

When the system specification review is completed, other parallel path tasks
start. Thus, the various elements of system engineering such as software,
hardware, database elements and human elements are considered in the
technical evaluation review.
Q5. Explain the 12-step program design process of software
engineering that is followed to get the organizations back on track.
Stellar software design process As we are studying the design process of
software engineering, let us now study the 12-step program that is followed to
get the organisations back on track, that is, to make them understand why their
software didnt perform as expected or why the users make errors unexpectedly:

1. Admit that there is a problem This is the first step in stellar software design
process. This step talks about the program. It is not always possible to develop
good usability program. It is preferable to carry out informal customer interviews
and to team up with technical support staff. The designer should always think
like the user.
2. Believe in a power greater than the designers power This is the second step
of the design process. This step is used to find out the end-users the people
who will use the final product. Sometimes, it so happens that the actual endusers do not turn out to be from a particular group for whom the design was
originally developed.
3. A decision to be made to identify good design This is the third step of the
stellar software design process. This step talks about the design. Design is not
just what it looks like and feels like; design is how it works.
4. To search and invent users experience shortcomings This is the fourth step
in the stellar software design process. This step talks about how the design can
be explained. We can use illustrations to explain the design.
5. Admit to someone else (other than designers) the nature of problems This is
the fifth step of the design process. This step talks about how the designer
should think. The designers should talk as an equal to users more than getting
feedbacks from the users. This helps to sort out many issues.
6. To be ready to solve defects of character This is the sixth step of the design
process. This step specifies how a system should be developed. We will need to
develop the system in such a way that it can accept changes without affecting
the rest of the system.
7. Take help This is the seventh step of the design process. This step talks
about how designers should take help. It is always preferable to ask for help from
related people or other sources. There is no rule that one has to only listen to the
feedback given after reviewing. The developers can take an extra step by their
own.
8. Prepare a list of all the users who have been affected and then their lives can
be made better This is the eighth step of the design process. This step specifies
how to handle the issues. We can take this step to scale from functional to
reliable, then from usable to convenient and finally agreeable to meaningful. The
developer should be able to assess where he has failed. This step is extremely
difficult.
9. Make direct damages This is the ninth step of the design process. This step
talks about how a designer should act when sufficient feedback is not obtained.
It is difficult to get feedback from users. If unable to deliver an improvement, it is
better to prepare for the worst. Always make failures consciously and undertake
testing.

10. Continue the inventory This is the tenth step of the design process. This
step talks about the prior tasks of design. Usability testing is not a one-time
event but it is a cycle. Always observe, analyse and then design.
11. Realise that without users, it does not matter This is the 11th step of the
design process. This step specifies how the attitude of developers should be.
Usability testing is not only important for users but also equally important for the
developers, as it is continuously improved by developers.
12. Pay it forward This is the 12th step of the design process. A number of
resources are present in the software community for offer various courses that
can be learned.
Q6 a. Elaborate on Capability Maturity Model components.
The Capability Maturity Model defined by the Software Engineering Institute (SEI)
for Software describes the principles and practices to achieve a certain level of
software process maturity. The model is intended to help software organizations
improve the maturity of their software processes in terms of an evolutionary path
from ad hoc, chaotic processes to mature, disciplined software processes. The
CMM is designed towards organizations.
Components of CMM
We can use a maturity model as a standard for assessment and as an aid to
analyse the maturity software process. For example, for relative assessment of
different organisations, where there is some commonality, the model can be
utilized as a base for comparison. Like other models, CMM also has some
components, which include the following.
Maturity levels We can define maturity levels as well-defined levels, which
help in achieving a mature software process.1 The five maturity levels provide
the top-level structure of the CMM. In this structure, the uppermost (5th) level is
a theoretical ideal state where the processes are methodically managed by an
arrangement of process optimization and non-stop process improvement.
Process capability It refers to a variety of expected results that can be
attained by implementing software process. It provides a means to foresee the
possible results to be expected from the next software project that the
organization undertakes.
Key Process Areas (KPAs) This is an important component of CMM. We can
define KPA as a cluster of related activities that, when performed collectively,
aids to attain a set of goals considered to establish process capability at the
maturity level.
Goals This component of CMM recapitulates the key practices of a KPA and
determines whether an organization or project has effectively implemented it or
not. The goal signifies the scope and purpose of all the KPAs.

Common features Common features of CMM are aspects which signify

whether the implementation of a KPA is capable, and can be done repetitively
while being sustainable. We can divide it into the following five features:
o
o
o
o
o

Commitment to perform
Ability to perform
Activities performed
Measurement and analysis
Verifying implementation

b. Define Quality control and Cost of quality with the types of cost.
Quality Control (QC) we can define the concept of QC as a set of activities,
namely, inspection of the software product, review and testing the software
product that is used throughout the software process. The main focus of QC is on
the techniques that are operational, and on the activities that are used to meet
and check the quality requirements. Implementation of QC needs procedures,
practices and resources, which comprises the following:

A training program.
Policies and standards.
Review and audit procedure.
Dedicated and trained employees.
A program for measurement.
A process for planning.
Effective techniques and tools for testing

Cost of quality- We can define this quality concept as the total cost incurred in
maintaining the quality of a product that meets the customers requirements.
Cost of quality includes three types of costs:
Costs of prevention We can define these costs as the total cost of activities that
are undertaken for preventing bad quality. Examples are costs of surveys for
analysing supplier capabilities, costs incurred in making quality plans, and so on.

Costs of appraisal We can define these costs as the sum of costs that are
related to the measurement, evaluation or trial of products or services for
assuring conformance to the standards of quality and the requirements for
good performance. Examples are costs of in-process or final testing, costs
incurred in the audits process, and so on.
Costs of failure We can define such costs as the aggregate costs that
result from those products or services that do not conform to the needs of
the customer. These costs may occur either before the delivery of the
product or service, or after the delivery of product or service. Examples
are costs of rework, costs of warranty claims, and so on.