Project Plan: Dutch Auctioning System
This document’s purpose is to define the project and capture the essential information for its correct management. Its goal is to identify the project as correctly as possible, to serve as a basis for future administration and enable the assessment of the project’s success. This document will be used: • By the client to receive information about the project, the members of the team and their plan.
It will be used in order to have the ability to make a good decision before committing to the realization of the venture • By the Project Leader, who can monitor the progress of the assignment and serve and refer to the document whenever questions appear regarding the project’s validity 1. Project Statement 1. 1 Formal client 1. 2 Project team Project leader: Document controller: Members: 1. 3 Current situation The client wants to have a Dutch Auction Management System with servers for each country. 1.
4 Project GoalThe goal of this project is to create a Dutch Auctioning System where the user can put up items for auction and bid on other items. Each country has one server. A user can register on the server of his/her own country and he/she can log on to the same server. The user account data is stored in all the servers. All users can view/search for item(s) by using keywords in all servers and follow the item they want. The auction process: The auction creator sets the initial price (highest price), and the interval time and amount for the price decrease.
When the auction starts, price will decrease N price every M time. The auction ends when the first bidder that follows the item bids. 1. 5 Selected approach The project uses an incremented phasing approach. In the first increment we will draw up a Project Plan which will be presented to the client. Changes will be made if necessary and along with the final version of the Project Plan we will also send a Process document with details about spent hours, activities and what is to come in the next phase.
This will be the Initiative phase.After this we will begin the Definition Phase, and here we will draw up a Requirements Document, which will describe functional and technical requirements and will include an early version of the User Interface Design. The document will probably be revised a couple of times before the final version is sent in. Again, a Process Document will accompany the Requirements Document. Next, we will begin the Design Phase.
This phase is more technical then the two previous phases, because here we are already switching to creating class diagrams and sequence diagrams useful when we start the actual programming of the application.The most important thing for the client will probably be the Use Cases, where the general outline of how the application will work is presented. This document will also go through a couple of revisions before it reaches its final state. At the end of the phase a Design Document and a Process Document will be handed in. Subsequently, we will begin programming the current application increment (Realization Phase).
This will be the longest part of all the phases and the most time consuming. Meetings will still take place every week to discuss (and if possible show) the progress done with the application.At the end of each of these phases, the client will receive the current application, based on the current incremental cycle. A process document will accompany all the other documents at the end. At this point the second and third increments follow. In the second and third increment only a small startup phase, a shorter version of the first three phases, is done.
The rest of each increment is purely realization phase. In the Transfer Phase, the application is formally passed to the client and if necessary changes made to the application.This is the final stage of the project, and one the shortest (planned 1 week). This phase will only happen after the last increment; in the other increments there will be a presentation to show the progress of the project. The whole project is planned to last about 1 semester, from 30th August 2010 until 30th January 2011. 1.
6 Project product Auction Management System is an application to auction on item. User can register, login, view, search and follow item(s). User can create auctions and define when the auction starts and how long the auction runs.Administrator can manage user/bidder information (Limited Account User, Delete Auction). 1. 7 Project deliverables • Software would be delivered electronically (deadline: 14th January 2011 ) • User Manual for the end user (deadline: 14th January 2011) • User Manual for the server administrator (deadline: 14th January 2011) • Technical Manual for the server administrator (deadline: 14th January 2011) • Zip file with the client / server source code (deadline: 14th January 2011) 1.
Project non deliverables • Installation • Update • Maintenance • Support 1. 9 Project constraints Delivery Constraints The Project has to be finished in 1 semester, from 30th August 2010 to 14th January 2011 Operating System The client application will work on Windows XP, Vista and 7. The server application will work on Windows XP, Vista, and 7. It will also be tested on Windows Server 2008. Environment The Development environment will use Microsoft Visual Studio 2010, and Microsoft SQL Server. 2. PhasingIf the project team fails to finish the project and deliver the program with the agreed documentation on time, in which case the team’s client might suffer some material loss, then the project team takes responsibility and agrees to pay the client the compensation for the losses the client has suffered. [pic] 2. 1 Phase I: Initiative phase In the initiative phase we will get acquainted with the project by reading the project description and if necessary planning an interview or two in order to shed light on some matters of the project.After receiving the final Project Plan, the client has a Go/No-Go saying within the project.
Depending on the results of the Project Plan the client makes a decision to continue, change or stop the current project. Deliverables: – process document – project plan 2. 2 Phase II: Definition phase In the definition phase, we will go more in depth towards understanding the client’s wishes and requirements, this time with regard to the end result of the project. We will have to create functional and technical requirements (software and hardware requirements) and make a design for a user interface.These will be included in the requirements document, which is a deliverable in this stage of the process. After receiving the Requirements Document, the client has a Go/No-Go saying within the project.
Depending on the information contained within the Requirements Document, the client makes a decision to continue, change or stop the current project. Deliverables: – process document – requirements document 2. 3 Phase III: Design phase In this phase we will create use cases, a class diagram, specify functions er class (pre/post conditions), create sequence diagrams for some important transactions within the program and make a test and integration plan. This will be included in the design document. The Design Document will be mostly a technical document.
The only part that will be interesting to the client is the “Use Cases” which define, in general, how the application will work. At this point the client has a Go/No-Go saying in the project. Depending on the information contained within the Design Document, the client makes a decision to continue, change or stop the current project.This is the last Go/No-Go stage within the project. Deliverables: – process document – design document 2. 4 Phase IV: Realization phase The realization phase covers the implementation of the design and the programming of the whole application.
This phase happens in each increment. Deliverables normal realization phase: – application up to the current increment Deliverables final realization phase: – final application 2. 5 Phase V: Transfer phase The final phase of the process will be the transfer phase. In this phase, we, the team hand over the application and documentation over to the client.This phase comes after final negotiations about things that need to be changed from the Realization phase. Deliverables: – application – application source code Sub – deliverables: – process document – approved user manual.
One for the administrator, and one for the user. – approved technical manual The process document is a document presented at the end of each phase, detailing the amount of time spent by individual group members on the tasks at hand (in order to complete that phase of the project) and also includes a raw plan of what is to come within the next phase of the program.In the case of the last phase (transfer phase) there is no plan of the future actions taken by the team, since there will be no more phase afterwards. 2. 6 Client Planning Time table for meeting where the client needs to be present |Meeting |Week or day | |Startup Meeting 1 |30. 8.
2010 | |Startup Meeting 2 |6. 9. 010 | |Startup Meeting 3 |13. 9. 2010 | |End 1 /Start 2 Meeting |1.
11-5. 11. 2010 | |End 2 /Start 3 Meeting |13. 12-17. 12. 2010 | |Transfer |10.
1. 2011-14. 1. 2011 | Management Plan 3. 1 Money Money planning is not involved in this project.
3. 2 Skills ? Analyzing and Designing a Project ? Coding in C# ? Teamwork/Interpersonal Skill ? Holding a presentation ? Paperwork: writing report, minutes, etc. ? Knowledge in UML ? Knowledge about sequence diagram and use cases ? Familiarity with remoting techniques 3. 3 Quality We are aiming for a professional quality program; there should not be many differences between a “real” professional program and our “student” version. We will realise this quality through clever and well proportioned testing.It is set that every part of the program that is delivered as a part of an assignment is fully working for itself, so that we can find bugs easier because we can be sure that the new part is working.
This also means that everybody should test their code as soon as possible to ensure that he doesn’t have to redo bigger parts of his coding. The final testing of a program part is done by someone else then who did program it. This should one the one side gives us the guarantee that every part is critically analysed. Also it is easier to find errors if you haven’t worked on the piece by yourself. 3.
4 RisksSchedule Problems The group runs out of time due to bad planning or unforeseen technical problems It can be solved by carefully reviewing the tasks and schedule, and adjusting the planning when it becomes clear that some parts have not been accounted for. Personnel A project member not carrying out his/her part because of unwillingness or unavailability due to illness or other reasons. It can be solved by communication from the member who cannot be present, and discuss the problems within the group to make changes. Also, documenting all the team’s progress would help in case one of the team members becomes unavailable.Client Problems Misunderstanding of the client’s specification and requirements. It can be solved by reviewing the documents more carefully, making sure the client is properly interviewed beforehand, and contacting the client with questions or inquiries if some parts of the project are too vague or unclear.
