software engineering syllabus (cgpa )€¦ · software engineering syllabus (cgpa ) software...

24
By : Prof. Mr.P.R.Patil Page 1 UNIT-V SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People c. Product d. Process e. Project f. Critical Practices Estimation for software project: g. Project Planning Process h. Software scope and feasibility i. Resources j. Decomposition Techniques k. Empirical Estimation Models l. Make/Buy Decision Project Scheduling: a. Task set for Software project b. Defining a task network c. Scheduling d. Earned Value Analysis Product Metrics: e. A framework for product metrics f. Software Quality g. Software Quality Factors ************************************************************************************* THE MANAGEMENT SPECTRUM Effective software project management focuses on the four P’s: people, product, process, and project. 1.The People Every organization needs to continually improve its ability to attract, develop, motivate, organize, and retain the workforce needed to accomplish its strategic business objectives”. The people capability maturity model defines the following key practice areas for software people: staffing, communication and coordination, work environment, performance management, training, compensation, competency analysis and development, career development, workgroup development, team/culture development, and others.

Upload: others

Post on 14-Jun-2020

38 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 1

UNIT-V

SOFTWARE ENGINEERING SYLLABUS (CGPA )

Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People c. Product d. Process e. Project f. Critical Practices Estimation for software project: g. Project Planning Process h. Software scope and feasibility i. Resources j. Decomposition Techniques k. Empirical Estimation Models l. Make/Buy Decision Project Scheduling: a. Task set for Software project b. Defining a task network c. Scheduling d. Earned Value Analysis Product Metrics: e. A framework for product metrics f. Software Quality g. Software Quality Factors

*************************************************************************************

THE MANAGEMENT SPECTRUM

Effective software project management focuses on the four P’s: people, product, process, and

project.

1.The People

“Every organization needs to continually improve its ability to attract, develop, motivate, organize,

and retain the workforce needed to accomplish its strategic business objectives”. The people

capability maturity model defines the following key practice areas for software people: staffing,

communication and coordination, work environment, performance management, training,

compensation, competency analysis and development, career development, workgroup

development, team/culture development, and others.

Page 2: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 2

Organizations that achieve high levels of People-CMM maturity have a higher likelihood of

implementing effective software project management practices.

The People-CMM is a companion to the Software Capability Maturity Model–Integration that guides

organizations in the creation of a mature

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.

Without this information, it is impossible to define reasonable(and accurate) estimates of the cost,

an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project

schedule that provides a meaningful indication of progress.

Once the product objectives and scope are understood, alternative solutions are considered. the

alternatives enable managers and practitioners to select a “best” approach.

3. The process

Software process provides the framework from which a comprehensive plan for software

development can be established. A small number of framework activities are applicable to all

software projects, regardless of their size or complexity. A number of different tasks set—tasks,

milestones, work products and quality assurance points—enable the framework activities to be

adapted to the characteristics of the software project and the requirements of the project team.

Finally, umbrella activities—such as software quality assurance, software configuration

management, and measurement—overlay the process model .Umbrella activities are independent

of any one framework activity and occur throughout the process.

4. The Project

We conduct planned and controlled software projects for one primary reason—it is the only known

way to manage complexity. To avoid project failure, a software project manager and the software

engineers who build the product must avoid a set of common warning signs, understand the critical

success factors that lead to good project management, and develop a commonsense approach for

planning, monitoring, and controlling the project.

PEOPLE

The Software Team

Mantei suggests three generic team organizations:

Page 3: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 3

Democratic decentralized (DD)

This software engineering team has no permanent leader. Rather, "task coordinators are appointed

for short durations and then replaced by others who may coordinate different tasks." Decisions on

problems and approach are made by group consensus. Communication among team members is

horizontal.

Controlled decentralized (CD)

This software engineering team has a defined leader who coordinates specific tasks and secondary

leaders that have responsibility for subtasks. Problem solving remains a group activity, but

implementation of solutions is partitioned among subgroups by the team leader. Communication

among subgroups and individuals is horizontal. Vertical communication along the control hierarchy

also occurs.

Controlled Centralized (CC)

Top-level problem solving and internal team coordination are managed by a team leader.

Communication between the leader and team members is vertical.

-Mantei describes seven project factors that should be considered when planning the structure of

software engineering teams:

• The difficulty of the problem to be solved.

• The size of the resultant program(s) in lines of code or function points

• The time that the team will stay together (team lifetime).

• The degree to which the problem can be modularized.

• The required quality and reliability of the system to be built.

• The rigidity of the delivery date.

• The degree of sociability (communication) required for the project.

The Stakeholders

-The software process is populated by stakeholders who can be categorized into one of five

constituencies:

1. Senior managers

- Who define the business issues that often have a significant influence on the project?

2. Project (technical) managers

Page 4: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 4

- Who must plan, motivate, organize, and control the practitioners who do software work.

3. Practitioners

- Who deliver the technical skills that are necessary to engineer a product or application?

4. Customers

-who specify the requirements for the software to be engineered and other stakeholders who have

a peripheral interest in the outcome.

5. End users

- Who interact with the software once it is released for production use?

Team Leaders

- MOI model of leadership:

1. Motivation

- The ability to encourage (by “push or pull”) technical people to produce to their best ability.

2. Organization.

- The ability to mold existing processes (or invent new ones) that will enable the initial concept to

be translated into a final product.

3. Ideas or innovation.

- The ability to encourage people to create and feel creative even when they must work

within bounds established for a particular software product or application.Another view of

the characteristics that define an effective project manager emphasizes four key traits:

Problem solving.

- An effective software project manager can diagnose the technical and organizational issues that

are most relevant, systematically structure a solution or properly motivate other practitioners to

develop the solution, apply lessons learned from past projects to new situations, and

-remain flexible enough to change direction if initial attempts at problem solution are fruitless.

Managerial identity.

- A good project manager must take charge of the project. She must have the confidence to assume

control when necessary and the assurance to allow good technical people to follow their instincts.

Achievement.

Page 5: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 5

-A competent manager must reward initiative and accomplishment to optimize the productivity of a

project team. She must demonstrate through her own actions that controlled risk taking will not be

punished.

Influence and team building.

- An effective project manager must be able to “read” people; she must be able to understand verbal

and nonverbal signals and react to the needs of the people sending these signals. The manager must

remain under control in high-stress situations.

Coordination and Communication Issues

The scale of many development efforts is large, leading to complexity, confusion, and significant

difficulties in coordinating team members. Uncertainty is common, resulting in a continuing stream

of changes that ratchets the project team. Interoperability has become a key characteristic of many

systems. New software must communicate with existing software and conform to predefined

constraints imposed by the system or product.

- Kraul and Streeter [KRA95] examine a collection of project coordination techniques that are

categorized in the following manner:

Formal, impersonal approaches

- include software engineering documents and deliverables (including source code), technical

memos, project milestones, schedules, and project control tools, change requests and

related documentation , error tracking reports, and repository data .

Formal, interpersonal procedures

-focus on quality assurance activities applied to software engineering work products. These include

status review meetings and design and code inspections.

Informal, interpersonal procedures

-include group meetings for information dissemination and problem solving and “collocation of

requirements and development staff.”

Electronic communication

-encompasses electronic mail, electronic bulletin boards, and by extension, video-based

conferencing systems.

Interpersonal networking

-includes informal discussions with team members and those outside the project who may have

experience or insight that can assist team members.

Page 6: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 6

CRITICAL PRACTICES

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”. In an effort to enable a software organization to determine whether a specific

project has implemented critical practices, the Airlie Council has developed a set of “QuickLook”

questions for a project-

Formal risk management.

-What are the top ten risks for this project? For each of the risks, what is the chance that the risk

will become a problem and what is the impact if it does?

Empirical cost and schedule estimation.

- What is the current estimated size of the application software (excluding system software)

that will be delivered into operation? How was it derived?.

Metric-based project management.

- Do you have in place a metrics program to give an early indication of evolving problems? If so,

what is the current requirements volatility?

Earned value tracking.

-Do you report monthly earned value metrics? If so, are these metrics computed from an activity

network of tasks for the entire effort to the next delivery?

Defect tracking against quality targets.

Page 7: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 7

- Do you track and periodically report the number of defects found by each inspection (formal

technical review) and execution test from program 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?

Estimation for software project

Project Planning Process

The objective of software project planning is to provide a framework that enables the manager to

make reasonable estimates of resources, cost, and schedule. These estimates are made within a

limited time frame at the beginning of a software project and should be updated regularly as the

project progresses. Estimates should attempt to define best case and worst case scenarios.

SOFTWARE SCOPE

-Software scope describes the data and control to be processed, function, performance,

constraints, interfaces, and reliability. Functions described in the statement of scope are evaluated

and in some cases refined to provide more detail prior to the beginning of estimation.

- analyst start by asking context-free questions; that is, a set of questions that will lead to a basic

understanding of the problem, the people who want a solution, the nature of the solution desired,

and the effectiveness of the first encounter itself.

Feasibility

- Can we build software to meet this scope? Is the project feasible?”not everything imaginable

is feasible, not even in software, Software feasibility has four solid dimensions:

Technology—

Is a project technically feasible? Is it within the state of the art? Can defects be reduced to a level

matching the application’s needs?

Finance—Is it financially feasible? Can development be completed at a cost the software

organization, its client, or the market can afford?

Time—Will the project’s time-to-market beat the competition?

Page 8: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 8

Resources—does the organization have the resources needed to succeed?

A Scoping Example

Conveyor Line Sorting System (CLSS).

- The project planner examines the statement of scope and extracts all important software

functions. This process, called decomposition, and results in the following functions:

• Read bar code input.

• Read pulse tachometer.

• Decode part code data.

• Do database look-up.

• Determine bin location.

• Produce control signal for shunt.

• Maintain record of box destinations.

RESOURCES Three major categories of software engineering resources—

1. People

2. Reusable software components

3. Development environment (hardware and software tools)

1. Human Resources

The planner begins by evaluating software scope and selecting the skills required to complete

development. Both organizational position (e.g., manager, senior software engineer) and specialty

Page 9: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 9

(e.g., telecommunications, database, and client-server) are specified. For relatively small projects (a

few person-months), a single individual may perform all software engineering tasks, consulting

with specialists as required. For larger projects, the software team may be geographically dispersed

across a number of different locations. Location of each human resource is specified. The number of

people required for a software project can be determined only after an estimate of development

effort (e.g., person-months) is made.

2. Reusable Software Resources

Component-based software engineering (CBSE)4 emphasizes reusability—that is, the creation and

reuse of software building blocks. Such building blocks, often called components.

Off-the-shelf components. Existing software that can be acquired from a third party or from a past

project.

COTS (commercial off-the-shelf) components are purchased from a third party, are ready for use

on the current project, and have been fully validated.

Full-experience components. Existing specifications, designs, code, or test data developed for past

projects that are similar to the software to be built for the current project. Members of the current

software team have had full experience in the application area represented by these components.

Therefore, modifications required for full-experience components will be relatively low risk.

Partial-experience components. Existing specifications, designs, code, or test data developed for

past projects that are related to the software to be built for the current project but will require

substantial modification. Members of the current software team have only limited experience in the

application area represented by these components. Therefore, modifications required for partial-

experience components have a fair degree of risk.

New components. Software components must be built by the software team specifically for the needs

of the current project.

3. Environmental Resources

The environment that supports a software project, often called the software engineering

environment (SEE), incorporates hardware and software.

Hardware provides a platform that supports the tools (software) required to produce the work

products that are an outcome of good software engineering practice. Because most software

organizations have multiple constituencies that require access to the SEE, you must prescribe the

time window required for hardware and software and verify that these resources will be available.

When a computer-based system (incorporating specialized hardware and software) is to be

engineered, the software team may require access to hardware elements being developed by other

engineering teams. For example, software for a robotic device used within a manufacturing cell may

require a specific robot (e.g., a robotic welder) as part of the validation test step; a software project

for advanced page layout may need a high-speed digital printing system at some point during

development. Each hardware element must be specified as part of planning.

Page 10: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 10

SOFTWARE PROJECT ESTIMATION

To achieve reliable cost and effort estimates, a number of options arise:

1. Delay estimation until late in the project (obviously, we can achieve 100% accurate

estimates after the project is complete!).

2. Base estimates on similar projects that have already been completed.

3. Use relatively simple decomposition techniques to generate project cost and effort

estimates.

4. Use one or more empirical models for software cost and effort estimation.

SOFTWARE PROJECT ESTIMATION

DECOMPOSITION TECHNIQUES

- Decompose the problem, recharacterizing it as a set of smaller problems.

1. Software Sizing

size refers to a quantifiable outcome of the software project. If a direct approach is taken, size can

be measured in lines of code (LOC). If an indirect approach is chosen, size is represented as function

points (FP).Putnam and Myers [Put92] suggest four different approaches to the sizing problem:

• “Fuzzy logic” sizing.

- This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic. To

apply this approach, the planner must identify the type of application, establish its magnitude on a

qualitative scale, and then refine the magnitude within the original range.

• Function point sizing.

•Standard component sizing.

- Software is composed of a number of different“standard components” that are generic to a

particular application area.

For example, the standard components for an information system are subsystems, modules,

screens, reports, interactive programs, batch programs, files, LOC, and object-level instructions.

-The project planner estimates the number of occurrences of each standard component and then

uses historical project data to estimate the delivered size per standard component.

• Change sizing.

Page 11: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 11

- This approach is used when a project encompasses the use of existing software that must be

modified in some way as part of a project. The planner estimates the number and type (e.g., reuse,

adding code, changing code, and deleting code) of modifications that must be accomplished.

Problem-Based Estimation

An Example of LOC-Based Estimation

An Example of FP-Based Estimation

-The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a

burdened labor rate of $8000 per month, the cost per FP is approximately $1230.

- Based on the FP estimate and the historical productivity data, the total estimated

Page 12: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 12

project cost is $461,000 and the estimated effort is 58 person-months.

Process-Based Estimation

- Process is decomposed into a relatively small set of tasks and the effort required to

accomplish each task is estimated.

- Begins with a delineation of software functions obtained from the project scope. A series of

framework activities must be performed for each function.

- Functions and related framework activities may be represented as part of a table similar to

the one presented in Figure.

Estimation with Use Cases

Page 13: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 13

-Unlike an LOC or a function point, one person’s “use case” may require months of effort while

another person’s use case may be implemented in a day or two.

-Although a number of investigators have considered use cases as an estimation input, no proven

estimation method has emerged to date.

Reconciling Estimates

- Reevaluation of information used to make the estimates. Widely divergent estimates can often be

traced to one of two causes:

(1) The scope of the project is not adequately understood or has been misinterpreted by the

planner, or

(2) Productivity data used for problem-based estimation techniques is inappropriate for the

application, obsolete (in that it no longer accurately reflects the software engineering organization),

or has been misapplied. You should determine the cause of divergence and then reconcile the

estimates.

EMPIRICAL ESTIMATION MODELS No estimation model is appropriate for all classes of software and in all development environments.

Therefore, you should use the results obtained from such models judiciously.

Page 14: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 14

An estimation model should be calibrated to reflect local conditions.

The model should be tested by applying data collected from completed projects, plugging the data

into the model, and then comparing actual to predicted results. If agreement is poor, the model

must be tuned and retested before it can be used.

The Structure of Estimation Models

A typical estimation model is derived using regression analysis on data collected from past software

projects.

The overall structure of such models takes the form -

E =A + B * (ev)C

where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the

estimation variable (either LOC or FP).

Among the many LOC-oriented estimation models proposed in the literature are

S/W Project ab bb cb db Organic 2.4 1.05 2.5 0.38 SemiDetached 3.0 1.12 2.5 0.35 Emebedded 3.6 1.20 2.5 0.32

The COCOMO II Model

Barry Boehm introduced a hierarchy of software estimation models bearing the name COCOMO, for

COnstructive COst MOdel.

Page 15: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 15

The original COCOMO model became one of the most widely used and discussed software cost

estimation models in the industry. It has evolved into a more comprehensive estimation model,

calledCOCOMO- II. COCOMO II models require sizing information. Three different sizing options are

available as part of the model hierarchy: object points, function points, and lines of source code.

object point is an indirect software measure that is computed using counts of the number of (1)

screens (at the user interface), (2) reports, and (3) components likely to be required to build the

application. Each object instance (e.g., a screen or report) is classified into one of three complexity

levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm.

The Software Equation

Page 16: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 16

Putnam and Myers suggest a set of equations derived from the software equation. Minimum

development time is defined as

THE MAKE/BUY DECISION

In many software application areas, it is often more cost effective to acquire rather than develop

computer software. Software engineering managers are faced with a make/buy decision that can be

further complicated by a number of acquisition options:

(1) software may be purchased (or licensed) off-the-shelf,

(2) “full-experience” or “partial-experience” software may be acquired and then modified and

integrated to meet specific needs, or

(3) Software may be custom built by an outside contractor to meet the purchaser’s

specifications.

Creating a Decision Tree

Figure depicts a decision tree for a software based system X. In this case, the software engineering

organization can

(1) Build system X from scratch,

(2) reuse existing partial-experience components to construct the system,

(3) Buy an available software product and modify it to meet local needs, or

(4) Contract the software development to an outside vendor.

Page 17: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 17

Based on the probability and projected costs that have been noted in Figure 26.8, the lowest

expected cost is the “buy” option.

Project Scheduling

Task set for Software project

Software project scheduling is an action that distributes estimated effort across the planned project

duration by allocating the effort to specific software engineering tasks. It is important to note,

however, that the schedule evolves over time. During early stages of project planning, a

macroscopic schedule is developed. This type of schedule identifies all major process framework

activities and the product functions to which they are applied. As the project gets under way, each

entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software

actions and tasks (required to accomplish an activity) are identified and scheduled. Basic Principles

Compartmentalization.

-The project must be compartmentalized into a number of manageable activities and tasks. To

accomplish compartmentalization, both the product and the process are refined.

Interdependency. The interdependency of each compartmentalized activity or task must be

determined. Some tasks must occur in sequence, while others can. occur in parallel. Some activities

cannot commence until the work product produced by another is available. Other activities can

occur independently.

Time allocation. Each task to be scheduled must be allocated some number of work units (e.g.,

person-days of effort). In addition, each task must be assigned a start date and a completion date

that are a function of the interdependencies and whether work will be conducted on a full-time or

part-time basis.

Page 18: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 18

Effort validation. Every project has a defined number of people on the software team. As time

allocation occurs, you must ensure that no more than the allocated number of people has been

scheduled at any given time. For example, consider a project that has three assigned software

engineers (e.g., three person-days are available per day of assigned effort). On a given day, seven

concurrent tasks must be accomplished. Each task requires 0.50 person-days of effort. More effort

has been allocated than there are people to do the work.

Defined responsibilities. Every task that is scheduled should be assigned to a specific team

member.

Defined outcomes. Every task that is scheduled should have a defined outcome. For software

projects, the outcome is normally a work product (e.g., the design of a component) or a part of a

work product. Work products are often combined in deliverables.

Defined milestones. Every task or group of tasks should be associated with a project milestone. A

milestone is accomplished when one or more work products has been reviewed for quality and has

been approved.

Each of these principles is applied as the project schedule evolves.

A TASK SET FOR THE SOFTWARE PROJECT

A software team performs is achieved through a set of tasks that enable you to define, develop, and

ultimately support computer software. No single task set is appropriate for all projects. The set of

tasks that would be appropriate for a large, complex system would likely be perceived as overkill

for a small, relatively simple software product. Therefore, an effective software process should

define a collection of task sets, each designed to meet the needs of different types of projects. In

order to develop a project schedule, a task set must be distributed on the project time line. The task

set will vary depending upon the project type and the degree of rigor with which the software team

decides to do its work. Most software organizations encounter the following projects:

1. Concept development projects that are initiated to explore some new business concept or

application of some new technology.

2. New application development projects that are undertaken as a consequence of a specific

customer request.

3. Application enhancement projects that occur when existing software undergoes major

modifications to function, performance, or interfaces that are observable by the end user.

4. Application maintenance projects that correct, adapt, or extend existing software in ways that

may not be immediately obvious to the end user.

5. Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy)

system in whole or in part.

A Task Set Example

Page 19: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 19

- Concept development projects are approached by applying the following actions:

1.1 Concept scoping determines the overall scope of the project.

1.2 Preliminary concept planning establishes the organization’s ability to undertake the work

implied by the project scope.

1.3 Technology risk assessment evaluates the risk associated with the technology to be

implemented as part of the project scope.

1.4 Proof of concept demonstrates the viability of a new technology in the software context.

1.5 Concept implementation implements the concept representation in a manner that can be

reviewed by a customer and is used for “marketing” purposes when a concept must be sold to other

customers or management.

1.6 Customer reaction to the concept solicits feedback on a new technology concept and targets

specific customer applications.

Defining a task network

task network, also called an activity network, is a graphic representation of the task flow for a project.

It is sometimes used as the mechanism through which task sequence and dependencies are input to

an automated project scheduling tool.

In its simplest form (used when creating a macroscopic schedule), the task network depicts major

software engineering actions.

Figure 27.2 shows a schematic task network for a concept development project.

Scheduling

Project scheduling methods

Program evaluation and review technique (PERT)

Page 20: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 20

critical path method (CPM)

Both PERT and CPM provide quantitative tools that allow the software planner to

(1) determine the critical path

(2) establish “most likely” time estimates

(3) calculate “boundary times”

Time-Line Charts

- a time-line chart, also called a Gantt chart, is generated. A time-line chart can be developed for the

entire project. Alternatively, separate charts can be developed for each project function or for each

individual working on the project.

Timeline Charts

Page 21: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 21

EARNED VALUE ANALYSIS

The earned value system provides a common value scale for every [software project] task,

regardless of the type of work being performed. The total hours to do the whole project are

estimated, and every task is given an earned value based on its estimated percentage of the total. It

enables you to assess the “percent of completeness” of a project using quantitative analysis rather

than rely on a gut feeling. “provides accurate and reliable readings of performance from as early as

15 percent into the project.”

To determine the earned value, the following steps are performed:

1. The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the

schedule. During estimation, the work (in person-hours or person-days) of each software

engineering task is planned.

- Hence, BCWSi is the effort planned for work task i. To determine progress at a given point along

the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that

should have been completed by that point in time on the project schedule.

2. The BCWS values for all work tasks are summed to derive the budget at completion (BAC). Hence,

BAC (BCWSk) for all tasks k

3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is

the sum of the BCWS values for all work tasks that have actually been completed by a point in time

on the project schedule.

-Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:

-Schedule performance index, SPI= BCWP/ BCWS

-Schedule variance, SV =BCWP- BCWS.

- SPI is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI

value close to 1.0 indicates efficient execution of the project schedule.

-SV is simply an absolute indication of variance from the planned schedule.

Percent complete =BCWP/BAC

PRODUCT METRICS

Measures, Metrics, and Indicators

- Metric as “a quantitative measure of the degree to which a system, component, or process

possesses a given attribute.

- An indicator is a metric or combination of metrics that provides insight into the software process,

a software project, or the product itself.

Page 22: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 22

Measurement Principles

• Formulation. The derivation of software measures and metrics appropriate for

the representation of the software that is being considered.

• Collection. The mechanism used to accumulate data required to derive the formulated metrics.

• Analysis. The computation of metrics and the application of mathematical tools.

• Interpretation. The evaluation of metrics resulting in insight into the quality of the representation.

• Feedback

- Recommendations derived from the interpretation of product metrics transmitted to the software

team.

The following principles are representative of many that can be proposed for metrics

characterization and validation:

1. A metric should have desirable mathematical properties.’

2. When a metric represents a software characteristic that increases when positive traits

occur or decreases when undesirable traits are encountered, the value of the metric should

increase or decrease in the same manner.

3. Each metric should be validated empirically in a wide variety of contexts before being

published or used to make decisions.

Software Quality

Software quality can be defined as:

- An effective software process applied in a manner that creates a useful product that

provides measurable value for those who produce it and those who use it.

Garvin’s Quality Dimensions

Page 23: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 23

- suggests that quality should be considered by taking a multidimensional viewpoint that begins

with an assessment of conformance and terminates with transcendental (aesthetic) view. Although

Garvin’s eight dimensions of quality were not developed specifically for software, they can be

applied when software quality is considered:

1. Performance quality

2. Feature quality

3. Reliability

4. Conformance.

5. Durability.

6. Serviceability.

McCall’s Quality Factors

1. Correctness. 2. Reliability. 3. Efficiency 4. Integrity. 5. Usability. 6. Maintainability.

7. Flexibility 8. Testability. 9. Portability. 10. Reusability. 11. Interoperability

ISO 9126 Quality Factors

The ISO 9126 standard was developed in an attempt to identify the key quality attributes for

computer software. The standard identifies six key quality attributes:

1. Functionality.

- The degree to which the software satisfies stated needs asindicated by the following

subattributes: suitability, accuracy, interoperability, compliance, and security.

2. Reliability.

- The amount of time that the software is available for use as indicated by the following

subattributes: maturity, fault tolerance, recoverability.

Page 24: SOFTWARE ENGINEERING SYLLABUS (CGPA )€¦ · SOFTWARE ENGINEERING SYLLABUS (CGPA ) Software Project Planning & Management Concepts (08Hrs, 16 Marks) a. Management Spectrum b. People

By : Prof. Mr.P.R.Patil Page 24

3. Usability.

- The degree to which the software is easy to use as indicated by the following subattributes:

understandability, learnability, operability.

4. Efficiency.

- The degree to which the software makes optimal use of system resources as indicated by the

following subattributes: time behavior, resource behavior.

5. Maintainability.

- The ease with which repair may be made to the software as indicated by the following

subattributes: analyzability, changeability, stability, testability.

6. Portability.

- The ease with which the software can be transposed from one environment to another as

indicated by the following subattributes: adaptability, installability, conformance, replaceability.