Testing

5. Testing
-------------------------------------------------------------------------------

Software development is a complex and sizable team activity simulating several human capabilities. The importance of testing is therefore self- evident. As every single software development aims at different functional walks of life, the need for testing is further stressed.

There are various type of testing such as unit testing, integration testing, system tests, user acceptance tests and many more.

Such test and review are done by different people(analysts, designers, programmers, specialist testers and users, too) at various phase of the SDLC (like design, programming, implementation), using a variety of techniques (like black-box, white-box, etc.) and by deploying a range of procedures/ methods and automated tools.

Programming

4. Programming
-------------------------------------------------------------------------
Once the blue-print of the whole system is ready, the job of the programmer starts. A programmer would typically get all specifications from the designer in terms of the input, output, processing needs, etc and translate it in the programs. Programming is writing the logical processing steps in some computer language like C, Cobol, Java, etc.

Generally each program aims at one of the moderate sized tasks. For example, in a payroll system, there would be one program for getting the changes for the current month (like increments, new deductions, current DA percentage, etc.), another program for actual computations (like Provident Fund, gross & net pay) and yet another for printing the pay-sheet. This is just an illustration and in reality there may be several more programs.

A programmer has to adopt both a micro as well as macro approach. She focuses on the task on hand for a given program in a minute way while she has to look at the broader canvas, articulating a smooth handshake across multiple programs that together make up the complete application software.

It will be pertinent to mention here that programming is a separate branch in its own right - quantitatively there have been hundreds of programming languages and qualitatively there have been plethora of concepts like structured programming, modular approach, naming and scoping of variables, granularity of cohesion, coupling issues etc.

Design

3. Design
----------------------------------------------------------------------
Having understood the user requirements, the systems analyst has to chalk out a blueprint of the proposed system. This is a Herculean task where she has to keep track of inputs, outputs, data storage, processing steps, etc. so that all these components of the system work in harmony giving out the expected results.

The requirements grabbed in the earlier phase of SDLC are now to be mapped onto the computer realm. So the designers try to track back in a logical way from outputs towards inputs, trying to figure out the origin of each of the tidbits appearing in the output and related processing it has to undergo. Each fact/figure in the output has to be either input by the user or processed by the system based on some other user inputs. This processing may bank upon some reference data stored on computers. For example, in a payroll system, the pay slip for each employee is one of the outputs containing all pay details for that employee. Each of those pay details must have been either directly input or computed by the system.

All this presupposes a neat design of the system in terms of inputs, outputs, data storage, codification scheme and data processing.

Requirement Analysis

2. Requirement Analysis:
---------------------------------------------------------------------------

Now that the proposed system appears to be feasible, the next step is to understand neatly all the requirements of the would- be users of that software. Unless all these user requirements are appreciated fully, the developers can not design the software, let alone write the programs. The requirements collection is therefore a critical and foundational phase in the SDLC.

Typically, the person who interacts with the user to get their requirements is called a 'System Analyst'. He has to be a well-versed professional having multi-faculty skills in software development, analytical bend of mind, inter-personal communication skills and preferably working skills in functional walk/ subject matter to be computerized. The next two units provide an elaborate account on the topic and hence here we shall not delve into it.

These requirements are gathered in the form of umpteen tidbits like how many reports user expect, what are the layout & frequencies of such outputs, what inputs go into the system and what are their respective formats and sources, what are their respective formats and sources, what exactly takes place in the name of processing and what are all the intermediate recordings, calculations, authorizations, etc. that decide the path of work flow and fate of an individual transaction, what happens if it is an exceptional case, how much of human intervention is needed, and many such points.

If we get back to our earlier example of the carpenter, user requirements could be quite limited however, in a complex application like e-com portal, there may be hundreds of outputs that are worked out from several inputs coming from thousands of customers whose traction types might be running into dozens.

Concept Of Software Development Life Cycle (SDLC)

Concept Of Software Development Life Cycle (SDLC)
----------------------------------------------------------------------
Software Development Life Cycle (SDLC) is a set of several phases as under. Once the software phases through all these phases over a period of time, it becomes necessary to restart the software development afresh. That is why it is called a cycle.

1) Feasibility Study
In this curtain raiser phase, the developer tries to visualize all the subsequent phases and then tries to answer the question, "Is it feasible?" This crucial phase has a decisive bearing on the project initiation and hence the developer aims at a sort of skimming through all the future phases to figure out probable handicaps & hindrances. Unless there are promising solutions to these anticipated hiccups and the complete, smooth activity, no green signal is given to the project. This critical phase has many areas that are important:

a) Technical Feasibility
This ascertains whether the tasks to be delegated to the computer could be successfully articulated with software and whether the project is possible with the technology available currently in terms of hardware, communication links, software platforms/languages.

b) Economic Feasibility
This concentrates on the financial aspects of cost benefits and tries to ensure that the start-up cost and recurring expensive are justifiable. In many cases, the benefits are hard to quantify as they represent intangible gains like customer service, reduced time to market, etc. The importance of a nod or green signal from the finance angle hardly needs to be underlined.

c) Operational Feasibility
This looks into the probability of smooth working of the software when people put into the action. It is explored with the help of factors like ease software offers to those who operate it, fitting the work flow of steps to be taken by the man and the machine.

d) Social Feasibility
This examines the broader issues relating to the people at large who, though not directly operating the software, from the significant class of end user. They interface with the system in an indirect manner, yet are impacted by the inputs, outputs and the response time of the system.

SDLC

SDLC :
-----------------------------------------------------------------
The process used to create a software product from its initial conception to its public release is known software development life cycle (SDLC).

Software Development Life Cycle

Software Development Life Cycle (SDLC):

---------------------------------------------------------------------------

Introduction:

The software development embrace many features like problem solving, creativity, logical thinking, disciplined approach, team work, need for documentation, etc. All these make software development quite unique activity. During the development, the software passes through several phases such as feasibility study, requirement analysis, and design, coding and maintenance. Over developed, the software goes through two or more phases of implementation and maintenance. There are various models of SDLC like waterfall, evolving spiral, prototyping model etc. Whatever is the model, the two sides of User and Developers have some differing standpoints to view the software and these views have to be reconciled for successful software project. Feasibility Study is a precursor to the whole cycle and it is a miniature SDLC visualized by the developers to ensure the smooth implementation.

SDLC model to be used

6.5.3 SDLC model to be used
--------------------------------------------------------------------
Depending upon the scope of work relevant life cycle phases applicable to the project are identified.

Customer details

6.5.2 Customer details
-------------------------------------------------------------------
Contact details along with the communication channels to be used between the project team and the customer. The names, phone numbers, addresses, fax numbers and email addresses of the contact persons should be clearly mentioned in the Project plan.

Scope of the project

6.5.1 Scope of the project
---------------------------------------------------------------------
The scope of work that needs to be done in the project. The scope of work can be arrived at from the Requirements Specification Document.

Preparing the Project Plan

6.5 Preparing the Project Plan
-------------------------------------------------------------------------
The designated Project Manager will prepare the Project Plan (consisting of project plan / quality plan / configuration management plan) according to Project Plan Template in the initial stages of the project. The Project Manager may also involve QA representative in the preparation and review of Project plan, as appropriate.

Defining the project software process

6.4 Defining the project software process
---------------------------------------------------------------------------
The project software process is derived from organization standard set of processes. The project defined software process is documented through project plan. In case the Project Manager feels that tailoring/ customization is required for the SDLC/Processes for the project, the description of the tailoring shall be documented in the Project Plan and shall be informed to the Head of EPG. The revision of Project Planning is carried out according to the project monitoring and control process.

Project kick off meeting

6.3 Project kick off meeting
----------------------------------------------------------------------------
Organize and conduct a formal project kick off meeting to initiate the project. The participation of other project groups/ head of support functions like HR, QA, etc is optional and can be invited by invitation as the case may be. In the kick off meeting the project’s proposed commitments like technical goals/ objectives/ schedule/ resources/ processes, etc., are discussed.

• Roles and responsibilities with respect to project for every member attending the meeting should be clarified
• The commitments made to the individuals and groups external to the organization, if any, are discussed with Senior Management and recorded for addition to the Project plan. This will include the commitment received from the person managing the resource pool regarding the resource requirement based on the estimation.
• Critical dependencies between Project and the support groups are identified and discussed.

Study the input documents

6.2 Study the input documents

This study should result in understanding the overall scope of the project, risks involved, etc. that will help the project manager to plan for the project.

Tasks (Project Planning)

6. Tasks (Project Planning)
------------------------------------------------------------

6.1 Project Handover

On receipt of the project contract, a Project Initiation Note is issued and inputs containing, but not limited to the following, are handed over to the Project Manager (PM):

• Estimation sheets and the document listing the assumptions made during estimation
• Requirements Specification Document
• Proposal/contract/statement of work
• Risk register
• Feasibility study report
• Client communication
• Any other project related document(s)

On receipt of these documents the PM will baseline the same.

Roles and Responsibilities (Project Planning)

5. Roles and Responsibilities (Project Planning)
-------------------------------------------------------------------------------------

Roles	Responsibilities	Notes
Project Manager	Creating the plans and updating it as and when necessary
Functional Area Representatives	Providing the technical inputs to make the plans	SQA is also one of the FAR SQA role in a project is a must
Project Sponsor/ Systems Owner	Approving the plans

Inputs (Project Planning)

4. Inputs (Project Planning)
-------------------------------------------------------------------------

• Software Process Database,
• Inputs from the business development team
• Baselined Requirements Specification Document
• One or more of the following:

• System enhancement request

• Contract

• Scope of work

• Risk register

Project Entry Criteria (Project Planning)

3. Project Entry Criteria (Project Planning)
----------------------------------------------------------------------------
Project concept initiation note

Concept Note is prepared for Feasibility Study. In this all the basic logic is defined and what will be the impact of this project, does it full fill the requirement of the client or not.