Goals and Measurements (Part of Planning)

1 / 15

Goals and Measurements (Part of Planning) - PowerPoint PPT Presentation

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 &amp; WBS)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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)
• 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

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 “;”
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

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
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.
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)

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
Software Product & Project Goals
• Software Product Goals
• “Excellent” Quality
• “Good”Usability
• etc.
• Software (Non-product) Project Goals
• “Absolute”Schedule Integrity
• “Meets” Cost Target
• “Good” Productivity
• etc.
• 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.
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
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”
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
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
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?