SOFTWARE PROJECT

MANAGEMENT
UNIT - I
Dr.A.Pathanjali Sastri
Professor, Dean Academics & QA
EVOLUTION OF SOFTWARE
ECONOMICS
Software Economics
• Most software cost models can be described five parameters : size,
process, personnel, environment and required quality.
1. The size of the end product which is typically measured in terms of the
number of source lines or the number of function points developed to
achieve the required functionality.
2. The process used to produce the end product, the ability of the process is to
avoid non value adding activities
3. The capabilities of software engineering personnel, and particularly their
experience with the computer science issues and the applications domain
issues of the project
4. The environment, which is made up of the tools and techniques available to
support efficient software development and to automate the process
5. The required quality of the product, including its features, performance,
reliability, and adaptability
Software Economics
• The following equation shows the relationship between size, process,
personnel, environment, quality parameters and between the
estimated cost

Effort = (Personnel) (Environment) (Quality) ( Sizeprocess)

• Here one important feature of software economics is the

relationship between effort and size exhibits is a diseconomy of
scale.
• It indicates that more software we build it consumes more
expensive per unit of the software.
Software Economics
• So the per line cost of smaller applications is less than for the larger
applications.
• The following diagram shows 3 generations software economics in the
form of basic technology advancement in tools, components and
processes.
Software Economics
Software Economics
• The phases represents the life cycle of software business in the
organization.
• We can define the three generations of software development as
follows:
1.Conventional:
• The software is developed in conventional manner between 1960 and 1970.
• Organizations used custom tools, custom processes, and virtually custom components
built in primitive languages
• Here the performance of the project is highly predictable and cost, schedule and quality
objectives were always under achieved
Software Economics
2. Transition:
• This is middle age of the software development which is between 1980 and
1990.
• At this time some software engineering principles are formed and organizations
used repeatable and off the shelf tools.
• During this phase custom components are built in higher level languages and
Some of the components were available commercially such as operating system,
database management system, networking, and graphical user interface.

3. Modern practices:
• This phase of software development process started in year 2000 and later.
• In this phase software development is treated as production.
• Here we use integrated automation environments, off the shelf components.
Pragmatic Software Cost Estimation
• One critical problem in software cost estimation is a lack of well
documented case studies of projects that used an iterative
development approach.
• Software industry has inconsistently defined metrics or atomic units
of measure the data.
• It is hard enough to collect a homogeneous set of project data within
one organization with different processes, languages, domains, and so
on.
Software Economics
• There have been many debates among developers and vendors of
software cost estimation models and tools.
1. Which cost estimation model to use?
2. Whether to measure software size in source lines of code or function points.
3. What constitutes a good estimate?
Software Economics
• There are several popular cost estimation models
• COCOMO is also one of the most open and well documented cost estimation
models.
• SLOC worked well in applications that were predominantly custom built &
SLOC measurement was easy to automate.
• Most real world use of cost models is bottom up rather than top down.
Software Economics
• A good estimate has the following attributes:
• It is conceived and supported by the project manager, architecture team,
development team, and test team accountable for performing the work
• It is accepted by all the stake holders.
Software Economics
• The above figure illustrates the predominant practice:
• The software project manager defines the target cost of the software, and
then manipulates the parameters and sizing until the target cost can be
justified.
• The rationale for the target cost maybe to win a proposal, to solicit customer
funding, to attain internal corporate funding, or to achieve some other goal.
• In fact, it is absolutely necessary to analyze the cost risks and understand the
sensitivities and trade-offs objectively.
• It forces the software project manager to examine the risks associated with
achieving the target costs and to discuss this information with other
stakeholders.
Improving Software Economics
• Five basic parameters of the software cost model are:
1. Reducing the size or complexity of what needs to be developed.
2. Improving the development process.
3. Using more-skilled personnel and better teams (not necessarily the same
thing).
4. Using better environments (tools to automate the process).
5. Trading off or backing off on quality thresholds.
• The following table lists some of the technology developments,
process improvement efforts, and management approaches targeted
at improving the economics of software development and integration.
Improving Software Economics
Reducing Software Product Size
• The most significant way to improve affordability and return on investment (ROI)
is usually to produce a product that achieves the design goals with the minimum
amount of human-generated source material.

• Component-based development is introduced as the general term for reducing the

"source" language size to achieve a software solution.
• Reuse, object-oriented technology, automatic code production, and higher order
programming languages are all focused on achieving a given system with fewer lines of
human-specified source directives (statements).
• Size reduction is the primary motivation behind improvements in:
• Higher order languages (such as C++, Ada 95, Java, Visual Basic)
• Automatic code generators (CASE tools, visual modeling tools, GUI builders)
• Reuse of commercial components (operating systems, windowing environments, database management
systems, middleware, networks), and
• Object-oriented technologies (Unified Modeling Language, visual modeling tools, architecture
frameworks).
Reducing Software Product Size
• The reduction is defined in terms of human-generated source
material.
• In general, when size-reducing technologies are used, they reduce the
number of human-generated source lines.
• Languages
• Universal function points (UFPs1) are useful estimators for language-
independent, early life-cycle estimates.
• The basic units of function points are external user inputs, external outputs,
internal logical data groups, external data interfaces, and external inquiries.
• SLOC metrics are useful estimators for software after a candidate solution is
formulated and an implementation language is known.
Reducing Software Product Size
• Object-oriented Methods and Visual Modeling
• Object-oriented programming languages appear to benefit both software productivity
and software quality.
• The fundamental impact of object-oriented technology is in reducing the overall size of
what needs to be developed.
• The designers use a modeling language or diagrammatic models which are understood
very easily.
• An object-oriented model of the problem and its solution encourages a common
vocabulary between the end users of a system and its developers, thus creating a shared
understanding of the problem being solved.
• The use of continuous integration creates opportunities to recognize risk early and make
incremental corrections without destabilizing the entire development effort.
• An object-oriented architecture provides a clear separation of concerns among disparate
elements of a system, creating firewalls that prevent a change in one part of the system
from rending the fabric of the entire architecture.
Reducing Software Product Size
• Booch also summarized five characteristics of a successful object-
oriented project.
1. A ruthless focus on the development of a system that provides a well
understood collection of essential minimal characteristics.
2. The existence of a culture that is centered on results, encourages
communication, and yet is not afraid to fail.
3. The effective use of object-oriented modeling.
4. The existence of a strong architectural vision.
5. The application of a well-managed iterative and incremental development
life cycle.
Reducing Software Product Size
• Reuse
• Reuse in order to minimize development costs while achieving all the other
required attributes of performance, feature set, and quality and also
achieving a return on investment.
• Most truly reusable components of value are transitioned to commercial
products supported by organizations with the following characteristics:
• They have an economic motivation for continued support.
• They take ownership of improving product quality, adding new features, and
transitioning to new technologies.
• They have a sufficiently broad customer base to be profitable.
Reducing Software Product Size
• The cost of developing a reusable component is not trivial. The
following figure examines the economic trade-offs.
• The steep initial curve illustrates the economic obstacle to developing
reusable components.
Reducing Software Product Size
• Commercial Components
• A common approach being pursued today in many domains is to maximize
integration of commercial components and off-the-shelf products.
• While the use of commercial components is certainly desirable as a means of
reducing custom development, it has not proven to be straightforward in
practice.
Reducing Software Product Size
• Some of the advantages and disadvantages of using commercial
components
Improving Software Processes
• Three distinct process perspectives are:
• Metaprocess:
• An organization's policies, procedures, and practices for pursuing a software-intensive line of
business.
• The focus of this process is on organizational economics, long-term strategies, and software
ROI.
• Macroprocess:
• A project's policies, procedures, and practices for producing a complete software product
within certain cost, schedule, and quality constraints.
• The focus of the macro process is on creating an adequate instance of the Meta process for a
specific set of constraints.
• Microprocess:
• A project team's policies, procedures, and practices for achieving an artifact of the software
process.
• The focus of the micro process is on achieving an intermediate product baseline with adequate
quality and adequate functionality as economically and rapidly as practical.
Improving Software Processes
Improving Software Processes
• An underlying premise for most process improvements
• In a perfect software engineering world with a perfect problem description,
an obvious solution space, a development team of experienced geniuses,
adequate resources, and stakeholders with common goals, we could execute
a software development process in one iteration with almost no scrap and
rework.
• Because we work in an imperfect world, however, we need to manage
engineering activities so that scrap and rework profiles do not have an impact
on the win conditions of any stakeholder.
Improving Team Effectiveness
• Teamwork is much more important than the sum of the individuals.
• With software teams, a project manager needs to configure a balance
of solid talent with highly skilled people in the leverage positions.
• The following are the facts to consider:
• A well-managed project can succeed with a nominal engineering team.
• A mismanaged project will almost never succeed, even with an expert team
of engineers.
• A well-architected system can be built by a nominal team of software
builders.
• A poorly architected system will flounder even with an expert team of
builders.
Improving Team Effectiveness
• Boehm five staffing principles are
1. The principle of top talent: Use better and fewer people
2. The principle of job matching: Fit the tasks to the skills and motivation of
the people available.
3. The principle of career progression: An organization does best in the long
run by helping its people to self-actualize.
4. The principle of team balance: Select people who will complement and
harmonize with one another
5. The principle of phase-out: Keeping a misfit on the team doesn't benefit
anyone
Improving Team Effectiveness
• Software project managers need many leadership qualities in order to enhance
team effectiveness.
• The following are some crucial attributes of successful software project managers:
1. Hiring skills.
Placing the right person in the right job seems obvious but is surprisingly hard to achieve.
2. Customer-interface skill:
Avoiding adversarial relationships among stakeholders is a prerequisite for success.
3. Decision-making skill
A decision-making skill seems obvious despite its intangible definition.
4. Team-building skill.
Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas,
transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a
team direction.
5. Selling skill
Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell
candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements
against objectives. In practice, selling requires continuous negotiation, compromise, and empathy
Improving Automation Through
Software Environments
• The tools and environment used in the software process generally have a
linear effect on the productivity of the process.
• Planning tools, requirements management tools, visual modeling tools,
compilers, editors, debuggers, quality assurance analysis tools, test tools,
and user interfaces provide crucial automation support for evolving the
software engineering artifacts.
• Configuration management environments provide the foundation for
executing and instrument the process.
• Automation generally allows improvements of 20% to 40% in effort.
• Tools and environments must be viewed as the primary delivery vehicle for
process automation and improvement
Improving Automation Through
Software Environments
• Round-trip engineering describes the key capability of environments that
support iterative development.
• As we have moved into maintaining different information repositories for the
engineering artifacts, we need automation support to ensure efficient and
error-free transition of data from one artifact to another.
• Forward engineering is the automation of one engineering artifact from
another, more abstract representation.
• For example, compilers and linkers have provided automated transition of source code
into executable code.
• Reverse engineering is the generation or modification of a more abstract
representation from an existing artifact
• For example, creating a visual design model from a source code representation
Improving Automation Through
Software Environments
• Economic improvements associated with tools and environments.
• It is common for tool vendors to make rela- tively accurate individual
assessments of life-cycle activities to support claims about the potential
economic impact of their tools.
• Requirements analysis and evolution activities consume 40% of life-cycle costs.
• Software design activities have an impact on more than 50% of the resources.
• Coding and unit testing activities consume about 50% of software development effort
and schedule.
• Test activities can consume as much as 50% of a project's resources.
• Configuration control and change management are critical activities that can consume as
much as 25% of resources on a large-scale project.
• Documentation activities can consume more than 30% of project engineering resources.
• Project management, business administration, and progress assessment can consume as
much as 30% of project budgets.
Achieving Required Quality
• Software best practices are derived from the development process and technologies
• Key practices that improve overall software quality include the following:
• Focusing on driving requirements and critical use cases early in the life cycle, focusing on
requirements completeness and traceability late in the life cycle, and focusing throughout the
life cycle on a balance between requirements evolution, design evolution, and plan evolution
• Using metrics and indicators to measure the progress and quality of an architecture as it
evolves from a high-level prototype into a fully compliant product
• Providing integrated life-cycle environments that support early and continuous configuration
control, change management, rigorous design methods, document automation, and regression
test automation
• Using visual modeling and higher level languages that support architectural control,
abstraction, reliable programming, reuse, and self-documentation
• Early and continuous insight into performance issues through demonstration-based
evaluations
Achieving Required Quality
Peer Inspections: A Pragmatic View
• Peer inspections is the key aspect of a quality system.
• Transitioning engineering information from one artifact set to another, thereby
assessing the consistency, feasibility, understandability, and technology
constraints inherent in the engineering artifacts
• Major milestone demonstrations that force the artifacts to be assessed against
tangible criteria in the context of relevant use cases
• Environment tools (compilers, debuggers, analyzers, automated test suites) that
ensure representation rigor, consistency, completeness, and change control
• Life-cycle testing for detailed insight into critical trade-offs, acceptance criteria,
and requirements compliance
• Change management metrics for objective insight into multiple-perspective
change trends and convergence or divergence from quality and progress goals
• All authors of software and documentation should have their products
scrutinized as a natural by-product of the process.