Software Engineering II

Solved Assignments
Semester Spring 2010
Assignment 1
A software xyz company is developing IT Services and products for different organizations.
Most of their projects, when delivered to the customer didn’t fulfill the customers’ expectations.
During the testing phase they found lot of defects which require more cost and resources to fix
them. As a result most of their projects fail or they have to modify the project in order to make it
according to the customer’s expectations. At the moment they have their own ad-hoc process
model for Software Development. Now Company hired you as a project manager. So as a project
manager:

Q No.1: Identify the reasons why project fails?

Answer.
A number of reasons contribute to Projects Failure. Some of them are outlined below.
o The product scope is poorly defined.
One of the main reasons of Project failure is that Project scope is not clearly defined. The
Scope Statement should includes the list of users using the product, as well as the features
in the resulting product, however, when any of these things are missed or are not given
too much importance in the Project Scope Statement, then Projects usually fail, or if they
succeed, then they succeed only after so many changes.
o Changes are managed poorly.
Another reason for failures of software project is that Changes in the existing system are
managed poorly. Changes can be changes in the existing system or even changes in the
other aspects of software projects, like deadline of software.
o Businesses needs change or are ill-defined.
 When the business needs change and are not managed properly then the result is software
failure. Business Needs should also be defined clearly in Software Requirements
documents.
o Deadlines are unrealistic.
This happens when the deadlines of software change unexpectedly. If not managed
properly, software fails.
o The project team lacks people with appropriate skills.
As we know that software engineers work on projects that do not belong to their domain.
So, when the software engineer could not understand the domain of the software
correctly, then it results in project failures. Even if succeeded, software includes lot of
bugs which are fixed time to time, and thus cost of software project increases.
o Miscommunication among Project members
Miscommunication among Project Staff also leads to software failures. When software
developers do not interact with each other to solve problems that they face, then the
software development usually takes more time then it should.
o Inadequate software Testing
In many cases software testing is left to users who are not able to fully exercise the
system. Regression testing is not performed at each release and functionality formerly
present in the software is not verified and can be lost.
o Frequent or large changes to project scope.
Scope changes can significantly impact the cost, schedule, risks and quality of the entire
effort. Software Project managers should watch out for early and frequent changes to the
software project scope.
o Risk Management
Risk management is an important factor towards software project failure if it's not
managed timely and effectively. As nothing can be predicted that what will happen in
future so we have to take the necessary steps in the present to take any uncertain situation
in the future. Risk management means dealing with a concern before it becomes a crisis.
Q No.2: Give the recommendation in order to avoid the failure.
Answer.
Starting on the right Path:
Lot of projects do not start on the right path, i.e. the objectives and the problem that is to be solve
is not stated clearly. For successful software projects, one should work hard to understand the
problem that is to be solved and then setting realistic objects and expectations for every one who
will be involved in the project. It can be reinforced by building the right team and giving the
team the autonomy, authority, and technology needed to do the job.
Maintain Momentum:
Lot of projects fails because of the fact that that the momentum does not remains the same in all
the stages of software development. To maintain momentum, the project manager must provide
incentives to keep turnover of personnel to an absolute minimum, the team should emphasize
quality in every task it performs, and senior management should do everything possible to stay
out of the team’s way.
Track Progress:
The manager should track progress of all the ongoing activities of software development. It not
only includes tracking the progress of software deliverables, source code, use case diagrams etc.
etc. but also requires for the software manager to keep track of the software developers, and
should try to remove the problems that are hindering the development of software.
 Assignment 2
You have the following scenario in which bank maintains their ATM information.

You are given three tables:

ATM_Acc (Table of ATM Card Account), Person (Table of the Person Detail),
Transactions_Details:

1. ATM_Acc: atmcardno, bankacc_no, person_id, pin_code, branch_name, branch_id,

security_question, issue_date, expiry_date, card_type, card_limit, multiple_transaction,
status_of_card.
2. Person: person_id, name, temp_addr, permanent_addr, phone_no, mobile_no,
father_name, date_of_birth, NIC.
3. Transaction_Details: amount, bankacc_no, date, branch, balance, atmcardno,

Note: ATM transaction can only be performed from the bank which issued the person ATM
card. You can consult the tables given in lecture slides (ppt slides for lecture # 11) to determine
the complexity of ILF, EIF, EI, EO, and EQ:

You should consider only the above given tables for the following operations being performed:

• Add a ATM card (with all its details)

• Delete the record of a ATM Card
• Update the record of the ATM card
• Add a new person (with all its details) in the system
• Do the transaction using ATM Card.
• Generate a report that shows the number of Transactions between two given dates.
• Issue an ATM card to the person.

Keeping in view the given scenario, you have to find the following:
 a) Identify the number of ILF and EIF in the system.
b) Determine the no. of RETs and DETs in the system.
c) Determine the complexity of ILFs and EIFs ?
d) Identify all the transaction operations (EI, EO, EQ) in the system.
e) Find the complexity of EI, EO, and EQ?
f) Determine the un-adjusted function point count of the given system.
Solution:
(a)

No. of ILF: 3
1. ATM_Acc
2. Person
3. Transactions_details

Reason:

For each entity Following question should be answered.

1. Is the group of data or control information is logical and user identifiable?
2. Is the group of data maintained through an elementary process within the application
boundary?

ATM_Acc:

1. Yes
2. Yes.

Person:

1. Yes
2. Yes

Transactions_details:

1. Yes.
2. Yes.

No. of EIF: 0

Reason: There is a condition for EIF that group of data is not maintained by the application
being counted? As this condition is not satisfied by any entity/ class so there is no EIF in the
system.
 (b)

No. of RETs:
1. ATM_Acc =1
2. Person = 1
3. Transactions_details = 1

No. of DETs: The DETs are the no. of attributes of a table

ATM_Acc <20
Person < 20
Transaction_details <20

(c)

Complexity of ILF and EIF:

The following table is given in lecture # 11 to determine the complexity of ILF and EIF:
Now by using the following table we can find the contribution of ILFs in FP count.
 ILF/EIF RETs DETs Complexity FP
Contribution
ATM_Acc 1 <19 Low 7
Person 1 <19 Low 7
Transactions_Details 1 <19 Low 7
Total FP Count 3*7=21

EIF: as no EIF has been identified in the system so EIF contribution in FP count will be zero.

So Total contribution of ILF and EIF in FP count is 21

(d)

Identification of EI, EO and EQ

Now we will identify the EI, EO and EQ with the help of following table.
Data Transaction
Use case File Maintained Calculation Performed
Presented Type
Add a ATM
Yes EI
card
Delete the
record of a
Yes EI
ATM Card

Update the
record of the
Yes EI
ATM card

Add a new
person (with
all its details) Yes EI
in the system

Do the
transaction
Yes Yes Yes. Balance is calculated EI
using the
ATM Card

Generate a
report that
shows the
number of Yes No No EQ
Transactions
between two
given dates

Issue an ATM
card to the
Yes No EI
person.

(e)

Complexity of EI, EO and EQ:

We can find the complexity of EI, EO and EQ with the help of the following tables:
 Use case Transaction type FTRs DETs Complexity
Add a ATM card EI ATM_Acc 5-15 Low
Delete the record
of a ATM Card EI ATM_Acc 5-15 Low

Update the record

of the ATM card EI ATM_Acc 5-15 Low

Add a new person

(with all its
details) in the EI Person 5-15 Low
system

Do the transaction
using the ATM EI Transaction_details 5-15 Low
Card
Generate a report
that shows the
number of
EQ Transaction_details 6-19 Low
Transactions
between two given
dates
Issue an ATM
card to the person. EI Person, ATM_Acc >16 High

Contribution of Transaction Functions

Function Type Complexity Multiplier Line Item Sub-Total Section Total

EI 5 Low x3= 15
0 Average x4= 0
1 High x6= 6 21

EQ 1 Low x3= 0
0 Average x4= 0
0 High x6= 0 3

EO 0 Low x4= 4
0 Average x5= 0
0 High x7= 0 0
 (f)

Total Unadjusted FP Count

• ILF: 21
• EIF: 0
• EI: 21
• EQ: 3
• EO: 0

Total: 45
 Assignment 3

What are the main functions performed by the automated estimation

tools? Describe each function briefly.
Answer.

Automated Estimation Tools:

Automated estimation tools are the tools that allow software planner to estimate cost and effort
and to perform "what-if" analyses for important project variables such as delivery date or
staffing. Although many automated estimation tools exist, all exhibit the same general
characteristics and all perform the following generic functions.

1. Sizing of project deliverables

Automated Estimation tools help to estimate “size” of the project deliverables that must be
constructed. The sizing specification of the software deliverables include source code, test
cases, function point metrics, lines of code (LOC) metrics, object-oriented metrics, analogy
with past projects, attributes such as screens and reports created etc. etc.

2. Selecting project activities

Once the size of various deliverables has been approximated the next step is to determine
which specific activities will be carried out for the project being estimated. This is one of the
major areas where software cost estimating tools excel. Modern cost estimating tools can
analyze the nature, size, and class of the application being estimated and automatically select
the most likely set of activities. Appropriate process framework is selected and the software
engineering task set is specified.

3. Predicting staffing levels

The number of people who will be available to do the work is specified. Because the
relationship between people available and work (predicted effort) is highly nonlinear, this is
an important input. The fundamental equation for determining staff is:

Size of deliverable / assignment scope = staff.

It is necessary to determine staffing levels not only for software engineers, but for a host of
other occupations such as quality assurance, technical writing, data base administration,
measurement and metrics, testing, configuration control, and many others.
4. Predicting software effort
The term “effort” defines the amount of human work associated with a project. The amount
of effort can be expressed in any desired metric, such as work hours, work days, work weeks,
work months, or work years. The fundamental equation for estimating effort is:

Size of deliverable / production rate = staff effort

5. Predicting software cost

The fundamental equation for estimating the cost of a software activity is simple in concept,
but very tricky in real life:

Effort * (salary + burden) = cost

The cost situation is made more difficult by several other factors that need to be considered:

Paid overtime for critical portions of rush projects

Inflation rates for long-range projects spanning several years

Currency exchange rates for international projects

Special fees or costs outside the burden rate

Determining the true cost structure of a software project is a very complicated piece of work.
The ranges of software costs are so broad that it is very hazardous to compare costs such as
“cost per function point” across industries or geographic areas.

6. Predicting software schedules

The fundamental equation for estimating the schedule of any given software development
activity is:

Effort / staff = time period

However in real life schedule estimating is one of the most difficult parts of the software
estimation process and many highly complex topics must be dealt with, such as:

Dependencies of one activity upon previous activities

Overlap or concurrency of activities

The critical path through the sequence of activities


Less than full-time availability of staff

Number of shifts worked per day

Number of effective work hours per shift

Paid or unpaid overtime applied to the activity

Interruptions such as travel, meetings, training, or illness

It is at this final point of determining software schedules that software cost estimating tools
and project management tools come together. The normal mode of operation is that the
software cost estimating tool will handle sizing, activity selection, effort estimation cost
estimation, and approximate scheduling by phase or activity.

7. Estimating Requirements Changes During Development

One important aspect of estimating is dealing with the rate at which requirements “creep”
and hence make projects grow larger during development. Fortunately, function point metrics
allow direct measurement of the rate at which this phenomenon occurs, since both the
original requirements and changed requirements will have function point counts.
 Assignment 4
Suppose you are a project manager of a company xyz. You have been asked to compute the
earned value analysis of a software project. The software project has 70 planned work tasks that
are estimated to require 620 person-days to complete. At the time you have been asked to do the
earned value analysis, 13 tasks have been completed. However, the project schedule indicates
that 16 tasks should have been completed. The following scheduling data in person-days are
available:

Task Planned Effort Actual Effort

1 11 10
2 8 9
3 5 4
4 13 13.5
5 11 11
6 15 16
7 8 10
8 7 7
9 10 9
10 12.5 13
11 6 5
12 3 5
13 10
14 5
15 6

You are required to compute the SPI, schedule variance, percent scheduled for completion,
percent complete, CPI, and cost variance for the project.
Solution:

Budgeted cost of work scheduled (BCWS)

The value of BCWS is the sum of the BCWS values for all work tasks that should have been
completed by that point in time on the project schedule.

11 + 8 + 5 + 13 + 11 + 15 + 8 + 7 + 10 + 12.5 + 6 + 3 + 10 + 5 + 6 = 130.5
Budgeted cost of work performed (BCWP):
The value for BCWP is the sum of the BCWS values for all work tasks that have actually been
completed by a point in time on the project schedule.

11 + 8 + 5 + 13 + 11 + 15 + 8 + 7 + 10 + 12.5 + 6 + 3 = 109.5

Budget at Completion
The BCWS values for all work tasks are summed to derive the budget at completion
620

Schedule performance index, SPI = BCWP/BCWS = 109.5/130.5 = 0.83

Schedule variance, SV = BCWP – BCWS = 109.5 - 130.5 = -21

Percent scheduled for completion = BCWS/BAC = 130.5/620 = 0.21

Percent complete = BCWP/BAC = 109.5/620 = 0.17

Actual Cost of Work Performed

The value for ACWP is the sum of the effort actually expended on work tasks that have been
completed by a point in time on the project schedule.

10 + 9 + 4 + 13.5 + 11 + 16 + 10 + 7 + 9 + 13 + 5 + 5 = 112.5

Cost performance index, CPI = BCWP/ACWP = 109.5/112.5 = 0.97

Cost variance, CV = BCWP – ACWP = 109.5 – 112.5 = -3

Negative cost variance suggests that more money was spent for the work accomplished than was
planned
 Assignment 5
Q.No.1: “software engineering is an umbrella activity” what do you understand by this term.
Explain in detail.
Answer.

Software engineering is the establishment and sound engineering principles applied to obtain
reliable and efficient software in an economical manner.
In Software Engineering, a software development project consists of two main categories
first is construction and second is management.
Construction activities are those that directly related to the development of software, e.g.
gathering the requirements of the software, develop design, implement and test the software etc.
Management activities are kind of umbrella activities that are used to smoothly and
successfully perform the construction activities. Here some Software Engineering Umbrella
Activities are given bellow:

Software project management: This umbrella is used to tracking and control overall progress
of the project.

Software quality assurance:

Quality assurance is an umbrella activity and it is applied throughout the software development
life cycle. As quality assurance is not the name of testing but it is applied throughout the life
cycle of the software development process. It is applied on the requirements phase, in the design
phase, in the coding phase, in the testing.

Software configuration management: It manages effects of changes which occurred during

the project development.

Installation and training:

Complete installation guide given to the users. And necessary training material is also provided
to the users when delivering application.
 • Project Planning and
Management
Management • Configuration Management
• Quality Assurance
• Installation and Training

Construction

• Requirements
• Design
• Coding
• Testing
• Maintenance

Management activities are kind of umbrella activities that surround the construction activities so
that the construction process may proceed smoothly. This fact is empathized in the Error!
Reference source not found.. The figure shows that construction is surrounded by management
activities. That is, certain processes and rules govern all construction activities. These processes
and rules are related to the management of the construction activities and not the construction
itself.

Q.No.2: Quality and reliability are related concepts but are fundamentally different in a number
of ways. Discuss them.
Answer.
Quality focuses on the software's conformance to explicit and implicit requirements. Reliability
focuses on the ability of software to function correctly as a function of time or some other
quantity. Safety considers the risks associated with failure of a computer-based system that is
controlled by software. In most cases an assessment of quality considers many factors that are
qualitative in nature. Assessment of reliability and to
some extent safety is more quantitative, relying on statistical models of past events that are
coupled with software characteristics in an attempt to predict future operation of a program.
 Assignment 6
Q.No.1. Assume that you're the manager of a small project. What baselines would you define for
the project and how would you control them?

Answer.

A baseline is a software configuration management concept that helps us to control change

without seriously impeding justifiable change.

The baselines that I will define for the project are as under:

 Schedule baseline
 Cost baseline
 Scope baseline
 Development baseline
 Source code
 Test cases
 Design specification
 System specification
 Software requirements

As a project manager, I will ensure that all the baselines are being met accordingly and the
software project is proceeding as desired. Software schedule will be monitored throughout the
software development, and in case of any deficiencies, appropriate solution will be figured out.
Cost is also a baseline for project. It can only be met in case the software requirements are easily
understood and are complete. Source code needs also be checked through the development
process and the bugs that are found will be fixed at appropriate time in order to deliver good
quality product to end users.

Q.No.2. What is the difference between an SCM audit and a formal technical review? Can their
function be folded into one review? What are the pros and cons?

Answer.

1st version of the answer:

SCM Audit:

A software configuration audit complements the formal technical review by assessing a

configuration object for characteristics that are generally not considered during review.

Formal Technical Review:

The formal technical review focuses on the technical correctness of the configuration object that
has been modified. The reviewers assess the SCI to determine consistency with other SCIs,
omissions, or potential side effects. A formal technical review is the most effective filter from a
quality assurance standpoint. Conducted by software engineers for software engineers, the FTR
is an effective means for improving software quality.

No, the functions of SCM Audit and Formal Technical Review cannot be folded into one review
because of the fact.

Formal Technical Reviews are used for improving software quality, whereas software
configuration management audit is usually used to answer the questions that are indirectly
related to software to achieve the desired quality. For example, we can perform formal technical
reviews for coding, testing, debugging etc, as these are directly related to the quality of the
software, however, for SCM Audit, we will answer the questions which are not directly related to
software quality rather indirectly. Some questions could be...

 Has the change specified in the ECO been made? Have any additional modifications been
incorporated?

 Has a formal technical review been conducted to assess technical correctness?

 Has the software process been followed and have software engineering standards been
properly applied?

 Has the change been "highlighted" in the SCI? Have the change date and change author
been specified? Do the attributes of the configuration object reflect the change?

 Have SCM procedures for noting the change, recording it, and reporting it been
followed?

 Have all related SCIs been properly updated?

Besides above, in some cases questions are asked as part of a formal technical review. However,
when SCM is a formal activity, the SCM audit is conducted separately by the quality assurance
group.

2nd version of the answer:

Configuration Audit ensures that the correct CI’s being incorporated into specific build and all
documentation is up – to – data and it may consistent with the version that has been built.
SCM Audit is conducted separately by the quality assurance group and it complements the
formal technical review by addressing the below questions.

 Has the change specified in the ECO been made? Have any additional modifications been
incorporated?

 Has a formal technical review been conducted to assess technical correctness?

 Has the software process been followed and have software engineering standards been
properly applied?

 Has the change been "highlighted" in the SCI? Have the change date and change author
been specified? Do the attributes of the configuration object reflect the change?

 Have SCM procedures for noting the change, recording it, and reporting it been
followed?

 Have all related SCIs been properly updated?

Whereas in formal technical reviews...

 Mainly this focuses on the technical correctness of the configuration object been
modified .

 Formal technical reviews access the CIs to determine consistency with other CIs,
omissions, or potential side effects.

Besides above, in some cases questions are asked as part of a formal technical review. However,
when SCM is a formal activity, the SCM audit is conducted separately by the quality assurance
group.

Benefits of SCM Audit:

 Reduces the effort required to manage and effect change -- improved productivity

 Leads to better software integrity and security -- increased quality

 Generates information about the process -- enhanced management control

 Maintains a software development database -- better record keeping and tracking