What is meant by Statistical Usage Testing?

Statistical usage testing is the testing process that is aimed at the fitness of the software system or application.

The test cases chosen for carrying out statistical usage testing mostly consist of the usage scenarios and so the testing has been named as statistical usage testing. Software quality is ensured by the extensive testing but that has to be quite efficient. Testing expenditures covers about 20 – 25 percent of the overall cost of the software project. In order to reduce the testing efforts, deploy the available testing tools since they can create automated tests. But usually what happens is that the important tests require manual intervention with the tester requiring thinking about the usage as well behavior of the software. This is just the repetition of the tasks that were done during the requirements analysis phase.

About Statistical Usage Testing

- A usage model forms the basis for the creation of tests in statistical usage testing.

- Usage model is actually a directed usage graph more like a state machine and it consists of various states and transitions. 

- Every transition state has a probability associated with it regarding the traversal of the transition when the system would be in a state that marks the beginning of the transition arc. 

- Therefore, the sum of the probabilities of outgoing transitions sum up to unity for every state.

- Every transition can be associated with an event and more with parameters that are known to trigger the particular transition. 

- Such event associated transitions can be further related to certain conditions called the guard conditions. 

- These conditions imply that the transition occurs only if the value of the event parameter satisfies the condition.

- For assigning probabilities to the transitions, 3 approaches have been defined as follows:

1. Uninformed approach: In this approach, same probability is assigned to the exit arcs of a state.
2. Informed approach: In this approach, a sample of user event sequences for calculating suitable properties. The sample is captured from either an earlier version of the software or its prototype.
3. Intended approach: This approach is used for shifting the focus of the test to certain state transitions and for modeling the hypothetical users.

- According to a property termed as the marcov property, the actual state is what on which the transition probabilities are dependent. 

- However, they are independent of the history again by the property. 

- This implies that the probabilities must be fixed numbers. 

- A system based up on this property is termed as a marcov chain and it requires conclusion of some analytical descriptions. 

- Usage distribution is one among such descriptions. 

- It gives for every state its steady–state probability i.e., appearance rate that is expected.

- All the states are associated to one or the other part of the software system or application and the part of the software that attracts more attention from the tests is shown by the usage distribution. 

- Some other important descriptions are:

1. Expected test case length
2. Number of test cases required for the verification of the desired reliability of the software system or application.

- The idea of the usage model generation can be extended by handling guard conditions and enabling the non–deterministic behavior of the system depending on the state of the system’s data. 

- All this helps towards the application of the statistical usage testing to systems over a wide range. 

- The use cases are defined by the top–level structure of the unified modeling language (UML). 

Transition Phase - One of the phase of Rational Unified Process

There are 4 phases which together constitute the rational unified process namely:

1. Inception phase
2. Elaboration phase
3. Construction phase
4. Transition phase

The above mentioned phases are responsible for the representation of the rational unified process at the highest level in the way which is similar to waterfall model representation but the difference is that the key for the rational unified process lies in the development iterations which form an integral part of all the phases of the rational unified process. 

Also, each of the four phases of the rational unified process are characterized by two things namely the objective and the milestone. The objective drives the whole phase from the beginning to the end and the milestone concludes the end of it. 

The phase is said to be complete with successful result if and only if it passes the milestone since this only marks the conclusion of the phase. All of the phases of the rational unified process are visualized in the form of a chart called the RUP hump chart which is drawn over the course of the whole process. 

In this article we shall discuss exclusively about the fourth phase of the rational unified process i.e., the transition phase. 

Objective of Transition Phase

- The primary objective with which the transition phase is driven is “to transit the software system or application” from the phase of development in to the actual phase of production. 

- This also extends the availability of the software system or application to the end user in such a form that it is understandable by the end user. 

- This phase involves the below mentioned activities:

1. Training the end users
2. Training the maintainers as well.
3. Carrying out beta testing on the software system or application for validating it against the expectations of the end users.
4. Checking the software product against the quality level that was set in the inception phase.

- When all the objectives are said to be accomplished, the software system or application is said to reach the ‘product release milestone’ and the development cycle is said to be concluded.

- This fourth phase of the rational unified process does the fine tuning of the software product.

- It is based on the feedback from the user and the software product is made ready for the release. 

- The transition phase is basically focused on the availability of the software system or application to the end users.

- The transition phase often involves the spanning of the several iterations. 

- The software product is tested in order to prepare it for the release and also minor adjustments are made as per the feedback provided by the end users. 

- When this point in the software development life cycle is reached, it is required that the feedback from the end user should be majorly focused up on the following issues:

1. Fine tuning of the software system or the application.
2. Configuration of the product
3. Installation issues
4. Usability issues

- By this time, almost all the major issues of the product structure should have been worked out in the earlier phases of the software development life cycle. 

- The product release milestone can be defined as a point where it is decided that all the objectives of the project have been met and whether or not another development cycle is required. 

- The basic and majority of the evaluation as well as the refinement of the software system or application is done based up on the feedback from the user.

- This can be considered to be a kind of fine tuning exercise for the software system since the system has already met the requirements of the users as it is driven by the use cases. 

- At the end, a final evaluation is done and accordingly the project is released to the public or is considered for another development cycle. 

Overview of The Concurrent Development Model

The concurrent development model, sometimes called concurrent engineering The concurrent process model can be represented schematically as a series of major technical activities, tasks, and their associated states.
It makes use of state charts to represents the concurrentrelationship among tasks associated within a framework of activities. It isrepresented schematically by a series of major technical tasks, and associated states. The user's need, management decisions and review results drive theover-all progression of the development.

The concurrent model is often more appropriate for system engineering projects where different engineering teams are involved. The concurrent process model defines a series of events that will trigger transitions from state to state for each of software engineering activities, actions or tasks. This generates the event analysis model correction which will trigger the analysis action from done state to awaiting changes state.

The concurrent process model is applicable to all types of software development and provides an accurate picture of the current state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it defines a network of activities. Each activity on the network exists simultaneously with other activities, actions or tasks. Events generated at one point in the process network trigger transitions among the states.

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

Flow Oriented Modeling - Creating a Data Flow Model

Flow models focus on the flow of data objects as they are transformed by processing functions. Derived from structured analysis,flow models use the data flow diagram, a modeling notation that depicts how input is transformed into output as data objects move through the system. Each software function that transforms data is described by a process specification or narrative. In addition to data flow, this modeling element also depicts control flow.

Data flow oriented modeling is the most widely used analysis notation. Flow oriented modeling focuses on structured analysis and design, follows a top to down methodology and uses a graphical technique depicting information flows and the transformations that are applied as data moves from input to output.

The modeling tools that are used to build a data flow oriented model include context diagrams, data flow diagrams, entity relationship diagram, control flow diagram, state transition diagram, data dictionary, process specification and control specification.

Steps to create a data flow model
- Diagram 0: develop a context diagram.
- Decompose the Process into high level processes.
- In parallel to this, develop data flow diagrams, entity relationship diagrams and state transition diagrams.
- Define data stores which includes normalization.
- Develop data dictionary.
- Finalize data flow diagrams, entity relationship diagram and state transition diagrams.
- Develop process specifications which includes PDL, decision tables or trees.
- Perform transformational analysis which includes developing structure charts.
Information flow continuity must be maintained as each data flow diagram level is refined. This means that input and output at one level must be the same as input and output at a refined level.