Prepared by
Men’s Team
Waleed Al Zaabi
Ahmed Al-Qubaisi
Muntasir Syed
Yahya Al Bloushi
Jum Al Nuaimi
Mohamed Sadoon
20 November 2008
1. Project Overview
1.1 Purpose, Scope, and Objectives
1.2 Assumptions and Constraints
1.3 Project Deliverables
1.4 Schedule and Budget Summary
1.6 References
1.7 Definitions and Acronyms
2. Project Organization
2.3 Roles and Responsibilities
3. Managerial Process Plans
3.2 Work Plan
3.2.1 Work Breakdown Structure
3.4 Risk Management Plan
4. Supporting Process Plans
5.1 Testing plan
5. Technical Process Plans
5.1 Methods, Tools and Techniques
1. Project Overview
1.1 Purpose:
the system shall be called the Online Admission and Registration System (OARS). And
its main purpose will be to allow students to perform their admission online in the 1 st
phase and the 2nd phase will include the registration services, which include; register
into a course, drop a course withdraw…etc.
1.2 Scope:
This system will be built initially as a standalone system that could be hosted
anywhere. This approach will enable us to fully develop and debug the system in full
before it can be integrated within main ADU systems. This system will be built to be
highly available, redundant and fully secured. We will use the development tools and
database engine the client has proposed (java JSP Beans, and MySQL as a database
engine).
1.3 Objectives:
This project is intended to solve Abu Dhabi University (ADU) problem of not having an
online admission system. As we all know ADU is a leading university in the UAE and
the region its ambition and future plan is to keep expanding and attract students from
all over the world to study in it. This cannot be achieved if the admission system
which a core service in any modern day university is done in manual process.
We assume that this project will allow students from all over the world post and
undergraduate alike to be able to login into the ADU website and find all necessary
information of admission and will be ultimately perform the admission task online.
One of the main constraints that we have to observe is time is time, and the fact is
that we need to deliver the project and its associated documentation by the end of
January 2009, hence this project is divided into two phases one is the admission phase
and the other one is the registration phase, we believe that by January 2009 we shall
be able to complete the admission phase.
And fully functional OARS system, that enables the applicants to perform the
admission process online from a to z and this includes creating a new user
name and logging on with it, filling the application form, uploading and
attaching required documents, checking the status of the admission process
and then receive the final decision whether accepted, rejected, hold, or a
accepted with conditional terms.
Associated project document: A detailed software requirements specifications
(SRS)
A documented prototype that includes main functionalities that we aim to
achieve by the end of phase I.
A project plan that includes; testing details risk analysis, design architecture
and main system features.
Documentation of the code.
A collection of different testing documents.
1.5 NOT deliverables:
The following items and services will be part of phase I deliverables. As said earlier
this is because of the circumstances faced:
the registration part of the OARS system, which cannot be delivered in this
phase due to shortage in time and resources
although we guarantee the quality of the documents submitted we also agree
that they may be missing tasks and practices that are actually done but did
not have time to document and therefore will regrettably not delivered e.g.;
Managerial process plans, and technical process plan.
1.6 Assumptions:
For this project, there are circumstances and events that need to occur for the project
to be successful, but indeed they are outside the total control of the project team.
These assumptions are accepted as true and are often will not need so much of proof
or demonstration. These assumptions that prove to be incorrect can have a
significant impact on a project. It is important that project participants, stakeholders
understand and agree with the assumptions before the project begins.
Here we try to briefly and clearly describe our OARS project assumptions from all
aspects whether related to technology, resources, scope, expectations, or schedules.
I also would like to emphasize that these are only assumptions and will not be treated
as facts but are indeed base on the facts that are on the ground today they may
change, not exist, or even get worse when we start the project but we have to
consider them according to their rating which is explained in the following lines:
1.6.1.1 Confidence: is the measure of how certain we are of the Assumption. And
its rated on a scale of 1 to 4: 1-Almost Certain ( Very little
doubt about the Assumption) , 2-Highly Confident ( Some
doubt but we all feel it will be true) 3-Reasonably confident
(our best guess at the time) 4-Low confidence ( We would
prefer to not make a prediction)
1.6.1.2 Lead Time Lead time has an impact in that the longer it is before the
Assumption is proven true or false, the more work will be done
based on the Assumption. Lead Time is rated on a scale of 1
to 2: (1) The Assumption will be proven or disproven within
the first half of the remaining project time. (2)The Assumption
will be proven or disproven within the second half of the
remaining project time
1.6.1.3 Impact: Impact relates to the amount of rework that will need to be
undertaken if the Assumption proves incorrect. The rates are:
Minimal Rework: (minimal impact on the workload) Some
Rework: (still be accommodated within the existing
timeframes) Medium Rework: (either additional resources
required, or the finish date would need to be adjusted)
Significant Rework: ( A major impact on the project )
In this project we do our best in order to observe the project management triangle
with is nothing but the constraints of the project which are scope, schedule, and cost.
Scope
Quality
Schedule Cost
These are the constraints that might restrict, limit, or regulate the project. These
constrains are outside the total control of the project team and we have to accept
them and deal with them carefully:
No Constraints Remarks
1 Timeframes & We have to finish the project and submit it along with all
Deadlines associated document by mid January 2009
2 Resources Project team members are tight with their work schedules
3 Dependencies The C504 course is built in such a way that will not make
us as student to get the full knowledge on the project
management skills before the end of the course. This is
really diffecutl because we have to finish the different
classes first before we know what is to be done. For
instance the testing was the last classes in the course and
it’s a core part of the software project management but
we are asked to conduct testing practices in the project
and document them and submit them on time !!
Books notes:
- EEE recommended practice for software requirements specifications - IEEE Std 830-
1998
- Software requirement specification ver. 1.1 august 29 2003, Michael J. Reaver, of
Jacksonville State University
- Project management for information system – James Cadle and Donald Yeasts
- Metrics and Models in Software Quality Engineering, 2 nd Edition, Stephen H. Kan
- CSC 504 Dr. Rachides Class Notes.
- Indian Institute of Information Technology and Management – Kerala, Techno Park
SRS - Farm Health Record Management System.
Websites:
- http://www.wikipedia.org/
- http://www.adu.ac.ae/en
- https://ndeva.auckland.ac.nz/ndeva/guest/guest_frameset.asp (the university of
Auckland)
- http://www.ox.ac.uk/admissions/ ( university of Oxford)
- http://www.projectperfect.com.au/info_risk_mgmt.php
- http://isb.wa.gov/tools/pmframework/examples/mlsexample.aspx#assumptions
2. Project Organization:
uae.heart@hotmail.com
alnuaimi@gmail.com
This section of the IM/IT Project Management Plan specifies the project management
processes for the project. This section defines the plans for project start-up, risk management,
project work, project tracking and project close-out.
The WBS diagram that will follow will show the Work Breakdown
Structure of the various work activities to be performed in our project,
and the relationships among these work activities.
The ADU OARS system project was subject to an ad-hoc Quality Assurance and
Control technique mainly due to the time constraint on the deliverables. The use of
an evolutionary prototyping development model hybridized with aspects of the sync
'n stabilize model allowed for this approach to be taken. The following steps were
used to implement this process:
Integrating the development and test teams, thus avoiding any potential
conflicts between testers and developers.
Using and ensuring the IDE and database server used are up to date and in
sync within the entire team
A risk is actually, in one sense, the flip side of assumptions. With an assumption, we
expect something to happen. With a risk, we ask what will we do if something does
not happen, or how do we increase the probability that something will happen. Put in
other words a risk is something that may happen and if it does, will have a positive or
negative impact on the project. A risk has a probability of less then 100%, and above
0%. It must be a chance to happen or it is not a risk. We measure risks by looking at
their probability (likelihood) and impact. The probability may be highly likely, modest
likely and not likely. The impact may be large, moderate, or small. In the following
tables we summarize our risk management planning which includes:
Risk Identification
Risks Quantification
Risk Response
Risk Monitoring and Control
Project: AORS
Risk ID: R1 Title: Availability of team members
Date raised: 16-11-2008 Date closed: 16-1-2009
Description: Due to the fact that all team members are working it was very
hard to have meetings that agreed by all team members.
Impact Moderate
assessment:
Likelihood: High
Action History:
Date: Action
22-11-2008 Decide to have weekends meeting, Divide into sub teams
depending on the availability
15-12-2008 Team members have to work separately
Project: AORS
Risk ID: R2 Title: Unrealistic idea about how much work is involved
Date raised: 20-11-2008 Date closed: 15-12-2009
Description: Since it is the first time we develop this kind of project, team
members underestimated the size of the project and it turned out that these
were two projects in one, the admission part and the registration part.
Impact Moderate
assessment:
Likelihood: Medium
Action History:
Date: Action
22-11-2008 Team meeting that clears and explains the scale of the
project.
Description: Since all team members are working full time, it was hard to
work in an environment where all developers can synchronize effectively.
Impact Small
assessment:
Likelihood: High
Action History:
Date: Action
30-11-2008 Setting a unified template and enforce the developers to
use it.
Description: Since the size of the project was big and the time available is
limited with team members not fully dedicated, the project ran the risk of
running late.
Impact Large
assessment:
Likelihood: High
Action History:
Date: Action
3-12-2008 Ask for more time from the stakeholders.
This section of the IM/IT Project Management Plan specifies the project management
processes for the project. This section defines the plans for project start-up, risk management,
project work, project tracking and project close-out.
The project is to design an admission system for the ADU post and
undergraduate studies. It will allow student from all over the world to access
the admission service online and perform the admission process. This is
phase I. In phase II, the registration process will also be introduced. After
this phase I is completed the different user types; professor, registrar, and
applicants will be able to login and access the system and perform all required
activities concerning the admission process.
4.1.1 Introduction
This test plan documents the testing activities for the OARS
development activities. The programmers will complete the
application unit testing. Two assigned testers and their One test
Manager (Muntasir, Yahia Al Bloushi and Juma Al Nuaimi) then the
Test Manager will complete the system testing and record test cases
and errors in the Testlog database.
4.2 Assumptions
The developers will have the application ready for testing on schedule.
The assigned testers will be available for testing.
The following features implemented on the OARS and activities were subject
to the test plan and had testing performed on them as mentioned:
Student interface
The student interface was tested first as a requirements test, and then as
part of the admissions process tests. This was done as the system as
implemented by the time of delivery had the student's role limited to an
actor in the admission's process, i.e. the student's only implemented
function was to be an applicant for admission. This test was performed as a
black box test, using combinations of valid and invalid input to the system.
Professor interface
The professor interface was tested first as a requirements test, and then as
part of the admissions process tests. This was done as the system as
implemented by the time of delivery had the professor's role limited to an
actor in the admission's process, i.e. the professor's only implemented
function was to approve an applicant for admission. This test was performed
as a black box test, using combinations of valid and invalid input to the
system.
Registrar interface
The registrar interface was tested first as a requirements test, and then as
part of the admissions process tests. This was done as the system as
implemented by the time of delivery had the registrar's role limited to an
actor in the admission's process, i.e. the registrar's only implemented
function was to verify an applicant's admission form and move the
application forward to the professor during the admissions process. This test
was performed as a black box test, using combinations of valid and invalid
input to the system.
Encryption of passwords
This feature was tested after the encryption system was added to make the
passwords more secure. The underlying code was tested for integrity and
vulnerability, thus this was a white box test.
Browser compatibility
The development and test team used Microsoft Internet Explorer V7 and
Firefox V3 during the entire testing and development process. Since these
2 browsers are by far the most popular browsers used worldwide, and also
due to time constraints, a formal test using other browsers and versions
was not done.
4.6 Approach
Two test engineers and their manager will perform system testing. They will
record test cases and errors into the Test log. The Documentation manager
will record test cases and errors and then log them
All recorded errors are expected to pass by the second test. A test report
detailing the results of testing will be delivered at the end of testing.
Unfortunately client acceptance testing cannot be performed due to shortage
of time
4.8 Resources
For the unit testing each test engineer will have an up to date version to the
system and will conduct the test on his own pc. System testing
will take place at one time and with the presence of all testing team members
along with the developer and project manager.
Roles and responsibilities are listed next to the testers’ names in the
organization frame work document please look at it.
4.10 Schedule
Unit tests are left to different test engineers to perform on their own time and
as development and changes are received, but need to be submitted but
results need to be submitted to Development Manager once they are ready.
System testing must be conducted the first week of January 2009 and shall
be completed one the same day. The Project Manager will be notified of all
errors and assign
5. Technical Process Plan:
For our project which was the development of an Online Admission and
Registration System (OARS) we decided that a development model would be
needed that met the following criteria:
The shortfall in our case for using an evolutionary prototyping model alone is
the obvious trap of the whole process degenerating into a build and fix
pattern due to the lack of attention to testing, lack of proper documentation,
and poor communication between individual developers who work remotely
for the most part. These shortfalls can largely be overcome if we include the
sync 'n stabilize model as part of our overall development model, with the
main purpose being for implementing proper testing and documentation,
facilitating effective communication between developers, and providing a
proper control perspective for the manager. These advantages well warranted
our case where we hybridized these 2 development models for our project
demands.