Software Project Management Plan

Software Project Management Plan

For

‘Telemetry Display and Archival on Linux Platform’

Prepared by: Vikram Prasanakumar

Jung Pyo Hong Sahil Kumar

Table of Content

Table of Content..................................................................................................1

1.0 Project Overview.........................................................................................3

1.1 Project Summary.....................................................................................3

1.1.1 Purpose, Scope, and Objectives .....................................................3

1.1.2 Constraints ........................................................................................3

1.1.3 Project Deliverables..........................................................................4

1.1.4 Schedule and Budget Summary ......................................................4

1.2 Evolution of the SPMP ............................................................................6

2.0 References...................................................................................................6

3.0 Definitions & Abbreviations .......................................................................6

4.0 Project Organization ...................................................................................8

4.1 External Interfaces ..................................................................................8

4.2 Internal Structure ...................................................................................9

4.3 Roles and Responsibilities...................................................................10

5.0 Managerial process plans ........................................................................10

5.1 Project start-up plan .............................................................................10

5.1.1 Estimation plan ...............................................................................10

5.1.2 Staffing plan ....................................................................................11

5.1.3 Resource acquisition plan ............................................................12

5.1.4 Project staff training plan..............................................................12

5.2 Work plan ...............................................................................................12

5.2.1 Work Activities ................................................................................12

5.2.2 Schedule Allocation........................................................................12

5.2.3 Resource Allocation .......................................................................12

5.2.4 Budget Allocation ...........................................................................13

5.3 Control Plan ...........................................................................................13

5.3.1 Requirements Control Plan............................................................13

5.3.2 Schedule Control Plan....................................................................14

1

5.3.3 Budget Control Plan .......................................................................14

5.3.4 Quality Control Plan .......................................................................14

5.3.5 Reporting Plan ................................................................................15

5.3.6 Metrics Collection Plan ..................................................................16

5.4 Risk Management Plan .........................................................................17

5.4.1 Risk Identification ...........................................................................17

5.4.2 Risk Analysis...................................................................................18

5.4.3 Risk Planning ..................................................................................18

5.5 Project Closeout Plan ...........................................................................18

6.0 Technical Process plans ..........................................................................19

6.1 Process model.......................................................................................19

6.2 Methods, Tools & Techniques..............................................................19

6.2.1 S/W Development Processes, Techniques & Methodologies .....19

6.2.2 Design Strategies............................................................................23

6.2.3 Brief Description Of The Design Phase Of Our Project ...............24

6.2.4 High Level Design...........................................................................25

6.2.5 Low Level Designs..........................................................................25

6.2.6 Products ..........................................................................................27

6.3 Infrastructure plan.................................................................................27

6.4 Product acceptance plan ......................................................................27

7.0 Coding and Unit testing............................................................................27

7.1 Testing....................................................................................................27

7.2 Testing The Software ............................................................................27

7.3 Types Of Testing ...................................................................................28

7.4 Hardware and Software Requirements................................................31

2

1.0 Project Overview 1.1 Project Summary 1.1.1 Purpose, Scope, and Objectives Our project evaluates the process of Altitude and Orbit Control Electronics package. It involves communication between satellite and earth stations through the Telemetry subsystem in the satellite. Status of the spacecraft is available in the telemetry buffer. Thus we will need to retrieve the status from the ground station and issue the necessary control steps by performing a series of telecommands. The existing technology uses RPC and Digital Unix for the Front End Processors and hosts leading to certain limitations such as high maintenance and high cost. The use of RPC delays transmission and slows down the processing system. Therefore, the key objectives of our project are:

• Acquiring TM data at specified rate.

• Converting the hosts’ operating system from Digital unix to Linux.

• Using sockets instead of RPC.

• Making the processing units scalable.

• Display of acquired data in the format required by the user.

1.1.2 Constraints

• Project to be completed within a budget of $190,000

• Project to be completed within 4 months

• For the purpose of experimentation we will have to simulate satellite’s

telemetry hardware.

3

1.1.3 Project Deliverables

Deliverable Item Per Person Responsible Date Due

Telemetry Display and Archival on Linux Platform SPMP

Stage Project Manager At Proposal, Update as Required

TDALP Development Folder includes:

• Requirements Data • Design Data • Source Code • Test Cases

Baseline Software Engineering Group

N/A

Telemetry Display and Archival on Linux Platform Software

Release Senior Scientist 15th August ‘05

User’s Manual Version Software Engineer 15th August ‘05

System’s Manual Version Software Engineer 15th August ‘05

1.1.4 Schedule and Budget Summary

Resource Requirement Resource

Name Initials Position Std. Rate Cost/Rate

Vikram Kumar VK President $.00/hr $10,000.00

J.P. Hong JP Project Manager $40.00/hr $0.00

Sahil Kumar SK CFO $35.00/hr $0.00

Anshul Goel AG Technical Manager $25.00/hr $0.00

Shauvik Gayen SG Testing

Manager $25.00/hr $0.00

Anita Anand AA System Design

Engineer $25.00/hr $0.00

4

Vijay Paul VP Module Developer $25.00/hr $0.00

Rita Verma RV Module Developer $25.00/hr $0.00

Dinesh Mahant DM GUI

Developer $25.00/hr $0.00

Kunal Singh KS System Tester $25.00/hr $0.00

Nikhil Sandhu NS Unit Tester $25.00/hr $0.00

Budget Allocation

Entry Entry Cost No. of Units No. of Months Total Cost

Office Space $2,000.00 1 4 $8,000.00

Workstation $6,000.00 10 1 $60,000.00

Utilities $1,000.00 1 4 $4,000.00

Equipment $20,000.00 1 1 $20,000.00

Internet Access $200.00 1 4 $800,00.00

Legal Fees $1,000.00 1 4 $4,000.00

Employee Benefits $2,00.00 14 4 $14,000.00

Other $9,000.00 1 4 $27,000.00

Total Cost $137,800.00

5

1.2 Evolution of the SPMP

This is the first release of the SPMP. This SPMP will be updated as per the modification process.

2.0 References Author/Title Publisher/Year Purpose/Description W. Richard Stevens/Unix Networking Programming

Prentice Hall, 1997 Design and programming reference book

Roger S. Pressman/Software Engineering

McGraw-Hill College, 1996 Design reference book

AOCS Test System Software Design Document

Ref. 15-2002

AOCS Test System Document Ref. 99-2002

3.0 Definitions & Abbreviations

Definitions: AOCS – Attitude and Orbital Control System for checking that a spacecraft is placed in its precise orbital and attitude position and maintains, thereafter the required attitude throughout the mission life. AOCE – Is the heart Attitude and Orbital Control System. It provides an interface with attitude measuring sensors and commands them to operate in a controlled manner to maintain the desired attitude. TELEMETRY – Is the system by which measurements are made at a distance and transmitted to the observer. FRAME – A group of 128 bytes, which are organized in a fixed format. FEP – Is a server, which performs data acquisition & provides the necessary interface to the system under test.

6

Abbreviations: AOCS - Attitude and Orbit Control System. AOCE - Attitude and Orbit Control Electronics. TM - Telemetry ISRO – Indian Space Research Organization FEP - Front End Processor VSSC - Vikram Sarabhai Space Centre, Trivandrum, engaged in design and development of satellite launch vehicles. SHAR - Sriharikota, which is operational base of ISRO, fully equipped with sophisticated launching pad facilities. ISAC - ISRO Satellite Centre, Bangalore, engaged in design and development of satellite for multiple uses such as communication, weather forecasting, remote sensing etc. SAC - Space Application Centre, Ahmedabad engaged with activities in telecommunications and development of payloads for spacecraft. LPSC - Liquid Propulsion System Centre, Mahendragiri, engaged in launch vehicle propulsion system engine testing. ISTRAC - ISRO Telemetry Tracking and Command Network, Bangalore, provides ground support for the launch vehicle and satellite mission of ISRO. NRSA - National Remote Sensing Agency, Hyderabad, engaged in developing and utilizing modern remote sensing technique. MCF - Master Control Facility, Hassan, engaged in monitoring and control of INSAT series of spacecraft from different ground stations.

7

4.0 Project Organization 4.1 External Interfaces

ISRO

DOS

ISAC

CSG

CSHFD

Organization Hierarchy

8

4.2 Internal Structure

. Vikram Kumar President

J.P. Project Manager

Sahil Kumar Mr. Anshul Goel Paul CFO Technical Manager Testing Manager

Anita Anand Robert System Design

Engineer Module (FEP)

developer Mary . Dinesh Mahant . Rita Verma Alex

GUI developer Module developer System Tester Unit Tester

Project Organization

9

4.3 Roles and Responsibilities Vikram kumar– President • Funding

• Marketing • Non-software risk • Management

J.P – Project Manager • S/W development planning • S/W schedules • S/W cost estimation • Configuration management

Sahil kumar – CFO • Budget allocation • Financial risks • Project cost estimation

Anshul Goel – Technical S/W Manager

• Technology decisions • Domain research • System development scheduling • S/W risk assessment

Anita Anand – System Design Engineer

• Developing the S/W design • Integrating all developed modules

Paul– Testing Manager • Testing schedule • Quality assurance • Testing cost estimation • Acquiring testing resource • Satellite environment research • Telemetry h/w research

5.0 Managerial process plans 5.1 Project start-up plan 5.1.1 Estimation plan Microsoft Project and Cost Xpert were the primary tools used in estimating cost scheduling for this project.

Parameter MS Project Cost Xpert Cost $97,595.71 $133,032.54 Duration 6.9 mo 4 mo

10

5.1.2 Staffing plan The management of this organization feels that it has the sufficient manpower to carry out this project. No new hires or outsourcing is required. The following Table shows the number of personnel needed for each position.

Function/Task Number Comment

President 1 Responsible for funding, marketing, non-software risk management, management, staffing

Project Manager 1

Leads S/W development by providing S/W project plan, S/W schedule, S/W cost estimation, and manages configurations

CFO 1 Responsible for Budget allocation, financial risks, project cost estimation

Technical S/W Manager 1 Provide S/W risk assessment, system development scheduling, domain research, technology decisions

System Design Engineer 1 Designs overall S/W and integrates all developed modules

Testing Manager 1

Primary responsibilities are quality assurance, test cost estimation, acquiring test resources, research of satellite environment, telemetry H/W research, and establishing test schedules

Software Engineer 5 Responsibilities are Development of modules/ GUIs and system/unit testing

The following table shows the skill type required for each phase of the project.

Tasks Required Skill Type

Gather Requirements President, PM, CFO, Technical Manager, System Design Engineer, Module Developer

Analysis President, PM, CFO, Technical Manager, System Design Engineer, Module Developer

Design PM, CFO, Technical Manager, System Design Engineer, Module Developer

Develop PM, Technical Manager, System Design Engineer, Module Developer

11

Test PM, Testing Manager, Module Developer

Manage Release & Change President, PM, CFO, Technical Manager, Test Manager, System Design Engineer, Module Developer

Implement President, PM, CFO, Technical Manager 5.1.3 Resource acquisition plan Resources are acquired from ISRO. 5.1.4 Project staff training plan The following Table outlines the trainings that will be provided to staff members.

Training Number of participants Method Exit Criteria

Domain Training 11 Lecture Passing score on oral and written test

GUI development tool(Qt) Training 3 Lecture

Passing score on computer-based evaluation

5.2 Work plan 5.2.1 Work Activities Refer to Appendix A / CD included in this Plan

5.2.2 Schedule Allocation Refer to Appendix A / CD included in this Plan 5.2.3 Resource Allocation Refer Appendix B / CD included in this Plan

12

5.2.4 Budget Allocation Refer Appendix C / CD included in this Plan 5.3 Control Plan

5.3.1 Requirements Control Plan

5.3.1.1 Overview This plan documents the Requirements Management processes and procedures to be used by ISRO in the planning development and implementation of the ‘Telemetry System on Archival on Linux Platform’ project. This Plan defines how requirements will be recorded; how requirements will be modified; and how requirements will be reconciled for final completion of the product.

5.3.1.2 Objectives Describe the process and procedures used in the management process. Identify the tools to be used.

5.3.1.4 Processes and Procedures

Identification of Requirements The Project Manager will confer with the members of the department to identify the structure of the project, the desired functionality of the project, and any performance issues. The Project Manager will present the requirements to the Board of Directors for feasibility evaluation. The Project Manager will meet with the members of organization to review the Board's findings and negotiate any changes to requirements as a result of the Board's findings. The Project Manager will obtain the organizations’ members’ approval for the requirements to be implemented.

Recording Requirements

The Project Manager will keep track/record of the requirements approved by the organization members. The Project Manager will number and enter each requirement into a requirements tracking matrix and will keep a project requirements file containing documentation of approved requirements, and approved modifications to requirements.

13

Modification of Requirements

Instituted by the Members of the Department The Project Manager will receive direction from the members of the department to modify a requirement outlined on the properly completed Product Change Request From. The Project Manager will present the request to the Board of Directors for feasibility analysis and project impact. Project Manager will inform the members of project impact for approval before modifications are implemented. The Project Manager will also incorporate the approved requirement modification into the requirements tracking matrix, and add the modification request to the Requirements Project File. The project team will then implement the approved modification.

Instituted by Project Team Requirement modification requests must be presented to the Board of Directors for analysis on the properly completed Product Change Request Form. Once the Board completes the analysis of the modification request, the Project Manager will present request to the organization members for approval. If the organization members approve the modification, the Project Manager will incorporate the modification into the requirements tracking matrix and a record of the modification approval will be added to the Requirements Project File. The project team will then implement the modification.

5.3.1.5 Requirements Management Tools Requirements Tracking Matrix - Microsoft Excel Requirements Project File - Paper files (Product Change Request Forms) 5.3.2 Schedule Control Plan Refer to Appendix A / CD included in this plan 5.3.3 Budget Control Plan Refer to Appendix C / CD in this plan

5.3.4 Quality Control Plan Quality control is an integral part of the project in order to assure that the project satisfies the needs for which it was undertaken. Both the product of the project and the management of the project are addressed. The Work Plan of the project describes milestones and the acceptance criteria for each phase of the project. Assessing adherence to these baseline conditions provides the method for evaluating both the project and its product.

14

In addition, the project activities will be reviewed through at least two mechanisms:

• Internal validation –It will occur through peer reviews and quality management reviews. The quality management team would review a project for adherence to its plan and reporting requirements. Senior programmers would be asked to review junior programmers’ code.

• External validation – Organization’s satisfaction is an important indicator of the quality of the product. Department members are involved throughout the life of the project in establishing requirements and testing, accepting deliverables, and accepting products of the project. Their responses provide additional data for evaluating management of the project and how successfully the project achieves its purpose.

Reviews to validate acceptance and organization’s satisfaction for each milestone and for the acceptance criteria will be carried out quarterly or more frequently if required.

5.3.5 Reporting Plan The Reporting Plan establishes standards for the frequency of reporting and the recipients of reports. By following the standards set forth in the plan, subjective decisions about reporting are eliminated, and any events causing delay in the project will be reported up the ranks of ISRO. Reporting and Information Flow Matrix The Reporting and Information Flow Matrix below explains the standard schedule for reporting and meetings.

Action Weekly Monthly

Status Meetings • Project Team Meeting

• Project Manager & Department Director

Project Manager & Board of Directors

Reports • Completed Tasks

• Details on Schedules Tasks for Next Week

Summary of Standard Reports

15

5.3.6 Metrics Collection Plan Metrics will be collected according to the project plan, staffing plan and work plan. Metrics will be based on deliverables and baseline timeframes. Time, costs and expenditures will be tracked against these milestones to provide a detailed view of where the project is in relation to the estimated work, actual work completed. Reporting will be done against baselines to reveal the actual tasks accomplished. Project Metrics

Metric Description Tracking toolSchedule Milestones MS Project

Staff Usage Graph of person hrs used per month Both projected and actual MS Excel

Expenditures Graph of total expenditures over time Both projected and actual MS Excel

Requirements & analysis metrics

Metric Description Tracking tool

Number of Requirements

Graph of number of requirements Identified per module over time MS Excel

Number of Requirements defects

Graph of number of defects identified per module over time MS Excel

Architectural Design Metrics

Metric Description Tracking Tool Number of objects Graph number of objects identified

Over time MS Excel

Detailed Design metrics

Metric Description Tracking Tool

Number of objects Graph number of objects identified Over time MS Excel

16

Implementation metric Metric Description Tracking tool

Coding Progress Number of objects coded MS Excel Code size Lines of code measured daily MS Excel

Test progress Unit test cases passed over time MS Excel Defect Tracking Number of code defects MS Excel

Integration Testing metrics Metric Description Tracking tool

Test Progress Number of integration test Passed over time MS Excel

Defect Tracking Number of code defects identified Over time MS Excel

5.4 Risk Management Plan The purpose of the Risk Management Plan is to identify, analyse and rank risk Factors. Once factors have been identified then these will be analysed for impact and consequences and ranked accordingly plans will be put in place for contingencies and tracking and control measures will be put in place. Risk management is an ongoing task, as influencing conditions a rarely stagnant during the course of the project. 5.4.1 Risk Identification For the Telemetry System on Archival on Linux Platform Project we have identified the following areas of risk.

Identified Risks Risk Management Analysis

FEP memory overrun • test cases Increasing• Prototyping

Synchronization Issues • Simulation

Security Risk • Work done only at ISRO

Unsatisfactory GUI • Periodic review and prototyping

Cost Overruns • Cost estimation after each milestone

17

5.4.2 Risk Analysis The risks have been analyzed on a scale of three steps Low, Moderate and High. • FEP Memory Overrun – In case the memory of the buffer is not enough for

the amount of data that is being received, it would result in a memory over run of the Front End Processor. Due to its Severity is analyzed to be High.

To avert this, we can increase the number of test cases to come up with an adequate buffer size. Also, prototyping would prevent this defect.

• Synchronization Issues – If the sender and the receiver are not

synchronized, it could end up into retrieval of data loss. Thus its severity is evaluated to be High.

This fault can be avoided by proper simulation and reliable estimation.

• Security Risk – ISRO being a Government Research Organization works

secretly. Thus research done at ISRO can not be disclosed to anyone outside. Hence, the work that would be done on this project would strictly be at ISRO and no other place. The severity of this risk is also High.

• Unsatisfactory GUI – The satisfaction of the user-friendliness of the GUI is

an important requirement. There is a risk that the GUI would be substandard. Hence, the severity of this is Moderate.

Periodic reviewing and prototyping of the GUI is the only preventive measure.

• Cost Overruns – It is extremely important to complete the project in a timely

fashion and within the allotted budget. Cost overrun could be fatal for the project. Thus, its severity is High.

5.4.3 Risk Planning The loss of an important member of the project team is a fair amount of risk. Team members should be advised as to their decisive role in the project's success and should be committed to the success of the project. Keeping the objective clear in everyone mind will be priority. 5.5 Project Closeout Plan The ‘Telemetry System on Archival on Linux Platform’ project would require a project closeout process for finalisation before the ISRO can declare it to be

18

complete. This process provides a checklist of final deliverables, organization members’ approvals, project final financial report, and review of project quality measurements. The plan shall include a planned session for the project team to perform a Post Mortem review of the project and complete a Lessons Learned Document. These sessions would be carried out off site away form normal working disruptions. 6.0 Technical Process plans 6.1 Process model

6.2 Methods, Tools & Techniques 6.2.1 S/W Development Processes, Techniques & Methodologies 6.2.1.1 System Requirement Specification 6.2.1.1.1 Problem Defination The proposed Telemetry Acquisition system is based on the client-server model,

which use sockets as the medium of communication instead of RPC’s. Here the

server is responsible to serve multiple clients for processing data and interacts

with the acquisition module. The data acquisition module directly interacts with

the underlying hardware to acquire the data from the system under test. The

server acquires the data to serve the client’s requests. The multiple clients can

Feasibility study

Requirement Analysis

d fDesign and Specification

Coding & module testing

Integration & system Testing

Delivery & maintenance

19

request the data from the server and process the data in order to display it on the

user friendly GUI.

Due to the high risk involved, AOCE requires being highly reliable and should be

flawlessly working throughout its mission life. To perform this evaluation process

a highly sophisticated test system is required. The test system consists of

hardware and software on client server model. The acquisition of the data is

much faster than the time required completing it’s processing. If the acquisition

and processing is done simultaneously it may result in the loss of some important

data arriving from AOCS.

In order to avoid this loss the concept of client server model is being used so that

the server does the acquisition and the client does the processing. The server

here is known as the Front End Processor unit that performs the data acquisition

and interface simulation through various hardware links. The data acquired by

the FEP is requested by clients known as hosts and is processed at the client

side. As the data acquired by the FEP is bulky in nature processing by a single

client is not possible. Hence FEP supports multiple clients for processing. Along

with various functions of the client include commanding and display, graphical

user interface, data retrieving and automatic testing.

Requirements Inputs

The inputs to the system are to be taken from satellite in the form of frames. This

generation of data is simulated and is generated by the server, which sends the

data to the clients for processing. The inputs are to be taken at a particular time

rate that is specified by the user.

Outputs

The output of the system is displayed in different formats. It should work

according to user selection. The raw data that is acquired is also displayed. The

20

parameter name and the meaning of every word acquired is displayed which

makes the detection of errors simpler.

\

Requirement Analysis Process

REQUIREMENTS VALIDATION

PROCESS ENTRY

DOMAIN UNDERSTANDING

REQUIREMENTS COLLECTION

CLASSIFICATION

CONFLICT RESOLUTION

PRIORITIZATION

REQUIREMENTS & DEFINITION & SPECIFICATION

• Domain Understanding

Analysts should develop their understanding of the application domain.

• Requirements Collection

This is the process of interacting with stakeholders to discover their

requirements.

• Classification

This activity takes the unstructured collection of requirements and

organizes them into coherent structure.

• Conflict Resolution

21

This activity is concerned with finding & resolving the conflicts.

• Prioritization

This stage involves interaction with the stakeholders to find out the most

important requirements.

• Requirements Validation

The identified requirements are checked to discover if they are complete.

6.2.1.1.2 Products

Use Cases (UC)

UML diagrams

Software Requirements Specification (SRS)

Software Development Folder (SDF)

6.2.1.2 Architectural Design The architectural design phase will determine the overall architecture of the system and finalize the modules and their interfaces.

Hosts

PU

TM

AOCE

POWER SERVER

S/W

H/W PU

PU

FEP Satellite

INTERFACE

6.2.1.2.2 The Design Process The design process involves developing several models of the system at different

levels of abstraction. The stages of the design process are sequential and the

design activities are as follows.

22

•

•

•

•

•

•

•

The subsystems making up the system and their relationships are identified

and documented.

Abstract specification - For each subsystem an abstract specification of the

service it provides and the constraints under which it operates is produced.

Interface Design- The interface specification must be unambiguous as it

allows the subsystems to be used without the knowledge of the subsystem

operation.

Component design- Services allocated to different components and the

interfaces of these components are designed.

Data structure design - The data structures used in the system

implementation are designed in detail and specified.

Algorithm design - The algorithms used to provide services are designed in

detail and specified.

6.2.2 Design Strategies There are two important design strategies that can be summarized as follows

Functional design- The system is designed from a functional view point

starting with a high-level view and progressively refining this into a more

23

detailed design. The System State is centralized and shared between the

functions operating on that state.

• Object-oriented design - The system is viewed as collection of objects rather

than as functions. Object-oriented design is based on the idea of information

hiding.

In an object-oriented design the System State is decentralized and each object

manages its own state information. Objects have a set of attribute defining their

state and operations which act on these attributes.

There is no best design strategy, which is suitable for all projects and all type of application. The most appropriate approach is selected for each stage in the design process. 6.2.3 Brief Description Of The Design Phase Of Our Project

UML

24

6.2.4 High Level Design

6.2.5 Low Level Designs

Front End Processor

Raw TM datat the rate of128bytes/sec

Data ac uisition at the same Data from AOCE

Front End Processor

Raw data 128

a

Danfr

rate andestabliscommu

Establishe socket

Accepts connectrequests from clsocket()

q

ata processing d display on user

iendly GUI

Raw TM data

socket connection hment for nication

Hosts

s

ion ient –

Binds socket to port –

Listens to connections – listen()

Creates socket –

25

Front End Processor

Sends raw data Hosts

Refers files tm1map and piddata and processes the data

Writes into socket – write()

Reads from socket – read()

Requests for connection – connect()

Request for the establishment of socket connections

Dispalys on user friendly GUI in various formats

26

6.2.6 Products Use Cases (UC)

UML diagrams

Software Requirements Specification (SRS)

Software Development Folder (SDF)

6.3 Infrastructure plan All the equipment used in our project is maintained by ISRO satellite center.

6.4 Product acceptance plan Not required because the project is given by ISRO to us.

7.0 Coding and Unit testing The coding phase of the development will mostly consist of writing the actual

code and unit,task,system, Integration, Validation,UI testing at the object level.

7.1 Testing Testing is an important phase. It involves the testing of the system against the

requirement specification and successful running of the developed system. In

view of acceptance the user tests the developed system and changes are made

according to the needs. The testing phase involves testing of developed system

using various kinds of data.

An elaborate test data is prepared and the system is tested using the test data.

While testing, errors are noted and corrections are made. The correction is noted

for future use.

7.2 Testing The Software The objective of testing is as follows

• Testing is a process of executing a program with the intent of finding error.

• A good test case is one that has a high probability of finding errors which

is undiscovered.

27

• A successful test is one that tests all paths of execution and discovers

errors for possible inputs.

7.3 Types Of Testing • Unit testing

Unit testing focuses verification effort, on the smallest unit of software

design, the module. The relative complexity of tests and undiscovered

errors is limited by the constrained scope established for unit testing. The

module interface is tested to ensure that the information properly flows

into and out of the program unit under test. The local data structure is

examined to ensure that the data stored temporarily maintains its integrity

during all steps of execution. Boundary conditions are tested to ensure

that the module operates properly at boundaries established to limit or

restrict processing. All independent paths through the control structures

are exercised to ensure that all statements in the module have been

executed at least once. And finally all error-handling paths are tested.

• Task testing

Task testing is a type of testing for real time system. Each task which run

concurrently in the system are tested independently providing some test

data. Synchronization aspects are not considered. This test is performed

when all modules of the task are developed and tested. This is an

asynchronous form of testing.

• Integration testing

Data can be tested across an interface; one module can have an

inadvertent, adverse effect on the other. Sub functions, when combined

together, may not produce the desired result, individually accepted

impression may be magnified to unacceptable levels. Integration testing is

a systematic technique for constructing tests to uncover errors associated

28

with interfacing. The objective is to take unit tested modules and build a

program structure that has been dictated by design. Once all the

rectification pertaining to errors in individual tasks are completed, the

system is tested for synchronization, data exchange, signal mechanism

and other IPC functionality.

• Validation testing

After integration testing, software is completely assembled as a package.

Interfacing errors have been uncovered and corrected and the final series

of software tests, the validation tests begin. Validation succeeds when the

software functions in a manner can be reasonably expected. Steps taken

during software design and testing can greatly improve the probability of

successful integration in the larger system. System testing is to fully

exercise the computer based system. Although each test has a different

purpose all work to verify that all system elements have been properly

integrated and perform allocated functions.

• Security testing

It attempts to verify that protection mechanism built into a system will in

fact protect it from improper penetration. The system’s security must of

course be tested for invulnerability from formal attack.

• Performance testing

It is designed to test the run time performance of software within the

context of an integrated system. Performance testing occurs throughout all

steps in the testing process. Performance tests are often coupled with

stress testing and often require both hardware and software

instrumentation. That is, it is often necessary to measure resource

utilization in an exacting fashion. For real-time system performance is the

primary concern. The complexity of each module is calculated, thus a

29

mathematical figure depicting the execution is derived. Constant changes

in the techniques were done to optimize the system.

• Black box testing

Black box testing is also called the functional testing. Here all the

expected functionality of the system is tested. The focus remains on the

testing the output of the system for the given inputs, so the system for all

possible inputs it is giving the exact output or not. Black box testing is

done to find

o Incorrect or missing functions

o Interface error

o Performance error

o Termination error

The above testing is successfully carried out for application according to the

user requirement specification.

• Output testing

After performing the validation testing, the next step is output testing of the

proposed system, as no system would be termed useful if it does not

produce the requested output in the specific format. The user tests the

output generated by the system under consideration for the format

required by them.

• User acceptance testing

User acceptance of the system is the key factor for the success of any

system. The system under consideration is tested for user acceptance by

constantly keeping in touch with prospective system users at the time of

developing and making changes whenever required.

30

The project follows the following testing process sequence.

Unit i

Module i

Subsystem i

System testing

Acceptance i

7.4 Hardware and Software Requirements FEP - Hardware requirements

- Pentium 1.5 MHZ and above.

- 512 MB RAM and above.

- An Ethernet LAN between workstations.

- Developer Linux workstations( P3 750+,256MB RAM, 20GB hard drive )

Software requirements

- Project to be carried upon LINUX platform.

- GNU’s cc compiler.

31

32

Host - Hardware requirements

- Pentium machines 1.5 MHZ and above.

Software requirements

- Linux operating system.

Qt designer .

Appendix A Schedule – MS Project

33

34

35

Schedule – Cost Xpert

36

Appendix B Task Usage – MS Project

37

38

Appendix C Cost Estimation – Cost Xpert

39

Cost Estimation – MS Project

40