Project Plan document

Online Registration and Admission System (OARS)

Abu Dhabi University

Version 1.0 approved

Prepared by

Men’s Team
Waleed Al Zaabi
Ahmed Al-Qubaisi
Muntasir Syed
Yahya Al Bloushi
Jum Al Nuaimi
Mohamed Sadoon

20 November 2008

Copyright © 2008 – 2009 by Men’s Team . All rights Reserved

Table of Contents

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.

1.4 Main deliverables:

As we agree that it’s a (not-yet-finished-job) main deliverables shall be whatever

has been done so far in this phase which will be mainly the product that is the OARS
and the associated project documents. These deliverables are summarized as follows:

 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 Rating Assumptions

Our assumptions are rated based on three key parameters

 Confidence. How sure are we that the Assumption is true?

 Lead time. How long before we can prove or disprove the Assumption?
 Impact. If the Assumption proves incorrect, how much rework is involved?

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 )

No Assumption Remarks Confidence Lead-time Impact

1 Scope Scope had to be adjusted due to Reasonable 1 Medium

time so the project is divided in confident work
2 phases so less work is done in
each phase our objective is to
finish phase I which is the
admission process and the main
services within the OARS
2 Schedule We know that our project team Almost 2 Significant
members: Yahiya AlBloushi, and certain rework
Mohammed Sadoon will not be
available to us so often for at
least the first month of the
project, because one is moved
to Al Ain just recently, and the
other has been given a task to
finish in Al Ain by their
employers

I also assume as project

manager that most of the team
members will be so tight with
their schedule due to their
involvement in other course.
This will inevitably lead us to a
very tight schedule with
shortage in time to accomplish
what we promise to do.
3 Resources Main concern will be the Almost 1 Significant
availability of team members. certain rework

Availability of supporting tools

may take some time but not
cause serious delays such as:
Microsoft Project, and some
books on project management
details.
4 Expectation Our client assume that we will Almost 1 Minimal
s finish the phase I which is the certain rework
admission process but it has
been agree that phase II will not
likely be finished in this time
frame
1.7 Constraints

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 !!

4 Coordination and Dealing with project members that are geographically

communication dispersed as explained earlier (the case of Yahiya and
Mohammed Sadoon) could hinder coordination and
communication between group members this would
definitely be a real challenge.
1.8 References:

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

1.9 Definitions and Acronyms:

Activity A group of tasks undertaken to produce a tangible project deliverable.

   
Deliverable A product, capability to perform a service, or other result, that must be
produced to complete a project. Deliverables can be produced by the project
team or, in some cases, by suppliers contracted to the project.
 
Dependency A logical relationship between two or more activities. The four types of
dependencies are: start-to-finish, start-to-start, finish-to-start, and finish-to-
finish.  
Henry Gantt was an American mechanical engineer and management consultant, who
developed the Gantt chart in the 1910s.
Gantt chart is a type of bar chart that illustrates a project schedule. It illustrate the start
and finish dates of the terminal elements and summary elements of a project.
Terminal elements and summary elements comprise the work breakdown
structure of the project.
Goal or objective consists of a projected state of affairs which a person or a system
plans or intends to achieve or bring about — a personal or organizational
desired end-point in some sort of assumed development. Many people
endeavor to reach goals within a finite time by setting deadlines
Management in business and human organization activity is simply the act of getting people
together to accomplish desired goals. Management comprises planning,
organizing, staffing, leading or directing, and controlling an organization (a
group of one or more people or entities) or effort for the purpose of
accomplishing a goal.
Milestone The recognition of an important event within a project, usually the
achievement of a key project deliverable or a set of deliverables.
 
Phase A set of project activities and tasks that usually result in the completion of one
or more project deliverables.
   
Product A physical artifact that is produced by the project. Products are produced
primarily using goods and materials.
 
Project A unique endeavor to produce a set of deliverables within clearly specified
time, cost and quality constraints.
  
Project Management The skills, tools and management processes required to successfully
undertake a project.
 
Project Plan A document that lists the Work Breakdown Structure, timeframes and
resources required to undertake a project.
 
Project Schedule A document that identifies the timeframes for delivering a project and the
dependencies between activities within that project.
 
Project Task A specific work item that usually results in the partial completion of a project
deliverable.
 
Project Team A group of people who report to a Project Manager for the purpose of
delivering a project.
 
Planning n organizations and public policy is both the organizational process of creating
and maintaining a plan; and the psychological process of thinking about the
activities required to create a desired goal on some scale.
PRINCE2 PRINCE2 is a project management methodology.
Process is an ungoing collection of activities, with an inputs, outputs and the energy
required to transform inputs to outputs.
Project Management is a model of the constraints of project management.
Triangle
Project manager professional in the field of project management. Project managers can have
the responsibility of the planning, execution, and closing of any project,
typically relating to construction industry, architecture, computer networking,
telecommunications or software development.
Organization is a social arrangement which pursues collective goals, which controls its own
performance, and which has a boundary separating it from its environment.
Quality can mean a high degree of excellence (“a quality product”), a degree of
excellence or the lack of it (“work of average quality”), or a property of
something (“the addictive quality of alcohol”).[1] Distinct from the vernacular,
the subject of this article is the business interpretation of quality.
 
Quality Control The internal monitoring and control of project deliverables, to ensure that they
meet the quality targets set for the project.
Risk is a concept that denotes the precise probability of specific eventualities.
Resource The labor, equipment, materials and other items needed to undertake a
project.
 
Result The outcome of performing a project process or activity.
 
Risk Any event that is likely to adversely affect a project's ability to achieve the
defined objectives.
 
Risk Management The process of identifying, quantifying and controlling risks throughout a
project.
 
Risk Mitigation The actions taken to avoid, transfer or mitigate risks within a project.
 
Risk Planning The identification and scheduling of actions needed to reduce the level of risk
within a project.
 
Scope The total aggregation of deliverables to be produced by a project.
 
Service Work carried out to benefit a customer. Note: A service does not produce a
physical product or tangible result, as this is called an activity.
 
Solution A combination of deliverables that solve a specified business problem or
realize a specified business opportunity.
 
Schedules in project management consists of a list of a project's terminal elements with
intended start and finish dates.
Scope of a project in project management is the sum total of all of its products and
their requirements or features.
Systems (SDLC) is any logical process used by a systems analyst to develop an
Development Life information system, including requirements, validation, training, and user
Cycle ownership. An SDLC should result in a high quality system that meets or
exceeds customer expectations, within time and cost estimates, works
effectively and efficiently in the current and planned Information Technology
infrastructure, and is cheap to maintain and cost-effective to enhance
Task is part of a set of actions which accomplish a job, problem or assignment.
Work Breakdown The complete set of phases, activities and tasks required to undertake the
 Structure project and meet the full requirements of the customer.

2. Project Organization:

2.1 Roles & Responsibilities

Waleed Al Zaabi, Project Manager, 050 8133792, wa222666@yahoo.com

 Manage and direct project activities, including project documentation,

timelines, contact lists
 Write and approve software project specifications (SRS)
 Develop a complete working prototype
 Create, update and distribute project plan
 Oversight of entire project
 Support of project team

Ahmed Al Qubaisi, Development Team Manager, 050 4431744

alqubaisibuhamad@gmail.com

 Conceptual design architecture

 Development team leader
 ER and database building team leader
 project development and implementation
 project pilot

Muntasir Syed, QA and Test Manager, 050 7014067, jemsbhai@gmail.com

 Create test scripts

 Test plan team leader
 Development team member
 Preparation of test cases
 ER and database building team member
 Ensure that testing is performed
 Ensure that testing is documented

Yahia Al Bloushi, Developer, Test Engineer 050 8112207,

uae.heart@hotmail.com

 Lead testing effort

 ER and database building team member
 Conceptual design architecture team member
 Development team member
 Ensure that testing is performed
 Ensure that testing is documented
Juma Al Nuaimi, Developer, Test Engineer 050, 6436969

alnuaimi@gmail.com

 Conceptual design architecture team member

 Development team member team member
 ER and database building team member
 project development and implementation
 Ensure that testing is performed
 Ensure that testing is documented

Mohamed Sadoon, Documentation Officer, 050 2362877,

alnuaimi@gmail.com

 Document testing efforts

 Assist in process definition/documentation
 Charting of designs and documenting them
 Microsoft Project operator
 All project logging and documentation
3. Managerial Process Plan:

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.

3.1 Work Plan:

3.1.1 Work Breakdown Structure.

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.

3.2 Quality Control:

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:

 Requirements testing done as early as possible.

 Code review by a joint team of developers and testers before completion of

individual units.

 Concurrent to semi-concurrent testing of completed units

 Regular auditing and monitoring by the project manager

 Crashing on essential phases: Database design, login system, and Server

deployment

 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

 Comparing the incremental prototype being developed with some similar

existing systems already deployed; and this was done a regular basis.
3.3 Risk Management Plan:

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

Here we follow PRINCE2 methodology in approaching risk as seen in following risk

logs:

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 Delay on the development process.

description:

Impact Moderate
assessment:

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

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 Inability to deliver both parts on the specified time.

description:

Impact Moderate
assessment:

Likelihood: Medium

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action
22-11-2008 Team meeting that clears and explains the scale of the
project.

23-11-2008 Give more time for requirement gathering

15-12-2008 Ask to deliver the system on parts and postpone the

second part to version 2.
Project: AORS
Risk ID: R3 Title: Integration of code written by different developers
working separately.
Date raised: 30-11-2008 Date closed: 10-12-2009

Description: Since all team members are working full time, it was hard to
work in an environment where all developers can synchronize effectively.

Impact Inability to integrate parts of the code which leads to

description: losing time of development. Inability to deliver complete
project.

Impact Small
assessment:

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action
30-11-2008 Setting a unified template and enforce the developers to
use it.

10-12-2008 Use Sync and Stabilize method in short periods to ensure

new code is integrated immediately.
Project: AORS
Risk ID: R4 Title: Not enough time to finish the project
Date raised: 2-12-2008 Date closed: 5-1-2009

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 Not delivering the project on time or missing

description: functionalities.

Impact Large
assessment:

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action
3-12-2008 Ask for more time from the stakeholders.

10-12-2008 Start working on weekends.

5-1-2009 Deliver the system on different stages and delay the

registration part to the coming version.
4. Supporting Process Plans:

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.

4.1 Test Plan

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.

4.3 Scope and Objectives

4.3.1 Test Items:

Test items include the items listed as functional requirements, in the

Requirements Specification Document and include the following:

1 Requirement feasibility –Overall requirements

2 Requirement feasibility –Student interface
3 Requirement feasibility – Professor interface
4 Requirement feasibility –Registrar interface
5 Database Design Test – ERD Test white box
6 IDE & data server testing – Netbeans v6.1 & MySQL Server v5.1
7 Database connectivity testing - white box
8 Encryption Testing – white box
9 Validation testing – Validation of user input – white box
10 Login testing – black box
11 New user registration testing – black box
 12 admission step 1 testing – black box
13 admission step 2 testing – black box
14 admission step 3 testing – black box
15 admission step 4 testing – black box

4.4 Features to be tested

The following features implemented on the OARS and activities were subject
to the test plan and had testing performed on them as mentioned:

 Requirements documents and feasibility:

These were the first tests to be performed, and they were a gauge of the
feasibility of implementing the system as described in the requirement
documents. Once the overall design was tested and approved, the individual
requirements for each interface and use case of the system were tested for
feasibility, and these tests were performed subsequent to approval of the
modified requirements document.

 Database design, integrity and deployment

The database design and integrity test was one of the most crucial and
extensive tests in the test plan; as the integrity and design of the database
was vital to the success of the project. The design was tested as both an
Entity Relationship Diagram (ERD) and as the SQL code required to create
the schema. The deployment of the database was tested separately, once
the tested schema was built and deployed AND after the data server was
tested. Both these tests, due to their importance were performed using
white box testing techniques.

 IDE and data server employment

The IDE and data server to be used for deploying the project were tested
before any implementation work were done, and the tests were meant to
measure the optimality and feasibility of implementing the project on the
chosen IDE platform and data server.

 Login/Logout and session management system

This was the first required feature to be completely implemented, and
therefore this was the first actual feature test to be performed. The login
and session management system was tested as a black box test, using a
combination of valid and invalid inputs to the login subsystem.

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

 User registration system

This was an essential feature to be implemented, and since it was the first
step in the admissions process. This was performed as a black box test,
with combinations of valid and invalid input to the system.

 User input validation

The development team integrated all possible user input validation into one
java package consisting of 6 classes. Therefore, this package was tested as
a whole, using a comprehensive white box test that tested every class in the
package thoroughly, thereby ensuring the validation subsystem was
accurate.

 Admission processing system

The admissions process was the only major functional set of features to be
completely implemented as mentioned by the original requirements, and
since this process involved 4 discrete steps, 4 separate tests were
performed to verify this process. Each of the tests was a black box test,
with combinations of valid and invalid input to the interface involved in the
specified step of the process.

4.5 Features not to be tested

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

 Security issues and vulnerabilities

The only proper security feature to be implemented was encrypted
passwords, and this was tested. Other additional security features were
not implemented, and the vulnerability of the system to potential exploits
 and/or attacks were not tested. Again, this was due to time constraints on
the project.

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

4.7 Testing Deliverables

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.

4.9 Roles and Responsibilities

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:

5.1 Methods, Tools, and Techniques:

5.1.1 Software Development Model for ADU OARS

The usage of a software development model is essential for a software project

of any scale; and the as such using and implementing a proper and
appropriate development model is essential to the overall success,
effectiveness and efficiency of a project. Many well described development
models exist, however each project is a unique venture, and thus appreciating
this fact, most models are never used as is, there are always some
modifications made to the model as the situation of the particular project
would require. Often, no single model is exclusively used for a single,
sometimes a hybrid of models is created and used as per the project
demands, and other times a new purpose-built model is created and used.
The key to using a development model is, a model which enables the project
team to meet the requirements and goals of the project in the most optimally
effective and efficient manner should be the one employed. Therefore we
began our search for an appropriate software development model by listing
and analyzing our key requirements and goals for development.

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:

1. Very limited development time, scope of deadline extensions

are almost none.
2. Need to coordinate developers working in remote locations
3. Need to maintain proper documentation throughout the development
phase.
4. Need to have on the fly testing and quick feedback as time constraints
are high
5. Need to compensate for the fact that all requirements may not be met
at delivery, thus at any given stage we should have a product which
meets previous requirements/goals.

From the preceding criteria, we deduced the following points:

 The overwhelming factor was the limited time. Therefore all other
processes, decisions and activities should take this into consideration.
 Points 5 and 2, and to some extent 3 lend themselves to point out that
we should use some sort of prototyping technique as a development
model, most likely evolutionary prototyping.
 Point 2 and 4 emphasize the need for coordination between developers
especially in the light of the time constraints and this lends to the
suggestion that we should use a variant of the Microsoft "sync 'n
stabilize" model for development.
As mentioned previously, it is often the case that a hybrid of models
is used for a project, therefore we decided to use a hybrid approach.
We would use both evolutionary prototyping AND the sync 'n stabilize
model to achieve our goals.

Overall, the development would be done using the evolutionary prototyping

model, and this is almost a given default due to the fact that it is very likely
we would not be able to meet every given requirement by the client in the
time allocated; therefore it is the logical choice for us to keep incrementally
building on a prototype until we are at the deadline. Such an approach would
maximize the available time and resources we would have for development,
as well as solving potential redesign problems.

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.