Showing posts with label Software Engineering. Show all posts
Showing posts with label Software Engineering. Show all posts

Thursday, October 3, 2013

Method Stub

Stub :

Stubs are dummy modules which are known as "called programs" which is used in integration testing (top down approach), used when sub programs are under construction. A stub may simulate the behavior of existing code (such as a procedure on a remote machine) or be a temporary substitute for yet-to-be-developed code.
Example 1:
  
   BEGIN
       Temperature = ThermometerRead(Outside)
       IF Temperature > 40 THEN
            PRINT "It's HOT!"
       END IF
   END

BEGIN ThermometerRead(Source insideOrOutside)
        RETURN 28
   END ThermometerRead


Example 2: A drive program to calculate_income_taxfunction may consist line like
Cout << “income tax on 50000 is:”;
Cout << calculate_income_tax(5000)<<“\n”;

Example 3:
void function_under_test(int& x, int& y) {
  ...
  p = price(x);
  ...
}
double price(int x) {return 10.00;}
The value returned by function price is good enough for testing. The real price() function may not yet have been tested, or even written.


Driver:
Drivers are kind of dummy modules which are known as "calling programs", which is used in bottom up integration testing, used when main programs are under construction.
Example 1: to move a fighter on the game, the driver code would be 
moveFighter(Fighter, LocationX, LocationY);
This driver code would likely be called from the main method. A white-box test case would execute this driver line of code and check 
fighter.getPosition() to make sure the player is now on the expected cell on the board.

Example 2:           Edouble calculate_salary (double hours, double rate)
{      cout<< “salary is : ”;
                                   return (hours*rate);
                                 }
The main program can be tested using this code
Example 3:
#include <iostream.h>
void get_input(x& cost, int& y);
int main( )
{
    double a;
    int b;
    char ans;
    do
    {
        get_input(a, b);
        cout.setf(ios::fixed);
        cout.setf(ios::showpoint);
        cout.precision(2);
        cout << "a is " << a << endl;
        cout << "b is " << b << endl;
      
        cout << "Test again?"
             << " (Type y for yes or n for no): ";
        cin >> ans;
        cout << endl;
    } while (ans == 'y' || ans == 'Y');
    return 0;
}
Difference between stub and driver:

Stub
Driver

A piece of code that simulates the activity of missing component

A piece of code that passes test case to another piece of code

Stubs are created integration testing like Top-down approach 

Drivers are created integration testing like bottom-up approach

Stubs are simulations of the sub-code that otherwise is very gives full control to the test code

Driver takes care that the entry point of the application is masked by that of the test code and difficult to execute in the test code

A stub is a brief section of compliable code that serves as a class

A driver is a brief test program that demonstrates the functionality of a class or a portion of placeholder for future work

It is a temporary called program. It functions similarly like sub modules

It is a temporary Calling program. It functions similarly like main module for calling the sub when called by the main module

Stub is a simple routine that takes the place of the real routine Stubs let you check the interfaces and higher levels of the program

The driver approach is to write a program that passes input data to the unit under test and compares the output to the truth

Stub is a piece of special code that which is used to simulate the set up environment missing or not yet constructed

Driver is a code that which invokes the code to be tested

Stub is a skeleton of function having function header. This function can have actual statements or simple statements which can be      replaced with the actual code

Driver is a small program used to test a function

A driver creates necessary ‘Inputs’ required for      the Unit and then invokes the Unit

A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit
Stub
Driver

Stubs can be "filled in" to form the actual method

Drivers can become automated test cases

Example: In module A and module B, module A      ready and module B is not. For integration testing of module A, a dummy module is created which stimulate like module B. This dummy module is Stub.

Example: module B cannot send or receive data from module A automatically so, in such case we have to transfer data from one module to another module by some external features. This      external feature used is called Driver.




References:
  1. Pressman, Roger S., Software Engineering: A Practitioner's Approach (P 459-462), New Delhi, 2011
  2. http://www.qualitytesting.info/forum/topics/difference-between-stubs-and
  3. http://www.cs.gmu.edu/~mcjunkin/cs112lectures/Stubs.htm
  4. http://forums.sureshkumar.net/testing-interview-technical-questions/13586-what-difference-between-stub-driver.html
  5. https://en.wikipedia.org/wiki/Method_stub

Software Q&T


Software Quality:

There are many different definitions of quality. For some it is the "capability of a software product to conform to requirements." (ISO 9001) while for others it can be synonymous with "customer value" (Highsmith, 2002)

Kitchenham, Pfleeger, and Garvin's 5 perspectives on quality:
Transcendental Perspective:  quality is hard to define or describe in abstract terms, but can be recognized if it is present. It generally associated with some intangible properties, which make customer happy.

User Perspective, quality is fitness to meet user’s needs.

Manufacturing Perspective, quality means conformance to process standards.

Product Perspective, the focus is on inherent characteristics in the product itself hoping that controlling these internal quality indicators will result in improved external product behaviour (quality in use).

Value-based Perspective, quality is the customers’ willingness to pay for a software.

In Consortium for IT Software Quality (CISQ) Quality Model: Quality is related to reliability, Efficiency, Security, Maintainability and size.

Quality assurance refers to the processes and procedures that systematically monitor different aspects of a service, process or facility to detect, correct and ensure that quality standards are being met.

Quality engineering

  
Discipline that deals with the analysis of a manufacturing system at all stages, to improve the quality of the production process and of its output.


Quality in software engineering

In Musa and Everett (1990), these varying primary concerns were conveniently used to divide software engineering into four progressive stages:

·         In the functional stage, the focus was on providing the automated functions to replace what had been done manually before.
·         In the schedule stage, the focus was on introducing important features and new systems on a timely and orderly basis to satisfy urgent user needs.
·         3. In the cost stage, the focus was on reducing the price to stay competitive accompanied by the widespread use of personal computers.
·         4. In the reliability stage, the focus was managing users’ quality expectations under the increased dependency on software and high cost or severe damages associated with software failures.



Pr-industrialmindset that insists on building huge portions of software applications from scratch. This is inefficient, prone to error, and ultimately dangerous for the national infrastructure and for all those who rely on it. Standardizing software might just be a future we need to consider.




Inspection

·         Inspections are critical reading and analysis of software code or other software artefacts, such as designs, product specifications, test plans, etc.

·         Inspections are typically conducted by multiple human inspectors, through some, coordination process. Multiple inspection phases or sessions might be used.
·         Faults are detected directly in inspection by human inspectors, either during their individual inspections or various types of group sessions.

·         Identified faults need to be removed as a result of the inspection process, and their removal also needs to be verified.
·         The inspection processes vary, but typically include some planning and follow-up activities in addition to the core inspection activity.
·         The formality and structure of inspections may vary, from very informal reviews and walkthroughs, to fairly formal variations of Fagan inspection, to correctness inspections approaching the rigor and formality of formal methods.

Inspection is most commonly applied to code, but it could also be applied to requirement specifications, designs, test plans and test cases, user manuals, and other documents or software artifact.


Defect Containment

Because of the large size of most software systems, the defect reduction activities can only reduce the number of faults to a low level but eliminate them. So some other means need to be used to prevent failures by breaking the casual relations between these faults and the resulting failures, thus “tolerating” these faults, or "to contain” the failures by reducing the resulting damage.
This way of dealing with defects is called "defect containment".

Software Development Process



Common Process Framework

•          Framework activities - applicable to all software projects
–        Customer communication
–        Planning
–        Risk analysis
–        Engineering
–        Construction and release
–        Customer evaluation

•          Umbrella activities - applicable across entire software process
–        Project tracking and control
–        Technical review
–        Quality assurance
–        Risk management
–        Software configuration management
–        Measurements
–        Metrics collection


Purpose of Software Metrics:

–        Continuous improvement of a process
–        Estimation
–        Quality control
–        Productivity assessment


Software measurement is a quantified attribute of a characteristic of a software product or the software process. It is a discipline within software engineering. The content of software measurement is defined and governed by ISO Standard ISO 15939



Process metrics

•          Private process metrics
–        (e.g. defect rates by individual or module) are known only to the individual or team concerned.
•          Public process metrics
–        enable organizations to make strategic changes to improve the software process.
•          Metrics should not be used to evaluate the performance of individuals.
•          Statistical software process improvement helps an organization to discover its strengths and weaknesses.




–        the requirements description
–        the design of the solution
–        the code / program produced
–        the tests used to find errors



Project evaluation is an integral part of the planning process. At the stage of preparation of projects, it implies examining the relative profitability of a project via-à-vis other projects to enable planners in the choice of priority projects. Thus projects are appraised before they are actually put into operation. But project evaluation does not end here. The projects are also appraised during their execution in order to find out their operational success or otherwise. At the operational or the implementation stage, the objective of project evaluation is to suggest remedial measures and point out appropriate steps to improve upon its working.

Lastly exercise is repeated at the end of completion of a project. This post completion appraisal of projects is undertaken to find out whether all ends have been achieved in Toto or project is a partial success only. What are the lessons to be learn? How mistakes can be met and unexpected difficulties can be surmounted?

Present performance must act as an essential aid to future policy which may be immunized against the recurrence of similar mistakes. Projects evaluation is thus involved throughout various stages of formulation, implementation, completion and post completion analysis of projects. In the end of every project must ultimately be accepted or rejected on the basis of a subjective judgement about its worth.


   


 Program management: Individual project needs to be seen as components of a program and should be evaluated managed as such. 
     A program is a collection of projects that all contribute to the same overall organizational goals. Effective program management requires that there is a well-defined program goal and that all the organization’s projects are selected and tuned to contribute to this goal.
     A project must be evaluated according to how it contributes to this program goal and its viability, timing, resourcing and final worth can be affected by the program as a whole.
     In order to carry out a successful strategic assessment of a potential project there should therefore be a strategic plan clearly defining the organization’s objectives.
      Even where there is no explicitly defined program, any proposed project must be evaluated within the context of the organization’s overall business objectives. Moreover, any potential software project will form part of the user’s organization’s overall IS and must be evaluated within the context of the existing IS and the organization’s   IS strategy.


     Payback period is the time taken to break even or payback the initial investment. Normally, the project with the shortest payback period will be chosen on the basis that an organization will wish to minimize the time that a project is “in debt”.
     The advantage of the payback period is that it is simple to calculate and is not particularly sensitive to small forecasting error. Its disadvantage is that it ignores the overall profitability of the project– in fact it totally ignores any income (or expenditure) once the project has broken even.
4.

     The return on investment (ROI), also known as the accounting rate of return (ARR), provides a way of comparing the net profitability to the investment required. A straightforward calculating ROI is:
     ROI= (average annual profit/total investment/total investment)X100
   Ex.  Calculate the ROI for different projects using data given in the last table.
     The return on investment provides, a simple, easy to calculate measure of return on capital and is therefore quite popular.
      Disadvantages:
Ø        It takes no account of timing of the cash flows.
Ø        It is tempting to compare the rate of return with current interest rate. 
        


Cash flow forecasting

     A cash flow forecast will indicate when expenditure and income will take place.
     Accurate cash flow forecasting is not easy, as it is generally needs to be done early in the project’s life cycle (at least before any significant expenditure committed) and many items to be estimated (particularly the benefits of using software or decommissioning costs) might be some years in the future.   
     When estimating future cash flow, it is usual to ignore the effect of inflation increases the uncertainty of the forecasts. Moreover, if expenditure is increased due to inflation it is likely that income will increase proportionately.



Technical assessment

     Technical assessment of a proposed system consists of evaluating the required functionality against hardware and software available. Where an organization has a strategic IS Plan, this is likely to place limitations on the nature of the solutions that might be considered. The constraints will, of course, influence the cost of the solution and this must be taken into account in the cost-benefit analysis.