Project Plan document

Online Registration and Admission System (OARS)

Abu Dhabi University

Version 1.0 approved

Prepared by

Men’s Team

Waleed Al ZaabiAhmed Al-QubaisiMuntasir SyedYahya Al BloushiJum Al NuaimiMohamed 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 1st 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 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

confident work

2 Schedule We know that our project team members: Yahiya AlBloushi, and 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.

Almost certain

2 Significant rework

3 Resources Main concern will be the availability of team members.

Availability of supporting tools may take some time but not cause serious delays such as: Microsoft Project, and some books on project management details.

Almost certain

1 Significant rework

4 Expectations

Our client assume that we will finish the phase I which is the admission process but it has been agree that phase II will not likely be finished in this time frame

Almost certain

1 Minimal rework

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 & Deadlines

We have to finish the project and submit it along with all 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 communication

Dealing with project members that are geographically 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, 2nd 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 Triangle

is a model of the constraints of project management.

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 Development Life Cycle

(SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user 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 Structure

The complete set of phases, activities and tasks required to undertake the 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 4431744alqubaisibuhamad@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: AORSRisk ID: R1 Title: Availability of team membersDate 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 description:

Delay on the development process.

Impact assessment:

Moderate

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action22-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: AORSRisk 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 description:

Inability to deliver both parts on the specified time.

Impact assessment:

Moderate

Likelihood: Medium

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action22-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: AORSRisk 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 description:

Inability to integrate parts of the code which leads to losing time of development. Inability to deliver complete

project.

Impact assessment:

Small

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action30-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: AORSRisk 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 description:

Not delivering the project on time or missing functionalities.

Impact assessment:

Large

Likelihood: High

Urgency: Very urgent as project have small time scale

Risk Owner: Manager

Action History:

Date: Action3-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 requirements2 Requirement feasibility –Student interface3 Requirement feasibility – Professor interface4 Requirement feasibility –Registrar interface5 Database Design Test – ERD Test white box6 IDE & data server testing – Netbeans v6.1 & MySQL Server v5.17 Database connectivity testing - white box8 Encryption Testing – white box9 Validation testing – Validation of user input – white box10 Login testing – black box11 New user registration testing – black box12 admission step 1 testing – black box13 admission step 2 testing – black box14 admission step 3 testing – black box15 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 theorganization 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 locations3. Need to maintain proper documentation throughout the development

phase.4. Need to have on the fly testing and quick feedback as time constraints

are high5. 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.