CEN 4021 6 th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi sadjadi/ [email protected] Software Project Planning.

CEN 4021 6th Lecture

CEN 4021 CEN 4021 Software Engineering II Software Engineering II

Instructor: Masoud Sadjadi

http://www.cs.fiu.edu/~sadjadi/

[email protected]

Software Project Planning (POMA)Overview of goals and measurements

6th LectureCEN 4021: Software Engineering II

AcknowledgementsAcknowledgements

Dr. Onyeka Ezenwoye

Dr. Peter Clarke

2


AgendaAgenda

Software Project Planning (POMA)– Overview of goals and measurements


Overview of Goals and Overview of Goals and MeasurementsMeasurements

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.


Attributes of good Attributes of good softwaresoftware


What are the attributes of What are the attributes of good software?good 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


Functional and non-functional Functional and non-functional requirementsrequirements

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.


Functional requirementsFunctional 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.


Non-functional requirementsNon-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.


Categories of non-Categories of non-functional requirementsfunctional 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).


Categories of non-Categories of non-functional requirementsfunctional 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).


Overview of Goals and Overview of Goals and Measurements contMeasurements 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.


Measurable, Trackable, Measurable, Trackable, Validatable and Verifiable GoalsValidatable 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.


Goal/Question/Metric paradigmGoal/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


Goal/Question/Metric paradigmGoal/Question/Metric paradigm

6. Analyze data to assess conformance to the goals and make recommendations for future improvements

7. Provide feedback to stakeholders


Measurable, Trackable, Validatable Measurable, Trackable, Validatable and Verifiable Goalsand 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.


Metrics and MeasurementsMetrics 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.



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.



Better system of metrics and measurements are needed.

activities such as tracking, verification, and validation to be an art and not a science.



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



A useful metric is precisely defined (i.e. measurable and quantifiable)

Terms like “always”, “complex”, “efficient”, or “user-friendly” 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


Deliverable-related metrics Deliverable-related metrics and measurementsand 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


Deliverable-related metrics Deliverable-related metrics and measurementsand 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


Deliverable-related metrics and Deliverable-related metrics and measurementsmeasurements

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


Weekly Quality reportWeekly Quality report

Defect Type (by severity)

Problems found

Problems closed

Problems still open

Accumulative problems still open

Quality goal number

High severity

12 9 3 5 0 open at release

Medium severity

Low severity


Complex attributesComplex 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.


Project and project-related Project and project-related metrics and measurementsmetrics 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


Immediate-recoverable Immediate-recoverable goal settinggoal 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/sub-

goals) Slippages are detected early and easily corrected.

CEN 4021 6 th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi sadjadi/ [email protected] Software Project Planning.

Documents