1. CEN 4021 6 th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu Software Project Planning (POMA) Overview of goals and measurements

2. 6 th LectureCEN 4021: Software Engineering II Acknowledgements  Dr. Onyeka Ezenwoye  Dr. Peter Clarke 2

3. 6 th LectureCEN 4021: Software Engineering II Agenda  Software Project Planning (POMA) –Overview of goals and measurements

4. 6 th LectureCEN 4021: Software Engineering II 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.

5. 6 th LectureCEN 4021: Software Engineering II Attributes of good software

6. 6 th LectureCEN 4021: Software Engineering II 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

7. 6 th LectureCEN 4021: Software Engineering II 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.

8. 6 th LectureCEN 4021: Software Engineering II 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.

9. 6 th LectureCEN 4021: Software Engineering II 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.

10. 6 th LectureCEN 4021: Software Engineering II Categories of non-functional 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).

11. 6 th LectureCEN 4021: Software Engineering II Categories of non-functional 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).

12. 6 th LectureCEN 4021: Software Engineering II 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.

13. 6 th LectureCEN 4021: Software Engineering II 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.

14. 6 th LectureCEN 4021: Software Engineering II 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

15. 6 th LectureCEN 4021: Software Engineering II Goal/Question/Metric paradigm 6. Analyze data to assess conformance to the goals and make recommendations for future improvements 7. Provide feedback to stakeholders

16. 6 th LectureCEN 4021: Software Engineering II 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.

17. 6 th LectureCEN 4021: Software Engineering II 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.

18. 6 th LectureCEN 4021: Software Engineering II 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.

19. 6 th LectureCEN 4021: Software Engineering II 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.

20. 6 th LectureCEN 4021: Software Engineering II 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

21. 6 th LectureCEN 4021: Software Engineering II Metrics and Measurements  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

22. 6 th LectureCEN 4021: Software Engineering II 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

23. 6 th LectureCEN 4021: Software Engineering II 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

24. 6 th LectureCEN 4021: Software Engineering II 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

25. 6 th LectureCEN 4021: Software Engineering II Weekly Quality report Defect Type (by severity) Problems found Problems closed Problems still open Accumulative problems still open Quality goal number High severity 129350 open at release Medium severity Low severity

26. 6 th LectureCEN 4021: Software Engineering II 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.

27. 6 th LectureCEN 4021: Software Engineering II 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

28. 6 th LectureCEN 4021: Software Engineering II Immediate-recoverable goal 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.