Software Engineering & Project Management

BCS501 (3:0:0)

Software Engineering: A Practitioners Approach – Roger S. Pressman, 7th Edition, McGraw-Hill

2010

Overview
➢Project Management
➢Project Management Spectrum, People, Product
➢Process, Project
➢Software Project Estimation
➢Decomposition Techniques
➢Empirical Estimation Models
➢Report writing
 Project Management Spectrum
1. The People: In fact, the “people factor” is so important that the
Software Engineering Institute has developed a 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
2. The Product: Before a project can be planned, product
objectives and scope should be established, alternative
solutions should be considered, and technical and
management constraints should be identified.
3. The Process:A software process provides the framework from
which a comprehensive plan for software development can be
established.
4. The Project:We conduct planned and controlled software Fig1:
Four P’s of Management projects for one primary reason—it is the only known way to Spectrum manage complexity
 you do for a project is selecting the staff. .
People . . The success of the software
• In a study published by the IEEE development organization is very, very
much associated with the ability to
[Cur88], the engineering vice recruit good people.
presidents of three major technology • VP 3: The only rule I have in management
companies were asked what was the is to ensure I have good people—real
most important contributor to a good people—and that I grow good
successful software project. They people—and that I provide an
answered in the following way. environment in which good people can
• VP 1: I guess if you had to pick one thing out produce.
The Stakeholders: The software process (and every
that is most important in our environment,
software project) is populated by stakeholders who can
I’d say it’s not the tools that we use, it’s the be
people. categorized into one of five constituencies
• VP 2: The most important ingredient that 1. Senior managers
was successful on this project was having 2. Project (technical) managers
smart people . . . very little else matters in 3. Practitioners
my opinion. . . . The most important thing 4. Customers
5. End users • The Software Teams: There are almost as many
human organizational structures for software
Team Leaders: Project management is a people-intensive development as there are organizations that
activity, and for this reason, competent practitioners often develop software. For better or worse,
make poor team leaders. organizational structure cannot be easily
modified.
In an excellent book of technical leadership, Jerry Weinberg
• The “best” team structure depends on the
[Wei86] suggests an MOI model of leadership:
management style of your organization, the
Motivation
number of people who will populate the team
Organization and their skill levels, and the overall problem
Ideas or innovation difficulty.
Another view [Edg95] of the characteristics that define an • Mantei [Man81] describes seven project
effective project manager emphasizes four key traits factors that should be considered when
1. Problem solving 2. Managerial identity 3. Achievement 4.
planning the structure of software engineering
teams.
Influence and team building.

People:
The Software Team
 with the closed paradigm but also much of the
innovation that occurs when using the random
paradigm.
4. A synchronous paradigm relies on the natural
compartmentalization of a problem and organizes
team members to work on pieces of the problem with
little active communication among themselves
Constantine [Con93] suggests four “organizational

paradigms” for software engineering teams:

People:Agile Teams
• Agile software development has been suggested
as an antidote to many of the problems that have
1. A closed paradigm structures a team along a traditional
plagued software project work. To review, the
hierarchy of authority. Such teams can work well when agile philosophy encourages customer
producing software that is quite similar to past efforts, but satisfaction and early incremental delivery of
they will be less likely to be innovative when working software, small highly motivated project teams,
within the closed paradigm. informal methods, minimal software engineering
2. A random paradigm structures a team loosely and work products, and overall development
depends on individual initiative of the team members. simplicity.
3. An open paradigm attempts to structure a team in a • The small, highly motivated project team, also
manner that achieves some of the controls associated called an agile team, adopts many of the
 characteristics of successful software project teams Uncertainty is common, resulting in a continuing
discussed in the preceding section and avoids many stream of changes that ratchets the project team
of the toxins that create problems. However, the
agile philosophy stresses individual (team member)
These characteristics of modern software— scale,
competency coupled with group collaboration as
critical success factors for the team.
uncertainty, and interoperability— are facts of life.
To deal with them effectively, you must establish
• To make effective use of the effective methods for coordinating the people who
competencies of each team member do the work.
and to foster effective collaboration
through a software project, agile
teams are self-organizing
Coordination and Communication
Issues
The scale of many development efforts is large,
leading to complexity, confusion, and significant
difficulties in coordinating team members.
 •
Produc •
•
t •
•
• At a minimum, the scope of the product must be A statement of software scope must be bounded.
established and bounded. That is, quantitative data (e.g., number of
• Scope is defined by answering the following questions: simultaneous users, target environment,
• Context. How does the software to be built fit into a larger system, maximum allowable
product, or business context, and what constraints are imposed as a Problem Decomposition:
result of the context? Problem decomposition, sometimes called
• Information objectives. What customer-visible data objects are partitioning or problem elaboration, is an activity
produced as output from the software? What data objects are that
required for input? sits
• Function and performance. What function does the software at the
perform to transform input data into output? Are any special core
performance characteristics to be addressed? of
• Software project scope must be unambiguous and
understandable at the management and technical
levels.
software requirements analysis. During the scoping (1) the functionality and content (information) that
activity no attempt is made to fully decompose the must be delivered and (2) the process that will be
problem. Rather, decomposition is applied in two major used to deliver it
areas:
response time) are stated explicitly, constraints and/or limitations (e.g., product cost restricts memory size)
are noted, and mitigating factors (e.g., desired algorithms are well understood and available in Java) are
described.

Process
• The framework activities that characterize the software process are applicable to all
software projects. The problem is to select the process model that is appropriate for
the software to be engineered by your project team.
• Your team must decide which process model is most appropriate for (1) the
customers who have requested the product and the people who will do the work, (2)
the characteristics of the product itself, and (3) the project environment in which the
software team works.
• When a process model has been selected, the team then defines a preliminary
project plan based on the set of process framework activities. Once the preliminary
plan is established, process decomposition begins. That is, a complete plan,
reflecting the work tasks required to populate the framework activities must
becreated
 Melding the Product and the
Process

Process Cont..
• Process Decomposition :
Process decomposition commences when the project manager asks, “How do we
accomplish this framework activity?” For example, a small, relatively simple project
might require the following work
tasks for the communication activity:
1.Develop list of clarification issues.
2. Meet with stakeholders to address
clarification issues.
3. Jointly develop a statement of scope.
4. Review the statement of scope with
all concerned.
5. Modify the statement of scope as
required
Such a project might require the following work tasks
for the communication
 The Project
• What are the signs that a software How does a manager act to avoid the problems project is
in jeopardy? just noted? Reel [Ree99] suggests a five-part
commonsense approach to software projects:
1. Software people don’t understand their customer’s
needs. 1. Start on the right foot
2. The product scope is poorly defined. 2. Maintain momentum
3. Changes are managed poorly. 3. Track progress
4. Make smart decisions
4. The chosen technology changes.
Sponsorship is lost [or was never properly 5. Conduct a post-mortem
obtained]. analysis
9. The project team lacks people with appropriate
skills.
10. Managers [and practitioners] avoid best practices
and lessons learned.
5. Business needs change [or are ill defined]. Boehm suggests an approach that addresses project
6. Deadlines are unrealistic. objectives, milestones and schedules, responsibilities,
7. Users are resistant. management and technical approaches, and required resources. W5 HH Principle 8.

Estimation for Software Projects

• Software project management begins • Estimation of resources, cost, and schedule for a
with a set of activities that are software engineering effort requires experience,
collectively called project planning. access to good historical information (metrics), and
• Before the project can begin, the software the courage to commit to quantitative predictions
team should estimate the work to be done, when qualitative information is all that exists.
the resources that will be required, and the Estimation carries inherent risk,1 and this risk leads
time that will elapse from start to finish. Once
these activities are accomplished, the
to uncertainty.
software team should establish a project Project complexity has a strong effect on the uncertainty
schedule that defines software engineering inherent in planning. Complexity, however, is a relative measure
tasks and milestones, identifies who is that is affected by familiarity with past effort.
responsible for conducting each task, and
specifies the intertask dependencies that may Project size is another important factor that can affect the
have a strong bearing on progress. accuracy and efficacy of estimates. As size increases, the
interdependency among various elements of the Estimation risk is measured by the degree of uncertainty in the
software grows rapidly. quantitative estimates established for resources, cost, and
schedule. If project scope is poorly understood or project
The degree of structural uncertainty also has an requirements are subject to change, uncertainty and estimation
effect on estimation risk. In this context, structure risk become dangerously high
refers to the degree to which requirements have
been solidified, the ease with which functions can
be compartmentalized, and the hierarchical
nature of the information that must be processed
 Project Planning

Software Scope and Feasibility

Software scope describes the functions and features that are to be delivered to end
users; the data that are input and output; the “content” that is presented to users as
a consequence of using the software; and the performance, constraints, interfaces,
and reliability that bound the system.
Scope is defined using one of two techniques:
1. A narrative description of software scope is developed after communication with
all stakeholders.
2. A set of use cases is developed by end users.

Once scope has been identified (with the concurrence of the customer), it is
reasonable to ask: “Can we build software to meet this scope? Is the project feasible
 Resources
• The second planning task is
estimation of the resources
required to accomplish the
software development effort.

Figure 2:Project resources

 Software Project Estimation
• Software cost and effort estimation will never be an Decomposition techniques take a divide-and-conquer
exact science. Too many variables—human, approach to software project estimation. By decomposing a
technical, environmental, political—can affect the project into major functions and related software
ultimate cost of software and effort applied to engineering activities, cost and effort estimation can be
develop it. performed in a stepwise fashion Empirical estimation
• To achieve reliable cost and effort estimates, a models can be used to complement decomposition
number of options arise: techniques and offer a potentially valuable estimation
1. Delay estimation until late in the project approach in their own right. A model is based on experience
(obviously, we can achieve 100 percent accurate (historical data) and takes the form.
estimates after the project is complete!).
2. Base estimates on similar projects that have
already been completed. where d is one of a number of estimated values (e.g., effort,
3. Use relatively simple decomposition techniques to cost, project duration) and vi are selected independent
generate project cost and effort estimates. parameters (e.g., estimated LOC or FP).
4. Use one or more empirical models for software
Automated estimation tools implement one or more
cost and effort estimation
decomposition techniques or empirical models and provide
an attractive option for estimating. In such systems, the developed are described. Cost and effort estimates are
characteristics of the development organization (e.g., derived from these data.
experience, environment) and the software to be

Decomposition Techniques
Software Sizing: The accuracy of a software project
estimate is predicated on a number of things: (1) the
degree to which you have properly estimated the
size of the product to be built; (2) the ability to
translate the size estimate into human effort,
calendar time, and dollars (a function of the
availability of reliable software metrics from past
projects); (3) the degree to which the project plan
reflects the abilities of the software team; and (4) the
stability of product requirements and the
environment that supports the software

• Software Sizing engineering effort

• Problem-Based Estimation

• An Example of LOC-Based Estimation

• An Example of FP-Based Estimation

• Process-Based Estimation

• An Example of Process-Based Estimation

• Estimation with Use Cases

• An Example of Use-Case–Based Estimation

• Reconciling Estimates
6. In general, the LOC/pm and FP/pm metrics
Problem-Based Estimation should be computed by project domain –
Important factors are team size, application
1. Start with a bounded statement of scope area, and complexity
2. Decompose the software into problem functions that can
• LOC and FP estimation differ in the
each be estimated individually
level of detail required for decomposition with
3. Compute an LOC or FP value for each function each value – For LOC, decomposition of
4. Derive cost or effort estimates by applying the LOC or functions is essential and should go into
FP values to your baseline productivity metrics (e.g., considerable detail (the more detail, the more
accurate the estimate) – For FP, decomposition
LOC/person- month or FP/person-month)
occurs for the five information domain
5. Combine function estimates to produce an overall estimate characteristics and the 14 adjustment factors
for the entire project .
 • External inputs, external outputs, external
inquiries, internal logical files, external interface files pm =
person-month
For both approaches, the planner uses lessons learned to estimate
an optimistic, most likely, and pessimistic size value for each
function or count
(for each information domain value)
• Then the expected size value S is computed as
follows: S = (Sopt + 4Sm + Spess)/6
• Historical LOC or FP data is then compared to S in
order to cross-check it
 Process-Based Estimation and
1. Identify the set of functions that the software needs
to perform as obtained from the project scope
2. Identify the series of framework activities that need
to be performed for each function
3. Estimate the effort (in person months) that will be
required to accomplish each software process activity
for each function.
4. Apply average labor rates (i.e., cost/unit effort) to the
effort estimated for each process activity.
5. Compute the total cost and effort for each function
and each framework activity (See table in Pressman,
p. 655).
6. Compare the resulting values to those obtained by
way of the LOC and FP estimates • If both sets of
estimates agree, then your numbers are highly
reliable • Otherwise, conduct further investigation
 and analysis concerning the function and activity
breakdown
This is the most commonly used of the two estimation techniques
(problem and process

References
• Software Engineering: A Practitioners Approach – Roger S.
Pressman, 7th Edition, McGraw-Hill 2010
• Software Engineering: Ian Somerville, 10th Edition, Pearson
Education, 2016.
• https://www.digimat.in/nptel/courses/video/106101061/L01.html