Information Technology Reference
In-Depth Information
A unique feature is that measurements start with an SRM estimate. Clients can
examine the estimate and accept or modify each activity. This makes the SRM tool
a self-learning tool that can absorb new technical advances as they occur.
The fact that SRM measures individual activities allows very high precision
measurements that, in theory, can top 1%. However, most corporate historical data
“leak” and are incomplete, so interviews with team members may be needed to re-
cover missing elements such as unpaid overtime, which seldom gets recorded.
SRM size predictions use function points defined by the IFPUG as the primary
metric. However, the SRM tool is metric-neutral and in fact predicts software ap-
plication size by using 15 different metrics, including SNAP nonfunctional met-
rics, COSMIC function points, story points, use-case points, logical source code
metrics, and others. (COSMIC is a sort of strained acronym for “Common Soft-
ware Measurement International Consortium.” This is clearly an artificial arrange-
ment of words.)
The idea behind early sizing and early estimating is that if potential problems
can be identified early prior to determining requirements, then there is still time to
deploy effective technologies before the project proceeds in a hazardous direction.
Many factors influence project outcomes. The variables that are used to show
clients the outcomes of software projects include complexity of the problem set,
data complexity, and code complexity; the methodology used for development; the
experience of the development personnel; management experience; the program-
ming language or combination of languages used; the level of the organization on
the SEI capability maturity scale (CMMI); and several others. A total of 34 meth-
ods are supported, including Agile, iterative, waterfall, Prince2, Merise, RUP, TSP,
and others. Hybrid methods are also supported.
It is useful to show clients side-by-side results of the same project with different
technology stacks. For example, it is easy to show side-by-side results for a future
project with one version demonstrating the Agile method and the C# programming
language with 15% reuse, while a second version demonstrates the TSP method
and the Objective-C programming language with 30% reuse.
The major cost drivers for software projects in approximate order are the fol-
lowing:
1.
Finding and fixing bugs
2.
Producing paper documents such as requirements and specifications
3.
Developing code
Search WWH ::
Custom Search