Your SlideShare is downloading. ×
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Software Project Management Plan
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Software Project Management Plan

1,561

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,561
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
121
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Project Management Plan For ‘Telemetry Display and Archival on Linux Platform’ Prepared by: Vikram Prasanakumar Jung Pyo Hong Sahil Kumar
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 1.1.3 Project Deliverables Person Deliverable Item Per Date Due Responsible Telemetry Display and At Proposal, Archival on Linux Platform Stage Project Manager Update as SPMP Required TDALP Development Folder includes: Software • Requirements Data Baseline Engineering N/A • Design Data Group • Source Code • Test Cases Telemetry Display and Archival on Linux Platform Release Senior Scientist 15th August ‘05 Software Software User’s Manual Version 15th August ‘05 Engineer Software System’s Manual Version 15th August ‘05 Engineer 1.1.4 Schedule and Budget Summary Resource Requirement Resource Initials Position Std. Rate Cost/Rate Name Vikram VK President $.00/hr $10,000.00 Kumar Project J.P. Hong JP $40.00/hr $0.00 Manager Sahil Kumar SK CFO $35.00/hr $0.00 Technical Anshul Goel AG $25.00/hr $0.00 Manager Shauvik Testing SG $25.00/hr $0.00 Gayen Manager System Anita Anand AA Design $25.00/hr $0.00 Engineer 4
  • 6. Module Vijay Paul VP $25.00/hr $0.00 Developer Module Rita Verma RV $25.00/hr $0.00 Developer Dinesh GUI DM $25.00/hr $0.00 Mahant Developer System Kunal Singh KS $25.00/hr $0.00 Tester Nikhil Sandhu NS Unit Tester $25.00/hr $0.00 Budget Allocation No. of Entry Entry Cost No. of Units Total Cost Months 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 $200.00 1 4 $800,00.00 Access Legal Fees $1,000.00 1 4 $4,000.00 Employee $2,00.00 14 4 $14,000.00 Benefits Other $9,000.00 1 4 $27,000.00 Total Cost $137,800.00 5
  • 7. 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 Design and programming Prentice Hall, 1997 Networking reference book Programming Roger S. McGraw-Hill College, Pressman/Software Design reference book 1996 Engineering AOCS Test System Software Design Ref. 15-2002 Document AOCS Test System Ref. 99-2002 Document 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
  • 8. 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
  • 9. 4.0 Project Organization 4.1 External Interfaces ISRO DOS ISAC CSG CSHFD Organization Hierarchy 8
  • 10. 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 . Dinesh Mahant Module (FEP) . Rita Verma Mary Alex Engineer GUI developer developer Module developer System Tester Unit Tester Project Organization 9
  • 11. 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 • Technology decisions Manager • Domain research • System development scheduling • S/W risk assessment Anita Anand – System Design • Developing the S/W design Engineer • 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
  • 12. 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 Responsible for funding, marketing, President 1 non-software risk management, management, staffing Leads S/W development by providing S/W project plan, S/W schedule, S/W Project Manager 1 cost estimation, and manages configurations Responsible for Budget allocation, CFO 1 financial risks, project cost estimation Provide S/W risk assessment, system Technical S/W Manager 1 development scheduling, domain research, technology decisions Designs overall S/W and integrates all System Design Engineer 1 developed modules Primary responsibilities are quality assurance, test cost estimation, acquiring test resources, research of Testing Manager 1 satellite environment, telemetry H/W research, and establishing test schedules Responsibilities are Development of Software Engineer 5 modules/ GUIs and system/unit testing The following table shows the skill type required for each phase of the project. Tasks Required Skill Type President, PM, CFO, Technical Manager, Gather Requirements System Design Engineer, Module Developer President, PM, CFO, Technical Manager, Analysis System Design Engineer, Module Developer PM, CFO, Technical Manager, System Design Design Engineer, Module Developer PM, Technical Manager, System Design Develop Engineer, Module Developer 11
  • 13. Test PM, Testing Manager, Module Developer President, PM, CFO, Technical Manager, Manage Release & Change 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. Number of Training Method Exit Criteria participants Passing score on oral Domain Training 11 Lecture and written test Passing score on GUI development 3 Lecture computer-based tool(Qt) Training 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
  • 14. 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
  • 15. 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
  • 16. 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 • Project Team Meeting Project Manager Status Meetings • Project Manager & & Department Director Board of Directors • Completed Tasks Summary of Reports • Details on Schedules Tasks Standard Reports for Next Week 15
  • 17. 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 tool Schedule Milestones MS Project Graph of person hrs used per month Staff Usage MS Excel Both projected and actual Graph of total expenditures over time Expenditures MS Excel Both projected and actual Requirements & analysis metrics Tracking Metric Description tool Number of Graph of number of requirements MS Excel Requirements Identified per module over time Number of Graph of number of defects identified per Requirements MS Excel module over time defects Architectural Design Metrics Metric Description Tracking Tool Number of objects Graph number of objects identified MS Excel Over time Detailed Design metrics Metric Description Tracking Tool Graph number of objects identified Number of objects MS Excel Over time 16
  • 18. 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 Number of integration test Test Progress MS Excel Passed over time Number of code defects identified Defect Tracking MS Excel Over time 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. Unsatisfactory GUI • Periodic review and prototyping Identified Risks Risk Management Analysis • Cost estimation after each Cost Overruns • milestone test cases Increasing FEP memory overrun • Prototyping Synchronization Issues • Simulation Security Risk • Work done only at ISRO 17
  • 19. 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
  • 20. 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 Feasibility study Requirement Analysis d f Design and Specification Coding & module testing Integration & system Testing Delivery & maintenance 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 19
  • 21. 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
  • 22. parameter name and the meaning of every word acquired is displayed which makes the detection of errors simpler. REQUIREMENTS & DEFINITION & REQUIREMENTS SPECIFICATION VALIDATION DOMAIN PRIORITIZATION PROCESS UNDERSTANDING ENTRY CONFLICT REQUIREMENTS RESOLUTION COLLECTION CLASSIFICATION Requirement Analysis Process • 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
  • 23. 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 FEP Satellite PU SERVER POWER PU S/W TM H/W PU AOCE 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
  • 24. • 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
  • 25. 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
  • 26. 6.2.4 High Level Design Front End Processor Raw TM data at the rate of Data acquisition at the same 128bytes/sec rate and socket connection Data from AOCE establishment for communication Raw TM data Data processing and display on user friendly GUI Hosts 6.2.5 Low Level Designs Creates socket – Raw data 128 Listens to Front End connections Processor Establishes – listen() socket Binds socket to port – Accepts connection requests from client – socket() 25
  • 27. Reads from socket – read() Requests for connection – Writes into socket connect() – write() Request for the establishment of socket connections Refers files tm1map and Sends piddata and processes the raw data Dispalys on Front End Hosts data user friendly Processor GUI in various formats 26
  • 28. 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
  • 29. • 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. Host - Hardware requirements - Pentium machines 1.5 MHZ and above. Software requirements - Linux operating system. Qt designer . 32
  • 34. Appendix A Schedule – MS Project 33
  • 35. 34
  • 36. 35
  • 37. Schedule – Cost Xpert 36
  • 38. Appendix B Task Usage – MS Project 37
  • 39. 38
  • 40. Appendix C Cost Estimation – Cost Xpert 39
  • 41. Cost Estimation – MS Project 40

×