Submitted By:

Tausif Javed BCS-10134

Fareed Ali Azam BCS-10135

Khizar Javed BCS-10140

Mauzzam Khan BCS-10146

Anas Farooq BCS-10159

Submitted To:

Sir Yasar Islam

Table Of Contents: Software Project Management

1. Factors Influence SPM 1.1 Project Size

1.2 Delivery Deadline

1.3 Application Domain

1.4 System Constraints

1.5 Budgeting

1.6 Technology

1.7 Resources Allocation

2. The Management SPECTRUM (Four P’s Concept)

2.1 The People

2.1.1 The Stakeholders

2.1.1.1 Senior Manager

2.1.1.2 Project Manager

2.1.1.3 Practitioners

2.1.1.4 End User

2.1.2 The Team Leader

2.1.3 MOI MODEL

2.1.3.1 Motivation

2.1.3.2 Organization

2.1.3.3 Innovation

2.1.4 Software Team

2.1.4.1 Democratic Decentralized

2.1.4.2 Controlled Decentralized

2.1.4.3 Controlled Centralized

2.1.4.4 Agile Team

2.2 The Product

2.2.1 Scope

Context

Information objectives

Function and performance

2.2.2 Problem Decomposition

2.3 The Process

2.4 The Project

2.5 The W5HH Principle

3. Why Project Fails?

3.1 Changes in Customer Requirement (Requirement

Engineering)

3.2 Ambiguous Requirements

3.3 Unrealistic Requirement

3.4 Unpredictable

3.5 Technical Difficulties

3.6 Project Management

4. Characteristics of project Manager

4.1 Problem Solving

4.2 Managerial identity

4.3 Achievement

4.4 Influential

4.5 Team Building

5. Software Team

5.1 Democratic Decentralized

5.1.1. Management Structure

5.1.2. Communication channels

5.2 Controlled Decentralized

5.3 Controlled Centralized Team Structure

6. Critical Practices

6.1 Formal risk management

6.2. Empirical Cost and Schedule Estimation

6.3. Metric-bases project management

6.4. Earned value tracking

6.5. Defect tracking against quality target

7. Software Size Estimation

7.1 Objectivity

7.2 Comparable

7.3 Deliverable

7.4 Independent of technology

7.5 Mostly Used Mechanisms

7.5.1 LOC

7.5.2 FP

7.5.3 Comparison between LOC and FP

7.5.4 Productivity of H.L.L (high level language):-

7.5.5 IFPUG (International functional point user

group):-

7.5.6 ILF (internal logic file):-

7.5.7 EIF (External interface file):-

7.6 Estimating Software Cost:-

7.7 Estimation Techniques:-

7.7.1 Problem:-

7.7.2 Determining “development effort”:-

7.8 Why Estimate Software:-

7.8.1 Resource:-

8. Bibliography

SOFTWARE PROJECT MANAGEMENT (SPM) Software Project Management (SPM) is the scientific as well as artistic technique to

plan, manage and complete a software project. It Includes the Following:

1. Factors Influence SPM: 1.1 Project Size

The size of the project is always important, the cost estimation and time

management also rely on the project. A good project manager should predict the

project size. The project manager should be efficient for predicting software size under

its analysis phase. If the manager knows the complete and accurate size of the

software, then all other phases of software development life cycle will be easy to

schedule.

The size is also much important for cost estimation. Like we use a

method in cost estimation called LOC (Lines of code). For this, we must know the size

of project.

1.2 Delivery Deadline There is always a delivery deadline of the project. We must complete the

project in a given time. Generally saying, time and cost are inversely proportional to

each other. If we want to decrease the time, we must increase the cost. The higher the

cost, the lesser the time it is. If

If any software team is not able to deliver the project at the given

deadline. It well be resulted as a failure. That failure can be customer dissatisfaction,

financial loss and can result as bad impact on customer as well as other stakeholders.

1.4 Application Domain

A domain in software engineering is a set of related

software systems that share common design features. [19]

In other words, we can say that an application domain refers to the

category of applications. Project manager must decide the right application

domain and should schedule the project according to that application domain.

If the application is not defined, it may cause problems and customer

can be satisfied. In the analysis and requirement engineering phase, the

application domain should be confirmed.

1.4 System Constraints

A constraint is a restriction on the degree of freedom

you have in providing a solution. [20]

Constraints are effectively global requirements, such as

limited development resources or a decision by senior

management that restricts the way you develop a system. [21]

Constraints are things that we live within our daily

lives, accept them, and move on. With software engineering

groups that are well-established and have strong leadership,

constraints can get legs of their own and become excuses for

not delivering projects on time, not building something

correctly, or even stepping outside Enterprise Goals because

“they do not fit within our design.” [22]

Constrains are the restrictions on our projects. Constraints can be political, social,

technical, and environmental and can also be dependent on our software project

feasibility.

1.5 Budgeting Budgeting leads to the software crisis. This definition of software engineering defines

importance of budgeting:

Software engineering is the branch of software that deals

with development of well developed software that satisfies all

the users' requirements and ensures that the software is

provided on time and within budget. [23]

So, software engineering is the branch of technology responsible for completing the

software within a given (defined) budget. However, this definition tells us about the

importance of budgeting. If a project is not completed within a budget which was decided

earlier, then it leads the software team to software crisis. So, in the analysis phase the

project should be analyzed with i6ts budget as well as time.

1.6 Technology

Technology also influences software project management. Project should be managed

as concerned with the appropriate technology according to the time and cost.

Software project must be compatible with the technology that is alive in the market.

For example, if software team develops a program which is only compatible with the

Intel 16 bit architecture which has been obsolete, then it is useless.

1.7 Resources Allocation Resource allocation is the most important factor. If we allocated resources to the wrong

place or person, it will be resulted in the form of serious danger.

2. The Management SPECTRUM (Four P’s

Concept)

Software Project Management is very important part of software engineering.

Projects must be managed exactly according to the software engineering

standards. Projects must be completed within the organization budget and

schedule constraints. Project manager plays a very important role in software

project management. Project manager‘s duty is to check whether the project

meet exactly according to the predefined specifications and within the budget.

Ian Summerville states that “Good management cannot guarantee project

success. However, bad project management usually results in failure: the

software may be delivered late, cost more than the original estimated, or fail to

meet the expectations of the customers.

The success criteria for project management obviously vary from project

to project but, for most projects, important goals are:

1. Deliver the software to the customer at the agreed time.

2. Keep overall cost within the budget.

3. Deliver software that meets the customer‘s satisfaction.

4. Maintain a happy and well functional development team”.

Software Project Management focuses on four P’s. Project manager is

responsible to reinforce the stakeholders, if project manager paying less

attention during software development activities or project manager fails to

encourage the stakeholders then project may fail. Four P‘s of software project

management are:

1. People

2. Product

3. Process

4. Product

2.2 The People:

Software Project management is mix of people‘s skills. However, leader plays a

very essential role in solving the problems. A concrete understanding of the

problem is very important because solution must be implemented on root level.

Software engineering institute has developed a framework people capability

maturity model (PEOPLE-CMM) in recognition of the fact that ―Every

organization needs to continually improve its ability to

attract, develop, motivate, organize, and retain the

workforce needed to accomplish its strategic business

objectives” [24]. There are following personalities in the people:

2.2.1 The Stakeholders:

Every Software project, stakeholders can be categorized into following five

categories.

1. Senior Managers

2. Technical Managers

3. Practitioner

4. Customers

5. End User

2.2.1.1 Senior Manager:

Senior manager has to identify business issues that often have a major

influence on a software project. Senior manager is a hub between customer

and software.

2.2.1.2 Project Manager:

Project Manager who manage, motivate and assign task to practitioners.

2.2.1.3 Practitioners:

Practitioners are fully trained, skilled people who deliver technical skills those

are necessary for the application.

2.2.1.4 End User:

End Users are those persons who use software after its development

completion.

2.2.2 The Team Leader:

A team leader is a person who has ability to organize and motivate people

working on a project. Team leader organize new processes, tools, techniques

and provide rewards for software team motivation. Jerry Weinberg suggested

an MOI model for leader ship.

MOI MODEL:

Motivation: Team leader must motivate programmers to do their best

in form of incentives, good environment, etc.

Organization: Mold existing processes or create new processes to

achieve efficient results.

Innovation: Encourage appropriate level of creativity for each project.

2.2.3 Software Team:

2.2.3.1 Democratic Decentralized:

Software team has not any permanent leader. In this structure

coordinator is appointed for a short period. This is recommended

approach for a complex and large problems.

2.2.3.2 Controlled Decentralized:

In this structure a team has a project leader. This is again sub-divided

and a secondary leader is appointed on sub tasks.

2.2.3.3 Controlled Centralized:

This is managing by team leader the top level problem solving and a

team management is performed by a team leader. In this way few

benefits are obtained such as:

a) Difficult problems are solved.

b) The time duration is followed.

c) Software quality is assured.

d) Degree of communication is achieved.

e) ―Size‖ of the resultant program(s) in lines of code or function

points.

To achieve a high performance team:

Team members must have in trust with one another.

The distribution skills must be appropriate to the problem.

Individualists may have to be excluded from the team, if team

cohesiveness is to be maintained.

2.2.3.4 Agile Team

Agile software development technique has suggested reliable and

provide rapid development for large projects. Agile Team encourage

customer satisfaction and early incremental of software, small highly

motivated teams, informal methods, minimal software engineering

work product, and overall development simplicity.

2.2 The Product: Software that is built at the request in ordered to meet the objectives and scope

of software engineering. This project is referred as software product. Without

scope and objectives information it is impossible to estimate accurate cost and

effective risk management. Software developers, stakeholders and customer

must define project scope.

2.2.1 Scope:

Scope is defined by answering following questions:

Context: How does the software to be built fit into a larger system,

product, or business context, and what constraints are imposed as a

result of the context?

Information objectives: What customer-visible data objects are

produced as output from the software? What data objects are required

for input?

Function and performance. What function does the software

perform to transform input data into output? Are any special

performance characteristics to be addressed?

2.2.2 Problem Decomposition:

Problem decomposition some time called a portioning or problem

elaboration is an activity that considered the core of software

requirement analysis. Ian Summerville states that ―during project

scoping no attempt is made to decompose the problem. Decomposition is

applied in two major areas:

1. The functionality must be delivered.

2. The process that will be used to deliver it.‖

We apply the ‗‘Divide and Conquer strategy‘‘ to partition a Product into

smaller pieces so that can be managed better, as Project Planning begins.

2.3 The Process:

A process is defined as a collection of activities like work, actions, and task are

pefromed when the work product is created. Ian summerville states that each

of these activities, actions, and task reside within a framework or model that

defines their relationship with the process with one another.

A generic process framework for software engineering defines five framework

activities:

1. Communication

2. Planning

3. Modeling

4. Construction

5. Deployment

In addition, a set of umbrella activities—projecttracking and control, risk

management, quality assurance, configuration management, technical reviews,

and others—are applied throughout the process. Below is the diagram of

software processes:

Melding the Product and the Process:

Project planning starts with the merging of the product and the process. Every

that is engineering by your team must pass through set of framework activities

that are defined for software organization. Below diagram shows the melding

the product and the process.

In process there are too many models available like water fall model,

prototype model, iterative model, RAD (Rapid application Development),

Extreme Programming, RUP (Rational Unified Process). We can use any

model according to the requirement.

2.4 The Project:

To make successful project you must understand that problems will cause the

errors. In an excellent paper on software projects, John Reel [Ree99] defines 10

signs that indicate that an information systems project is in jeopardy:

1. Software people don‘t understand their customer‘s needs.

2. The product scope is poorly defined.

3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs change [or are ill defined].

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost [or was never properly obtained].

9. The project team lacks people with appropriate skills.

10. Managers [and practitioners] avoid best practices and lessons

learned.

2.5 The W5HH Principle:

BOEHM suggests an organizing Principle that scales down to provide simple

Project Plans for simple Projects. (WWWWWHH: why, what, when, who, where,

how, how much).

1. Project Objectives

2. Milestones and Schedules

3. Responsibilities

4. Management and Technical approaches

5. Required Resources

3. Why Project Fails?

Many projects fail due to many causes which affects software and IT industry

from growing. We can prevent those failures with effective requirement engineering

and analysis phase in software development life cycle. Some causes of project failures

are described below:

3.1 Changes in Customer Requirement (Requirement

Engineering)

Usually customers are not able to tell their requirements or the software team

is not able to translate them. In both of cases it causes failure of project.

Some customers change their requirement after once they clarify them; it

causes loss of time as well as cost. To prevent that failure, requirement engineering

must me effective because we have to get the requirements completely before the other

steps. The person responsible for requirement gathering is known as requirement

analyst.

3.2 Ambiguous Requirements

Requirement engineering is the most important phase of software engineering. If we

are not clear with the requirements, we cannot continue because if we can‘t describe

and translate requirements of customer, we cannot continue.

3.3 Unrealistic Requirement

Sometimes customers tells the requirements which are not feasible somehow these

requirements are not feasible in time, it can also be case of cost, economy, technology,

environment and social factors. If the requirements are not real (feasible), then it

should be told to the customer in the analysis phase of software development life

cycle.

3.4 Unpredictable

One serious cause of failure is the factor that cannot be predicted, these may be

disasters. Such threats have two types, one is logical another is physical threat.

Logical threats are the failure occurs from viruses, spywares, malwares, Trojan horses,

root kits etc. The physical threats can be natural disasters like sand storm, thunder

storm, lightening, theft etc.

Pakistan and Asia for years. There can be many other causes that are unpredictable

using the Project Management rules.

3.5 Technical Difficulties

Another cause of failure is technical difficulty. If we are not able to work with a

different or specific technology, then we cannot complete our project that requires

such technology.

Sometimes project managers try to fraud with customers on the basis of their

technical expertise, but it will degrade project manager as well as software team.

3.6 Project Management

If the project is not managed effectively, then it can cause failure. It is the

responsibility of the project manager to manager project and schedules it according to

right perspective of software project management.

4. Characteristics of project Manager:

A project manager is very vital or key-role of project management, who should

have to follow a system approach because system approach will help to view

things in a holistic manner or in macro-level as we cannot miss any single

piece of task in system approach that are strongly coupled to each other for

producing significant results. So, a project manager should have the ability to

put many pieces of interconnected and tightly coupled tasks together to form a

coherent model or unified system.

As far as the responsibilities of a project manager are concerned we can

see in figure 4.1 that for a successful completion of a project a manager should

not be a specialist of a single field but he or she would have to be a generalist

so that he/she can handle all aspects of project management as a good project

manager.

Fig-4.1

Keeping in the view above discussed value of project manager and his

responsibilities we can issue a checklist of major characteristics of a project

manager, that is

Problem Solving Skills

Managerial Identity

Achievement

Influential

Teambuilding

Now we discuss these characteristics in a little bit detail to clarify and to verify

the importance of these characteristics.

4.1 Problem Solving

Problem solving is a combination of problem definition and alternative

identification and analysis to resolve the problems before they may spoil the

whole recipe to achieve the final goal. Problem solving skill is one of the most

powerful weapons of project manager for the successful completion of the

project. Problem solving is the compound of some other skills that are

vigilance, esteem analytical power, forecasting and sound experience. The

more perfect in these sub skills, more efficient in problem solving which in turn

is a big deal.

“If there were no problem people there'd be no need for people who solve problems. Unknown author”

As a project manager can‘t leave problem in the way without resolving it. A

picture showing this capability of project manager in funny way is shown in

figure 4.2[25]

Fig-s4.2

4.2 Managerial identity

An important characteristic of a project manager is his/her ability to know the

managerial perspectives. He/she should have full command on assigning right

tasks to right persons with appropriate instructions so that loss of time, cost

and quality should be prevented. He/she should know his own authority and

command line and he/she should be good in communication with all the team

members as well as stakeholders and end users so that any ambiguity or miss-

understanding could be avoided.

The project manager has authority for coordinating and controlling the job.

He/she acts like an umbrella under which all actors are performing their

actions in the guidance of project manager to meet the deadline efficiently. Fig-

4.3 shows the entire responsibility and importance managerial identity of a

project manager. [26]

Fig-4.3

4.3 Achievement

For effective output from team members it is necessary technique for a project

manager to allow the subordinates to accomplish their tasks with reasonable

incentives, allowances and backups. This technique not only increase the

morale of workers it also creates competition among them. It is also necessary

that for a fine control over work quality and risk avoidance this technique must

“Need for achievement (N-Ach) refers to an individual's desire for significant

accomplishment, mastering of skills, control, or high standards.” Henry Murray[1]

be used in an appropriate manner. Inappropriate rewards for a task completion

creates greed among the workers and they try to complete their tasks for their

rewards leaving the quality and expected risks far behind. To avoid this

situation project manger should have to define the overall objective of each task

assigned to the team members in context of quality, risk avoidance and time

management.

When a project manager gives out tasks based on achievement there are a number

of things he will accomplish.

First, the members of your team will know exactly what he

wants. In addition to this, he will give the team members the

opportunity to develop a commitment towards the task [28].

The most important aspect of this strategy is that the team members will be

satisfied, because they know exactly what is expected of them.

4.4 Influential:

Successful project managers require support from their teams. However,

this support cannot be delegated or simply wished into existence. Acquiring

the authority to effectively lead a team demands a specific approach. [29]

Although a project manager is assigned with many responsibilities along with

enough authorities over the project handling and team members but it is not

quite enough for a project manager to be an influential project manager. Along

with responsibilities and decision making powers some extra qualities are also

required for being an influential project manager.

A project manager should be humble at times and assertive in others, and

know when to take a charge in a situation and when to assign roles to other

team members. It is also necessary to assign roles in different team members

in such a way that they don‘t put them self in inferiority or superiority

complex. Infallible leader often inspire team members as resistive and rigid

leader which spreads desperation among them and low work productivity. It is

important for a project manager to understand exactly when and to whom

power can be entrusted. Not everyone is cut out for a management role, and

some are much happier with strict oversight rather than free reign. Overall

essence of an influential project manager is that he is one who knows the

strengths and weaknesses of team members and how to deal with them in a

way to take an efficient output without losing his influence from the team

members in any circumstances.

4.5. Team Building:

For working in a stressed and pressurized environment building a good team is the

single most important thing a Project Manager can do to achieve a successful project.

With the right attitude, a team will overcome almost any difficulty to succeed in its

goals. In most projects there will be times when only the determination of the team

can overcome the difficulties and carry the initiative through to success. Even when

there is no pressure, the team's spirit and enthusiasm will be reflected in the quality

of the solution and the extent to which other people buy-in to it.

Fig-4.4

The reality is that a sensible balance achieves the best results:[6]

• reward vs punishment

• pleasure vs pain

• encouragement vs coercion

• opportunity vs threat

5. Software Team:

"[The trick in software engineering is to find out] how to do intellectually-intensive work

in teams.]" - R. E. Fairley

Software team structure is vital to study as it holds a driving seat while a software

project is on the road of completion. Usually there are three important software team

organization methods that are mostly adopted by different groups according to their

requirements. All of these three approaches are fair in different situations. Let us

discuss three of these for developing our concepts in this regard.

We shell discuss:

Democratic Decentralized Structure

Controlled Decentralization Structure

Controlled Centralized Structure

5.1 Democratic Decentralized:

Decentralization means a structure of authorities where a permanent or

specific leader or power is not present to handle or to solve all the

problems but all of the issues are handled in a combined or collective

manner.

Democracy means to choose an authority with mutual understanding for

a given time period.

Combining these two concepts develops a structure in which an authority is

selected with mutual understanding for a specific time to solve the issues and

to look after the whole project process. In democratic decentralized structure

all problems and relevant issues are discussed and with the help of effective

communication, development and research all expected and present problems

are solved.

5.1.1. Management Structure

5.1.2. Communication channels

Fig-5.1. An egoless team structure; where authority is dispersed and

communication linkages decentralized. [30]

5.2 Controlled Decentralized:

In Controlled Decentralized (CD) team Structure has a permanent leader

who primarily coordinates tasks. It has a secondary leader responsible for

subtasks. Decisions are solved by group consensus but the implementation

is done by subgroups. The communication during implementation is

horizontal but control is vertical. [31]

All individuals

have varying

skills levels and

area of

expertise.

Fig-5.2 5.2.1 Management structure in Controlled Decentralization.

Fig5.2: Controlled Decentralized team structure. Authority is vested in

project manager and senior programmers but communication at each level

is decentralized. [32]

5.3 Controlled Centralized Team Structure:

In controlled centralized team structure there is a team leader who

makes co-ordination among team members and take top level

decisions. T h e communication between leader and team members

is vertical. The decision on what team structure to employ would

depend on the project characteristics. [8, 9]

5.2.2. Communication

Channels

Consultants employing critical practice skills

aim to help people improve outcomes.

Analysis is applied to groups working in a

particular area of expertise and with

identifiable practice skills, and usually to a

defined range of problems and situations.

Thus practice tends be based on a restricted

view of people and their problems, with a

limited range of values applied in that

practice.

6. Critical Practices

Critical Practice is the methodology used by a critic or

observer to understand and evaluate a field of knowledge.

While sometimes the fields of knowledge studied are

academic, non-academic fields such as merchandising, law

enforcement and medical clinical practice have been

extensively studied. Critical practice is grounded in the

concepts of critical theory. [14]

A team of Software Engineering experts has developed a list of ‗‘Critical Software Practices for

Performance-based Management; These practices are consistently used by , and considered

critical by , highly successful Software Projects and Organizations whose ‗bottom line‘

performance is consistently much better than industry averages.

Critical Practices include the followings

1. Formal Risk Management

2. Empirical Costs and Schedule Estimation

3. Metric-based Project Management

4. Earned Value Tracking

5. Defect Tracking Against Quality Targets

6. People Aware Management

The Critical Practices is also known as QUICK LOOK QUESTIONS.

6.1 Formal risk management: Formal risk management is a policy or program that works to prevent all types of

problems arising from risk and uncertainty.

Although the actual risk management processes may be different in small and large

companies, the problems that arise as a result of poor risk management are the same.

Unmanaged risk creates inadequate security and safety measures, which can cause

financial loss, erode profits and create unnecessary liabilities. Inadequate risk

management can even scare away venture capital funding and lower your bank rating

status.

Effective implementation of formal risk management is based on the following set of benefits resulting from the process:

Appropriately tailored risk management strategies are defined and implemented

Potential problems (risks) that could impact project success are identified

The likelihood and consequences of these risks are understood

A priority order in which risks should be addressed is established

Mitigation alternatives appropriate for each potential problem are carefully considered based on project

circumstances

Optimized mitigation techniques for all risks above their thresholds are selected

Contingency plans in case the risk mitigates are developed proactively, rather than as a result of fire-fighting

Information to improve risk management policies is captured, analyzed and acted upon

Risk management processes/procedures are systematically and periodically reviewed and improved to further reduce risk.

6.2. Empirical Cost and Schedule Estimation:

Cost models were derived from the collection and analysis of large collections of project data.

Modelers would fit a curve to the data and analyze those parameters that affected the curve.

Early models applied to custom-developed software systems. New software development

philosophies and technologies have emerged in the 1980s and 1990s to reduce development

costs and improve quality of software products. These new approaches frequently involve the

use of Commercial-Off-The-Shelf (COTS) software, software reuse, application generators, and

fourth generation languages.

6.3. Metric-bases project management: Metric is a quantitative measure of the degree to which a system, a component, or a process

possesses a given attribute. Software process and projects metrics are quantitative measure

that enables software engineers to gain insight into the efficiency of the software process and

the projects conducted using the process framework. In software

project management, we are primarily concerned with productivity

metrics. The

6.4. Earned value tracking:

Earned value management, which is used to track earned value, is an integrated system of project management and control that

enables a Contractor and their customer to monitor the progress of a project in terms of integrated cost, schedule, and technical performance measures. The Contractor/developer

owns the process but the Acquirer/customer has full and timely visibility of the information contained within it. Traditional project management practice tends to compare actual costs

with planned expenditures, and confuses actual costs with actual progress. EVM provides a

third reference point that is an objective view of the status of the effort, i.e., the value to the end goal of the work completed to date.

6.5. Defect tracking against quality target: Defects should be tracked according to a planned, documented process, measured against

established targets, and systematically tracked through to removal or resolution.

Successful implementation of Earned Value Management principles can result in

Better Visibility into Program

Performance

Reduced Cycle Time to Deliver a

Product

Increased Accountability

Reduced Risk

Defect tracking against quality targets entails recording defects in a database; following a

documented process to analyze, resolve, and remove them; tracking the process; measuring

defects against quality targets; and reporting metrics on the process to program management.

[15]

The Airline Council is a team of Software engineering experts chartered by the U.S. Department of Defense to help develop guidelines for

the best practices in software project management and software engineering.

Questionnaire To Determine If You Are Practicing Defect Tracking

Against Quality Targets

1.What kind of defects do you track (faults, failures or both)?

2. What is your delivered quality target? What evidence do you have that you are currently managing

toward that target?

3. What kind of analysis do you perform on defect data? How are results used (e.g., tracking

improvement, prediction)?

4. How many defects are currently open? What are their priorities?

5. How are metrics on defect data gathered and analyzed to provide feedback to management?

“Quick Look” Questions Presented by [Air99]

6. How do you project expected defects?

If a software project team cannot answer the questions or answered them inadequately,

a thorough review of project practice is indicated. [16]

Question Related with Formal risk management:

What are the top ten risks for this project?

For each risk , what is the chance that the risk will become a problem and what

is the impact if it does.

Question Related with Empirical Cost and Schedule Estimation:

What is the current estimated size of the application software that will be

delivered into operation?

How was it derived?

Question Related with Metric-bases project management:

Do you have in place a metrics program to give an early indication of evolving

problems?

If so, what is the current requirement volatility?

Question Related with Earned value tracking:

Do you report monthly earned value metrics?

If so, are these matrices computed from an activity network of task for the entire

effort to the next delivery?

Question Related with Defect tracking against quality target:

Do you track and periodically report the number of defects found by each

inspection and execution test from inception and the number of defects

currently closed and open?

People-aware program management:

What is the average staff turnover for the past three months for each of the

suppliers/developers involved in the development of software for this system?

The Airline Council has developed a list of

critical software practices for performance

based management. These practices are time

after time whose bottom line performance is

consistently much better than industry

averages. In an effort to enable a software

organization to determine whether a specific

project has implemented critical practices, the

Airline Council has developed a set of “quick

Look” questions [Air99] for a project.

[17]

16 Critical Software Practices (Latest Research)

The SPMN was established in 1992 by the Assistant Secretary of the Navy to identify

proven industry and government software best practices and convey these practices to

managers of large-scale system acquisition programs. The SPMN Practices TM

specifically address underlying cost and schedule drivers that have caused many

software intensive systems to be delivered over budget, behind schedule and with

significant performance shortfalls.

The "16 Critical Software Practices TM for Performance-based Management" and

Templates contain the 16 practices (9 best and 7 sustaining) that are the key to

avoiding significant problems for software development projects. These practices have

been gathered from the crucible of real-world, large-scale, software development and

maintenance projects. Together they constitute a set of high-leverage disciplines that

are focused on improving a project's bottom line.

These practices are the starting point for structuring and deploying an effective process

for managing large-scale software development and maintenance. They may be tailored

to the particular culture, environment, and program phases of a program. Of course,

these practices cannot help "death march" programs that are expected to deliver under

impossible schedule deadlines with inadequate funding and without the required

staffing with essential skills.

PROJECT INTEGRITY

1. ADOPT CONTINUOUS PROGRAM RISK MANAGEMENT

2. ESTIMATE COST AND SCHEDULE EMPIRICALLY

3. USE METRICS TO MANAGE 4. TRACK EARNED VALUE

5. TRACK DEFECTS AGAINST QUALITY TARGETS 6. TREAT PEOPLE AS THE MOST IMPORTANT

RESOURCE

CONSTRUCTION INTEGRITY

Most software projects fail. In fact, the Standish

group reports that over 80% of projects are

unsuccessful either because they are over budget,

late, missing function, or a combination. Moreover,

30% of software projects are so poorly executed that

they are canceled before completion

7. ADOPT LIFE CYCLE CONFIGURATION MANAGEMENT

8. MANAGE AND TRACE REQUIREMENTS 9. USE SYSTEM-BASED SOFTWARE DESIGN

10. ENSURE DATA AND DATABASE INTEROPERABILITY 11. DEFINE AND CONTROL INTERFACES

12. DESIGN TWICE, CODE ONCE

13. ASSESS REUSE RISKS AND COSTS

PRODUCT STABILITY AND INTEGRITY

14. INSPECT REQUIREMENTS AND DESIGN

15. MANAGE TESTING AS A CONTINUOUS PROCESS

16. COMPILE AND SMOKE TEST FREQUENTLY

[18]

7. Software Size Estimation:- In today’s era most of the organization used their past experience to

estimate the size of their projects, which are not that much quantitative.

The real life example of software size estimation is that you are going

develop a new house then first you have to determine that how much

expenditure you have to put on labor, bricks, infrastructure and on

architect design then finally you sum up the whole cost and reached on

accurate conclusion that you should have put the that amount which is

required, similarly while developing a software you should have to

recognize its size under the consideration of LOC and FP etc.

However, it is very important to adopt an assessment mechanism. Which

are the following?

Objectivity

Acceptable standard with wide spread used

Comparable

Deliverable

Independent of technology

7.1 Objectivity:-

The scope and vision of software should be determined under the

consideration of software size estimation because if the objective of

software is not focusing then an organization will not estimate the cost of

the software appropriately.

Acceptable standard with wide spread used:-

The size of software should be according to the given standard providing

by ISO (International standard Organization). Also software has an ability

that it will be modifiable at according the requirement specification.

7.2 Comparable:-

Software has some uniqueness so on the bases of that it will be

comparable to other software.

7.3 Deliverable:-

This section determines what the project will deliver and outline of all the

work require completing the tasks.

7.4 Independent of technology:-

It means which technological factors your software uses. It helps you to

estimate the software size in term of technology is used during the

software development process.

7.5 Mostly Used Mechanisms:-

The mostly used mechanisms are:

Line of code (LOC)

Functional point (FP)

7.5.1 LOC:-

It is software metric which is used to calculate the size of the software

programs in the context of lines which are type by the programmer during

the developing process of program’s source code file. It is also used to

measure the amount of effort that is needed to create a program,

simultaneously to estimate the programming productivity and

maintainability of the software.

7.5.2 FP:-

It is a unit of measurement that is used to determine the amount of

business functionality and information system present to a user. In

functional point the expense of the single unit is estimated from the past

practices.

In functional point there are five types of externals to count:

1. External inputs: - data or control inputs (input files, tables, forms,

screens, messages, etc.) to the system.

2. External outputs: - data or control outputs from the system

3. External inquiries: - I/O queries which require a response (prompts,

interrupts, calls, etc.)

4. External interfaces: - libraries or programs which are approved into and

out of the system (I/O routines, sorting procedures, math libraries, run-

time libraries, etc.)

5. Internal data files - groupings of data stored internally in the system

(entities, internal control files, directories).

Apply these steps to calculate the size of a project:

1. Count or estimate all the occurrences of each type of external.

2. Assign each occurrence a complexity weight.

3. Multiply each occurrence by its complexity weight, and total the results

to obtain a function count.

7.5.3 Comparison between LOC and FP:-

1. Line of code focuses on existing source code as compare to

functional point.

2. Line of code is dependent on programming techniques where as

functional point is not dependent on programming techniques.

3. Line of code is dependent on the technology while functional point

is not dependent on technology.

4. Line of code is a mixture of languages as compare to functional

points.

7.5.4 Productivity of H.L.L (high level language):-

Productivity of high level languages means some languages requires a lot

of effort to deliver the required functionality whereas the same

functionality is easily deliver by other languages such as assembly and c++

etc .

History of FPA (functional point analysis):-

It includes the following factors:

IFPUG

ILF

EIF

7.5.5 IFPUG (International functional point user

group):-

It is introduced by IBM in 1970’s and after that it gain fame and has been

adopted as a standard in several organizations.

Example:-

IEEE recommend is for use in efficiency measurement.

UK government recommend functional point analysis standard for

the estimation of software size.

Australia’s state agencies adopt this standard.

US huge govt. department use functional point analysis.

Large companies such as IBM are using this standard from many

years.

7.5.6 ILF (internal logic file):-

Internal logic file is a user restricted group which is linked with logical

related data. Its responsibility to control the information within the

defined limit of an application also organized the creating, maintaining

and delete functions.

7.5.7 EIF (External interface file):-

External interface file is also a user identifiable group which is linked with

logical related data. The most important thing external interfaces file (EIF)

is that it holds data reference developed by one or more than one

reference within the limit of an application. EIF for an application is must

be ILF for another application.

7.6 Estimating Software Cost:-

The price of the contact mediums and huge software projects are

evaluated by the cost of creating the software included the price of

equipment and materials. The cost of the developing the software is

simply the calculated effort, multiply by most probably the labor cost

which is fixed.

7.7 Estimation Techniques:-

There is no simple way to build an accurate estimate of the effort

for a software system. The following techniques are used:

Initial estimates based on insufficient information.

User requirements definition.

Software may run on unusual environments.

Different computers or new technology.

The people in the project may be unknown.

Project cost estimates may be self-fulfilling.

The estimate defines the budget and the product is adjusted to meet

the budget.

7.7.1 Problem:-

The following problems occur during the software size estimation process:

The accuracy of the previous equation depends on what?

Project Cost = Time X Unit Cost

Accuracy of the development effort estimate.

Accuracy of the cost per unit.

Which one do we normally know?

7.7.2 Determining “development effort”:-

It includes the following factors:

Person-Month

LOC per Hour

Function point per hour

Requirement per hour

Most common is person-months (or hours)

7.8 Why Estimate Software:-

The following are the reasons which identify that why software should

have to be estimated:

30% of project never completes.

100-200% cost overruns not uncommon

Average project exceeds cost by 90%;

Schedule by 120%

15% of large project never deliver anything

Only 16.2% of projects are successful

7.8.1 Resource:-

Resource is the very important factor of software size estimation. It

means how greater the resource the size of the software is also very large.

The most imp resource requires developing software is HRM (human

resource management) which includes programmers, managers and

administrators etc. It is the responsibility of an organization to manage all

the resources on time as well as estimate the cost on those resources

during the managing process so that the software will be develops within

given budget.

Bibliography

[1]

http://en.wikipedia.org/wiki/Application_domain

01:24 PM 18-Apr-2012

[2]

http://www.agilemodeling.com/artifacts/constraint.htm

01:36 PM 18-Apr-2012

[3]

http://www.agilemodeling.com/artifacts/constraint.htm

01:38 PM 18-Apr-2012

[4]

http://danilogurovich.wordpress.com/2007/08/12/software-engineering-

constraints-taking-responsiblity-and-delivering/

01:40 PM 18-Apr-2012

[5]

http://voices.yahoo.com/software-engineering-characteristics-well-engineered-

2930151.html?cat=15

01:46 PM 18-Apr-2012

[6]

Curtis, B., W. Hefley, and S. Miller, People Capability Maturity Model,

Addison-Wesley, 2001.

[7]

Chapter 24 Project Management Concept

Roger .S. Pressman, (2010), SOFTWARE ENGINEERING: A

PRACTITIONER‘S APPROACH, SEVENTH EDITION Published by

McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221

Avenue of the Americas, New York, NY 10020.

[8]

Ian Summerville (2011), SOFTWARE ENGINEERING, Ninth Edition,

Pearson Education, Inc., Permissions Department, 501 Boylston Street,

Suite 900, Boston, Massachusetts 02116.

[9]

Project Management Concepts

http://sct.emu.edu.tr/gursev/ITEC346/SE%20Lecture%20notes/PP%20

SLIDES/PROJECT%20MANAGEMEN%20CONCEPT.ppt

[10] Software Project Management

http://www.sei.cmu.edu/reports/89cm021.pdf

[11]

Four P‘s of Software Engineering

http://fie-conference.org/fie2007/papers/1029.pdf

[12]

Software Project Management

http://www.csc.liv.ac.uk/~mjw/teaching/soft-eng/lect05.pdf

[13]

Ref: Henry Alexander Murray (May 13, 1893 – June 23, 1988) was an

American psychologist who taught for over 30 years at Harvard

University.

[14]

Self search over www.google.com/images

http://www.exforsys.com/career-center/project-

management/achievements-vs-activities-in-project-management.html

[15]

http://www.informationmanagement.com/newsletters/project_managem

ent_business_rules_BI_ROI-10020851-1.html

[16]

Article: The Effect of Programming Team Structures on Programming

Tasks by Marilyn Mantei, The University of Michigan. Page #107

[17]

http://www.epmbook.com/team.htm

[18]

Article: The Effect of Programming Team Structures on Programming

Tasks by Marilyn Mantei, The University of Michigan. Page #109

[19]

Article: The Effect of Programming Team Structures on Programming

Tasks by Marilyn Mantei, The University of Michigan. Page #111

[20]

http://www.allbusiness.com/glossaries/decentralization/4952507-

1.html

[21] Article written by ‗Brechin, H. Brown‘ and ‗M. Eby‘ Critical Practice

in Health and Social Care (eds) Sage 2000.

(http://en.wikipedia.org/wiki/Critical_Practice)

[22] SOFTWARE ACQUISITION GOLD PRACTICE™ (The Data and

Analysis Center for Software)

https://goldpractice.thedacs.com/practices/frm/index.php

[23] BOOK: Software Engineering A Practitioner‘s Approach

[24] Software Programs Network est. 1992

http://www.spmn.com/www2/16CSP.html#cost

[25]

http://www.spc.ca/resources/metrics/software_estimation.pdf

[26]

http://www.cs.cmu.edu/~aldrich/courses/413/slides/4-estimation.pdf

[27]

http://en.wikipedia.org/wiki/Source_lines_of_code

[28]

Book: Software Engineering A Practitioner‘s approach (seventh edition),

chp#26, pg#691