Biyani's Think Tank

Concept based notes

SPM
(B.Tech)

Vishakha Ashwani

Asst. Professor
Deptt. of Engineering
Biyani International Institute of Engineering and Technology

Published by :

Think Tanks
Biyani Group of Colleges

Concept & Copyright :

Biyani Shikshan Samiti

Sector-3, Vidhyadhar Nagar,
Jaipur-302 023 (Rajasthan)
Ph : 0141-2338371, 2338591-95 Fax : 0141-2338007
E-mail : [email protected]
Website :www.gurukpo.com; www.biyanicolleges.org

Edition : 2013
Price :
While every effort is taken to avoid errors or omissions in this Publication, any
mistake or omission that may have crept in is not intentional. It may be taken note of
that neither the publisher nor the author will be responsible for any damage or loss of
any kind arising to anyone in any manner on account of such errors and omissions.

Leaser Type Setted by :

Biyani College Printing Department

Preface

am glad to present this book, especially designed to serve the needs of the

students. The book has been written keeping in mind the general weakness in
understanding the fundamental concepts of the topics. The book is self-explanatory and
adopts the Teach Yourself style. It is based on question-answer pattern. The language of
book is quite easy and understandable based on scientific approach.
Any
further improvement in the contents of the book by making corrections, omission and
inclusion is keen to be achieved based on suggestions from the readers for which the author
shall be obliged.
I acknowledge special thanks to Mr. Rajeev Biyani, Chairman & Dr. Sanjay Biyani,
Director (Acad.) Biyani Group of Colleges, who are the backbones and main concept
provider and also have been constant source of motivation throughout this Endeavour. They
played an active role in coordinating the various stages of this Endeavour and spearheaded
the publishing work.
I look forward to receiving valuable suggestions from professors of various educational
institutions, other faculty members and students for improvement of the quality of the book.
The reader may feel free to send in their comments and suggestions to the under mentioned
address.
Note:

A feedback form is enclosed along with think tank. Kindly fill the feedback
form and submit it at the time of submitting to books of library, else NOC from
Library will not be given.

Author

Syllabus

Unit 1

Project Management
Q.1

What is Project Management? Explain Different Stages of a project.

Ans. Software project management is the art and science of planning and leading
software project. It is a sub discipline of project management in which software
project are planned, monitored and controlled.
PROJECT
A project is a temporary endeavour undertaken to create a unique product
service or result.
1. Every product has a beginning date and ending date.
2. The result of a project may b permanent.
3. it is executed by human beings.
4. it is headed by a project manager.
5 It should meet customer expectation.

Different Stages of a Project:

Every software project undergoes different stages before it gets closed.those
stages are project initiation, project planning ,project execution, project
monitoring and controlling and project closing.

THE PROJECT INITIATION PHASE is the first phase in the project management
life cycle,as it involves starting up a new project.we can start a new project by
defining its objective,scope,purpose and deliverables to be produced . well also
hire team, setup, the project office and review the project, to gain approval to
begin the next phase

THE PROJECT PLANNING PHASE is the second phase in the project life cycle.it
involves creating of a set of plans to help guide our team through the execution
and closure phase of the project. The plans created during this phase will help us
to manage time, cost, quality, change, risk and issues

THE PROJECT EXECUTION PHASE is the third phase in the project life cycle. In
this phase we will build the physical project and present them to our customer
for sign off.

THE PROJECT CONTROLLING AND MONITORING PHASE is the 4th phase.

These process help us to manage time , cost, quality, change, risk and issues.

THE PROJECT CLOSURE PHASE is the 5th phase. We will formally close our
project and then report its overall level of success to our sponcer.

There are many definitions of project management:

1.

Is the application of knowledge , skills and experience in meeting

customer requirement.

2.

It is about planning, directing, organising, controlling and executing the

project.

Q.2

Explain Management Spectrum?

Ans. Effective s/w project management focuses on the 4 Ps:

1. THE PEOPLE
The people are critical to software development and maintenance. People
connected directly or indirectly are the dynamic and live factor .The success of

the software project largely depend upon hoe leading role players in project
management handle people issues, concerns and their expectation while
developing the software for a given requirement.
People from within the organisation are developers , analyst, designers,
technology,

specialist, HR manager and the senior management. People from

outside the org. largely belongs to the customer org. and are known as primary
users , secondary users, stack holders, product coordinators, business manager.
The people resources falls into 5 categories; manager ,technocrat, developer,
customer and users.

THE PLAYERS :
The software process is populated by players, they are categorized into one of
five constituencies;
1.
2.
3.
4.
5.

Senior managers who define the business issues that often have significant
influence on the project.
Project managers who plan, motivate , organize and control the practitioners
who do software work.
Practitioners who deliver the technical skills that are necessary for an
engineer to develop a product or application.
Customers who specify the requirements for the software to be engineered
and other stake holders who have a peripheral interest in the outcome.
End users who interact with the software once it is released for production
use.

THE PRODUCT:
The product in the context of software , is the scope of the scope of the software
that is proposed to solve the requirements of the user.

CONTEXT: The scenario or situation in business which has problems and which
need solutions within the given domain. And with regard to constraints and
limitation prevailing in the environment.

OBJECTIVE: Software system objective in terms of info.,analysis, report etc,. is

the required output for the benefit of users to solve business problem.

FUNCTION: software system process and function such as data sources and
processing, info processing and analysis, transaction process are the key features
in order to achieve software product goal.

PERFOMANCE: This stipulate non functional requirement of speed , quality

and features such as ease of use adoptability , interoperability, achiving certain
measurable objective such as cost reduction, reduction in cycle time.

THE PROCESS: process has become the most discussed aspect of the 4ps.
Process is imp. Because it leads people build product .Iteration in a project shows
the nature of a product and its users. Process gives management a channel of
influence on software development and maintenance. The genri phases that
characterize the software process
The linear sequential model
The prortotyping model
The rad model
The incremental model
The spiral model
The WINWIN model

THE PROJECT:
When the software project is finalized with details such as context, objectives,
function, and performance. Since an org would have a number of software
development process. A project is defined as an activity that has a definite start
and a definite end, requires multiple resources and is full of uncertainities on a
number of counts.

A five parts common sense approach to software projects;

1. Start on the right foot; This is accomplished by working hard to understand
the problem that is to be solved and then setting realistic objects and
expectation for everyone who will be involved in the project.
2. Maintain Momentum: Many project get off to a good start and then slowly
disintegrate .To maintain momentum the project manager must provide
permomance.
3. Track progress: For a software project , progress is tracked as worked
products. A produced and approved as a part of a quality assurance activity.
4. Make a smart decision: The decision should be to keep it simple. Whenever
possible decide to use commercial of the shell software or existing software
components etc.
5. Conduct a post-mortem analysis:Establishes a consistent mechanism for
extracting lessons learnt from each product.
Q.3

What do you understand by W5hh principle ?

Ans- Bary boehm states: You

need an organising principle that scales down to

provide simple project plans for simple projects

Boehm suggests an approach that addresses project objectives , milestones and
schedules, responsibilities, management and technical approaches and required
resources.
He calls after a series of question that lead to a definition of key project
chahracteristics and the resultant project plan:
The question that are answered in this principle are:

Q.4

Why is the system being developed?

Ans

The answer to the question enables all parties to assess the validity of bisoness
reasons for the software work. Stated in another way, does the business purpose
justify the expenditurem of people , time, and money?

Q.5

What will be done?

Ans

The answer to these question help the team to establish a project schedule by
identifying key project tasks and the milestone that are required by the customer.

Q.6

When will it be done?

Ans

It helps to determine the project schedule. It helps in determining whwn task are
conducted and when milestone are reached.

Q.7

Who is responsible for a function ?

Ans

Earlier in the project we noted that the role and responsibility of each member of
a software team must be defined.

Q.8

Where they are organizationally located?

Ans

Not all roles and responsibilities reside within the software team itself .the
customer users, and other stake holders also have responsibilties.

Q.9

How will the job be done technically and managerially?

Ans

Once product scope is established , a management and technical strategies for the
project must be defined.

Q.10 How much of each resource is needed?

Ans

Answer is derived by developing estimatesbased on answers to earlier questions.

Q.11

Compute the function pointvalue for a project with the following information
domain characteristics.
Number of user input=32
Number of user output=60
Number of user enquiries=24

Number of files=8
Number of ext. interfaces=2
Assuming the weighing factor values are average. The various complexity
adjustment values are average.
Sol:

Function point= count_total[0.65+0.01* (fi)]

Fi=complexity adjustment values for i= (1 to 14)

As various complexity adjustment values are avg. then all Fis=3

F1=F2=F3=..=F14=3
(fi)=14*3=42
CAF=0.65+(0.01*42)
=1.07
s. no.

Measurement

Count

Weighing

parameter
1

Number

Total

factor
of

user 32

128

of

user 60

300

of

user 24

96

10

80

14

input
2

Number
output

Number
enquiries

Number of files

Number

of

8
ext. 2

interfaces
6

Count total

618

Function point=618*1.07
=661n

Q.12 Explain project matrics?

Ans. It is used by a project manager to control the project in terms of project cost,time
and effort through management of skills, customaer relation, technology of
development and software solution design.
1. Function point
It indicates the indirect measure if functionality and the complexity delivered by
the software. It can be useb effectivelyas a means of measuring the functionality
delivered by the system.
-

estimate the cost or effort req. to design, code and test the software

predict the no. or errors that will be encountered during testing.

forecast the no. of components and the no. of projected source lines in the
implemented system.

2. Line of code
It is a measure f the length of code the software engg. Will write to deliver
software req. there is a relationship between the lines of code and function point
depend upon the programming lang. and quality of design.

3.Process matrics
It is used to measure the overall progress of the project.It may also lead to
software processimprovement.
-

some specific attributes of the process are measured.

Then these attributes will develop the various matrics.
After executing these matrics indicators will be provided.
Then these indicators will improve the process

Unit 2

Estimation
Q.1

Explain Software-Project Estimation?

Ans

Software-Project Estimation is the process of estimating various

resources

required for the completion of a period. Effective Software-Project estimation

is an important activity in any

Software development Project.

Underestimating software projects and

understaffing it often leads to low-

quality deliverable, and the project misses the target deadline leading to
customer dissatisfaction and loss of credibility of the company. On the other
hand, Overstaffing a project without proper control will increase the cost of
the project and reduce the competitiveness of the company.

Fig:- Software-Project estimation

Software project estimation mainly encompasses the following steps:

 Estimating Size:- Estimating the size of the software to be developed is

the very first step to make an effective estimation of the project. Customer
requirements and system specification from a baseline for estimating the
size of a software. Syem design documents can provide additional details
for estimating the overall size of the software.
1.
The ways to estimate project size can be through past data from an earlier
development system. This is called estimation by analogy.
2.
The other way of estimation is through product feature/functionality. The
system is divided into several subsystems depending on functionality,
and the size of each subsystem is calculated.
Estimating Effort:- The estimation of effort can be made from the
organization specifies of Software-development life-cycle. The estimation
of effort for a project will vary.
Efforts are estimated in the number of person-months.
1. The best way to estimate effort is based on the organization's own
historical data of development processes.
2. If the project is of a different nature, which requires the organization to
adopt a different strategy for development, then different models based
on algorithmic approaches can be devised to estimate the required effort.

Efforts
Hardware Cost
Travel expense

Cost
estimation

Training Cost
Comunication Costs and other cost factors

Cost Estimation Process

Project Cost

Fig:- Project-estimation process

There is always some uncertainly associated with all estimation techniques. The
accuracy of project estimation will depend on the following:
Accuracy of historical data used to project the estimation.
Accuracy of input data to various estimates.
Maturity of an organization's software-development process.
Reasons for Poor Estimations are:

Requirements are imprecise. Also, requirements change frequently.

The project is new and is difficult from past projects handled.
Non-availability of enough information about past projects.
Estimates are forced to be based on available resources.
Cost and time trade-offs

Project-Estimation guidelines are: Preserve and document data pertaining to past projects.
Allow sufficient time for project estimation especially for bigger projects
Prepare realistic development-based estimates. Associate people who will
work on the project to reach a realistic and more accurate estimate.

 Use Software-estimation tools

Re-estimation the project during the life-cycle of the development process.
Analyze past mistakes in the estimation of projects.
Q.2

Short notes on
1.Resources
2.Software scope

Ans
Resources:Resources are the important and major factor of the software development.
They are required

to be estimated while accomplishing the software

development effort. They can be in the form of hardware facilities, users,

software data, information specialist, money etc. But the main three types of
resources are:
Human Resources
Reusable software components
Hardware /software tools

Fig:- Project Resources

There are four characteristics mentioned which are involved in all types of
resources:Description of the resource.
A statement of availability.
Time when the resources will be required
The total time duration for which the resources will be applied.

1. HUMAN RESOURCES:
Human Resources are considered as the primary resource among all types of
resources. It is the major resource, so the project planner concentrate more on this
factor. The project planner has to select the persons required for the software
project, so he starts with the evaluation of scope and select the skilled,
experience, knowledgeable persons to complete software development. For small
project, less number of people are required where as for large projects, a large
team is required to complete the project.

2. REUSABLE SOFTWARE RESOURCES:

The computer-based systems and projects make use of the reusability, that is the
creation and reuse of software building blocks called components. There are 4
types of components: Off-the-shelf components: These are the existing software that either has
been project.
Full-Experience components: These are the existing components that were
already some parts of some existing past projects. These components may be
specification, design, code or test data.
Partial Components: These are the existing ones that are related to the
software to be built for the new project but require some modifications
New components: These are the ones which must be completely built by the
team for a software project.

Table:- Comparison among various components

Factors

Off-the-shelf
component

Risk
Cost
Required
modification

Low
Low
No

Fullexperience
component
acceptable
Low
Low

Partial
experience
components
high
High
high

New
components
Very high
high
New one is
built

3. HARDWARE/SOFTWARE TOOLS:
Hardware/software tools are also called as the environmental resources.
Such tools are basically related to the internal and external environments
of the software.
1. Hardware

Resources:

Hardware

resources

is

tool

for

software

development. Three hardware tools categories should be considered during

software project planning:
The development system
The target machine
Other hardware elements
2. Software Resources: Past software can be used to aid in the development of
new software. The earliest application in software development was boot
strapping. Tools used in software resources are Computer-Aided-Design and
Computer-Aided-Engineering(CAD/CAE) tools

Software scope:Project scope is the part of project planning that involves determining and
documenting a list of specific project goals, deliverable, tasks, costs and
deadlines.
The documentation of a project's scope, which is called a scope statement, terms of
reference or statement of work, explains the boundaries of the project, establishes

responsibilities for each team member and sets up procedures for how completed
work will be verified and approved. During the project, this documentation
helps the project team remain focused and on task. The scope statement also
provides the project team with guidelines for making decisions about change
requests during the project.
It is natural for parts of a large project to change along the way, so the better the
project

has been "scoped" at the beginning, the better the project team will be

able to manage change. When documenting a project's scope, stakeholders

should be as specific as possible in order to avoid scope creep, a situation in
which one or more parts of a project ends up requiring more work, time or effort
because of poor planning or miscommunication.
Effective scope management requires good communication to ensure that
everyone on the team understands the scope of the project and agrees upon
exactly how the project's goals will be met. As part of project scope management,
the team leader should solicit approvals and sign-offs from the various
stakeholders as the project proceeds, ensuring that the finished project, as
proposed, meets everyone's needs.

Fig:- Project Scope

Q.3

Explain project planning process?

Ans

Software project planning is ongoing process that sets the goals for the

whole

organization. It also define how these goals can be achieved. It also set
priorities. Pritiorizing includes determining what share of an organizations
resources, including funds and people, will be used to develop new and reengineer existing information systems.
As the result of software of project planning, a plan must be made. A plan is an
often a complex

document that specifies the relationships between an

organizations business units, its relationship to its stakeholders and

environment. The must:

Set objectives or a mission for the organization,

Be futuristic and project a vision of the organization in the future,
Look outside the organization,
Consider the organization as a whole and not just its component parts,
Identify opportunities, for organization match them to what it does now and
see how it can make the most of these opportunities.

A good project plan includes the following items:

1. Project scope.
2. Project Schedule.
3. Project Team Organization.
4. Technical Description of the proposed System.
5. Project standards, procedures and Proposed Techniques and tools.
6. Quality Assurance Plan.
7. Configuration Management Plan.
8. Documentation Plan.
9. Data Management Plan.
10. Resource Management Plan
11. Test plan.
12. Security Plan.
13. Risk Management Plan.
14. Maintenance Plan.

Q.4

Explain COCOMO -1 in detail?

Ans

Constructive Cost Model (COCOMO) was proposed by B.W.Boehm in 1981.He

introduced a hierarchy of software estimation models named as COCOMO. The
projects estimation ranges from the simple, general applications to complex realtime applications, thats why the constant values used in the equations to
estimate Person-Months(PM) and Development Time(DT) may be applied to a
variety of different software products and development environments.
The COCOMO81 model is a static model for which Boehm described the three
modes based on the development complexity which are one of the most
important factors contributing to a project cost and time.
1. Organic Mode: Is considered for the application programs. To develop such
project, the development team is usually small.
2. Semidetached Mode: Such type of development mode, is used for developing
utility programs. The projects characteristics is intermediate between the
organic and embedded.
3. Embedded Mode:This mode is related to the system programs. The
development team size is large and have less experience.
Boehm hierarchy of models take the following form:
Model 1: Basic COCOMO Model
Model 2: Intermediate COCOMO Model
Model 3: Detailed COCOMO Model
1). Basic COCOMO Model:
This model is a static variable model. This model uses LOC as for the size
estimation. The effort, cost and development time to develop an application can
be calculated as:
Effort(E)= ab(KLOC)bb
DevT(D)= cb(Effort)db
Number of people=Efforto/DevTo

Where, E is the effort applied in person-months(PM), D is the development

months, KLOC is the estimated numbers of thousands of line of code for the
project and

ab,bb,cb,db.

The various constant values are given in the following table 2.1 for the three
previously mentioned:
Software Project
Organic
Semi detached
Embedded

ab
2.4
3.0
3.6

bb
1.05
1.12
1.20

cb
2.5
2.5
2.5

db
0.38
0.35
0.32

Table: Constant value of various software projects

2). Intermediate COCOMO Model:
This model is multivariable static model. There are major 4 categories in which
all the15cost drivers are divided:
1. Product Attributes:
RELY
DATA
CPLX
2. Computer Attributes:
TIME
STOR
VIRT
TURN
3. Personal Attributes
ACAP
AEXP
PCAP
VEXP
LEXP
4. Project Attributes
MODP
TOOL
SCHED

Initial Effort(Ei)=a* (KLOC)b PM

Final Effort Estimate(E)= EAF*Ei
The overall effect of cost driver attributes in computed as the product of the
values of each of the cost driver attributes. That is:
C=C1*C2*...........*C15
where, Ci is the value of the ith cost driver attributes for 1 to 15
Development Time(D): c* (E)d
Where c and d are constants.

Table: Effort and time constant values

System
Organic
Semidetached
Embedded

A
3.2
3.0
2.8

b
1.05
1.12
1.20

c
2.5
2.5
2.5

d
0.38
0.35
0.32

3) Detailed COCOMO Model:

The third COCOMO 81 model is the detailed model and is the most refined and
complex model of the three basic COCOMO models. This model is based on the
fact that different cost drivers have different impact on the phases of a project. It
also uses the product hierarchy of a project to refine the estimation.
The cost drivers used in the model are:
1.

CPLX, PCAP, VEXP, LEXP at the module level.

2.

VIRT, ACAP, AEXP, MODP, TOOL, RELY, DATA, TIME, STOR, TURN
at the subsystem level.

3.

SCED at the system level.

So, the cost drivers applicable in the model, somewhat different from the
intermediate one. The phase wise effort distribution percentages for the
three project development modes are given.

Table: Phase wise distribution of efforts in organic mode

Phase

Requirements
Design
Code and unit
test
Integration and
system test

Small 2
KLOC
5.7
15.1
64.2

Project size(organic mode)

Intermediate Medium 32
8 KLOC
KLOC
5.7
5.7
15.1
15.1
61.3
58.5

Large 128
KLOC
5.7
15.1
55.7

15.1

17.9

23.6

20.8

Table: phase wise distribution of efforts in semidetached mode

Phase

Requirements
Design
Code and
unit test
Integration
and system
test

Small 2
KLOC

Project size(Semidetached mode)

Intermediate
Medium 32 Large 128
8 KLOC
KLOC
KLOC

6.5
15.9
59.8

6.5
15.9
57

6.5
15.9
54.2

6.5
15.9
51.4

Very
large(over
128
KLOC)
6.5
15.9
48.6

17.8

20.6

23.4

26.2

29.0

Table: phase wise distribution of efforts in embedded mode

Phase
Small 2
KLOC
Requirements 7.4
Design
16.7

Project size(Embedded mode)

Intermediate
Medium 32 Large 128
8 KLOC
KLOC
KLOC
7.4
16.7

7.4
16.7

7.4
16.7

Very
large(over
128
KLOC)
7.4
16.7

Code and
unit test
Integration
and system
test

55.6

52.8

50.0

47.2

44.41

20.4

23.1

25.9

28.7

31.5

Q.5

Explain Software Effort Estimation approaches?

Ans

Barry Boehm, in his classic work on software effort models, identified the main
ways of deriving estimates of software development efforts as:
algorithmic models, which use 'effort drivers' representing characteristics of
the target system and the implementation environment to predict effort.
expert judgment, based on the advice of knowledgeable staff.
analogy, where a similar, completed, project is identified and its actual effort is
used as the basic of the estimate.
Parkinson, where the staff effort available to do a project becomes the
'estimate'.
price to win, where the 'estimate is a figure that seems sufficiently low to win a
contract.
top-down, where an overall estimates for the whole project is broken down
into the effort required for component tasks
Bottom-up, where component tasks are identified and sized and these
individual estimates are aggregated.
Clearly, the 'Parkinson' method is not really an effort prediction method, but
a method of setting the scope of a project. Similarly, 'price to win' is

a way

of identifying a price and not a prediction.We will now look at some of these
techniques more closely. First we will examine the difference between top-down
and bottom-up estimating.
1. Bottom-up Estimating: with the bottom-up approach the estimator breaks the
project into its component tasks with a large project, the process of breaking it
down into tasks is iterative: each task is decomposed into its component
subtask and these in turn could be further analyzed. It is suggested that this
is repeated until you get tasks an individual could do in a week or two. The

bottom-up part comes in adding up the calculated effort for each activity to
get an overall estimate.
The bottom-up approach is best at the later, more detailed, stages of project
planning.
A procedural code-oriented approach:
we describe how a bottom-up approach can be used at a level of software
components.
Envisage the number and type of software modules in the final system.
Estimate the SLOC of each identified module.
Estimate the work content, taking into account complexity and technical
difficulty
calculate the work-days effort
2. Top-Down Approach and parametric models:
The top-down approach is normally associated with parametric models.
These may be explained using the analogy of estimating the cost of
rebuilding a house. This is of practical concern to house-owners who need
insurance cover to rebuilt their property if destroyed. Unless the houseowner is in the building trade he is unlikely to be able to calculated the
numbers of bricklayer-hours, carpenter-hours, electrical-hours and so on,
required. Insurance companies, however, produce convenient tables
where the house- owner can find estimates of rebuilding cost based on
such parameters as the number of storeys and the floor space of the house.
A parametric model will normally have one or more formulae in the form
effort =(system size ) *(productivity rate)
A model to forecast software development effort therefore has two key
components . The first is a method of assessing the amount of the work
needed. The second assesses the rate of work at which the task can be
done.
If you have figures for the effort expended on past project(in work-days
for instance)and also the system size in KLOC,you should be able to work
out a productivity rate as

productivity = effort/size
A more sophisticated way of doing this work be by using the statistical
technique least square regression to derive an equation in the form:
effort=constant1+(size*constant2)
The top-down and bottom-up approaches are not mutually exclusive .
Project managers will probably try to get a number of different
estimate from different people using different methods .Some part of an
overall estimate could be derived using a top -down approach
while
other parts could be calculate using a bottom-up method.
3.

Expert judgment
This is asking for an estimate of task effort someone who is
knowledgeable
about either the application or the development
environment .This method is often used when estimating the effort
needed to change an existing pieces of software .The estimator would
have to examine the existing code in order to judge the proportion of code
affected and from the derive an estimate . Someone already familiar with
the software would be in the best position to do this.
Some have suggested that expert judgment is simply a matter of guessing
,but our own research has shown that expert tend to use a combination of
an informal analogy approach where similar projects from the past are
identified ,supplemented by bottom-up estimating.

Unit 3

Project Scheduling
Q. 1

Describe tasks set and task network and their use with examples.

Ans. Task set:

The task set is the collection of software engineering work task, milestones,
work products and quality assurance filters that must be accomplished to
complete a particular project. The task set must provide enough

discipline to

achieve high software quality.

To develop a project schedule, a task set must be distributed on the
project time line. The task set will vary depending upon the project type and
degree of rigor with which the software team decides to do its work.
Software organization encounters the following project.

Concept Development Project: projects are initiated to explore some new

business concept or application of some new technology.
New Application Development Projects: these projects are undertaken as a
consequence of a specific customer request.
Application Enhancement Projects: these projects occurs when existing software
undergoes major modification to function, performance or interface that are
observable by the end user.
Application Maintenance Project: The project that correct, adapt or extend
existing software in ways that may not be immediately obvious to the end-user.
Re-engineering Projects: these projects are undertaken with the intent of
rebuilding an existing system in whole or in part.

Task Network:
A task network is also called activity network, is a graphic
representation of the task flow of a project. It depicts the major software
engineering task from the selected process model arranged sequentially or in

parallel. The concurrent nature of software engineering activity leads to no. of

important scheduling requirements. Because parallel occur a synchronously.
For it we take an example of developing a software library information system.
The scheduling of this system must account for the following requirements.

Henry L. Gantt gives the basis Gantt chart. Gantt chart is an easy way to
document schedules; it is a horizontal bar schedule showing activity start,
duration and completion.

It shows the connection between events and the calendar and provides a
graphical analog of the activity duration.

Q.2

What is project scheduling and basic principle and relationship between

people and effort?

Ans: Project Scheduling: - Project scheduling means it related to scheduling process,

has been defined by the project Management Body of Knowledge as the
identification of the project objectives and the ordered activity necessary to

complete the project including the identification of resource types and quantities
required to carry out each activity or task.
Pharhaps you identified the following tasks needed to complete the assignment:
1.
2.
3.
4.
5.
6.
7.
8.

Identify topic
Research topic
Write first draft of paper
Edit and rewrite paper
Prepare class presentation
Complete final draft
Complete presentation
Hand in paper and present topic in class

Basic Principles of Project Scheduling:

Following are the basic principle based upon which the project scheduling is
done:

Compartmentalization: The product and process must be decomposed into a

manageable number of activities and tasks.
Interdependency: Tasks that can be completed in parallel must be separated
from those that must complete serially.
Time allocation: every task has start and completion dates that take the task
interdependencies into account.
Effort validation: Project manager must ensure that on any given day there is
enough staff members assigned to complete the task s within the time
estimated in the project plan.
Defined Responsibilities: Every Scheduled needs to have to be assigned to a
specific team member.
Defined Outcome: Every task in the schedule needs to have a defined
outcome (usually a work product or deliverable)
Defined milestones: A milestone is accomplished when one or more work
products from an engineering task have passed quality review.

Relationship between People and Effort:People work relationship are defined

to analyze that how much work is performed by the project members. As in a
small level project , a single person can analyze all the phases of software life
cycle like- analysis, design, code and test.
The software equation demonstrates the effort applied to the project. The number
of delivered lines of code L, is related to effort and development time by the
equation.
L + P * E1/3 T4/3
E development effort in person- month
p- Productivity parameter
E = L3 / P3 T4
Unit 4
Q.3

Explain various quality attributes of quality management.

Ans

SQA Tasks:- Software quality assurance is composed of a variety of tasks

associated with two different constituencies- the software engineers who do
technical work and an SQA group that has responsibility for quality assurance
planning, oversight, record keeping, analysis and reporting.
Prepares an SQA plan for a project: - The plan is developed as part of project
planning and is reviewed by all stakeholders. Quality assurance action
performed by the software engineering team and the SQA group are governed
by the plan.
Participates in the development of the projects software process description:The software team selects a process for the work to be performed. The SQA
group reviews the process description for compliance with organizational policy,
internal software standards, externally imposed standards and other parts of the
software project plan.

Reviews software engineering activities to verify compliance with the defined

software process: - The SQA group identifies, documents, and tracks deviations
from the process and verifies that corrections have been made.
Audits designated software work products to verify compliance with those
defind as part of the software process:-The SQA group reviews selected work
products; identifies; documents and tracks deviation; verifies the correction have
been made and periodically reports the results of its work to the project manager.
Ensures that deviation in software work and work products are documented
and handled according to a documented procedure: - Deviation may be
encountered in the project plan, process description, applicable standards, or
software engineering work products.
Records

and

noncompliance

and

report

to

senior

management:

Noncompliance items are tracted until they are resolved.

Q.2

Write a short notes on following:(a)Mc calls quality model

Ans : - Mc calls quality model:- In the 1990, there was a well publicized focus on
process modeling and process improvement in software engineering Inspried by
the work of deming and juran and implemented by companies such as IBM,
process guidelines such as the Capability Maturity Model, ISO 9000, and
Software process Improvement and Capability Determintion suggested that by
improving the software development process we can improve the quality of the
resulting products

McCalls Software quality Modal

Correctness

Traceability
Completeness

Reliability

Consistency
Accuracy

Efficiency

Error Tolerance
Execution Efficiency

Integrity
Usability

Storage Efficiency
Access Control
Access Audit

Maintainability

Operability
Training

Testability
Flexibility

Communicativeness
Simplicity
Conciseness

Portability

Interoperability

Instrumentation
Self- Descriptiveness
Expandability
Generality
Modularity

Reusability

Software

System

Independence
Machine Independence
Communications
Commonality
Data Commonality

Q.3

What are the key functions of configuration management? Give the schematic
of changes to software components and reasons for making changes to
software.

Ans:

The first requirement for the SCM process is the identification of objects in
software configuration. When a change is done, it should be clear to what the
change has been applied.
To control and manage SCIs, the concept of object- oriented approach is used. As
in an object- oriented approach, first the object are identified, then their attributes
and relationships are defined. Similarly in SCM, first we identify the various
objects by providing them unique names, and then define their related attributes
and relationships with each other. Objects, attributes and relationship in SCM are
discussed below:

1.

Identify Objects
There are basically two types of objects:

a) Basic Object: A basic object is a unit of text that has been created by a software
engineer during analysis, designs, code or test.
For Example, Requirement Specification, A Suite of Test Cases etc.
b) Aggregate Object: An aggregate object is collection of basic object and other
aggregate object. So, the concept of an aggregate object shows a mechanism for
representing a complete version of a software configuration.
For Example, Design Specification is an aggregate object because it has a named
list of pointers which points to the Data Model and Component N. But if we see
the basic object- Data Model, it doesnt have any such type of pointer to any
other object.

2. Define Attributes of Each Identified Object

After identifying all the objects, next we must define various attribute of each
of the identified object. There are lists of attribute that identify each object

uniquely. Each object must have all the four attributes. These attributes are
mentioned below, as:

(a) A Name: Each object must have a unique name, so that it can be identified
uniquely, where, the name of the object is a sequence of character, i.e., a string
name. So, no duplicate name must be provided to identify more than one
object.
(b) A Description: Each object should be described in well manner. The object
description consists of a list of data items. These data items identify.

The SCI type represented by the object.

A project identifier

Change information and version information

(c) A List of Resource: Another defined number attribute of the object is a list of
resources. A resource is an entity that is provide, referenced or otherwise
required by the object.

(d) A Realization: A last attribute to be defined for an object is realization. The

realization is defined either as a null or pointer. For a basic object <pointer
point to the unit of text, for an aggregate object, it is null.
3. Define Relationship Among Identified Objects: After identified the entire
object and identifying their attribute, next step to be followed is to define
relationship among the various object. There are two type of relationship,
which we have
(a) Part-Of: As we have already discussed that such type of relationship exist
when one SCI became the part of any other SCI. So, an object can be
identified as <part - of> can define a hierarchy of object.
For Example, we can define <par-of> relationship as:

Data Model <part-of> Design Specification

(b) Interrelationship: In such type of relationship, object is interrelated across
branches of the object hierarchy. They are interrelated using doubleheaded arrows, i.i., on both sides.

For Example, consider where

Design specification < interrelated > Test specification
To represent the interrelationship among object, a language is generally used,
i.e., Module Interconnection Language (MIL). MIL describes the
interdependencies among configuration object and also enable any
version of a system to be constructed automatically.
Q.

Give the schematic of defect prevention process with details explanation.

Ans.

Defect Prevention Planning:

Defect Prevention Planning is one of the major
goals of the software development process.

Defect prevention is used to deliver a high quality production. While there are
many aspects of quality, the single most critical aspect is defect.
Defective software causes intense customer dissatisfaction; increase the cost of
delivery to astronomical levels because of rework for fixing the defect.
It also increases the effort and the elapsed time uncertain.
Defect prevention process is to improve quality and productivity.

In the process area defect prevention, defect encountered in the past are analyzed
and the most frequent, the most troublesome and the most time consuming
defects are identified and specific action are defined to prevent the same defects
from occurring in the future.
1.
Goals:
The goal of this process is to plan defect preventive activity and
implement them so to identify common causes of defects and
systematically eliminate them on a priority basis.
2.
Activities:

The plan should identify the activity, schedule, allocate resource and
assign responsibilities. Casual analysis meeting are held as postmortem
after every major software activity to identify the root causes
of the
most commonly breakdown of communication defects and to classify
them into categories. Proposed actions as a result of casual analysis are
identification and documented. Teams are formed to implement the
proposed defect prevention activities and their program is tracked. Then
integrated and impact of defect prevention activity are maintained and
analyzed.
3.

Ability to Perform:
An organization level team should be interested the task of continuously
initiation and coordinating defect prevention activities. Defect
prevention activity should be provided with adequate resource and
funding and members of the engineering group should be adequately
trained.

4.

Commitment to Perform:
The organization should have written policy that specifies that the
activity for defect prevention shall be followed by every project.

5.

Measurement and Analysis:

The organization team measure and analysis the defect injected, the
change in cost of quality, productivity etc.

6.

Implementation:
The defect prevention activities are reviewed by the senior management,
the projects manage, and the quality assurance group on a periodic basis
and on event driven basis.

Unit 5

Project Execution and Closure

Q.1

Write short note on NAH syndrome?

Ans

Despite considerable evidence to show that inspection or review can help to

reduced cost and improve quality, reviews are not widely deployed in the
software industry. One of the reason for this is 'not applicable here (NAH)
Syndrome':

Developers and managers believe that in their environment reviews will not
provide the benefits seen by other organizations.

When human effort is the most critical resource in a project, it is not easy for
them to accept the position that the highly manpower intensive review process
can make the overall process more productive and improve quality.

As a result, it is very difficult to convince people to use reviews if inspections are

to be deployed in a project, the NAH Syndrome must be to overcome with
solution.

Q.2

Explain the role of tracking in project monitoring with their types in detail?

Ans

There are two key aspects of project monitoring:

Project manager must have visibility into true status o f a project, for which the
best approach is to quantitively measure the key parameters.

Second, the visibility by itself does not solve any problem, if they find that the
project is not moving along the planned path, they must apply the proper
corrective actions to bring it back on the track.

There are 4 types of tracking:

Project tracking: It is the process by which the project progress is measured,
working with the WBS and the key sage Gantt Chart to show the real status of
project ensuring that:

The work is carried out in the right order.

Planned performance is maintained.

Changes to plan caused by problems or the customer are promptly acted

upon.

Activity Tracking: Activity tracking is an important first step in goal setting and
time management because it ses benchmarks for evaluating our progress. It lets
us see where the valuable time is being spent and gives the data needed to set
goal.
Defect tracking: Many companies uses a defect control system for tracking
defects. It remain open until it has been fixed. The defect is marked as closed
when its removal has been verified. Each defect is closed and track to closure.
Issue tracking: Many small jobs come up during a project. These problems are
called issues. Managing issues is an important task for any project manager
because they can be potentially delay a project. Issues are recorded as they arise
,along with related information. When these issues are closed they marked as
closed.
Q.3
Ans

What is closure analysis? How closure analysis is performed? Explain.

Project closure analysis is the key to learning from he past so as to provide future
improvements. To achieve this goal, it must be done carefully in an atmosphere

of safety so that lessons can be captured and used to improve the project and
future projects.
The objective of closure analysis is to determine what went right, what went
wrong, what worked, what did not, how it could be made better the next time.
The closure analysis are used to populate the process database. The process
database is repository of a process performance data from projects, which can
be used for project planning, estimation, analysis of productivity quality, and
other purpose.

PERFORMING CLOSURE ANALYSIS:

The closure analysis is carried out by the quality advisor from the SEPG
associated with project. The template for analysis report is used. The person
carrying out the closure analysis fill up the template. The main information
needed for metric analysis are:
Effort data is obtained from PDB.

Defect data is obtained from DCS.

Size data is obtained from Project Management Plan.

Planning data appear in the project management plan.

Q.4
Ans

Write short note on Group Review Meeting?

The basic purpose of the group review is to come up with the final detect list, this
list is based on the initial list of defects and issues reported by the reviewers and
any new ones found during the meeting discussion.
Team leader should schedule a review meeting every six months will all leaders
to discuss progress, get specific feedback on action plans, and offer suggestions
to enhance performance.
When everything is ready, the group review meeting is held. One revieweris
designated as the scribe and another the reader. The meeting is conducted as
follows:
The reader goes over the work product line by line paraphrasing each line to the
team. At any line, if any reviewer has previously identified any issues or finds
new issues in the meeting while listening to others,he raises the point.There may
be a discussion on the issue raised, and other reviews may agree or disagree
with it. The scribe records the issues and defects identified.

Q.5
Ans

Write short note on Monitoring quality?

To monitor the quality, the important thing is to measure the no. of defects
found. As the no. of defects are also estimated during planning, therefore the no.
and status of review done and the status and effect of defect prevention activities
are also monitored.
The project manager can compare an actual and estimated analysis of defects in
the various stages of project. If the deviation exceeds, then the project manager
must analyze the causes.
Another thing to be monitored for quality is the no. of reviews conducted. As
time pressure mount, can be tendency to skip the planned reviews which was the
important part of quality plan. The milestone report herefore indicates which
reviews were planned and which were actually executed.