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/N

2. Are the goals and objectives in the scope section of the plan document? Y/N
3. Have assumptions been included? Y/N
4. Have constraints been identified? Y/N

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

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

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

Project Schedule (WBS)

1. Is there a clear WBS? Y/N
2. Is the project schedule structured into overview and sub-phases? Y/N
3. Are dependencies identified in the plan? Y/N
4. Are external dependencies linked to activities in the plan? Y/N
5. Are public & resource holidays identified in the schedule? Y/N
6. Is there a Gantt chart? Y/N
7. Has work effort been estimated? Y/N
8. Has task duration been estimated? Y/N
9. Has skill level of resources been taken into account? Y/N
10. Have the estimates been supplied by or validated by the resource assigned to it? Y/N
11. Has PM effort been included in the plan? Y/N
12. Have all activities been decomposed to an individual effort estimate i.e. no more than 5
days effort per activity. Y/N
13. Has the Cost Estimates (Budget) been calculated from the WBS? Y/N

Milestones & Dates

1. 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

Resources
1. Resources Resource Requirements: are named resources assigned to activities,
appropriate to their skills?
2. Y/N
3. Is Resource Loading based on 5 days per week/ normal working hours? Y/N
4. Have resource requirements, hardware/additional software costs been estimated? Y/N
5. 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/N
2. 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 Quantity

SPMP (version 1) October 5, 2010 SSUET 1
SPMP (version 2) October 7, 2010 SSUET 1
Software Requirement October 7, 2010 SSUET 1
Specification
Prototype One October, 2010 SSUET 1
Software Development Plan TBD TBD TBD
High Level Design TBD TBD TBD
Specification
High Level Function TBD TBD TBD
Prototype
Detail Design Specification TBD TBD TBD
Detail Product Prototype TBD TBD TBD
System Construction Plan TBD TBD TBD
System Construction TBD TBD TBD
Prototype
Testing and Evaluation TBD TBD TBD
Specification
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.html
www.soft.com/evalid/technology/White.Papers/website.testing.html
www.keynote.com
www.timberlinetechnologies.com/products/www.html
www.spmn.com/products_software.html
www.ittoolkit.com
www.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 Program

CASE – Computer Aided Software Engineering
SAAFM – Student Affairs and Financial Management
PP - Project Plan
SDD - Software Design Description
SRS - Software Requirement Specification
SDS – Software Design Specification
SPMP - Software Project Management Plan
GUI – Graphical User Interface
QAM – Quality Assurance Manager
PDM – Project Development Manager
PMP – Project Management Professional
TBD – To be determined
UML – 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: Don Shafer 86-1-5128931

CRM

Software Configuration Don Shafer cs5391@yahoo.com

Management: Team 2
 Change Control: Team 2 Don Shafer cs5391@yahoo.com

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 Sharjeel Ali Shaukat
deliverables

Project Assisting in building SPMP, SRS and prototype, as Syed Haider Abbas
Team/Analysts well as doing the necessary requirement and risk Nida Akber
analysis for the project
Faiz Masroor
Sulaiman Shahab
Faraz Ahmed
Farhan Mallick
Zia ur Rehman
Uzair Khan
Arsalam Allauddin
Project Leads SSUET web and software developers; Syeda Umema Hani
Development responsible for project deliverables
Manager

Programming Responsible for the communication between the TBD

Manager 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.

Software Managers Responsible for managing the team of 10 people; Syeda Umema Hani
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

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 TBD
his/her team; leads Test Technician in the testing
process and reports the results of the testing process
to the software manager

Test Technician Performs the testing and validation procedure; TBD

reports found errors to Test Engineer

Quality Assurance Responsible for quality assurance; reports to TBD

Manager Software Manager and Project Development
Manager

Quality Engineer Performs quality assurance procedure; reports the TBD

results to Quality Assurance Manager

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
The software not being
accepted by the CRM
Cost factor involved in this
project
Students requirements may
change
Technology will not meet
Reviewing constant feedbacks
from the customers in project
meetings
Response from the CRM,
reviewed on every project
meeting
Reviewing reports on
expenditure and other cost
related tp the estimated cost in
the SPMP
Administration participation in
design process and reviewing
feedback information in group
meetings
Constantly reviewing project
Being flexible in the software
design to accommodate the
necessary changes
Early and intensive interaction
with the customer for the success
of project.
Have additional funding allocated
for it in advance and using it in
case of emergencies.
A new prototype will replace the
previous one to accommodate the
change
Exploring alternatives for the
expectation
Lack of training on tools
and staff being
inexperienced
The prototype not being
delivered on time
progress reports by Project
Development Manager and
software managers
Reviewing progress report by
software managers to determine
the status of the project
Constant reviews among team
members to ensure continuous
progress on the prototype
outdated technologies
Providing adequate training that is
necessary for the completion of the
project
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.

 Time Period
Information From To
Communicated

Once per two

Project Review Project Management Team
weeks
Development
Manger
Every eight days
Status Report Team 1, 2, 3 Project Development
Manager
Software
Manager
Once a week
Status Report Programming Project Development
Manager Manager
Weekly
Status Report Development Team 1, 2, 3
Engineer, Test Software Manager
Engineer and
Quality
Assurance
Manager

Progress report Quality Software Manager and Project Weekly as needed

Assurance Team Development Manager
As needed
Status Report Test Technician Development Engineer and
and Code Test Engineer
Developers

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

Schema Design
Database
Review

Server
Design Review
Implementation

User Interface Functional

Design 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 Development, Quality Development Test

Management Programming Assurance Engineer Engineer
Team and and Software Manager and Code and Test
Project Managers and Quality Developer Technician
Development Engineer
Manager
Personnel 1 SSUET 4 SSUET 4 SSUET 4 SSUET 4 SSUET
Student analysts/ analysts/ analysts/ analysts/
person and 1 programmers programmers programmers programmers
SSUET
Faculty
Hardware 2 pc, one per 4 pc, one per 4 pc, one per 4 pc, one per 4 pc, one per
person person person person 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 Free software available on the web
Windows
Apache
Hardware Provided by Administration
Total 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

Staffing with talent,team building; morale building; pre-
Personnel Shortfalls
scheduling key people
Detailed, multi source cost and schedule estimation; design to
Unrealistic schedules
cost; incremental development; software reuse; requirement
and budgets
scrubbing
Developing the wrong Organizational analysis; mission analysis; ops-concept
software functions formulation; user surveys; prototyping; early users' manuals
 Developing the wrong Task analysis; prototyping; scenarios; user characterization
user interface (functionality, style, workload)
Requirement scrubbing; prototyping; cost-benefit analysis; design
Gold Plating
to cost
Continuing stream of High change threshold; information hiding; incremental
requirement changes development (defer changes to later increments)
Shortfalls in externally Benchmarking; inspections; reference checking; compatibility
furnished components analysis
Shortfalls in externally Reference checking; pre-award audits; award-fee contracts;
performed tasks competitive design or prototyping team building
Real-time performance Simulation; benchmarking; modeling; prototyping;
shortfalls instrumentation; tuning
Straining computer- Technical analysis; cost-benefit analysis; prototyping; reference
science capabilities checking

B. Current Project Work Breakdown Structure

C. Current Detailed Project Schedule

D. Software Risk Management Plan

1 Identify the project’s top10 risk items

2 Present a plan for resolving each risk item
3 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: