Upload
liveforotherz
View
32
Download
1
Tags:
Embed Size (px)
Citation preview
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.
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