SPMP

SOFTWARE ENGINEERING

LAB 11 (W13:5/Oct/)

Cover Case Study On

“Software Project Management Plan”

Automated Railway Reservation System

Page 59 – 87

Reference: [http://www.geocities.com/cs5391/]

DELIVERABLE FOR

PLANNING PHASE

OF SDLC

PROJECT MANAGEMENT - PROJECT PLANNING CHECKLIST

Project Scope

1. Are there clearly defined business goals and objectives? Y/N2. Are the goals and objectives in the scope section of the plan document? Y/N3. Have assumptions been included? Y/N4. Have constraints been identified? Y/N

Deliverables 1. Is there a list of all the deliverables for the project? Y/N

Completion Criteria1. Is the completion criteria clearly defined? Y/N

Acceptance Criteria1. Is the acceptance criteria clearly defined? Y/N

Project Schedule (WBS)1. Is there a clear WBS? Y/N2. Is the project schedule structured into overview and sub-phases? Y/N3. Are dependencies identified in the plan? Y/N4. Are external dependencies linked to activities in the plan? Y/N5. Are public & resource holidays identified in the schedule? Y/N6. Is there a Gantt chart? Y/N7. Has work effort been estimated? Y/N8. Has task duration been estimated? Y/N9. Has skill level of resources been taken into account? Y/N10. Have the estimates been supplied by or validated by the resource assigned to it? Y/N11. Has PM effort been included in the plan? Y/N12. Have all activities been decomposed to an individual effort estimate i.e. no more than 5

days effort per activity. Y/N13. Has the Cost Estimates (Budget) been calculated from the WBS? Y/N

Milestones & Dates1. Have key milestones & dates been identified in the plan? These are the key points at

which they project will be reviewed for performance? Y/N

Resources1. Resources Resource Requirements: are named resources assigned to activities,

appropriate to their skills?2. Y/N3. Is Resource Loading based on 5 days per week/ normal working hours? Y/N4. Have resource requirements, hardware/additional software costs been estimated? Y/N5. Has any necessary resource training been scheduled in to the project schedule? Y/N

6. Are resources available to the project 100%? Y/N

Project Organisation:1. Have Roles and responsibility been assigned? Y/N2. Have you produced an Organisational Chart for the project? Y/N

Plan Reviews:1. Has the Project Plan been reviewed internally? Y/N

Plan Updates:1. Have the necessary activities to update the Project Plan/ Budget at the end of each phase

been identified in the WBS? Y/N

Table of Contents

1. Introduction. 1.1 Project Overview. 1.2 Project Deliverables.

1.3 Evolution of the SPMP. 1.4 Reference Materials. 1.5 Definitions and Acronyms.

2. Project Organization. 2.1 Process Model. 2.2 Organizational Structure. 2.3 Organizational Interfaces. 2.4 Project Responsibilities.

3. Managerial Process. 3.1 Management Objectives and Priorities. 3.2 Assumptions, Dependencies, and Constraints. 3.3 Risk Management. 3.4 Monitoring and Controlling Mechanisms. 3.5 Staffing Approach.

4. Technical Process. 4.1 Methods, Tools, and Techniques. 4.2 Software Documentation.

4.2.1. Software Requirements Specification (SRS). 4.2.2. Software Design Description (SDD). 4.2.3. Software Test Plan. 4.2.4. User Documentation.

4.3 Project Support Functions. 5. Work Packages, Schedule, and Budget.

5.1 Work Packages and Schedule. 5.2 Dependencies. 5.3 Resource Requirements. 5.4 Budget and Resource Allocation.

6. Additional Components. 6.1 Index. 6.2 Appendices.    

1.     Introduction.

The Sir Syed University of Engineering and Technology currently consists of app 9000(Students, Faculty, Administrations) plans are being developed to provide them sufficient facility through. It is estimated that approximately 4000(students, Faculty , administration) and Visitors use the university website. Furthermore, the website use is expected to increase as the members of the university started to take the interest new dimensions in web application and new website contents are added. Therefore, the Administration have expressed great concern about redesigning the web system.

Currently, the registration forms can usually be purchased/ or get from the Administration offices desk in SSUET. In order to keep up with the Facilitating the members of the SSUET, the existing registration system needs to be refined. Thus the SSUET Administration requests proposals to build a prototype of an Computer Engineering Academic Programe (CEAP) based on their current Academic system.

The new CEAP needs to be scalable enough so that it can accommodate the increase in providing easy registration facility in SSUET. The proposal must express this ideology in the project plan (PP) and implement a prototype to illustrate this functionality. The PP and the prototype to be presented will be evaluated on the feasibility of the development plan and process description. However, the management approach and appropriateness to the project at hand will play an important part in the selection of the proposal. If the prototype proves to be a feasible alternative to the needed CEAP, our team will be given the opportunity to manage the overall development of the actual ARRS that will be implemented in registration office/Department in SSUET. In the case that our plan is approved by the Administration, the PP will be updated as the project progresses.

1.1 Project Overview.

CEAP begins the new journey in the development of a scalable and improved registration system for SSUET. The goal of the project is to create a working prototype of the CEAP that will be designed to provide a web and electronic version of the registration system in SSUET. The CEAP will have a user-friendly graphical interface, and it will be cost effective compared to the current non-electronic and non-web version of the registration system.

The objectives of the development effort are as follows: To provide existing student with a new environment in which to

make registration for their university activities.

To provide an avenue for student to obtain their forms in a more convenient way.   

To regain control of the registration form in order to avoid scalping and overselling of forms.

To collect statistics in a more efficient manner for future university student development.

To increase efficiency of registration. 

Furthermore, the project is divided into major work tasks that enables to determine the phase of the project plan. The list below indicates the work activities:         Problem specification        Risk Analysis        Design stage        Implementation        Testing and evaluation        Quality Assurance        Maintenance

Project resources fall into two categories: people and equipment. People working for the CEAP include 10 software and web developers of SSUET who shall be provided by the Administration, and other 1 member from Faculty team. Furthermore, the Administration will also provide the necessary hardware and software for implementing the project. The CEAP system structure to be developed will include a central database to keep all registration information, and web servers to process all registration transactions if necessary. Students will be able to obtain their Form online through a web browser, by calling a registration. There are no budget constraints for the project at this time.

The major milestone involves building a prototype within one month of getting to SSUET, which will be a tough challenge. This prototype relates to the attempt by Administration to develop a full-blown registration system. The actual look and feel of the registration system prototype will be similar to the current online registration system implemented by the university of Texas at https://utdirect.utexas.edu/registration/chooseSemester.WBX

1.2 Project Deliverables.

Table 1: Project Deliverables

Deliverable Delivery Date Delivery Location QuantitySPMP (version 1) October 5, 2010 SSUET 1SPMP (version 2) October 7, 2010 SSUET 1Software Requirement Specification

October 7, 2010 SSUET 1

Prototype One October, 2010 SSUET 1Software Development Plan TBD TBD TBDHigh Level Design Specification

TBD TBD TBD

High Level Function Prototype

TBD TBD TBD

Detail Design Specification TBD TBD TBDDetail Product Prototype TBD TBD TBDSystem Construction Plan TBD TBD TBDSystem Construction Prototype

TBD TBD TBD

Testing and Evaluation Specification

TBD TBD TBD

Final Product TBD Beijing, China TBD

1.3 Evolution of the SPMP.

The different sub modules of the project will be divided among the team members, who will submit their work in a group Windows Live web account. The individual parts of the project will be checked and put together by the project manager. All changes will be reflected on the table at the beginning of this document and each note and change date will be noted. A team member will regularly review all documents. Weekly updates shall be communicated to the project manager who will immediately address these changes. After comments and issues are resolved, the document will be approved.

1.4 Reference Materials.

More information about the project can be found in the following documents:

        Chapter 20, 21, 23 and 17 Software Project Plan

Reference 23.2, 23.3,23.4       Project Plan Document

Reference 17.4.2        Group Wise SRS Discussion

www.daveeaton.com/scm/CMtools.htmlwww.soft.com/evalid/technology/White.Papers/website.testing.htmlwww.keynote.comwww.timberlinetechnologies.com/products/www.htmlwww.spmn.com/products_software.htmlwww.ittoolkit.comwww.distributive.com

         Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill Companies, Inc., 2006.

1.5 Definitions and Acronyms.

CEAP – Computer Engineering Academics ProgramCASE – Computer Aided Software Engineering SAAFM – Student Affairs and Financial ManagementPP - Project PlanSDD - Software Design DescriptionSRS - Software Requirement SpecificationSDS – Software Design SpecificationSPMP - Software Project Management PlanGUI – Graphical User InterfaceQAM – Quality Assurance ManagerPDM – Project Development ManagerPMP – Project Management Professional TBD – To be determinedUML – Unified Modeling Language

2.     Project Organization.

This section refers to the process model for the project and its organizational structure.

2.1 Process Model.

The CEAP project requires frequent user interaction. For that reason, our first choice included the Prototype model. However, we had doubts about the prototype model, and therefore we concluded to use the Spiral Model. The risk-based approach of the Spiral Model is significant to the development of this prototype, and it would also help select an established lifecycle model or determine a different model constructed from various phases of other lifecycle models. After regular reviews using the risk analysis table stated in the appendix,

we decided that the best approach was to use a Extreme Programming(XP model) which is our requirement according to the webapp. Currently, the project revolves around two established stages: Requirement Analysis and Prototype Development. Figure 1 shows the life cycle for the development process as well as entry and exit criteria for the different phases of the project.

Figure 1: Life Cycle Model

2.2 Organizational Structure.

The internal management of the project, as well as how the project relates to the rest of the organization is included in Figure 2.

Figure 2: Organization Chart

2.3   Organizational Interfaces.

The administrative and managerial interfaces between the project and primary entities with which it interacts are presented in Table 2.

Table 2: Project Interfaces

Organization Liaison Contact Information

Customer: APMM Don Shafer 86-1-5128931

Subcontractor: None  Don Shafer  

Software Quality Assurance: CRM

 Don Shafer  86-1-5128931

Software Configuration Management: Team 2

 Don Shafer [email protected] 

Change Control: Team 2  Don Shafer [email protected]

2.4 Project Responsibilities.

The project responsibilities are presented in Table 3.

 Table 3: Project Responsibilities.

Role Description Person

Project Leader Leads project team; responsible for project deliverables

Sharjeel Ali Shaukat

Project Team/Analysts

Assisting in building SPMP, SRS and prototype, as well as doing the necessary requirement and risk

analysis for the project

Syed Haider Abbas

Nida Akber

Faiz Masroor

Sulaiman Shahab

Faraz Ahmed

Farhan Mallick

Zia ur Rehman

Uzair Khan

Arsalam Allauddin

Project Development

Manager

Leads SSUET web and software developers; responsible for project deliverables

Syeda Umema Hani

Programming Manager

Responsible for the communication between the Management Team and the rest of the software

development team; the Programming Manager is also responsible for reallocating the human

resources and equipment of the project.

TBD

Software Managers Responsible for managing the team of 10 people; does the design of the software; after reviewing

reports from Test Engineer decides whether code needs to be sent back to Development Engineer for

improvement or to be send to Quality Assurance Manager for quality assurance phase

Syeda Umema Hani

Development Responsible for designing of webapp and Faraz Ahmed

Engineers distributing work among Code Developers Nida Akber

Code Developers Responsible for writing programming code Sharjeel Ali Shaukat

Syed Haider Abbass

Sulaiman Shahab

Test Engineer Responsible for testing and validation process in his/her team; leads Test Technician in the testing

process and reports the results of the testing process to the software manager

TBD

Test Technician Performs the testing and validation procedure; reports found errors to Test Engineer

TBD

Quality Assurance Manager

Responsible for quality assurance; reports to Software Manager and Project Development

Manager

TBD

Quality Engineer Performs quality assurance procedure; reports the results to Quality Assurance Manager

TBD

3.     Managerial Process.

This section specifies the management process for this project.

3.1 Management Objectives and Priorities.

Poor management process increases the failure rate of any project. Therefore, it is essential to establish the management objectives and priority for the CEAP. The goal of the project is to satisfy the requirements with a feasible development process that will improve the registration process for the SSUET. The central idea of the management of this project is the on time delivery of a reliable and good quality product, along with an intensive and early exchange of ideas and concepts necessary for the successful completion of the project at reduced cost. This will be achieved by early reviews of existing or new information and implementation on a regular basis.

In order to achieve the established management goals, management priorities must be recognized and acted upon immediately. The ARRS priorities involve delivery of the project plan and a prototype to the CRM. Therefore, gathering and analyzing information must be completed in order to fully comprehend the CEAP problem domain. Furthermore, this enables flexibility in finding innovative solutions for the problem,

approximate cost schedules for the CEAP and evaluate and resolve major risks.

The flexibility matrix in Table 4 communicates the characteristics of the different project dimensions

Table 4. Flexibility Matrix.

Project Dimension Fixed Constrained Flexible

Cost    X

Schedule  X

Scope (functionality)    X

3.2 Assumptions, Dependencies, and Constraints.

The CEAP project will be tested among sub modules before being implemented on a main website. Therefore, the foundation of the prototype must be based on several assumptions and restrictions.

Assumptions on which the project management plan is based are as follows:

        We will decompose our main module in 5 sub module according to the student and faculty need

        Each sub module has different registration criteria from one another to provide positive interaction between members

        Registration can be made up to one month before a particular student or faculty activity.

        Approval are assigned during registration.

        Student lists will be provided for Faculty at each student Activity.

        The following management reports will be available:

         Number of registration made for each student activity

         Number of student turned away because of no availability of form for each student activity

         Number of no-shows for each departure          Number and names of student who show up without

registration for each student activity.          List of Faculty who manage student activity events.

         The expected reservations during test period may amount to approximately 3,000 per day. This volume varies by hour, day, and season.          SSUET Chancellor Department will provide us with information

about identification process used in SSUET, so that it can be applied to the registration system and scalping of forms is avoided.

         Network connection will always remain established.

 Dependencies, or external events, upon which the project is dependent on

are: 

        Scalping of forms is a popular activity in SSUET, and Admistrators wants to discourage such practices.

        10 developers will be provided by the CRM as follows:        1 project manager who speaks English very well.         3 analysts, who have had extensive experience in developing

applications, none speak English, all read English, and all have a fair ability to write in English.

        2 Programmer/Analyst who has extensive telecommunications skills and communicates fairly well in English.

        4 Programmers in developing extensive applications. 3 of this group have excellent English                                     communication skills.

        The Administration will provide all the required hardware and software resources for the development of the project.

        The telecommunications channels available in SSUET are sufficient for the development of a feasible client server system.

       Two documentation specialists from our batch. 

Constraints, under which the project is to be conducted, are:

        The number of forms is limited to 5 categories.

        The number of students that can be taking a form at once is limited to 500 students.

        The functional prototype should be available after 10 days upon the arrival of the management team to SUET. This may prove to be a serious time constraint on the development of a successful prototype.

        Team members are restricted from bringing their own equipment, and insufficient equipment supply may hinder project development.

        Team members are restricted to bringing only the analysts of the team to SSUET. This might affect the project development if more people are needed or the required skills are not available.

        The majority of the SSUET members have limited access to the Internet, and thus they may not be able to get to the system.

3.3 Risk Management.

Table 5 gives a detailed description of the process used to identify, analyze, and manage the risk factors associated with the project.

Table 5: Risk Management.

Potential Risk 

Risk Monitoring Risk Management

Size of the software being very large and larger number of users than planned

Reviewing constant feedbacks from the customers in project meetings

Being flexible in the software design to accommodate the necessary changes

The software not being accepted by the CRM

Response from the CRM, reviewed on every project meeting

Early and intensive interaction with the customer for the success of project.

Cost factor involved in this project

Reviewing reports on expenditure and other cost related tp the estimated cost in the SPMP

Have additional funding allocated for it in advance and using it in case of emergencies.

Students requirements may change

Administration participation in design process and reviewing feedback information in group meetings

A new prototype will replace the previous one to accommodate the change

Technology will not meet Constantly reviewing project Exploring alternatives for the

expectation progress reports by Project Development Manager and software managers

outdated technologies

Lack of training on tools and staff being inexperienced

Reviewing progress report by software managers to determine the status of the project

Providing adequate training that is necessary for the completion of the project

The prototype not being delivered on time

Constant reviews among team members to ensure continuous progress on the prototype

Setting deadline before the actual time for submission of the project

3.4 Monitoring and Controlling Mechanisms.

Reporting  

Auditing Mechanism will be as follows: The Report Formatting procedure will be that it will discuss the progress of the project .How is the present phase going , it will also include the errors and difficulties that team had during that phase .In the last the future plans for the next phase of the project

  Software Quality Assurance Plan

 The Software Quality Assurance Plan is a proposal for the

Software Quality Assurance System of the organization. In addition, it is also an organizational structure and a series of activities, which help ensure a persistent high quality by product monitoring and control during the development of the software

 Quality Assurance (QA) includes procedures, techniques and tools

used to ensure that a product meets or exceed specified standards during its development cycle.

 The purpose of this Software Quality Assurance Plan (SQAP) is to

define the techniques, procedures, and methodologies that will be used to assure timely delivery of the software that meets specified requirements within project resources.

  Management

 Within an organization, Quality Assurance should be carried out

by an independent software quality assurance team that reports to Software Manager and project development manager The Quality Assurance team will be associated with a particular development group but also responsible for Quality Assurance across the organization. Figure 3 shows the basic management structure for software Quality Assurance.

Figure 3: Basic Management Structure

 The Quality Assurance team must, in the first place, ensure the

quality of the software process. So, the Quality Assurance team:        Defines process standards such as how reviews should be

conducted, and when reviews should be held;        Monitors the development process to ensure that the standards are being followed; and        Reports the software process to software manager and project development manager.

 Responsibilities

 The Quality Assurance team is responsible for the development

and maintenance of the product and process standards, The QA team is responsible for proposing and establishing techniques, procedures, and methodologies that may be effective used to assure timely delivery of the software that meets specified requirements within project resources.

Communication and Reporting Plan

Table 6 shows the reporting and communication plan for the project. This may change as the project progresses.

Table 6: Communication and Reporting Plan.

Information Communicated

From To Time Period

Project Review Project Development

Manger

Management Team Once per two weeks

Status Report Team 1, 2, 3

Software Manager

Project Development Manager

Every eight days

Status Report Programming Manager

Project Development Manager

Once a week

Status Report Development Engineer, Test Engineer and

Quality Assurance Manager

Team 1, 2, 3

Software Manager

Weekly

Progress report Quality Assurance Team

Software Manager and Project Development Manager

Weekly as needed

Status Report Test Technician and Code

Developers

Development Engineer and Test Engineer

As needed

3.5 Staffing Approach.

We intend to use the people recommended by the Administrator for various tasks. At the moment, we don’t foresee a need for any extra staffing on the project. The staffing approach for this project is as follows:

        Management Team – Sharjeel,Haider.

        The Project Management Team decides who is qualified enough to be Project Development Manager among the 10 people provided by the Administrator.

        The Software Manager for team 1, team 2, and team 3 and the Programming Manager is interviewed by the Project Development Manager and the Project Management Team. The Project Development Manager decides who gets to be manager of which team.

        The Software Manager of team 1, team 2, and team 3 and the Programming Manager will decide who will become Development Engineer, Test Engineer, Code Developer, and Test Technician. In the end, the Project Development Manager approves the decision.

        The Project Development Manager and the Project Management Team staff the Quality Assurance Manager and the Quality Engineer positions.

        Nida and Faraz will receive UML and CASE Knowledge through our course book and apply this new knowledge on this project to improve work efficiency and effectiveness.

        The Project Manager gets to decide or redistribute the work force among teams in the case that any member of the team gets sick. Nevertheless, he needs to inform the Project Development Manager about it. 

4.     Technical Process.

This section specifies the technical methods, tools, and techniques to be used on the project. It also includes identification of the work products and reviews to be held and the plans for the support group activities in user documentation, training, software quality assurance, and configuration management.

4.1 Methods, Tools, and Techniques.

The approach used for the project development is an Hypertext Preprocessor technique, and thus, the programming language will be php as well. Furthermore, Function Points will be used to track defects on the modification and maintenance. More details will be added as the Software Requirements Specification is further developed.

The CASE tool and its object oriented development methodology with unified modeling language representation (UML) and instant HTML code generation is used in this software or web development project. The manager with Project Management (PM) knowledge works closely to use all the varied hardware and software capabilities.

4.2 Software Documentation.

The work falls into separate categories, where each category involves one or more people working on it. A reference to initial computing design structure is shown in Section 4.2.2 Software Design Description (SDD) to illustrate the functionalities of the work products. The initial design requires four work products. However, this is a target of constant change after every review. The work products are divided according to their different contributions to the whole project. For instance, data storage and

is a different module from the server, since both have different functionalities. One holds data, while the other controls traffic flow and access to the database.

Table 7 displays the work products and the types of reviews held for each one.

Table 7: Work Products and Review Schedules

Work Products Review

DatabaseSchema Design Review

Server Implementation

Design Review

User Interface Design

Functional Review

Coding Code Review

4.2.1 Software Requirements Specification (SRS) .

This requires separate documentation so refer to the SRS document for more information.

4.2.2 Software Design Description (SDD).

Figure 4 is not a concrete software design description, but it is the basis for the design structure that we will develop at a later time. Furthermore, the diagram helped to determine our resource requirements and it effectively focused our thoughts and refined our ideas. Once again, this is not an established SDD for the project but a rough implementation of the project design

Figure 4: Software Design Description

4.2.3 Software Test Plan.

90% of the gathered information relevant to the CEAP in the SPMP must be evaluated and fully understood. The problem domain must be explored extensively then we proceed to the SRS. The SRS can be tested in two ways. First, we can validate the SRS by cross checking it with the SPMP to ensure all identified risks are resolved and the requirements are satisfied. The second test will occur when the CRM is fully satisfied with the SRS and agrees to proceed to the next phase of the project.

The design must satisfy the SDD, since it is based on the SRS. Reviews of the SDD must be based on the SRS, and the test criterion includes strictly validating the SDD against the SRS. Each risk in the SRS must be confronted and shown to be resolved in the SDD. Redesign or alteration of the SDD will be implemented if unsatisfied requirements are confronted during SDD validation and verification tests or reviews.

Each developer will be responsible for a portion of the project. There are two things that are important in the coding phase. First, the code functionality must strictly meet the SDD. The second important part is the consistency of code writing for the ease of product maintenance. Therefore, weekly code reviews shall track the progress made by individuals, and furthermore, eradicate any undetected serious errors. In addition, there shall be consistency in the program, and the developers will become familiar with each other’s code. This makes it easier for them to maintain the product in the future. Finally, the code reviews will be verified against the SDD to ensure that the project implementation follows the process we originally intended.

Developer’s work will be validated and verified to satisfy the SRS and SDD by other developers before commencing the system and functional tests. Once all sub modules have been verified, only then will the modules be integrated together.

4.2.4 User Documentation.

User documents will be uploaded online and the Administrator will receive a hardcopy after the project completes. The two document maker from our group will prepare these documents.

                                      4.3 Project Support Functions.                                                            The project manager is responsible for the project

configuration management. Zia is assigned the job for software quality assurance, the testers from Administration are responsible for verification and validation while Sulaiman and Nida are the supervisors for planning and inspecting the verification and validation. 

5.      Work Packages, Schedule, and Budget.

In this section, the work packages, dependency relationships, resource requirements, allocation of budget and resources to work packages, and a project schedule are specified

5.1 Work Packages and Schedule.

Table 8 shows the work packages for the activities and tasks that must be completed in order to satisfy the project agreement. Each work package is uniquely identified.

GANTT CHART Table 8:

5.2 Dependencies.

Figure 5: Dependencies of the Main Work Packages

5.3 Resource Requirements.

The resource requirements are divided into four separate categories, and these may be needed at different times during the lifecycle of the project. The division of resources falls into hardware and software requirements, people, database.

A large chunk of resource requirements involves hardware and software. However, major use of these resources comes into play after the project design is completed. Some of the resources required are listed below:

        A network (LAN) is required to facilitate the whole operation. This network consists of a database server, several workstations, and a build server to host the compilers. Refer to section 4.2.2 - Software Design Description for more information.

        A Windows operating system for different servers and apache server programs is also required.

These are the basic computer resources required. The coding period involves the use of all hardware and software, as well as 10 persons working on the project. Therefore, all resources are used at this point in time.

Activity issues for maintenance purposes will be addressed after the completion of the project. Therefore, such resource requirements come at the end of the project.

The other resource that is worth acknowledging since it may be used extensively throughout SSUET. The wireless resource falls in both the software and hardware categories. The mobile phones have excellent reception in SSUET. Furthermore, the technology to have access to the internet is possible through specially designed mobile phones that support WAP structure. Finally, the application design such as WML (language interpreted by the WAP technology) shall be implemented by us so that the SSUETIANS have the ability to access the CEAP using their mobile units.

Use of resources is limited to a minimum during the initial stages of the project. However, this increases once the coding and testing.

Figure 6 displays the relation of the resource requirement as a function of time.

Figure 6: Approximate Resources Vs Time Graph

5.4 Budget and Resource Allocation.

Table 9: Resource Allocation

  Project Manageme

nt Team and Project Development Manager

Development,

Programming and

Software Managers

Quality Assurance Manager

and Quality

Engineer

Development Engineer and Code Developer

Test Engineer and Test

Technician

Personnel

1 SSUET Student

person and 1 SSUET Faculty

4 SSUET analysts/

programmers

4 SSUET analysts/

programmers

4 SSUET analysts/

programmers

4 SSUET analysts/

programmers

Hardware

2 pc, one per person

4 pc, one per person

4 pc, one per person

4 pc, one per person

4 pc, one per person

Other          

Required software for the project includes: XAMPP DBMS, Windows Operating System, Apache Web Server Development Internet Explorer

Budget

Some of the basic items required for the development process, and their prices are listed in Table 10.

Table 10: Budget Allocations

Resource Description 

Allocated Budget

Poster Presentation Rs500 Filing Presentation Rs300

Software XAMPP Windows Apache

 Free software available on the web

Hardware Provided by AdministrationTotal Rs800

6.      Additional Components.

This section contains any additional components required for clarification of the different part of the SPMP.

6.1 Index.

An index to the key terms and acronyms used throughout the SPMP will be provided in the future.

6.2 Appendices.

A. Current Top 10 Risk Chart

Risk Items Risk Management Techniques

Personnel ShortfallsStaffing with talent,team building; morale building; pre-scheduling key people

Unrealistic schedules and budgets

Detailed, multi source cost and schedule estimation; design to cost; incremental development; software reuse; requirement scrubbing

Developing the wrong software functions

Organizational analysis; mission analysis; ops-concept formulation; user surveys; prototyping; early users' manuals

Developing the wrong user interface

Task analysis; prototyping; scenarios; user characterization (functionality, style, workload)

Gold PlatingRequirement scrubbing; prototyping; cost-benefit analysis; design to cost

Continuing stream of requirement changes

High change threshold; information hiding; incremental development (defer changes to later increments)

Shortfalls in externally furnished components

Benchmarking; inspections; reference checking; compatibility analysis

Shortfalls in externally performed tasks

Reference checking; pre-award audits; award-fee contracts; competitive design or prototyping team building

Real-time performance shortfalls

Simulation; benchmarking; modeling; prototyping; instrumentation; tuning

Straining computer-science capabilities

Technical analysis; cost-benefit analysis; prototyping; reference checking

B. Current Project Work Breakdown Structure

C. Current Detailed Project Schedule

D. Software Risk Management Plan

1 Identify the project’s top10 risk items2 Present a plan for resolving each risk item3 Update list of top risk items, plan, and results monthly

4 Highlight risk-item status in monthly project reviews. Compare with previous month’s ranking status

5 Initiate appropriate corrective actions

D. General Information

CO STAR: