CEN 4021
Software Engineering II
Software Project Planning (POMA)
Overview of goals and measurements
Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/
sadjadi@cs.fiu.edu
CEN 4021
6th Lecture
Acknowledgements

Dr. Onyeka Ezenwoye

Dr. Peter Clarke
CEN 4021: Software Engineering II
6th Lecture
2
Agenda

Software Project Planning (POMA)
– Overview of goals and measurements
CEN 4021: Software Engineering II
6th Lecture
Overview of Goals and Measurements

During the planning phase the goals for and
measurements of, the key attributes of the product and
services are determined.

Many of the goals for the system are deduced from the
functional and nonfunctional requirements.
CEN 4021: Software Engineering II
6th Lecture
Attributes of good software
CEN 4021: Software Engineering II
6th Lecture
software?

The software should deliver the required functionality.

Maintainability
– Software must evolve to meet changing needs;

Dependability
– Reliable, Secure, Safe, trustworthy;

Efficiency
– Software should not make wasteful use of system resources;

Usability
– Used without undue effort.
– Appropriate interface
– Good documentation
CEN 4021: Software Engineering II
6th Lecture
Functional and non-functional
requirements

Functional requirements
– Statements of services the system should provide, how the system
should react to particular inputs and how the system should
behave in particular situations.
– Describe interaction between the system and its environment.

Non-functional requirements
– constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.
– Describes aspects of the system that are not directly related to the
functional behaviour.
CEN 4021: Software Engineering II
6th Lecture
Functional requirements



Describe functionality or system services.
Depend on the type of software, expected users and the
type of system where the software is used.
Functional user requirements may be high-level
statements of what the system should do but functional
system requirements should describe the system services
in detail.
CEN 4021: Software Engineering II
6th Lecture
Non-functional requirements


These define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
Non-functional requirements may be more critical than
functional requirements. If these are not met, the system is
useless.
CEN 4021: Software Engineering II
6th Lecture
requirements


Usability: the ease of use (e.g., interface, online help,
documentation)
Reliability (Dependability): the ability of a system to
perform its required functions under stated conditions for a
specified period of time (e.g., mean time to failure, ability
to withstand attacks and safety).
CEN 4021: Software Engineering II
6th Lecture
requirements


Performance: Quantifiable attributes of the system (e.g.,
response time, throughput, availability).
Supportability: the ease of changes to the system after
development (e.g., adaptability, maintainability, portability).
CEN 4021: Software Engineering II
6th Lecture
Overview of Goals and Measurements
cont
Example goals:
–
A secure system
–
A fully functional system
–
A high-quality system
–
A user-friendly and attractive system
–
A cost-effective project
–
A project that meets the schedule
(please do not just copy these goals into your project plan)

Note that the above goals are not measurable!

The above goals must be recast as more precise attributes with
metrics, so that the attributes are measurable, tracked, validated,
and verifiable.
CEN 4021: Software Engineering II
6th Lecture
Measurable, Trackable, Validatable and
Verifiable Goals

Goals in the planning phase is derived from G/Q/M (V.
Basili and others)

G/Q/M (Goal/Question/Metric) – A s/w metric paradigm
based on identifying the goals, formulating questions
about the goals in quantifiable terms, and establishing
the metrics to answer the formulated questions.

E.g., user reqs state that the response to queries should
be no more than 2 secs. Goal for the attribute “query
response time” would be set at less than 2 secs.
CEN 4021: Software Engineering II
6th Lecture
Goal/Question/Metric paradigm
1.
Develop a set of goals. Set of corporate, division, or
project goals for productivity and quality of product or
process
2.
Develop a set of questions that characterize that goal.
For each goal the question that must be answered to
determine if the goal is being met
3.
Specify the metric needed to answer the question
4.
Develop mechanisms for data collection. (who, when,
how)
5.
Collect, validate and analyze. Keep simple, avoid
unnecessary recording
CEN 4021: Software Engineering II
6th Lecture
Goal/Question/Metric paradigm
6.
Analyze data to assess conformance to the goals and
make recommendations for future improvements
7.
Provide feedback to stakeholders
CEN 4021: Software Engineering II
6th Lecture
Measurable, Trackable, Validatable and
Verifiable Goals

Measurable attribute: An attribute for which there is a
well-defined metric and a methodology for its
measurements.

Tracking: Keeping a record of the measurement taken
on an attribute.

Validation of goal: Comparing a stated goal for an
attribute with the actual measurement taken for the
attribute.

Verification of measurement: Ensuring that the
measurement of an attribute is properly taken and
recorded through repetition, tracing, or some other
means.
CEN 4021: Software Engineering II
6th Lecture
Metrics and Measurements

Metric: The unit used to characterize an attribute.

Measurement: The act of characterizing an attribute,
which may involve multiple steps, utilizing the agreed
upon metric for that attribute.

E.g., Attribute is “elapsed time”, metric “hour” – required
to take the start time and the end time, the compute the
difference.

Planning team may also be required to define metrics
project-related attributed. e.g., productivity, team morale,
tool effectiveness, user satisfaction.
CEN 4021: Software Engineering II
6th Lecture
Metrics and Measurements

The schedule is the most obvious attribute for all
projects i.e., it is a defined set of time goals agreed
upon.

Both the metric and the measurements for schedules
are defined in the calendar.

The cost as an attribute is also relatively easy to
measure. Cost given in terms of some currency is also
a well-defined metric.

Other project attributes and their goals are difficult to
measure, e.g., quality, completeness of functions, and
ease of use.
CEN 4021: Software Engineering II
6th Lecture
Metrics and Measurements

Better system of metrics and measurements are
needed.

activities such as tracking, verification, and validation to
be an art and not a science.
CEN 4021: Software Engineering II
6th Lecture
Metrics and Measurements

The importance of metrics to Software Projects
–
Analyze product errors and defects
–
Assess status
–
Derive a basis for estimates
–
Determine product complexity
–
Establish baselines
–
Experimentally validate best practices
–
Predict quality, schedule, effort, and cost
–
Track project cost
–
Understand when a desired state of quality has been achieved
CEN 4021: Software Engineering II
6th Lecture
Metrics and Measurements

A useful metric is precisely defined (i.e. measurable and
quantifiable)

Terms like “always”, “complex”, “efficient”, or “userfriendly” are not measurable without further definition.

A useful metric should be accountable.

Raw metric and control data (date of observation,
identity of the observer, etc) should be saved along with
the audit trail of the metric analysis process.

Conclusions may then be reconstructed from the data
CEN 4021: Software Engineering II
6th Lecture
Deliverable-related metrics and
measurements

Some s/w deliverable attributes include:
– Quality
– Usability
– Functional completeness
– Maintainability
– Modifiability
– Reliability
– Installability

Requires some thought and insight before a reasonable
goal and metric can be designed
CEN 4021: Software Engineering II
6th Lecture
Deliverable-related metrics and
measurements
Example “Quality”

Required by all s/w eng projects

Usually it is not clearly defined

Quality maybe amount of errors in s/w, how well the
stated functional reqs are met.

It is necessary to identify all the sub-attributes that make
up the quality attribute.

Setting quality goal to “zero known software errors”
makes attaining such a goal almost impossible
CEN 4021: Software Engineering II
6th Lecture
Deliverable-related metrics and
measurements
Zero defect software:
May not be a prudent goal for large commercial products

–
Effort needed to attain this goal may not be worth the cost

Instead quality goal may be expressed in incremental
form (sub-goals)

Level of defect severity:
–
High-level defect
–
Medium-level defect
–
Low-level defect
CEN 4021: Software Engineering II
6th Lecture
Weekly Quality report
Defect Type Problems
(by severity) found
Problems
closed
Problems
still open
Accumulative Quality goal
problems still number
open
High
severity
9
3
5
12
0 open at
release
Medium
severity
Low
severity
CEN 4021: Software Engineering II
6th Lecture
Complex attributes
Complex attribute: whose metric definition requires a
combination of statements and defintions.
 Metric for attributes should be a specific number
 For arithmetic comparison and operation
 What about
– Usability
– Maintainability

No standard goals, metrics or measurements.
CEN 4021: Software Engineering II
6th Lecture
Project and project-related metrics
and measurements

Software project manager is usually required to describe
the project in terms of the following:
– Schedule integrity
– Cost minimization
– Productivity
– Efficiency
– Employee morale
CEN 4021: Software Engineering II
6th Lecture
setting
Setting a goal, its metric and measurement in such a
way that if missed, recovery is immediate without
large cost to resources and other goals.
 Set minor milestones
 Break tasks into sub-goals (e.g. daily milestones/subgoals)
 Slippages are detected early and easily corrected.
CEN 4021: Software Engineering II
6th Lecture