CEN 4021 Software Engineering II Software Project Planning

  • Slides: 28
Download presentation
CEN 4021 Software Engineering II Software Project Planning (POMA) Overview of goals and measurements

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 6 th Lecture

Acknowledgements Dr. Onyeka Ezenwoye Dr. Peter Clarke CEN 4021: Software Engineering II 6 th

Acknowledgements Dr. Onyeka Ezenwoye Dr. Peter Clarke CEN 4021: Software Engineering II 6 th Lecture 2

Agenda Software Project Planning (POMA) – Overview of goals and measurements CEN 4021: Software

Agenda Software Project Planning (POMA) – Overview of goals and measurements CEN 4021: Software Engineering II 6 th Lecture

Overview of Goals and Measurements During the planning phase the goals for and measurements

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 6 th Lecture

Attributes of good software CEN 4021: Software Engineering II 6 th Lecture

Attributes of good software CEN 4021: Software Engineering II 6 th Lecture

What are the attributes of good software? The software should deliver the required functionality.

What are the attributes of 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 CEN 4021: Software Engineering II 6 th Lecture

Functional and non-functional requirements Functional requirements – Statements of services the system should provide,

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 6 th Lecture

Functional requirements Describe functionality or system services. Depend on the type of software, expected

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 6 th Lecture

Non-functional requirements These define system properties and constraints e. g. reliability, response time and

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 6 th Lecture

requirements Usability: the ease of use (e. g. , interface, online help, documentation) Reliability

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 6 th Lecture

requirements Performance: Quantifiable attributes of the system (e. g. , response time, throughput, availability).

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 6 th Lecture

Overview of Goals and Measurements cont Example goals: – A secure system – A

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 6 th Lecture

Measurable, Trackable, Validatable and Verifiable Goals in the planning phase is derived from G/Q/M

Measurable, Trackable, Validatable and Verifiable 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 6 th Lecture

Goal/Question/Metric paradigm 1. Develop a set of goals. Set of corporate, division, or project

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 6 th Lecture

Goal/Question/Metric paradigm 6. Analyze data to assess conformance to the goals and make recommendations

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 6 th Lecture

Measurable, Trackable, Validatable and Verifiable Goals Measurable attribute: An attribute for which there is

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 6 th Lecture

Metrics and Measurements Metric: The unit used to characterize an attribute. Measurement: The act

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 6 th Lecture

Metrics and Measurements The schedule is the most obvious attribute for all projects i.

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 6 th Lecture

Metrics and Measurements Better system of metrics and measurements are needed. activities such as

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 6 th Lecture

Metrics and Measurements The importance of metrics to Software Projects – Analyze product errors

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 6 th Lecture

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

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 6 th Lecture

Deliverable-related metrics and measurements Some s/w deliverable attributes include: – Quality – Usability –

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 6 th Lecture

Deliverable-related metrics and measurements Example “Quality” Required by all s/w eng projects Usually it

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 6 th Lecture

Deliverable-related metrics and measurements Zero defect software: May not be a prudent goal for

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 6 th Lecture

Weekly Quality report Defect Type Problems (by severity) found Problems closed Problems still open

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 6 th Lecture

Complex attributes Complex attribute: whose metric definition requires a combination of statements and defintions.

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 6 th Lecture

Project and project-related metrics and measurements Software project manager is usually required to describe

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 6 th Lecture

setting Setting a goal, its metric and measurement in such a way that if

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 6 th Lecture