Explain empirical vs defined & prescriptive process?

To make any process successful it has to be controlled in a way that it achieves its predefined goals or we can say it should be guided along the path of success. This fact holds good for any type of process in this world and so does for the processes in the field of software engineering.

In the field of software engineering, two approaches have been identified for keeping a control over the development and other related processes namely:


1. The empirical process control method and
2. The defined process control method.


In this article the above mentioned two approaches have been compared so that you get a better understanding of both the programs. So let us see how these two approaches control the processes.

The Empirical Process Control Method

- The empirical process control model was defined to exercise or control the process via following some frequent adaptations as well as frequent inspections.

- These inspections and the adaptations both are meant for the generation of the unpredictable and unrepeatable outcomes or results and can be thought of as being imperfectly designed.

- Since for the past many years the various software development methodologies have been known to be controlled by the latter approach i.e., the defined process control method.

- But we all know that every time a certain same output or outcome cannot be expected from the software development processes.

- Therefore, most of the agile software development methodologies are controlled by the empirical process control model and the most famous example being that of the “scrum” agile software development methodology.

- The term empirical process control model itself justifies as the term empirical means the information acquired by the means of experimentation and observation.

- Here the information is achieved by means of inspection and adaptations which serve as a means for the observation and experimentation.

- The process of the empirical control is constituted of a continuous cycle of adaptation of the process as per the requirements and inspection of the process for correct working.

- The empirical control process model has three pillars as we can make out from the definition of the process control model without which it cannot be called as the empirical process control method:
1. Transparency
2. Inspection and
3. Adaptation.

- The first pillar i.e., transparency indicates that the outcomes of the affects of the empirical process control model and the aspects affecting the outcomes should be visible to the programmers and developers who are responsible for controlling the whole process.

- The second pillar i.e., the inspection indicates that all the aspects of the control process should be monitored quite frequently to enable the fast and early detection of the unacceptable variances.

- The third pillar i.e., the adaptation indicates the adjustment of one or more aspects as required of the control process if the software system or application being processed is observed to lie outside the acceptable limits implying that the result will also be unacceptable.

- The defined process control model approach is adopted when the underlying mechanisms of the software system or application are well understood by the programmers and the developers.

The Defined Process Control Model

- The defined process control model can be thought of as a theoretical approach.

- When a well defined set of inputs is given, it is obvious that the same outcomes will be generated every time the program executes.

- With the well understood technologies and stable requirements, one can very well predict a whole software project.

- Even nowadays the empirical process control model holds as the essence of the agile software development processes.

- Empirical process holds good for the complex development processes which encounter difficulty in the production of repetitive outcomes.

What are different interpreting data defects?

A software system or application can perform an assigned task only when it is capable of interpreting or analyzing the data. The proper analysis or interpretation of data is very much necessary for the proper execution of the task.
If the data interpretation itself is wrong, then you cannot expect the accurate results.

STEPS INVOLVED IN INTERPRETATION OF DATA
The interpretation of data involves the following steps:
- Inspection of data
- Cleaning of data
- Transformation of data
- Modeling of data

These steps are responsible for producing only the meaningful data with conclusions and any other supportive decisions. There are many approaches and facets of the data interpretation.

DATA INTERPRETING TECHNIQUES
- Data analysis employs various different data interpretation techniques in different domains.
- Following are some data interpreting techniques:
1. Data mining
These techniques are focused up on the modeling of data as well as descriptive purposes.

2. Business intelligence
- This interpreting technique is suitable for heavy data bases where a lot of aggregation work is required.
- This basically used in the business domain.

3. Statistical Analysis
Further comprises of two techniques namely exploratory data analysis (EDA, discovers new features), descriptive analysis and CDA or confirmatory data analysis (responsible for proving the existing hypotheses wrong).

4. Predictive Analytic
It is employed for predictive forecasting.

5. Text Analytic
It is used for extraction and classification of the data from various sources.

CATEGORIES OF DATA TYPES
Different data types employ different interpreting techniques. The data is classified in to the following categories:

1. Qualitative Data
Data denotes the presence or absence of a particular characteristic (passes/ fail).
2. Quantitative Data
Data is numerical either a continuous decimal number to a specified range or a whole counting number.
3. Categorical Data
Data from several different or similar categories.

DATA INTERPRETATION/ANALYSIS PROCESS
The interpretation or analysis of data is not a simple process and indeed involves complex processes. And complex processes are very much prone to defects and errors.
- In a data interpretation process, defects can exist in every phase.
- Let us start from the first step of the process and discuss the defects as we move down in the process.
- Data cleaning involves the removal of erroneous data.
- If the program performing the task of data cleaning itself is diagnosed with some defect, then it can let in some erroneous data which in turn can cause many defects in the whole process.
- The changes made in data should be retrievable and should be documented.
- It is recommended that the data to be analyzed should be quality checked as soon as possible since the defective data is the cause of many defects in the interpretation process.
- There are several ways of checking the quality like:
# Descriptive statistics
# Normality
# Associations
# Frequency counts

- In some cases the values of data might be missing.
- This can also cause the whole interpretation process to hang up or falter or it can also come to a halt.
- In such a case the missing data can be imputed.
- Defects can occur if the data is not uniformly distributed.
- To determine this randomization procedure should be checked for its success.
- If you have not included a randomization procedure, you can use a non sampling randomization procedure.

SOME DATA DISTORTIONS
There are some possible data distortions that also give rise to data interpreting defects:
1. Item Non Response
The data should be analyzed for this factor in the initial stage of the data analysis itself. The presence of randomization does not matter here.
2. Drop Out
Like item non response, the data is to be analyzed for this also in the beginning itself.
3. Quality Treatment
The bad quality of the data should be treated with various manipulation checks.

Some best practices that contribute to improved software testing

There is always a serach for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The basic practices are like training wheels which you need to get started and when you take them off, you know ow to ride. The basic practices include:

- Functional Specifications
It is basically a development activity but it is also necessary for software functional test. It defines the external view of an object or procedure. It helps the test generation activity to move in parallel with code development. It helps in the clarity from designer's and an architect perspective.
- Reviews and Inspections
Software reviews and inspection provides a ten times gain in debugging process.
- Formal entry and exit criteria
This practice offers a careful management of software development process. Every process step has a precise entry and exit criteria defined by development process and management keeps a track of the movement from one stage to another.
- Functional test varaitions
This practice involves understanding how to write variations which refers to combination of input condition to yield a output and gain coverage to thoroughly test the function.
- Multi platform testing
Today products run on different platforms so the necessity arises of designing and testing the product for different platforms. This practice addresses aspects of multi platform development and testing.
- Internal betas
Beta means the product is released to few customers and their feedback is recorded. This practice deals with beta programs to best levarage it and reduce cost of external beta.
- Automated test execution
Using automated test execution, the amount of manual work is minimized and higher coverage is gained. This is the best practice which is well understood in some areas. This practice needs to levarage and then develop methods for areas where automation is not fully done.
- Beta programs
- Nightly builds
Nightly build captures frequent builds from changes that being promoted. Advantages include firstly, errors are captured quickly if major regression occurs. Secondly, regression tests can run in background. Thirdly, newer releases of software are available to developers and testers sooner.

Formal Technical Review - Fagan's Inspection Method

Fagan's Inspection Method is introduced by Fagon. Apart from checking codes of programs,it is used to check other work products such as technical documents, model elements, data and code design etc. It follows certain procedural rules that each member should follow:
- The time limit for an inspection meeting is for two hours.
- Inspections are led by a trained moderator.
- Inspections are carried out at a number of points in the process of project planning and systems development.
- All classes of defects in documentation and work product are inspected.
- Inspection is carried out by colleagues at all levels of seniority except the big boss.
- Inspectors are assigned specific roles to increase effectiveness.
- Statistics on types of errors are key, and used for reports which are analyzed in a manner similar to financial analysis.

Different activities that are involved in conducting inspections are:
- Planning is very important and in this case the moderator is asked to build up a plan.
- Presentation should be given which gives an overall overview.
- Each inspector is given 1 to 2 hours alone to inspect the workproduct.
- Meeting should be held in which participants of the meeting are the inspectors, moderator and the developer of the work product.
- The defect list is given for repair.
- Follow up with the repair work.
- Casual analysis meeting is held where inspectors are given a chance to express their personal view on errors and improvements.

Verification Strategies - Overview of Inspections

Inspections are static analysis techniques that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include :
- code inspection
- design inspection
- architectural inspections
- test ware inspections

The participants in inspections include inspection leader, recorder, reader, author, inspector. All participants in the review are inspectors. The author should not act as an inspection leader, reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over nay member of the inspection team shall not participate in the inspection.

Input Criteria includes:
- Statement of objectives for the inspection.
- The software product to be inspected.
- Documented inspection procedure.
- Inspection reporting forms.
- Current anomalies or issues list.
- Inspection checklists.
- Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected.
- Hardware product specifications.
- Hardware performance data.
- Anomaly categories.
The individuals may make additional reference material available responsible for the software product when requested by the inspection leader.

The purpose of the exit criteria is to bring an unambiguous closure to the inspection meeting. The exit decision shall determine if the software product meets the inspection exit criteria and shall prescribe any appropriate re-work and verification. Specifically, the inspection team shall identify the software product disposition as one of the following:
- Accept with no or minor re-work : The software product is accepted as is or with only minor re-work.
- Accept with re-work verification : The software product is to be accepted after the inspection leader or a designated member of the inspection team verifies re-work.
- Re-inspect : Schedule a re-inspection to verify rework. At a minimum, a re-inspection shall examine the software product areas changed to resolve anomalies identified in the last inspection.