The COCOMO (Constructive Cost Estimation Model) Model - Basic, Intermediate and Complete COCOMO

COCOMO (Constructive Cost Estimation Model) was proposed by Boehm. COCOMO is a widely spread model that combines statistical figures, mathematical equations, and expert judgement. COCOMO is an open model. It includes the underlying cost estimation equations, every assumption made in the model, every definition and the costs included in an estimate are explicitly stated.

- COCOMO estimates are more objective and repeatable than estimates made by methods relying on proprietary models.
- COCOMO can be calibrated to reflect your software development environment, and to produce more accurate estimates.

Software cost estimation should be done through three stages:
- Basic COCOMO : It is a single-valued, static model in which the development effort is estimated as a function of program size.
Effort = a1 х (KLOC)^a2 PM
Tdev = b1 x (Effort)^b2 Months
where:
• KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
• a1, a2, b1, b2 are constants for each category of software products,
• Tdev is the estimated time to develop the software, expressed in
months,
• Effort is the total effort required to develop the software product.

- Intermediate COCOMO : It computes software development effort as a function of program size and a set of fifteen "cost drivers". It takes into account factors such as required product reliability, database size, execution and storage constraints, personnel aptitude, and the use of software tools.

- Complete COCOMO : The main shortcoming of basic and intermediate COCOMO model is that they consider a software product as a single homogeneous entity. The system is made up of sub-systems which have their own characteristics. Sub-systems may have different inherent development complexity, reliability requirements may be high, development team experience.
The complete COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems.

Project Management - The W5HH Principle

Barry Bohem suggested an approach that addresses project objectives, milestones and schedules, responsibilities, management and technical approaches and required resources. This is called W5HH principle. The questions that are answered in this principle are:

- Why is the system being developed?
- What will be done by When?
- Who is responsible for a function?
- Where are they organizationally located?
- How will the job be done technically and managerially?
- How much of each resource is needed?

WHY IS THE SYSTEM BEING DEVELOPED?
It enables the parties to assess the validity of business reasons for the software work. It justifies the expenditure of people, time, and money.

WHAT WILL BE DONE?
It specifies the task set required for the project.

WHEN WILL IT BE DONE?
It helps to determine the project schedule. It helps in determining when tasks are conducted and when milestones are reached.

WHO IS RESPONSIBLE FOR A FUNCTION?
It helps to accomplish the role and responsibilities of each member of the software team.

WHERE ARE THEY ORGANIZATIONALLY LOCATED?
The software team does not contain all the roles and responsibilities. The customers, users and stakeholders also have responsibilities.

HOW WILL THE JOB BE DONE TECHNICALLY AND MANAGERIALLY?
The management and technical strategy of project is defined once the scope of the product is established.

HOW MUCH OF EACH RESOURCE IS NEEDED?
It helps in deriving estimates based on the answers to the above questions.

Cleanroom Software Engineering - Advantages, Principles and Process Teams

Cleanroom software engineering involves the integrated use of software engineering modeling, program verification and statistical software quality assurance.
- Cleanroom software engineering verifies design specification using mathematically-based proof of correctness.
- Cleanroom software engineering relies heavily on statistical use testing to uncover high impact errors.
- Cleanroom software engineering generally follows an incremental development process.

CLEANROOM PRINCIPLES

- Small Teams include independent specification, development, and certification sub-teams.
- Incremental development under statistical quality control.
- Software development is based on mathematical principles. The box principle is used for specification and design. The formal verification is used to confirm correctness of implementation of specification. The program correctness is verified by team reviews using questionnaires.
- Testing is based on statistical principles.

CLEANROOM PROCESS TEAMS

- Specification team develops and maintains the system specification.
- Development team develops and verifies software. The software is not compiled or executes during verification.
- Certification team develops set of statistical test to exercise software after development. Reliability growth models are used to assess reliability.

BENEFITS OF CLEANROOM SOFTWARE ENGINEERING

- Zero failures in the field which is a goal but a realistic expectation is<5 failures per KLOC on first program execution in the first team project.
- Short development cycles
- Longer product life.

Cleanroom Testing - Statistical Use Testing and Certfication

Clean room testing is different from conventional testing approaches. The goal of clean room testing is to validate software requirements by demonstrating that a statistical sample of use-cases have been executed successfully.

Statistical use testing tests the software in a way the users intend to use it. the clean room testing teams determine the usage probability distribution or the software. Each increment's specification is analyzed to define a set of inputs or events that cause the software to change its behavior. A probability of use is assigned to each input or event based on the interviews with users, the creation of usage scenarios and a general understanding o application domain. The testing team executes these use cases and verifies software behavior against the specification for the system. Using the recorded interval times, the certification team can compute mean time to failure.

Within the clean room software engineering approach, certification implies that the reliability can be specified for each component. Reusable software components can be stored along with their usage scenarios, program stimuli, and probability distributions. The certification approach involves :
- usage scenarios must be created.
- usage profile is specified.
- test cases are generated from profile.
- tests are executed and failure data are recorded and analyzed.
- reliability is computed and certified.

Certification for clean room software engineering requires creation of three models:
- Sampling Model : Certification is given if no failure or a specified number of failures occur after executing m random test cases. The value of m is derived mathematically.
- Component Model : This model enables the analyst to determine the probability that component i will fail prior to completion.
- Certification Model : The overall reliability of the system is projected and certified.

Model Driven Architecture (MDA) - Advantages and MDA Process

The MDA is a new way of writing specifications, based on a platform-independent
model.

Why should we use Model Driven Architecture

- Portability
- Interoperability
- Domain facilities provide much wider interoperability.
- MDA allows to model the functionality and behavior only once, therefore saves a lot of time.
- Requirements are always changing.
- New technology is arising.
- Require to integrate old system with new system, and any other system in future.
- MDA makes it easier to integrate applications and facilities across middle-ware boundaries.

Model Driven Architecture Process

THE BASIC PROCESS
- To construct a MDA application, the first step is to create a computation independent model(CIM) by a business analyst.
- The CIM is transformed into platform independent model(PIM) by enterprise architect.
- The resulting PIM has to be targeted to a platform to complete the build process.
- The transformation of a PIM to a PSM will be done by a platform specialist.

THE COMPLEX PROCESS
The process from computation independent model to platform specific model can be a bit more complex.
- Between the models, there can be some gaps present which makes transformation difficult.
- As a result, you can have interrelated models having different layers of abstraction.
- One consequence is that a single layer of abstraction can have horizontal transformations. Consider the example where a PIM is converted multiple times into more detailed PIMs. And there are vertical transformations in addition to vertical transformation of models.

Model Driven Architecture (MDA) - Characteristics and Viewpoints

OMG was formed as a standards organization to help reduce complexity, lower costs, and hasten the introduction of new software applications.
- The Object Management Group (OMG) adopted the Model Driven Architecture as an approach for using models in software development.
- Its three primary goals are portability, interoperability and reusability through architectural separation of concerns.

Characteristics of Model Driven Architecture(MDA)

- MDA enables development of new specifications.
- MDA provides a comprehensive, structured solution for application interoperability and portability into the future.
- MDA consists of services specified by OMG. It also includes directory services, event handling, persistence, transactions, and security.
- MDA enables the creation of standardized domain models for some vertical industries.
- MDA separates the operation of the system from the way it uses its capabilities of its platform.
- MDA enables converting platform-independent models to produce platform-specific models using mappings.

What are different viewpoints of Model Driven Architecture

- The first viewpoint is called Computation Independent Viewpoint which focuses on environment and requirements of the system rather than the details of system's structure and processing.
- The second viewpoint is called Platform Independent Viewpoint which focuses on how the system operates. It hides the details necessary for a particular platform. The part of complete specification does not change when the platform changes.
- The third viewpoint is called Platform Specific Viewpoint which focus on the detail of the use of a specific platform in addition to platform independent viewpoint.

Rapid Application Development (RAD) - Advantages and Disadvantages

The main objective of Rapid Application Development is to avoid extensive pre-planning, generally allowing software to be written much faster and making it easier to change requirements.
Rapid Application Development Model (RAD Model) is a linear sequence of the software development process model where we focus a very short development cycle by using a component based construction approach.

When organizations adopt rapid development methodologies, care must be taken to avoid role and responsibility confusion and communication breakdown within the development team, and between the team and the client.

To facilitate rapid development, strong emphasis was placed on the idea of software re-use. The notion of software components began to be nurtured.

ADVANTAGES OF RAPID APPLICATION DEVELOPMENT(RAD)

- It increases speed of developing software. It can be achieved using methods like rapid prototyping, virtualization of system related routines, the use of CASE tools and other techniques.
- Re-usability of components help to speed up development.
- It increases the quality.
- Some systems also deliver advantages of interoperability, extensibility, and portability.
- It incorporates short development cycles.
- Promotes strong collaborative atmosphere and dynamic gathering of requirements.

DISADVANTAGES OF RAPID APPLICATION DEVELOPMENT(RAD)

- Unknown cost of product.
- Difficult to commit the time required for success of the RAD process.
- Short iteration may not add enough functionality, leading to significant delays in final iterations.
- Early RAD systems faces reduced scalability occurs because a RAD developed application starts as a prototype and evolves into a finished application.
- Early RAD systems have reduced features that occur due to time boxing, where features are pushed to later versions in order to finish a release in a short amount of time.
- Dependency on strong cohesive teams and individual commitment to the project.