HistoryViewLinks to this page 2012 September 24 | 01:48 pm

REST API main topics: Architecture, Design, Data Model, Standard URIs

Standard URIs child topics : Key Software Metrics, Role Names

Contents

  • ems:Format
  • ems:Metric
  • ems:UnitOfMeasure
  • ems:Dimension
  • ems:DimensionMember
  • ems:Grain
  • QUDT
  • ems:Format
  • ems:WbsFormat
  • ems:TimeMetric
  • metric:Duration
  • metric:Start
  • metric:Finish
  • Time Units of Measure
  • ems:EffortMetric
  • metric:Staffing
  • metric:PeakStaffing
  • metric:FullTimeEquivalent
  • metric:Effort
  • Effort Units of Measure
  • ems:SizeMetric
  • metric:Sloc
  • metric:Esloc
  • metric:IFPUG42_FunctionPoints
  • metric:UseCasePoints
  • metric:StoryPoints
  • metric:IdealDays
  • Size Units of Measure
  • ems:ReliabilityMetric
  • Reliability Units of Measure
  • ems:ProductivityMetric
  • Productivity Units of Measure
  • ems:ProcessMetric
  • Process Units of Measure
  • Builds
  • Tests
  • CMMI
  • ems:FinancialMetric
  • Financial Units of Measure
  • Standard Dimensions
  • Standard Grains
  • grain:DoD_Phase
  • grain:RUP_Phase
  • grain:Role
  • COCOMO
  • metric:COCOMO_EffortMultiplier
  • References

  • Status

    This is a Working Draft and is therefore subject to frequent and major change.

    Introduction

    Many of the resources defined in the EMS 1.0 data model have properties that refer to formats, metrics, units of measure, dimensions, and grains. We model these property values as resources themselves, and identify them using URIs. This use of URIs to identify resources is consistent with the underlying RDF data model of EMS 1.0 and enables the unambiguous interchange of information among multiple service providers and consumers.

    This specification defines standard URIs for many of these key resources. Other organizations MAY define additional standard URIs. Users of EMS 1.0 SHOULD use standard URIs where they are applicable, but MAY use other URIs when no standard ones exists.

    This specification defines a standard classification scheme for these key resources as well as assigning them standard URIs. The classification scheme consists of a set of classes with subclass relationships among them. Each class is also assigned a standard URI. A set of related classes, subclasses, and individuals is sometimes referred to as an ontology.

    EMS URI Prefixes

    The following URI prefixes are used in this document:

    Table of URI Prefixes
    Prefix URI
    ems: <http://open-services.net/ns/ems#>
    format: <http://open-services.net/ns/ems/format#>
    metric: <http://open-services.net/ns/ems/metric#>
    unit: <http://open-services.net/ns/ems/unit#>
    dimension: <http://open-services.net/ns/ems/dimension#>
    dimension-member: <http://open-services.net/ns/ems/dimension-member#>
    grain: <http://open-services.net/ns/ems/grain#>

    ems:Format

    A format is a specification of the syntax of a resource. In EMS 1.0, the value of the ems:wbsFormat property is a format resource. ems:Format is the class of all formats and ems:WbsFormat is the subclass of all WBS formats.

    ems:Metric

    A metric is a procedure or algorithm for quantifying or measuring some aspect of a thing, system, event, etc. In EMS 1.0, we are concerned with metrics for software development projects. For example, duration is the metric that measures the amount of time that a project takes. ems:Metric is the class of all metrics.

    A metric may be either directly measured or it may be computed from other metrics. Metrics that are computed from other metrics are referred to as derived metrics.

    In general, a project is a time-bounded work effort that produces a unique result. Time (ems:TimeMetric) and effort (ems:EffortMetric) are therefore key metrics that apply to any project. For software development projects, the result produced is new or enhanced source code that provides some desirable capabilites. Size metrics (ems:SizeMetric) quantify the capability, scope, or bulk of the software. Reliability metrics (ems:ReliabilityMetric) quantify the correctness of the software. Productivity metrics (ems:ProductivityMetric) quantify the amount of time or effort required to produce the software. Time, effort, size, reliability, and productivity are core metrics for software development projects.

    People produce software using processes and practices, e.g. automatic unit testing, continuous integration, etc. It is often useful to monitor metrics that quantify these processes. For example, the test execution success/fail rates is a useful metric for the quality management processes. Process metrics (ems:ProcessMetric) quantify the processes and practices used by the development team.

    Cost is a key metric to track for any project. In software projects, labor is usually the main cost component so there is a close relationship between cost and effort. However, there are other cost components, and other financial metrics, such as benefit and value. We therefore group all of these financial metrics into a separate class (ems:FinancialMetric).

    See Key Software Metrics for more detail.

    ems:UnitOfMeasure

    The value of a measurement of a metric is expressible as a real number with respect to some unit of measure. For example, project duration is typically measured in units of months or years. ems:UnitOfMeasure is the class of all units of measure.

    We slightly abuse the term unit of measure since in general it includes both a unit of measure and an origin from which measurements are made. For example, temperature is often measured in units from some value designed as zero degrees, and calendar dates are measured from some starting time.

    ems:Dimension

    A project metric is often an aggregate quantity that is built up from more detailed metrics. For example, the total effort for a project is the sum of the effort spent in each time period of the project. Here effort is said to be analyzed along the dimension of time. A metric may be simultaneously analyzed along more than one dimension. For example, effort is often analyzed along both time and role dimensions. ems:Dimension is the class of all dimensions

    ems:DimensionMember

    A dimension member is any subset, interval, or region of a dimension. In the example of the time dimension, any specific day, week, month, year, etc., such as the day 1970-01-01, is a member. ems:DimensionMember is the class of all dimension members.

    ems:Grain

    The level of detail used to analyze a metric along some dimension is referred to as the grain of the dimension. A grain is a set of dimension members that are mutually exclusive and that together span the entire dimension. For example, if we measure effort per month then we are analyzing effort along the time dirmension using a grain size of one month. A dimension may have more than one grain. For example, time may be analyzed by day, month, week, month, year, etc. ems:Grain is the class of all grains.

    One grains refines another is every member of the coarser grain is equal to a union of some members of the finer grain. For example, days refine weeks, however, weeks do not refine months since some weeks begin and end in different months. The refinement relation between grains defines a natural hierarchy.

    QUDT

    NASA has published the QUDT ontology for Quantities, Units, Dimensions, and Data Types. This ontology contains standard URIs for time (qudt:TimeUnit) and currency (qudt:CurrencyUnit) units. We will use these rather than defining new ones here.

    The class qudt:Unit describes units of measure. We therefore define ems:UnitOfMeasure to be a superclass of qudt:Unit, i.e. any instance of qudt:Unit is also an instance of ems:UnitOfMeasure .

    The class qudt:QuantityKind corresponds closely to ems:Metric.

    We could therefore use the QUDT ontology to provide machine-readable information about the metrics and units of measure defined in this specification. One advantage of doing this is that qudt:Unit has properties that give the conversion factors for transforming between compatible units of measure, i.e. units of measure that apply to the same quantity kinds such as months and years applying to duration. Since the set of metrics and units of measures is open, other organizations that define new metrics and units of measure could also describe them using QUDT and thereby enable automatic conversions between the new and existing units. An EMS 1.0 service provider SHOULD provide QUDT descriptions of metrics and units of measure.

    The classes qudt:Quantity and qudt:QuantityValue together correspond roughly to ems:Measure. Each specifies the metric (aka quanity kind), the numeric value, and the units of measure.

    The class qudt:Dimension describes dimensions in the sense of dimensional analysis of quantities which is a different concept than that described by ems:Dimension.

    QUDT URI Prefixes

    The following QUDT URI prefixes are used in this document:

    Table of QUDT URI Prefixes
    Prefix URI
    qudt: <http://data.nasa.gov/qudt/owl/qudt#>
    qudt-quantity: <http://data.nasa.gov/qudt/owl/quantity#>
    qudt-unit: <http://data.nasa.gov/qudt/owl/unit#>

    ems:Format

    ems:Format is the class of all format URIs.

    ems:WbsFormat

    ems:WbsFormat is the class of all WBS format URIs. This class is the range of the ems:wbsFormat property of an ems:WorkBreakdownStructure resource. The following table contains the standard WBS format URIs:

    Table of ems:WbsFormat Standard URIs
    URI Description
    <http://schemas.microsoft.com/project/2007> Microsoft Office Project 2007 XML Data Interchange Schema

    ems:TimeMetric

    ems:TimeMetric is the class of all time metrics. It is a subclass of ems:Metric. Time metrics quantify both when events occur and how much time passes between two events. These two types of time metric are closely related but different. Here we use the term event to mean some instant that marks a point in time, but that itself occupies no duration. The length of time that passes between two project events is typically measured in hours, days, weeks, etc.

    The point in time at which an event occurs is measured with reference to some calendar that establishes an origin point in time. For example, in the Gregorian calendar, points in time are measured as the amount of time that has elapsed since a certain historical event that is denoted as year 1 AD. Points in Unix time as measured as the elapsed time since the so-called epoch which has the Gregorian date 1970-01-01T00:00:00Z.

    Table of ems:TimeMetric Standard URIs
    URI Description
    metric:Duration The amount of time that passes between two events, e.g. the start and finish of a project or task.
    metric:Start The point in time that marks the start of some activity or process, e.g. the start of a project or task.
    metric:Finish The point in time that marks the finish of some activity or process, e.g. the finish of a project or task.

    metric:Duration

    metric:Duration measures the amount of time between the start and finish of a project. It is typically broken down by task and phase dimensions.

    metric:Start

    metric:Start measures the point in time at which the project starts. It is typically broken down by task and phase dimensions.

    metric:Finish

    metric:Finish measures the point in time at which the project finishes. It is typically broken down by task and phase dimensions.

    Time Units of Measure

    The metric metric:Duration is the kind of quantity identified by qudt-quantity:Time. QUDT defines several units of measure for it. We introduce additional standard URIs for a more complete list of time units, but define them in terms of QUDT.

    QUDT does not describe the concept of a point in time such as Gregorian date-time or UNIX time.

    The following table lists the QUDT units for measuring time durations:

    Table of qudt:TimeUnit Standard URIs for Time Duration Metrics
    URI Description
    qudt-unit:SecondTime A time duration of one SI second.
    qudt-unit:MinuteTime A time duration of one minute = 60 SI seconds.
    qudt-unit:Hour A time duration of one hour = 3600 SI seconds.
    qudt-unit:Day A time duration of one mean solar day = 86400 SI seconds.
    qudt-unit:Year365Day A time duration of one 365-day year = 31536000 SI seconds.
    Table of ems:UnitOfMeasure Standard URIs for Time Metrics
    URI Description
    unit:Second A time duration of one second, same as qudt-unit:SecondTime.
    unit:Minute A time duration of one minute, same as qudt-unit:MinuteTime.
    unit:Hour A time duration of one hour, same as qudt-unit:Hour.
    unit:Day A time duration of one day, same as qudt-unit:Day.
    unit:Week A time duration of one week = 7 days.
    unit:Month A time duration of one month = 1/12 of one 365-day year.
    unit:Year A time duration of one year, same as qudt-unit:Year365Day.
    unit:GregorianDateTime A point in time measured in decimal Gregorian years.
    unit:UnixTime A point in time measured in seconds elapsed since the epoch.

    ems:EffortMetric

    ems:EffortMetric is the class of all effort metrics. It is a subclass of ems:Metric. Effort metrics quantify the amount of people and time required to produce software.

    Table of ems:EffortMetric Standard URIs
    URI Description
    metric:Staffing The average number of people working.
    metric:PeakStaffing The maximum number of people working.
    metric:FullTimeEquivalent The average number of full-time equivalent (FTE) people working.
    metric:Effort The effort expended by the people working.

    metric:Staffing

    A project is a time-bounded work effort, and the work on a project is performed by people. At any given point in time during the project, some number of people will be working on it. This number varies over the course of the project. metric:staffing is the average number of people working on a project. This metric is typically broken down by role, time, and task dimensions. A staffing curve for a project is simply the metric:Staffing metric broken down along the time dimension.

    metric:PeakStaffing

    metric:PeakStaffing is the maximum number of people that work on a project. Like metric:Staffing, it can be broken down by time or task, although it is usually of interest as a whole project metric.

    metric:FullTimeEquivalent

    Some people that work on a project may be working on other projects at the same time, or may not be full-time employees. In this case, the ems:Staffing metric does not give a completely accurate picture of the staffing level. Full-time equivalent (FTE) provides a count of the number of people weighted by their level of assignment to the project. For example, 10 half-time people count as 5 FTE people. ems:FullTimeEquivalent measures the average number of FTE people that are working and like ems:sfaffing, is tyically broken down by time and task.

    metric:Effort

    ems:Effort is the product of the staffing level and the time spent. It is measure in person-time units. For example, 10 people working 12 months expend 120 person-months of effort. Effort is typically broken down by task or phase.

    Effort Units of Measure

    Table of ems:UnitOfMeasure Standard URIs for Effort Metrics
    URI Description
    unit:Person A real or FTE person.
    unit:PersonHour The amount of effort expended by one person working for one hour.
    unit:PersonMonth The amount of effort expended by one person working for one month.
    unit:PersonYear The amount of effort expended by one person working for one year.

    ems:SizeMetric

    ems:SizeMetric is the class of all size metrics. It is a subclass of ems:Metric. Size metrics quantify the capability or bulk of software.

    Table of ems:SizeMetric Standard URIs
    URI Description
    metric:Sloc The count of source lines of code (SLOC).
    metric:Esloc The count of effective source lines of code (ESLOC).
    metric:IFPUG42_FunctionPoints The count of function points as defined by IFPUG Function Point Counting Practice Manual, Release 4.2.
    metric:UseCasePoints The count of use case points.
    metric:StoryPoints The count of story points.
    metric:IdealDays The count of ideal days.

    metric:Sloc

    Software development projects produce source code. The rules for what counts as a line of code have been established by the industry. This metric is typically broken down along component, feature, and programming language dimensions.

    metric:Esloc

    The work of the project involves both modifying pre-existing source code and writing new source code. The effective source lines of code (ESLOC) is the sum of the modified and new lines of code. This metric is typically broken down along component, feature, and programming language dimensions.

    metric:IFPUG42_FunctionPoints

    A function point count is a measure of the amount of function embodied in the source code developed by a project. The rules for counting function points have been established by standards organizations. metric:IFPUG42_FunctionPoints is defined by International Function Point User Group (IFPUG), The Function Point Standard, Counting Practices Manual, Release 4.2. This metric is typically broken down along the feature dimension.

    metric:UseCasePoints

    A use case is a way of describing requirements. Use cases are frequently used in object-oriented development projects. Use case diagrams are part of Unified Modelling Language (UML). A use case point count is a measure of the size of a software system based on the use cases it implements and other environmental factors.

    metric:StoryPoints

    A story point is an Agile metric that measures the relative size of a user story or epic. The relative scale is established by the Agile team and will differ from team to team. metric:StoryPoints is the total number of story points produced during a project. It is typically broken down along iteration and user story dimensions.

    metric:IdealDays

    An ideal day is an Aglie metric that measures the relative size of a user story or epic. The relative scale is established by the Agile team and will differ from team to team. metric:IdealDays is the total number of ideal days produced during a project. It is typically broken down along iteration and user story dimensions.

    Size Units of Measure

    Table of ems:UnitOfMeasure Standard URIs for Size Metrics
    URI Description
    unit:Loc One source line of code.
    unit:Kloc One thousand source lines of code (KLOC).
    unit:FunctionPoint A function point.
    unit:UseCasePoint A use case point.
    unit:StoryPoint A story point.
    unit:IdealDay An ideal day.

    ems:ReliabilityMetric

    ems:ReliabilityMetric is the class of all reliability metrics. It is a subclass of ems:Metric. Reliability metrics quantify the correctness of software.

    Table of ems:ReliabilityMetric Standard URIs
    URI Description
    metric:Defects The number of defects injected into the software.
    metric:FixedDefects The number of defects removed from the software.
    metric:LatentDefects The number of defects remaining in the software.
    metric:DefectsPerEsloc The number of injected defects per unit ESLOC produced.
    metric:DefectsPerFunctionPoint The number of injected defects per function point produced.
    metric:DefectsPerUseCasePoint The number of injected defects per use case point produced.
    metric:Failures The number of failures reported.
    metric:MeanTimeToFailure The average time between failures (MTTF).

    Reliability Units of Measure

    Table of ems:UnitOfMeasure Standard URIs for Reliability Metrics
    URI Description
    unit:Defect A defect, fault, or flaw in some software artifact, usually source code.
    unit:DefectsPerKloc Defects per KLOC.
    unit:DefectsPerFunctionPoint Defects per function point.
    unit:DefectsPerUseCasePoint Defects per use case point.
    unit:Failure A observed failure in the behaviour of the software system, e.g. an error in the output.

    ems:ProductivityMetric

    ems:ProductivityMetric is the class of all productivity metrics. It is a subclass of ems:Metric. Productivity metrics quantify the rate at which software is produced.

    Table of ems:ProductivityMetric Standard URIs
    URI Description
    metric:EslocPerTime The amount of ESLOC produced per unit time.
    metric:EslocPerEffort The amount of ESLOC produced per unit effort.
    metric:FunctionPointsPerTime The amount of function points produced per unit time.
    metric:FunctionPointsPerEffort The amount of function points produced per unit effort.
    metric:UseCasePointsPerTime The amount of use case points produced per unit time.
    metric:UseCasePointsPerEffort The amount of use case points produced per unit effort.
    metric:Galorath_EffectiveTechnology The Galorath Effective Technology.
    metric:QSM_ProductivityConstant The QSM Productivity Constant.
    metric:QSM_ProductivityIndex The QSM Productivity Index.
    metric:TeamVelocity The number of story points produced per iteration.

    Productivity Units of Measure

    Table of ems:UnitOfMeasure Standard URIs for Productivity Metrics
    URI Description
    unit:KlocPerMonth KLOC per month.
    unit:KlocPerPersonMonth KLOC per person-month.
    unit:FunctionPointPerMonth Function point per month.
    unit:FunctionPointPerPersonMonth Function point per person-month.
    unit:UseCasePointPerMonth Use case point per month.
    unit:UseCasePointPerPersonMonth Use case point per person-month.
    unit:Galorath The standard units in which the Galorath Effective Technology metric is measured.
    unit:Putnam The standard units in which the QSM Productivity Constant metric is measured.
    unit:StoryPointsPerIteration Story points per iteration.

    ems:ProcessMetric

    ems:ProcessMetric is the class of all process metrics. Process metrics measure the development process itself as opposed to the product being produced by the project. They are useful for monitoring and controlling the project.

    Table of ems:ProcessMetric Standard URIs

    URI Description


    metric:Builds The number of attempted software builds. metric:FailedBuilds The number of failed software builds. metric:SuccessfulBuilds The number of successful software builds. metric:TestCases The number of test cases. metric:TestExecutions The number of test executions. metric:FailedTestExecutions The number of failed test executions. metric:SuccessfulTestExecutions The number of successful test executions. metric:CMMI_MaturityLevelRating The CMMI maturity level rating.

    Process Units of Measure

    Table of ems:UnitOfMeasure Standard URIs for Process Metrics
    URI Description
    unit:Build A build of the system.
    unit:TestCase A test case.
    unit:TestExecution An execution of a test case.
    unit:CMMI_Level A CMMI level. Integer values from 1 to 5.

    Builds

    A build is a process the transforms source code into an executable system. Builds may be manual or automated, and may succeed or fail. A build attempt is successful if it produces an executable system. The frequency of successful builds is an indicator of project health.

    Tests

    A test case is an artifact that describes how to test some aspect of a software system. A test case specifies a sequence of inputs or actions, and their expected outputs or results. The number of test cases, the rate at which they are produced, and the coverage of the software system by test cases are useful metrics.

    A test execution is a process that runs a test case on a software system. Test executions may be manual or automated, and may succeed or fail. A test execution is successful if the system system produces the expected result for the test case. The percentage and frequency of successful test executions is an indicator of project health, and may be used as an exit criterion for the testing phase.

    CMMI

    Capability Maturity Model Integration (CMMI) is process improvement approach defined by industry experts and the Software Engineering Institute (SEI). The CMMI maturity level rating is a metric that describes the quality of the software development process used by an organization on a project. This metric is measured on the following numeric scale:

    CMMI Level Description
    1 Initial
    2 Managed
    3 Defined
    4 Quantitatively Managed
    5 Optimizing

    ems:FinancialMetric

    ems:FinancialMetric is the class of all financial metrics. It is a subclass of ems:Metric. Financial metrics quantify the cost, benefit, value, and investment aspects of a project.

    Table of ems:FinancialMetric Standard URIs
    URI Description
    metric:Cost The total cost to produce the software, including labor and all other costs.
    metric:LaborCost The cost of the labor used to produce the software.

    Financial Units of Measure

    QUDT defines standard URIs for currency units and we will use these here rather than defining new ones. The QUDT currency units are based on the ISO 4217 standard and they are members of the class qudt:CurrencyUnit. We therefore define qudt:CurrencyUnit to be a subclass of ems:UnitOfMeasure. All ISO 4217 currencies are defined in a qudt:SystemOfUnits resource named qudt-unit:SystemOfUnits_ISO4217-Currencies. The following table lists a sample of these currency units:

    Table of some qudt:Currency Standard URIs for Financial Metrics
    URI Description
    qudt-unit:CanadianDollar A currency amount of one Canadian dollar (CAD).
    qudt-unit:Euro A currency amount of one Euro (EUR).
    qudt-unit:IndianRupee A currency amount of one Indian rupee (INR).
    qudt-unit:JapaneseYen A currency amount of one Japanese yen rupee (JPY).
    qudt-unit:USDollar A currency amount of one US dollar (USD).
    qudt-unit:YuanRenminbi A currency amount of one Chinese yuan (CNY).

    Standard Dimensions

    A dimension is an attribute that can be used to analyse a metric. Metrics are typically computed by aggregating project events and so any attribute of those events may be a useful way to analyse the metric.

    For example, consider the peak staffing metric. It is computed by counting the number of people working on the project during each time period and taking the maximum of those counts. Peak staffing can therefore be analyzed by time. Furthermore, the count of all people could be broken down by their role, so peak staffing could also be analysed by role. In general, any metric may be analysed along several dimensions.

    In general, zero or more dimensions may be applicable to any given metric, and a given dimension may be applicable to zero or more metrics. The following table lists standard URIs for the key dimensions:

    Table of ems:Dimension Standard URIs
    URI Description
    dimension:Time How the project timeline is broken down into time periods, e.g. weeks, months, years.
    dimension:Phase How the work of the project is broken down into phases, e.g. requirements, design, construction.
    dimension:Iteration How the work of the project is broken down into iterations.
    dimension:Wbs How the work of the project is broken down into activities, tasks, etc.
    dimension:Role How the kind of work people perform on the project is broken down into roles, e.g. manager, programmer, tester.
    dimension:Product How the product being developed is broken down into systems, subsystems, components, etc.
    dimension:ProgrammingLanguage The source code produced in the project is broken done by programming language, e.g. Java, C#.
    dimension:Organization How the people are organized into functions, departments, teams, etc.
    dimension:Location How the people are located geographically.

    Standard Grains

    A grain defines the granularity by which a dimension is partitioned into a set of mutually exclusive bins or buckets. Any dimension may have one or more grains. The grains themselves may belong to one or more hierarchies such as the day-month-year hierarchary for calendar time.

    Table of ems:Grain Standard URIs
    URI Dimension Description
    grain:CalendarDay dimension:Time The set of calendar day time periods.
    grain:CalendarWeek dimension:Time The set of calendar week time periods.
    grain:CalendarMonth dimension:Time The set of calendar month time periods.
    grain:CalendarQuarter dimension:Time The set of calendar quarter time periods.
    grain:CalendarHalf dimension:Time The set of calendar half time periods.
    grain:CalendarYear dimension:Time The set of calendar year time periods.
    grain:ElapsedDay dimension:Time The set of elapsed day time periods.
    grain:ElapsedWeek dimension:Time The set of elapsed week time periods.
    grain:ElapsedMonth dimension:Time The set of elapsed month time periods.
    grain:ElapsedQuarter dimension:Time The set of elapsed quarter time periods.
    grain:ElapsedHalf dimension:Time The set of elapsed half time periods.
    grain:ElapsedYear dimension:Time The set of elapsed year time periods.
    grain:DoD_Phase dimension:Phase The set of standard US Department of Defense (!DoD) phases, e.g. Feasibility Study, High-Level Design.
    grain:RUP_Phase dimension:Phase The set of standard Rational Unified Process (RUP) phases, e.g. Inception, Elaboration.
    grain:Iteration dimension:Iteration The set of iterations.
    grain:Activity dimension:Wbs The set of activities.
    grain:Task dimension:Wbs The set of tasks.
    grain:WaterfallActivity dimension:Wbs The set of standard Waterfall activities, e.g. Requirements, Analysis.
    grain:Role dimension:Role The set of standard software project roles, e.g. Manager, Programmer, Tester.
    grain:System dimension:Product The set of systems.
    grain:Subsystem dimension:Product The set of subsystems.
    grain:Component dimension:Product The set of components.
    grain:Feature dimension:Product The set of features.
    grain:ProgrammingLanguageFamily dimension:ProgrammingLanguage The set of programming languages familites, e.g. Java, C, C++, C#, COBOL.
    grain:Department dimension:Organization The set of departments.
    grain:Team dimension:Organization The set of teams.
    grain:Continent dimension:Location The set of continents, e.g. North America, Europe, Asia.
    grain:Country dimension:Location The set of countries, e.g. Canada, USA, India, China.
    grain:City dimension:Location The set of cities, e.g. Toronto, Boston, Bangalore, Beijing.
    grain:Site dimension:Location The set of sites, i.e. the building or campus where people are located.

    grain:DoD_Phase

    grain:DoD_Phase is the class of all !DoD phases. The following table contains the standard URIs for !DoD phases:

    Table of !DoD Phase URIs
    URI Phase Name
    dimension-member:DoD_FeasibilityStudy Feasibility Study
    dimension-member:DoD_HighLevel Design High-Level Design
    dimension-member:DoD_MainBuild Main Build
    dimension-member:DoD_OperationMaintenance Operation, Maintenance

    grain:RUP_Phase

    grain:RUP_Phase is the class of all RUP phases. The following table contains the standard URIs for RUP phases:

    Table of RUP Phase URIs
    URI Phase Name
    dimension-member:RUP_Inception Inception
    dimension-member:RUP_Elaboration Elaboration
    dimension-member:RUP_Construction Construction
    dimension-member:RUP_Transition Transition

    grain:Role

    grain:Role is the class of all standard roles. The members of this class correspond to the standard role names commonly used in software estimation tools. The following table contains the standard URIs for roles:

    Table of Standard Role URIs for Dimension Members of grain:Role
    URI Role Name
    dimension-member:Manager Manager
    dimension-member:Tester Tester
    dimension-member:RequirementsAnalyst Requirements Analyst
    dimension-member:ArchitectOrDesigner Architect/Designer
    dimension-member:Programmer Programmer
    dimension-member:InformationDeveloper Information Developer
    dimension-member:ConfigurationManager Configuration Manager
    dimension-member:QualityAssurer Quality Assurer
    dimension-member:SupportTechnician Support Technician
    dimension-member:Other Other

    COCOMO

    The Constructive Cost Model (COCOMO) is a software estimation model defined by Dr. Barry Boehm. The current version is referred to as COCOMO II.

    The COCOMO II model computes project effort and duration from size. It contains several main parameters known as A, B, C, D, E, F, SF, and EM which are defined in the COCOMO II Model Definition Manual Version 2.1. SF is called the scale factor and EM is called the effort multiplier. Since these parameters are used to compute effort and duration from size, they are productivity metrics for the project.

    This model is of more general interest since it provides an analysis of the scale and cost drivers that influence SF and EM. SF can therefore be broken down along the scale driver dimension and EM can be broken down along the cost driver dimension. The model defines one grain size for the scale driver dimension and it contains five scale drivers. The model defines two grains for the cost driver dimension. There is one cost driver grain for use in the early design stage and it contains seven cost drivers. There is a second, more detailed grain size for the post-architecture phase and it contains seventeen cost drivers.

    Scale drivers only apply to the project as a whole, as does the required development schedule (SCED) cost driver. The other cost drivers may be further broken down by component of the system being developed.

    URI Class Description
    metric:COCOMO_A ems:ProductivityMetric The COCOMO II A parameter (A).
    metric:COCOMO_B ems:ProductivityMetric The COCOMO II B parameter (B).
    metric:COCOMO_C ems:ProductivityMetric The COCOMO II C parameter (C).
    metric:COCOMO_D ems:ProductivityMetric The COCOMO II D parameter (D).
    metric:COCOMO_E ems:ProductivityMetric The COCOMO II E parameter (E).
    metric:COCOMO_F ems:ProductivityMetric The COCOMO II F parameter (F).
    metric:COCOMO_ScaleFactor ems:ProductivityMetric The COCOMO II scale factor (SF).
    metric:COCOMO_EffortMultiplier ems:ProductivityMetric The COCOMO II effort multiplier (EM).
    dimension:COCOMO_ScaleDriver ems:Dimension The COCOMO II scale driver dimension for SF.
    dimension:COCOMO_CostDriver ems:Dimension The COCOMO II cost driver dimension for EM.
    grain:COCOMO_ScaleDriver ems:Grain The COCOMO II scale driver grain.
    grain:COCOMO_EarlyDesignCostDriver ems:Grain The COCOMO II early design stage cost driver grain.
    grain:COCOMO_PostArchitectureCostDriver ems:Grain The COCOMO II post-architecture stage cost driver grain.

    metric:COCOMO_ScaleFactor

    SF is broken down by scale drivers and the aggregate result is the sum of the values for each scale driver.

    The following table lists the members of the COCOMO scale driver dimension:

    Table of Members of grain:COCOMO_ScaleDriver
    URI Symbol Scale Driver Name
    dimension-member:COCOMO_Precedentedness PREC Precedentedness
    dimension-member:COCOMO_DevelopmentFlexibility FLEX Development Flexibility
    dimension-member:COCOMO_ArchitectureOrRiskResolution RESL Architecture/Risk Resolution
    dimension-member:COCOMO_TeamCohesion TEAM Team Cohesion
    dimension-member:COCOMO_ProcessMaturity PMAT Process Maturity

    metric:COCOMO_EffortMultiplier

    EM is broken down by cost drivers and the aggregate result is the product of the values for each cost driver.

    The following table lists the members of the COCOMO cost driver dimension for the early design stage:

    Table of Members of grain:COCOMO_EarlyDesignCostDriver
    URI Symbol Scale Driver Name
    dimension-member:COCOMO_PersonnelCapability PERS Personnel Capability
    dimension-member:COCOMO_ProductReliabilityAndComplexity RCPX Product Reliability and Complexity
    dimension-member:COCOMO_DevelopedForReusability RUSE Developed for Reusability
    dimension-member:COCOMO_PlatformDifficulty PDIF Platform Difficulty
    dimension-member:COCOMO_PersonnelExperience PREX Personnel Experience
    dimension-member:COCOMO_Facilities FCIL Facilities
    dimension-member:COCOMO_RequiredDevelopmentSchedule SCED Required Development Schedule

    The following table lists the members of the COCOMO cost driver dimension for the post-architecture stage:

    Table of Members of grain:COCOMO_PostArchitectureCostDriver
    URI Symbol Scale Driver Name
    dimension-member:COCOMO_RequiredSoftwareReliability RELY Required Software Reliability
    dimension-member:COCOMO_DataBaseSize DATA Data Base Size
    dimension-member:COCOMO_ProductComplexity CPLX Product Complexity
    dimension-member:COCOMO_DevelopedForReusability RUSE Developed for Reusability
    dimension-member:COCOMO_DocumentationMatchToLifeCycleNeeds DOCU Documentation Match to Life-Cycle Needs
    dimension-member:COCOMO_ExecutionTimeConstraint TIME Execution Time Constraint
    dimension-member:COCOMO_MainStorageConstraint STOR Main Storage Constraint
    dimension-member:COCOMO_PlatformVolatility PVOL Platform Volatility
    dimension-member:COCOMO_AnalystCapability ACAP Analyst Capability
    dimension-member:COCOMO_ProgrammerCapability PCAP Programmer Capability
    dimension-member:COCOMO_PersonnelCapaility PCON Personnel Capaility
    dimension-member:COCOMO_ApplicationsExperience APEX Applications Experience
    dimension-member:COCOMO_PlatformExperience PLEX Platform Experience
    dimension-member:COCOMO_LanguageAndToolExperience LTEX Language and Tool Experience
    dimension-member:COCOMO_UseOfSoftwareTools TOOL Use of Software Tools
    dimension-member:COCOMO_MultisiteDevelopment SITE Multisite Development
    dimension-member:COCOMO_RequiredDevelopmentSchedule SCED Required Development Schedule

    References

    Category:Rest API main topics


    Categories