1Q.

Barry Boehm's "Industrial Software Conventional work breakdown reduce the amount of human-
Metrics Top 10 List” structures are prematurely structured generated source code and custom
around the product design. Figure 10-1 development.
It is a good, objective characterization of shows a typical conventional WBS that has
the state of software development. been structured primarily around the 4. Establish a change
subsystems of its product architecture, then management environment. The
1. Finding and fixing a software further decomposed into the components
dynamics of iterative
problem after delivery costs 100 of each subsystem. A WBS is the
architecture for the financial plan. development, including
times more than finding and fixing concurrent workflows by
the problem in early design phases. Conventional work breakdown structures different teams working on
2. You can compress software are prematurely decomposed, planned, and shared artifacts, necessitates
development schedules 25% of budgeted in either too little or too much objectively controlled baselines
nominal, but no more. detail. Large software projects tend to be .
3. For every $1 you spend on over planned and small projects tend to be 5. Enhance change
development, you will spend $2 on under planned. The basic problem with freedom through tools that
maintenance. planning too much detail at the outset is support round-trip engineering.
4. Software development and that the detail does not evolve with the Round-trip engineering is the
maintenance costs are level of fidelity in the plan. environment support necessary to
primarily a function of the automate and synchronize
Conventional work breakdown structures
number of source lines of engineering information in
are project-specific, and cross-project different formats(such as
code. comparisons are usually difficult or
5. Variations among people account requirements specifications,
impossible. With no standard WBS design models, source code,
for the biggest differences in structure, it is extremely difficult to
software productivity. executable code, test cases).
compare plans, financial data, schedule
6. The overall ratio of software to data, organizational efficiencies, cost 6. Capture design artifacts in
hardware costs is still growing. In trends, productivity trends, or quality rigorous, model-based notation. A model
1955 it was 15:85; in 1985, 85:15. trends across multiple projects. based approach (such as UML) supports
7. Only about 15% of software the evolution of semantically rich
development effort is devoted to 3Q. THE PRINCIPLES OF graphical and textual design notations.
programming.
8. Software systems and MODERN SOFTWARE 7. Instrument the process for
products typically cost 3 MANAGEMENT objective quality control and progress
times as much per SLOC as assessment. Life-cycle assessment of the
individual software Top 10 principles of modern software progress and the quality of all intermediate
programs. Software-system products must be integrated into the
management are. (The first five, which are
products (i.e., system of process.
the main themes of my definition of an
systems) cost 9 times as 8. Use a demonstration-based
iterative process, are summarized in
much. approach to assess intermediate
Figure 4-1.)
9. Walkthroughs catch 60% of the artifacts.
errors
1. Base the process on an
10. 80% of the contribution comes architecture-first approach. This 9. Plan intermediate releases
from 20% of the contributors. requires that a demonstrable in groups of usage
balance be achieved among the scenarios with evolving
2Q. CONVENTIONAL WBS driving requirements, the levels of detail. It is essential
architecturally significant design that the software
ISSUES decisions, and the life-cycle plans management process drive
before the resources are committed toward early and continuous
for full-scale development. demonstrations within the
Work Breakdown Structure
Work breakdown structure (WBS) is the 2. Establish an iterative life-cycle operational context of the
vehicle for budgeting and collecting costs. process that confronts risk early. system, namely its use cases.
To monitor and control a project's financial With today's sophisticated 10. Establish a configurable
performance, the software project man1ger software systems, it is not possible process that is economically
must have insight into project costs and to define the entire problem, scalable. No single process is
how they are expended. The structure of design the entire solution, build the suitable for all software
cost accountability is a serious project software, and then test the end developments.
planning constraint. product in sequence. Instead, an
iterative process that refines the
problem understanding, an
Conventional work breakdown effective solution, and an effective
structures frequently suffer from three plan over several iterations
fundamental flaws. encourages a balanced treatment of
all stakeholder objectives. Major
1. They are prematurely structured risks must be addressed early to
around the product design. increase predictability and avoid
expensive downstream scrap and
2. They are prematurely decomposed, rework.
planned, and budgeted in either too 3. Transition design methods to
much or too little detail. emphasize component-based
3. They are project-specific, and cross- development. Moving from a line-
project comparisons are usually of-code mentality to a component-
difficult or impossible. based mentality is necessary to
 4Q. SOFTWARE PROCESS 6Q. Boehm five staffing principles are
WORKFLOWS
The term WORKFLOWS is used to mean 1. The principle of top talent: Use
a thread of cohesive and mostly sequential better and fewer people
activities. Workflows are mapped to 2. The principle of job matching:
product artifacts There are seven top-level Fit the tasks to the skills and
workflows: motivation of the people
available.
1. Management workflow: controlling
the process and ensuring win 3. The principle of career
conditions for all stakeholders progression: An
organization does best in
2. Environment workflow: the long run by helping its
automating the process and people to self-actualize.
evolving the maintenance 4. The principle of team balance:
environment Select people who will
3. Requirements workflow: analyzing complement and harmonize with
the problem space and evolving the one another
requirements artifacts 5. The principle of phase-out:
Keeping a misfit on the team
4. Design workflow: modeling the
doesn't benefit anyone
solution and evolving the
architecture and design artifacts
Software project managers need many
5. Implementation workflow:
leadership qualities in order to enhance
programming the
team effectiveness. The following are
components and evolving
some crucial attributes of successful
the implementation and
software project managers that deserve
deployment artifacts
much more attention:
6. Assessment workflow: assessing 1. Hiring skills.
the trends in process and product Few decisions
quality are as important
as hiring
7. Deployment workflow:
decisions.
transitioning the end products to Placing the
the user 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. The
jillion books written about
management have failed to
provide a clear definition of
this attribute. We all know a
good leader when we run
into one, and decision-
5Q Software Change Orders making skill seems obvious
The atomic unit of software work that is despite its intangible
authorized to create, modify or obsolesce definition.
components within a configuration
4. Team-building skill.
baseline is called a software change orders
Teamwork requires that a
(SCO)The basic fields of the SCO are
manager establish trust,
Title, description, metrics, resolution,
motivate progress, exploit
assessment & disposition eccentric prima donnas,
Software Change Order Database transition average people
Managing change is one of the
fundamental primitives of an iterative into top performers,
development process. With greater change eliminate misfits, and
freedom, a project can iterate more consolidate diverse opinions
productively. This flexibility increases the into a team direction.
content, quality, and number of iterations 5. Selling skill. Successful project
that a project can achieve within a given managers must sell all
schedule. Change freedom has been stakeholders (including
achieved in practice through automation, themselves) on decisions and
and today's iterative development priorities, sell candidates on job
environments carry the burden of change positions, sell changes to the
management. change management
 status quo in the face of
resistance, and sell achievements
against objectives. In practice,
selling requires continuous
negotiation, compromise, and
empathy 8Q. MAJOR MILESTONES
7Q. MINOR MILESTONES
For most iterations, which have a one- The four major milestones occur at the
month to six-month duration, only two transition points between life-cycle phases.
minor milestones are needed: the iteration They can be used in many different
process models, including the
readiness review and the iteration
conventional waterfall model. In an
assessment review.
iterative model, the major milestones are
used to achieve concurrence among all
 Iteration Readiness Review. stakeholders on the current state of the
This informal milestone is project. Different stakeholders have very
conducted at the start of different concerns:
each iteration to review the
detailed iteration plan and
the evaluation criteria that  Customers: schedule and
have been allocated to this budget estimates,
iteration. feasibility, risk assessment,
requirements
 Iteration Assessment understanding, progress,
Review. This informal product line compatibility
milestone is conducted at
the end of each iteration to  Users: consistency
assess the degree to which with requirements and
the iteration achieved its usage scenarios,
objectives and satisfied its potential for
evaluation criteria, to accommodating
review iteration results, to growth, quality
review qualification test attributes
results (if part of the  Architects and systems
iteration), to determine the engineers: product line
amount of rework to be compatibility, requirements
done, and to review the changes, trade-off analyses,
impact of the iteration completeness and consistency,
results on the plan for balance among risk, quality,
subsequent iterations. and usability

The format and content of these minor  Developers: sufficiency of

milestones tend to be highly dependent requirements detail and usage
on the project and the organizational scenario descriptions, .
frameworks for component
culture. Figure 9-4 identifies the various
selection or development,
minor milestones to be considered when
resolution of development risk,
a project is being planned. product line compatibility,
sufficiency of the development
environment
 Maintainers: sufficiency of
product and documentation
artifacts, understandability,
interoperability with existing
systems, sufficiency of
maintenance environment
 Others: possibly many other
perspectives by stakeholders
such as regulatory agencies,
independent verification and
validation contractors, venture
capital investors,
subcontractors, associate
contractors, and sales and
marketing teams
 developed as new
generations of a legacy
system (with a mature WBS)
or in the context of existing Metric Purpose Perspectives
9Q. EVOLUTIONARY WORK organizational standards Iteration
(with preordained WBS planning,
BREAKDOWN STRUCTURES expectations). SLOC, function
plan vs.
Work and points, object
An evolutionary WBS should organize the actuals,
progress points, scenarios,
planning elements around the process managem
framework rather than the product test cases, SCOs
The WBS decomposes the character ent
framework. The basic recommendation of the project and maps it to the life indicator
for the WBS is to organize the hierarchy cycle, the budget, and the
as follows: Financial
personnel. Reviewing a WBS
provides insight into the important insight,
Budgeted Cost per month,
plan vs.
 First-level WBS elements are attributes, priorities, and structure cost and full-time staff per
the workflows (management, of the project plan. actuals,
expenditure month, percentage
environment, requirements, managem
s of budget expended
design, implementation, Another important attribute of a good ent
assessment, and deployment). WBS is that the planning fidelity inherent indicator
in each element is commensurate with the Resource
 Second-level elements are
current life-cycle phase and project state. plan vs.
defined for each phase of the
life cycle (inception, Staffing actuals, People per month
elaboration, construction, and 10Q. Seven Core Metrics and team hiring added, people per
transition). dynamics rate, month leaving
 Third-level elements are defined for Software metrics instrument the activities attrition
the focus of activities that produce and products of the software rate
the artifacts of each phase. development/integration process. Metrics Iteration
A default WBS consistent with the values provide an important perspective planning,
process framework (phases, for managing the process. The most useful managem SCOs opened vs.
workflows, and artifacts) is shown metrics are extracted directly from the Change ent SCOs closed, by
in Figure 10-2. This recommended evolving artifacts. There are seven core traffic and indicator type (0,1,2,3,4), by
structure provides one example of metrics that are used in managing a stability of release/component/
how the elements of the process modern process. schedule subsystem
framework can be integrated into a convergen
plan. It provides a framework for ce
estimating the costs and schedules of Seven core metrics that should be used on
Converge
each element, allocating them across all software projects. Three are Reworked SLOC
nce,
a project organization, and tracking Breakage per change, by type
management indicators and four are software
expenditures. and (0,1,2,3,4), by
scrap,
quality indicators. modularity release/component/s
The structure shown is quality
ubsystem
intended to be merely a starting indicator
point. It needs to be tailored to the Management Indicators: Converge
specifics of a project in many ways. Average hours per
nce,
Rework change, by type
• Work and progress (work performed over software
 Scale. Larger projects will have and (0,1,2,3,4), by
time) rework,
more levels and substructures. adaptability release/component/
quality
subsystem
 Organizational structure. • Budgeted cost and expenditures (cost indicator
Projects that include incurred over time) Test
subcontractors or span coverage/ Failure counts, test
multiple organizational adequacy, hours until failure,
entities may introduce • Staffing and team dynamics (personnel MTBF and
constraints that necessitate robustness by
changes over time) maturity
different WBS allocations. for use, release/component/
 Degree of custom quality subsystem
development. Depending on Quality Indicators: indicator
the character of the project,
there can be very different • Change traffic and stability (change
emphases in the requirements, traffic over time)
design, and implementation
workflows.
 Business context. Projects • Breakage and modularity (average
developing commercial breakage per change over time)
products for delivery to a
broad customer base may
require much more elaborate • Rework and adaptability (average rework
substructures for the per change over time)
deployment element.
 Precedent experience. Very • Mean time between failures (MTBF) and
few projects start with a maturity (defect rate over time)
clean slate. Most of them are
 changes), the deployment documents Analysis of the internal consistency
11Q. THE ARTIFACT SETS (cutover plan, training course, sales rollout and quality of the design model
kit), and the environment (hardware and Analysis of consistency with the
To make the development of a complete
software tools, process automation, & requirements models
software system manageable, distinct
documentation). Translation into
collections of information are organized
into artifact sets. Artifact represents implementation and
cohesive information that typically is Management set artifacts are evaluated, deployment sets and
developed and reviewed as a single entity. assessed, and measured through a notations (for example,
Life-cycle software artifacts are organized combination of the following: traceability, source code
into five distinct sets that are roughly  Relevant stakeholder review generation, compilation,
partitioned by the underlying language of  Analysis of changes between the linking) to evaluate the
current version of the artifact and consistency and
the set: management (ad hoc textual
previous versions completeness and the
formats), requirements (organized text and
Major milestone semantic balance between
models of the problem space), design information in the sets
(models of the solution space), demonstrations of the
balance among all artifacts Analysis of changes between
implementation (human-readable
and, in particular, the the current version of the
programming language and associated design model and previous
accuracy of the business
source files), and deployment (machine- versions (scrap, rework, and
case and vision artifacts
process able languages and associated defect elimination trends)
files). Subjective review of other
6.1.2 THE ENGINEERING SETS dimensions of quality
The engineering sets
consist of the Implementation set
requirements set, the The implementation set includes source
design set, the
implementation set, and code (programming language notations)
the deployment set. that represents the tangible
implementations of components (their
Requirements Set form, interface, and dependency
Requirements artifacts are evaluated, relationships)
assessed, and measured through a Implementation sets are human-
combination of the following: readable formats that are evaluated,
assessed, and measured through a
Analysis of consistency with the combination of the following:
release specifications of the Analysis of consistency with the
management set design models
Analysis of consistency between the  Translation into deployment
vision and the requirements models set notations (for example,
compilation and linking) to
 Mapping against the design, evaluate the consistency and
implementation, and completeness among artifact
deployment sets to evaluate sets
the consistency and
completeness and the  Assessment of component
semantic balance between source or executable files
THE MANAGEMENT SET against relevant evaluation
information in the different
The management set captures the artifacts sets criteria through inspection,
associated with process planning and analysis, demonstration, or
execution. These artifacts use ad hoc Analysis of changes testing
notations, including text, graphics, or between the current  Execution of stand-alone
whatever representation is required to version of component test cases that
requirements automatically compare
capture the "contracts" among project artifacts and
personnel (project management, architects, expected results with actual
previous versions
developers, testers, marketers, results
(scrap, rework, and
administrators), among stakeholders defect elimination  Analysis of changes between
(funding authority, user, software project trends) the current version of the
manager, organization manager, regulatory implementation set and
Subjective review of other previous versions (scrap,
agency), and between project personnel dimensions of quality
and stakeholders. Specific artifacts rework, and defect
elimination trends)
included in this set are the work
Design Set  Subjective review of other
breakdown structure (activity breakdown
UML notation is used to engineer dimensions of quality
and financial tracking mechanism), the
business case (cost, schedule, profit the design models for the solution. The
design set contains varying levels of Deployment Set
expectations), the release specifications
(scope, plan, objectives for release abstraction that represent the components The deployment set includes user
baselines), the software development plan of the solution space (their identities, deliverables and machine language
(project process instance), the release attributes, static relationships, dynamic
notations, executable software, and the
descriptions (results of release baselines), interactions). The design set is evaluated,
the status assessments (periodic snapshots assessed, and measured through a build scripts, installation scripts, and
of project progress), the software change combination of the following: executable target specific data necessary to
orders (descriptions of discrete baseline use the product in its target environment.
Deployment sets are evaluated, assessed, GUIs, RDBMS, networks,
and measured through a combination of middleware), and installation tools.
the following: 12Q. The Waterfall Model
13Q. CMM
Testing against the usage The Software Engineering Institute
scenarios and quality It remains one of the oldest strategies ever
attributes defined in the applied in the development of a software. (SEI) Capability Maturity Model
requirements set to evaluate It is also known as classic life model (CMM) specifies an increasing series
the consistency and which divides the entire software of levels of a software development
completeness and the~ development into 5 main phases.
They are: organization. The higher the level, the
semantic balance between better the software development
information in the two sets
1. Communication – Requirement process, hence reaching each level is
Testing the partitioning, an expensive and time-consuming
replication, and allocation gathering
process.
strategies in mapping
components of the 2. Planning – Estimation, Scheduling,
implementation set to Tracking Levels of CMM:
physical resources of the
deployment system (platform 3. Modelling – Analysis, Design Level One: Initial - The software process is
type, number, network characterized as inconsistent, and
topology) 4. Construction – Coding, Testing
occasionally even chaotic. Defined
 Testing against the defined processes and standard practices that
usage scenarios in the user 5. Deployment – Delivery, Support,
exist are abandoned during a crisis.
manual such as installation, Feed back
Success of the organization majorly
user-oriented dynamic
reconfiguration, mainstream depends on an individual effort, talent,
usage, and anomaly and heroics. The heroes eventually move
management on to other organizations taking their
wealth of knowledge or lessons learnt
 Analysis of changes with them.
between the current version
of the deployment set and
previous versions (defect Level Two: Repeatable - This level of
elimination trends, Software Development Organization has a
performance changes) basic and consistent project management
processes to track cost, schedule, and
Subjective review of other
functionality. The process is in place to
dimensions of quality
Phases of Waterfall Model repeat the earlier successes on projects
with similar applications. Program
Each artifact set is the predominant
The Waterfall was proposed with feedback management is a key characteristic of a
development focus of one phase of the life
cycle; the other sets take on check and loops. However, most of the organizations level two organization.
balance roles. each phase has a avoid these loops. Thus, this model is also
predominant focus: Requirements are the called Linear sequential model. Level Three: Defined - The software
focus of the inception phase; design, the process for both management and
elaboration phase; implementation, the All these phases are cascaded to eachother engineering activities are documented,
construction phase; and deploy-ment, the in which the progress is seen as flowing standardized, and integrated into a
transition phase. The management artifacts steadily downwards (like a waterfall) standard software process for the entire
also evolve, but at a fairly constant level through the phases. The next phase is organization and all projects across the
across the life cycle. started only after the defined set of goals organization use an approved, tailored
are achieved for the previous phase and it version of the organization's standard
Most of today's software is signed off, so the name “Waterfall software process for developing,testing
development tools map closely to model”
one of the five artifact sets. and maintaining the application.
Advantages:
1.Management: scheduling, Level Four: Managed - Management can
workflow, defect tracking, 1. It allows for departmentalization and effectively control the software
control. development effort using precise
change management,
. measurements. At this level, organization
documentation, spreadsheet,
resource management and 2.It is easy to manage due to rigidity of the set a quantitative quality goal for both
model. software process and software
presentation tools
maintenance. At this maturity level, the
2. Requirements: requirements 3. In this model, phases are processed and performance of processes is controlled
management tools completed one aat a time and they do not using statistical and other quantitative
3. Design: visual modeling tools overlap. It does work well for smaller techniques, and is quantitatively
4. Implementation: projects predictable.
compiler/debugger tools,
code analysis tools, test Disadvantages: Level Five: Optimizing - The Key
coverage analysis tools, and characteristic of this level is focusing on
test management tools 1. It is difficult to estimate time and cost continually improving process
5. Deployment: test coverage and test for each phase of the development process.
performance through both incremental
automation tools, network
and innovative technological
management tools, commercial 2. Not good for complex and object-
components (operating systems, oriented projects improvements. At this level, changes to
the process are to improve the process
performance and at the same time
maintaining statistical probability to Managed, and Optimizing. Version 2.0
achieve the established quantitative was published in 2018 (Version 1.3 was One important aspect of software
process-improvement objectives. published in 2010, and is the reference economics (as represented within today's
model for the remaining information in software cost models) is that the
relationship between effort and size
this wiki article). CMMI is registered in
exhibits a diseconomy of scale. The
the U.S. Patent and Trademark Office by diseconomy of scale of software
CMU development is a result of the process
exponent being greater than 1.0. Contrary
Originally CMMI addresses three areas of to most manufacturing processes, the more
interest: software you build, the more expensive it
is per unit item.
Figure 2-1 shows three generations
1. Product and service development of basic technology advancement in tools,
– CMMI for Development components, and processes. The required
(CMMI-DEV), levels of quality and personnel are
2. Service establishment, assumed to be constant. The ordinate of
management, – CMMI for the graph refers to software unit costs (pick
Services (CMMI-SVC), and your favourite: per SLOC, per function
3. Product and service acquisition – point, per component) realized by an
Levels Of CMM organization. The three generations of
CMMI for Acquisition (CMMI-
ACQ). software development are defined as
Key Process Areas (KPA’s):  follows:
Each of these KPA’s defines the basic
In version 2.0 these three areas (that Conventional: 1960s and 1970s,
requirements that should be met by a
previously had a separate model each) craftsmanship. Organizations used
software process in order to satisfy the
were merged into a single model. custom tools, custom processes, and
KPA and achieve that level of maturity. 
virtually all custom components
15Q. SOFTWARE ECONOMICS built in primitive languages. Project
Conceptually, key process areas form the performance was highly predictable
basis for management control of the Most software cost models can be in that cost, schedule, and quality
software project and establish a context in abstracted into a function of five basic objectives were almost always
which technical methods are applied, work parameters: size, process, personnel, underachieved.
products like models, documents, data, environment, and required quality.
reports, etc. are produced, milestones are Transition: 1980s and 1990s, software
established, quality is ensured and change 1. The size of the end product (in engineering. Organiz:1tions used more-
human-generated components), repeatable processes and off-the-shelf
is properly managed.  which is typically quantified in tools, and mostly (>70%) custom
terms of the number of source components built in higher level
instructions or the number of languages. Some of the components
function points required to develop (<30%) were available as commercial
the required functionality products, including the operating system,
database management system, networking,
2. The process used to produce the and graphical user interface.
end product, in particular the ability
of the process to avoid non-value- Modern practices: 2000 and later,
adding activities (rework, software production. This book's
bureaucratic delays, philosophy is rooted in the use of managed
communications overhead) and measured processes, integrated
automation environments, and mostly
(70%) off-the-shelf components. Perhaps
3. The capabilities of software as few as 30% of the components need to
engineering personnel, and be custom built. Technologies for
particularly their experience with environment automation, size reduction,
the computer science issues and the and process improvement are not
applications domain issues of the independent of one another. In each new
project era, the key is complementary growth in
all technologies. For example, the process
4. The environment, which is made advances could not be used successfully
14Q.Capability Maturity up of the tools and techniques without new component technologies and
increased tool automation.
Model Integration (CMMI) available to support efficient
It is a process level improvement training software development and to
and appraisal program. Administered by automate the process
the CMMI Institute, a subsidiary of 5. The required quality of the product,
ISACA, it was developed at Carnegie including its features, performance,
Mellon University (CMU). It is required reliability, and adaptability
by many U.S. Government contracts,
especially in software development. CMU The relationships among these parameters
claims CMMI can be used to guide process and the estimated cost can be written as
improvement across a project, division, or follows:
an entire organization. CMMI defines the
following maturity levels for processes: Effort = (Personnel) (Environment) (Quality)
Initial, Managed, Defined, Quantitatively (Sizeprocess)
16Q. Improving 17Q. IMPROVING SOFTWARE
PROCESSES 19Q. THE PRINCIPLES OF
Software Economics Process is an overloaded term. Three CONVENTIONAL
Five basic parameters of the software cost distinct process perspectives are. SOFTWARE
model are
Metaprocess: an organization's
ENGINEERING
1.Reducing the size or complexity of
policies, procedures, and practices
what needs to be developed. for pursuing a software-intensive line
of business. The focus of this process 1.Make quality Quality must be
2. Improving the development process. quantified and mechanisms put into place
is on organizational economics, long-
3. Using more-skilled personnel and term strategies, and software ROI. to motivate its achievement
better teams (not necessarily the Macroprocess: a project's policies, 2.High-quality software is possible.
same thing). procedures, and practices for
producing a complete software Techniques that have been demonstrated
4. Using better environments (tools to product within certain cost, schedule, to increase quality include involving the
automate the process). and quality constraints. The focus of
the macro process is on creating an customer, prototyping, simplifying design,
5. Trading off or backing off on adequate instance of the Meta
quality thresholds. conducting inspections, and hiring the best
process for a specific set of
constraints. people
These parameters are given in priority
order for most software domains. Table 3- Microprocess: a project team's 3.Give products to customers early. No
policies, procedures, and practices
1 lists some of the technology matter how hard you try to learn users'
for achieving an artifact of the
developments, process improvement software process. The focus of the
efforts, and management approaches needs during the requirements phase, the
micro process is on achieving an
targeted at improving the economics of intermediate product baseline with most effective way to determine real needs
software development and integration. adequate quality and adequate
is to give users a product and let them play
functionality as economically and
rapidly as practical. with it
Although these three levels of process
overlap somewhat, they have different 4.Determine the problem before writing
objectives the requirements. When faced with what
they believe is a problem, most engineers
18Q. IMPROVING TEAM rush to offer a solution. Before you try to
EFFECTIVENESS
Teamwork is much more important than solve a problem, be sure to explore all the
the sum of the individuals. With software alternatives and don't be blinded by the
teams, a project manager needs to
configure a balance of solid talent with obvious solution
highly skilled people in the leverage 5.Evaluate design alternatives. After the
positions. Some maxims of team
management include the following: requirements are agreed upon, you must
 A well-managed project can
examine a variety of architectures and
succeed with a nominal engineering
team. algorithms. You certainly do not want to
 A mismanaged project will almost use” architecture" simply because it was
never succeed, even with an expert
team of engineers. used in the requirements specification.
 A well-architected system can be 6.Use an appropriate process model.
built by a nominal team of software
builders. Each project must select a process that
 A poorly architected system will makes ·the most sense for that project on
flounder even with an expert team
of builders. the basis of corporate culture, willingness
to take risks, application area, volatility of
requirements, and the extent to which
requirements are well understood.
7.Use different languages for different
phases. Our industry's eternal thirst for
simple solutions to complex problems has
driven many to declare that the best
development method is one that uses the
same notation through-out the life cycle.
8.Minimize intellectual distance. To Most real-world use of cost models
is bottom-up (substantiating a target cost)
minimize intellectual distance, the rather than top-down (estimating the
software's structure should be as close as "should" cost). Figure 2-3 illustrates the
predominant practice: The software project
possible to the real-world structure manager defines the target cost of the
9.Put techniques before tools. An software, and then manipulates the
parameters and sizing until the target cost
undisciplined software engineer with a can be justified. The rationale for the target
cost maybe to win a proposal, to solicit
tool becomes a dangerous, undisciplined customer funding, to attain internal
software engineer corporate funding, or to achieve some
other goal.
10.Get it right before you make it
faster. It is far easier to make a working
program run faster than it is to make a fast
program work. Don't worry about
optimization during initial coding

20Q. 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 from
actual projects are highly suspect in terms
of consistency and comparability. It is hard
enough to collect a homogeneous set of
project data within one organization; it is
extremely difficult to homog-enize data
across different organizations with
different processes, languages, domains,
and so on.
There have been many debates among
developers and vendors of software cost
estimation models and tools.
Three topics of these debates are of
particular interest here:

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?

There are several popular cost estimation

models (such as COCOMO,
CHECKPOINT, ESTIMACS, Knowledge
Plan, Price-S, ProQMS, SEER, SLIM,
SOFTCOST, and SPQR/20), CO COMO is
also one of the most open and well-
documented cost estimation models.

The general accuracy of conventional cost

models (such as COCOMO) has been
described as "within 20% of actuals, 70%
of the time."