software project management plan
DESCRIPTION
TRANSCRIPT
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