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.

Use case Data

Presented File Maintained Calculation Performed Transaction

Type

Add a ATM card

Yes EI

Delete the record of a ATM Card

Yes EI

Update the record of the ATM card

Yes EI

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

Yes EI

Do the transaction using the

ATM Card

Yes Yes Yes. Balance is calculated EI

Generate a report that shows the number of

Transactions between two given dates

Yes No No EQ

Issue an ATM card to the person.

Yes No EI

(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 system

EI Person 5-15 Low

Do the transaction using the ATM

Card EI Transaction_details 5-15 Low

Generate a report that shows the

number of Transactions

between two given dates

EQ Transaction_details 6-19 Low

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 x 3 = 15 0 Average x 4 = 0 1 High x 6 = 6 21 EQ 1 Low x 3 = 0 0 Average x 4 = 0 0 High x 6 = 0 3 EO 0 Low x 4 = 4 0 Average x 5 = 0 0 High x 7 = 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.

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.

Management

Construction

• Project Planning and Management

• Configuration Management • Quality Assurance • Installation and Training

• Requirements • Design • Coding • Testing • Maintenance

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