View
38
Download
0
Category
Preview:
Citation preview
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.
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:
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
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.
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.
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.
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?
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
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.
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.
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
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
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.
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.
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
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.
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.
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
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)
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
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.
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
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.
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.
Recommended