1 / 15

Goals and Measurements (Part of Planning)

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**). Goals and Measurements. Now that we have (completed requirements & WBS)

jenis
Download Presentation

Goals and Measurements (Part of Planning)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related