Goals and Measurements (Part of Planning)

1. Goals and Measurements(Part of Planning) • This is one of the hardest topic for “lower level” managers to either appreciate or accept (**More meaningful at higher Level management**)

2. Goals and Measurements • Now that we have (completed requirements & WBS) • defined the deliverables and • analyzed the tasks to complete the deliverables • We need to characterizethese deliverables & the project: • the deliverables in terms of “goals” • the project in terms of “goals” • Without “Goals” there is really nothing to manage • Goals are expressed through some attribute: (well defined attribute so that it is) • “validatable” • “verifiable” Usually, this mean measurableand trackable

3. A “Review” on Metric/Measurement • Must clearly define the attribute of interestbefore measuring it • e.g. length of a table or size of software program 2. Define the metric(unit of measurement): • Unit of measurement may be : • Inches or (square inches or cubic inches) • Lines of code or FP or (number of distinct variables) • “squigley-goo” 3. Define the measuring act(the act of counting through using the metric) • Placing a devise, “ruler,” that is marked with the metric next to the subject item and count the number of units of measurement for length • Counting the physical lines of statements end-marked by “;”

4. Metric via GQM* Example • Goal : Measure the Size of Software • Question: What is the size of a software in terms of its: • Data files (internal logical files, external file interface) • Transactions (input, output, query) • Metrics: Function Points ---- * GQM is a methodology invented and advocated by V. Basili of U. of Maryland

5. Well Defined Goals/Metric • “Validatable” goal/metric (in terms of attributes of interest) • An attributethat is defined, understood and agreed upon • A metric for that attributeis agreed upon • A specific value of the metricfor that attribute is specified by the customer/team requirements as the “goal” • Attainment of that “goal” can be shown • Verifiable goal/metric • Include the aboveand in addition • The measurement process(monitoring) can be shown • The recorded value of the metric used for the goal is kept and any transformations needed in the derivation of the metric is traceable and demonstrable

6. Consider a Project Goal --- “On Schedule” • Define the “goal attribute” ----- project schedule: • meeting allmajor and finalmilestone dates for 3 defined deliverables of i) final design specification, ii) pre-tested source code, iii) final system tested source code • Validate the goal: • “schedule” Attribute is --- “meeting the major and final milestone dates” • metric is ---- calendar date • “on/meeting schedule” is defined as: [ comparing: “actual” delivery date(6pm) = “scheduled” calendar date(6pm)] • Attainment can be shown (compared) for all three deliverables at the milestone dates • Verify the goal: • Measure the 3 project deliverables status each day. • Trace the completion dates of the 3 deliverables by milestone dates • If there are any transformation in terms of -- “% of meeting schedule” by counting the number of times major milestones and final date were met by 3 deliverables - - - can be shown.

7. Example: of a “tougher” Validatable Goal • The Product should be “user friendly” • Understand and define the user-friendliness attributes • Screen looks prettiness, navigation flow smoothness, response timeliness, meeting standards, informational messages usefulness, etc. • Agree on an attribute definition from above choices • Screen looks and the conformance to industry UI standards on screen layout • Define a metric for that attribute • Number of non-standard (standard) icon and non standard (standard)positioning of icons on screens • The Customer requirements goal may be: • 100% conformance to standard on all main screens or • 98% conformance on all message boxes and information sub-screens - The attainment of this goal can be shown through examining the icons and screens (match std. or not)

8. Example: a “tougher” Verifiable Goal/Metrics • The goal of “user-friendliness” as defined is verifiable • 100% of main screens conforms to standard • 98% of message boxes and sub-screens conforms to standard • We can show the actual measurement activity, or monitoring process as screens are developed (weekly ?): • All main screens • All the sub-screens and message boxes • Show and trace all the non-conformance and count the number of non-conforming screens and message boxes • Show the computation of percentages from the measurements

9. Software Product & Project Goals • Software Product Goals • “Excellent” Quality • “Good”Usability • “Adequate” Maintainability • etc. • Software (Non-product) Project Goals • “Absolute”Schedule Integrity • “Meets” Cost Target • “Good” Productivity • etc.

10. Consider Product’s“Adequate Maintainability” Goal • Ensure clear understanding and agreement on the attribute, “maintainability” • Use industry standard if available (most likely not ---) • In software, software engineers together with customers may often need to devise an applicable description • Ensure that the goal “adequate” is understood and defined • What is the metric ----- e.g. cohesion and coupling measurements? • How would it be measured - (for verification) • What value of the metric equates to “adequate” - (for validation) • Software Project Manager should not necessarily define these, but ensure that it is properlyunderstood, defined, and used.

11. Validatable and Verifiable Goal • Once the metric for “maintainability” is defined and the goal “adequate” is defined in terms of the values of the metric : • Can that goal, “adequate,” be validated via? • Comparing the measured results with the goal • Can it be verified via? • Showing the measurement process • Showing the measurement results (monitoring results) • Showing and tracing any necessary “computations” on the measured results

12. Consider a “Project” Goal • Consider a project goal such as developers’ “goodproductivity” • Ensure that all understand and agree on the projectattribute, “productivity” • Ensure that all understand and agree on the goal, “good”. • What is the metric • How is it measured • What is the value of the metric that equates to “good”

13. Validatable and Verifiable Goal • Once the metric for “productivity” is defined and the goal “good” is defined in terms of the values of the metric : • Can that goal, “good,” be validated via? • Comparing the measured results with the goal • Can it be verified via? • Showing the measurement process • Showing the measurement results (monitoring results) • Showing and tracing any necessary “computations” on the measured results

14. Managing Inter-related Attributes • Inter-relationships among attributes: • Product attribute to Product attribute • product quality and product functionality • Product attribute to Project attribute • product functionality and project cost • Project attribute to Project attribute • project schedule and project cost • “Managing” multiple attributes and their inter-relationships is both interesting and difficult

15. Consider Some Examples of Inter-Relationships • Project Schedule vs Project Cost • Improve on Schedule with Increased resources (Cost)? • Improve on Cost but still “meeting” the schedule goal ? • Product Quality vs Project Productivity • Improve productivity with improved quality ? • Improve quality with increased productivity ? • Product Usability vs Product Functionalextra-featureness • Increase usability with increased functions (full-feature)? • Improved functional completeness with improved usability? Are these supportive or conflictinggoals?