EMS 1.0 REST API Standard URIs

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

CMMI
COCOMO-II
Cohn2006, Mike Cohn, Prentice Hall, 2006
Collaris2009, Remi-Armand Collaris and Eef Dekker, IBM developerWorks, 2009
Galorath2006, Daniel D. Galorath and Michael W. Evans, Auerbach Publications, 2006
IFPUG
IFPUG42
Krutchen2003, Philippe Krutchen, Addison-Wesley, 2003
PMBOK
ISO4217
Putnam2003, Lawrence H. Putnam and Ware Meyers, Dorset House, 2003
QUDT2010, James Masters, Ralph Hodgson, and Paul J. Keller, NASA and !TopQuadrant, 2010
SWEBOK

Category:Rest API main topics