What is Throughput, Turnaround time, waiting time and Response time?

In this article we discuss about four important terms that we often come across while dealing with processes. These 4 factors are:

1.  Throughput

2.  Turnaround Time

3. Waiting Time

4.  Response time

What is Throughput?

- In communications networks like packet radio, Ethernet etc., throughput refers to the rate of the successful delivery of data over the channel. 

- The data might be delivered via either logical link or physical link depending on the type of communication that is being used. 

- This throughput is measured in the terms of bps or bits per second or data packets per slot. 

- Another term common in networks performance is the aggregate throughput or the system throughput. 

- This equals to the sum of all the data rates at which the data is delivered to each and every terminal in a network. 

- In computer systems, throughput means the rate of successful completion of the tasks by the CPU in a specific period of time. 

- Queuing theory is used for the mathematical analyzation of the throughout. 

- There is always a synonymy between the digital bandwidth consumption and the throughput. 

- Another related term is the maximum throughput.This bears synonymy with the digital bandwidth capacity.

What is Turnaround Time?

- In computer systems, the total time taken by the CPU from submission of a task or thread for execution to its completion is referred to as the turnaround time. 

- The turnaround time varies depending on the programming language used and the developer of the software.

- It deals with the whole amount of time taken for delivering the desired output to the end user following the start of the task completion process. 

- This is counted among the metrics that are used for the evaluation of the scheduling algorithms used by the operating systems. 

- When it comes to the batch systems, the turnaround time is more because of the time taken in the formation of the batches, executing and returning the output.

What is Waiting Time?

 

- This is the time duration between the requesting of an action and when it occurs. 

- Waiting time depends up on the speed and make of the CPU and the architecture that it uses. 

- If the processor supports pipeline architecture, then the process is said to be waiting in the pipe. 

- When the current task in processor is completed, the waiting task is passed on to the CPU for execution. 

- When the CPU starts executing this task, the waiting period is said to be over. 

- The status of the task that is waiting is set to ‘waiting’. From waiting status, it changes to active and then halts.

What is Response Time?

 

- The time taken by the computer system or the functional unit for reacting or responding to the input supplied is called the response time. 

- In data processing, there are various situations for which the user would perceive the response time:

Ø  Time between operator entering a request at a terminal  and

Ø  The instant at which appears the first character of the response.

- Coming to the data systems, the response time can be defined as the time taken from the receipt of EOT (end of transmission) of a message inquiry and start of the transmission in response to that inquiry. 

- Response is an important concept in the real time systems and it is the time that elapses between the dispatch of the request until its completion. 

- However, one should not confuse response time with the WCET.

- It is the maximum time taken by the execution of the task without any interference. 

- Response time also differs from the deadline. 

- Deadline is the time for which the output is valid. 

What are the different attributes of the use cases?

Use cases sound similar to test cases. But the two are not same. Where the test cases are used in software testing, the use cases are used in the general software systems engineering. We have dedicated this whole article to the discussion of the use cases.

What are Use Cases?

- The use case is a set of steps which are implemented to define the interactions occurring between the software system and a role.

- This is basically done to achieve a predefined goal. The role is commonly called as an actor and can be an external software system or simply a human.

- The use cases are often used at the higher levels of the software systems engineering.

- The goals to achieve for which the use cases are developed are often defined by the stake holders.

- The requirements are stated by the stake holders in a separate documentation.

- This documentation serves at a contract between the two i.e., between the software developers or programmers and the stake holders or the clients.

- The structure of a use case has been a quite debated topic. Many opinions were given regarding the how the structure of a typical use case should be.

- But usually the structure defined by the Alistair Cockburn is followed. It is popularly known as the “fully dressed use case structure”.
It consists of the following aspects:

1. Title of the use case
2. Primary role
3. Goal of the use case
4. Scope
5. Level
6. Interests
7. Stake holders
8. Preconditions or requirements
9. Guarantees (both minimal and success)
10.Success scenario
11. Technology
12. Data variations
13. Extensions and
14. Related information

He gave some other many useful aspects related to the use cases like:

1. Casual use case structure
2. Design scope icon
3. Goal level icon

ROLE OF AN ACTOR

- The role of an actor in a use case is to make effective decisions and so calls for the need of good decision making ability.

- It is not necessary that an actor should always be a human. It can be a computer system also.

- Though the decisions of an actor influences the whole use case implementation, there does not exist any direct link between the system and the actor.

ATTRIBUTES OF USE CASES

- Certain necessary attributes have been discovered so far that are needed by the use case to accomplish the goal for which it has been developed.

- The attributes need not be only functions; they can be in the form of data variables also.

- Not all the attributes have been extracted from the preceding steps; some have been taken as the general assumptions out of common knowledge of the use cases.

1. System requirements: These requirements form the basis for thedelopmnt of a use case.
2. The requirements need to be complete and correct and of quality.
3. Software requirements specification testing
4. User- centred approach for the specification of the requirements.
5. Unified modelling language: this language based on the object oriented paradigm is employed for the construction, visualization and documentation of the system.
6. Use case diagrams

The below mentioned are the three attributes of the use cases:

1. Level of validity
This attribute is concerned with the validation of the use cases. It queries about the completeness of the use case, achievement of the goals, changes to be made, addressing of the additional goals and representation of the additional actors and so on.

2. Metrics
This use case attribute deals with the factors like the ambiguity, completeness, trace-ability and volatility of the use case.

3. Risk indicators
Typical 3 risk indicators have been identified namely incompleteness, options and weak phrases.

What is Earned Value Analysis (EVA) in Project Scheduling?

Earned Value Analysis(EVA) provides a quantitative indication of progress. The project manager uses this method to track the project. Proponents of the earned value system claim that it works for every software project irrespective of the kind of work. As a part of this, there is an initial estimation of the total number of hours of doing this project, with every task being given an earned value which is based on its estimated percentage of the total effort. In simpler terms, a project manager will be able to determine, through a quantitative analysis, how much of the project is actually complete.

As a part of this process, the following steps are needed to be done:
- The BCWS (Budgeted Cost of Work Schedule) is evaluated for each task that is included in the project. This estimation is done in terms of person-hours or person-days(if the effort is much more than a few hours). So, for a given work task its BCWS is the effort.
- All the BCWS that are calculated for all the tasks are summed up to get a value called BAC(Budgeted Completion).
- The next variable BCWP(Budgeted Cost of Work Performed) is calculated. The method to calculate BCWP is by taking BCWS value for all the tasks that have been completed(at any point in the schedule).

In simple terms, the difference between BCWS and the BCWP is that BCWS is the estimate for all task that was supposed to be done, while BCWP is the summary of all the activities that were completed.

EVA compares the planned amount of work with what has actually been completed, to determine if cost, schedule, and work accomplished are progressing as planned. Work is earned or credited as it is completed.

Earned Value Analysis
- compares like terms and is quick to apply in practice.
- requires the ongoing measurement of the actual work done.
- tasks that have not been started or that have been completed are relatively easy to quantify in terms of earned value.

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.