ETVX

 Process quality and ETVX

Quality in the process

A quality process has the right inputs and performs the right actions to produce outputs that meet the needs of customer processes.
Definitions of quality thus include:

• Fitness for purpose
• Right output, right time, right place
• Customer satisfaction

ETVX

There are four places where the quality can be specified and checked:

• Entry criteria define what inputs are required and what quality these must be to achieve the exit criteria. Entry criteria should be communicated to supplier processes, to become their exit criteria. If supplier processes are sufficiently well controlled, then there is no need to check inputs.
• Task definitions specify the actions within the process.
• Validation definitions identify test points within the process and define the tests and criteria for checking at these points. This enables problems to be caught close to their cause, reducing rework and scrap costs, and enabling problem causes to be addressed.
• Exit criteria define what outputs are required and what quality these must be to meet the needs of customer processes. Exit criteria may be derived from the entry criteria of customer processes.

Together, these make up what is known as the ETVX model (as below), which can be used to define the process and the quality required within it completely.

Fig. 1. The ETVX model

Spiral Model

The WIN-WIN Spiral Model

In this model the developer and the customer both together strive for a “win-win” result. The customer wins by getting the system or product that satisfies the majority of the customer needs and the developer wins by working on realistic and achievable goals, budgets and deadlines. Rather than a single customer communication activity the following activities are defined:

• Identification of the Key Stakeholders in the organization.
• Determination of the Key Stakeholders “Win conditions” - a crucial step.
• Negotiating of the stake holders win conditions into a set of win-win conditions for all including the developers, management, customers and the various other stake holders.

In addition to the negotiations, the WINWIN spiral model also introduces three process milestones (anchor points) which help completion of one cycle around the spiral and provides the decision milestones. The three process milestones are:

• 1. Life Cycle Objective (LCO) – defines a set of activity for each major software engineering activity. Eg. Defining the top-level system/product requirements.
• Life Cycle Architecture (LCA) – defines the objectives that must be met as the system and software architecture is defined. Eg. The software team can demonstrate that they have evaluated the applicability of the software and also considered the impact on architectural decisions.

3. Initial Operational Capability (IOC) – defines the set of objectives

Advantages:

• Faster software production facilitated through collaborative involvement of the relevant stake holders.
• Cheaper software via rework and maintenance reductions

The Spiral Model

The Spiral Model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the Linear Sequential Model. Using the Spiral Model the software is developed in a series of incremental releases. Unlike the Iteration Model where in the first product is a core product, in the Spiral Model the early iterations could result in a paper model or a prototype. However, during later iterations more complex functionalities could be added.

A Spiral Model, combines the iterative nature of prototyping with the controlled and systematic aspects of the Waterfall Model, therein providing the potential for rapid development of incremental versions of the software. A Spiral Model is divided into a number of framework activities, also called task regions. These task regions could vary from 3-6 in number and they are:

• Customer Communication - tasks required to establish effective communication between the developer and customer.

• Planning - tasks required to define resources, timelines and other project related information /items.

• Risk Analysis - tasks required to assess the technical and management risks.

• Engineering - tasks required to build one or more representation of the application.

• Construction & Release - tasks required to construct, test and support (eg. Documentation and training)

• Customer evaluation - tasks required to obtain periodic customer feedback so that there are no last minute surprises.

Advantages of the Spiral Model

• Realistic approach to the development because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.

• The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.

• It maintains a systematic stepwise approach, like the classic waterfall model, and also incorporates into it an iterative framework that more reflect the real world.

Disadvantages of the Spiral Model

• One should possess considerable risk-assessment expertise
• It has not been employed as much proven models (e.g. the Waterfall Model) and hence may prove difficult to ‘sell’ to the client. 

COCOMO MODEL

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic regression formula, with parameters that are derived from historical project data and current project characteristics.
COCOMO was first published in 1981 Barry W. Boehm's Book Software engineering economics^[1] as a model for estimating effort, cost, and schedule for software projects. It drew on a study of 63 projects at TRW Aerospace where Barry Boehm was Director of Software Research and Technology in 1981. The study examined projects ranging in size from 2,000 to 100,000 lines of code, and programming languages ranging from assembly to PL/I. These projects were based on the waterfall model of software development which was the prevalent software development process in 1981.
References to this model typically call it COCOMO 81. In 1997 COCOMO II was developed and finally published in 2000 in the book Software Cost Estimation with COCOMO II^[2]. COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability and the use of off-the-shelf software components. This article refers to COCOMO 81.
COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally accounts for the influence of individual project phases.

Basic COCOMO

Basic COCOMO computes software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of lines of code (KLOC).
COCOMO applies to three classes of software projects:

• Organic projects - "small" teams with "good" experience working with "less than rigid" requirements
• Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than rigid requirements
• Embedded projects - developed within a set of "tight" constraints (hardware, software, operational, ...)

The basic COCOMO equations take the form

Effort Applied = a_b(KLOC)^b_b [ man-months ]

Development Time = c_b(Effort Applied)^d_b [months]

People required = Effort Applied / Development Time [count]

The coefficients a_b, b_b, c_b and d_b are given in the following table.

Software project    ab      bb      cb      db
  
   Organic             2.4     1.05    2.5     0.38
   Semi-detached       3.0     1.12    2.5     0.35
   Embedded            3.6     1.20    2.5     0.32

Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on.

Intermediate COCOMO

Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers", each with a number of subsidiary attributes:-

• Product attributes
  
  
  • Required software reliability
  • Size of application database
  • Complexity of the product
• Hardware attributes
  
  
  • Run-time performance constraints
  • Memory constraints
  • Volatility of the virtual machine environment
  • Required turnabout time
• Personnel attributes
  
  
  • Analyst capability
  • Software engineering capability
  • Applications experience
  • Virtual machine experience
  • Programming language experience
• Project attributes
  
  
  • Use of software tools
  • Application of software engineering methods
  • Required development schedule

Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). An effort multiplier from the table below applies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.

Cost Drivers	Ratings
	Very Low	Low	Nominal	High	Very High	Extra High
Product attributes
Required software reliability	0.75	0.88	1.00	1.15	1.40
Size of application database		0.94	1.00	1.08	1.16
Complexity of the product	0.70	0.85	1.00	1.15	1.30	1.65
Hardware attributes
Run-time performance constraints			1.00	1.11	1.30	1.66
Memory constraints			1.00	1.06	1.21	1.56
Volatility of the virtual machine environment		0.87	1.00	1.15	1.30
Required turnabout time		0.87	1.00	1.07	1.15
Personnel attributes
Analyst capability	1.46	1.19	1.00	0.86	0.71
Applications experience	1.29	1.13	1.00	0.91	0.82
Software engineer capability	1.42	1.17	1.00	0.86	0.70
Virtual machine experience	1.21	1.10	1.00	0.90
Programming language experience	1.14	1.07	1.00	0.95
Project attributes
Application of software engineering methods	1.24	1.10	1.00	0.91	0.82
Use of software tools	1.24	1.10	1.00	0.91	0.83
Required development schedule	1.23	1.08	1.00	1.04	1.10

The Intermediate Cocomo formula now takes the form:

E=a_i(KLoC)^(b_i).EAF

where E is the effort applied in person-months, KLoC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The coefficient a_i and the exponent b_i are given in the next table.

Software project	ai	bi
Organic	3.2	1.05
Semi-detached	3.0	1.12
Embedded	2.8	1.20

The Development time D calculation uses E in the same way as in the Basic COCOMO.

 Detailed COCOMO

Detailed COCOMO - incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.

Example