ZIXUAN NIE
Table of content
The statement of study case ........................................................................3 Appraisal of plan-driven document ............................................................4 Appraisal of agile planning document ........................................................6 Comparison of plan-driven and agile planning ..........................................7
The patient management system is an information system that is not only used to record patient information and treatment, it also gives warning when patients are in emergency, but it also has contributions to Clinic management, such as the system used to provide medical staff with timely information to support the treatment of patients.
The system is related to two different laws, which are personal information data protection and mental health law, so they are two key requirements which are privacy and safety
The plan-driven document for the patient information system is to document the key baseline including objectives, project organization, risk analysis, hardware and software resource requirements, work breakdown, project schedule and monitoring and reporting mechanisms. The objectives of project are complete the project by the project due date, complete the project within the budget, provide all deliverable identified and fulfill all stated requirements which will be analyzed by requirement analyst.
The document provided 7 assumptions that mean something may be happened during the planning of the project. And there are four constraints which is shown: setting budget is $100000, time is six months, one consultant from clinic to assist the project and maintenance fee wont be exceed $5000 per year.
The project will be produced 5 deliverables to project manager: System program, system document, requirement documentation, end-user documentation, updates documentation, installation of system program, system training and project document (SRS, SDS and some relevant plan).
4
All of roles and responsibilities are arranged by the project manager. Control plan has divided into four parts. Change requirement refers to change of the project scope, activity, budget and timeframe. Schedule plan is that using critical path method will manage what activities should be doing at this time, make sure the arrangement is suit for the timeframe of project. Communication, reporting plan indicates that the type of communication can be used, and who initiates and who is recipient. Metrics plan illustrates that what kind of metrics can be collected.
Risk analysis part shows numbers of risk can be potential found in the project. These data need to be submitted to project manager.
Problem resolution plan has three parts, firstly, problem report is that if problem occurs, staff needs to report problem to manager, then analyst will analyze and work out what is going on with the system. Finally, problem processing is way of looking for method to solve the problem. That is overall of plan driven document for patient information system; all of relevant points related to Summerville about such plan are included.
Agile planning document for patient information system has two parts which are release planning and iteration planning. This method shows that customers and developers as act main participants. Customers need to provide some stories as the requirement of the system, and collected by developer, they will estimate stories, split stories, then sort by timeframe which means which requirement requires the least actual time, and then translate them into tasks; these can be assigned to each developer to work on. Iteration planning is repeat activities of release planning; it is short time frames that last from one to four weeks. It allows the project to adapt to changes quickly.
Agile method breaks tasks into small increments with minimal planning, and emphasizes face to face communication over written documents when the members of project are the same location. Otherwise, they maintain daily contact by videoconferencing, email, etc.
6
Plan-driven approaches: Artifact and milestone driven Documentation is formal and structured Emphasis on up-front planning Higher degree of project ceremony Structured communications Heavy project governance and oversight Formal change control with change control board
7
Project stage gates requiring formal approval in order to proceed. Well defined project roles with separation of duties.
Agile approaches: Code-based deliverable driven People oriented with informal but constant Emphasis on on-going planning Lower project ceremony Limited or no formal change control within iterations. Limited project stage gates requiring formal approval in order to proceed.
The differences between agile approaches and plan-driven approaches are in two areas: the timing and depth of the practices. The focus on iterative and incremental development means agile teams plan enough to get started. Agile development is a much better approach when the properties of the final product cannot be determined on beforehand, when the project has release planning, there is basic part of the project to be build in order to determine what is needed for the project to evolve.
Plan-driven Waterfall
incremental Project planning Detailed project plan from start to end, created early in the project Requirements engineering Dedicated specification phase Requirement evolve over the course of a Basic plan for overall project, detailed plan per iteration.
initial requirements are project, no or very signed off. Comprehensive requirement documents often part of a contract relaxed change request regime. Easy access to customer rather than reliance on comprehensive requirement documentation Architecture and design Complex architecture and design specification before implementation begins. Implementation Programming work concentrated on Programming work involved over the
9
implementation phase. Testing Testing is at the end of the project, functional test executed by test specialist Quality assurance Formal QA role
whole project Testing involved over the whole project. Functional test executed by end user No explicit QA role
Here is a question about when do we choose plan driven and when do we choose Agile? We need to think about organizational requirements, team skills and abilities, problem complexity. In plan driven approaches, a project would be successful if it follows plan, more problems occur if plan is changed. In Agile approach, it breaks the project into smaller doable parts with independent requirements and come up with a process that takes into account changes.
The plan driven methodology still have prevalence, it often use in open source projects. Use in industry, such as military, government projects and many large financial institutions. The reasons why plan driven development persists are standard, expertise, dependencies,
10
Conclusion
It is conclude that both plan driven and agile approach are feasible, no single factor will dictate which type of methodology will be used. The selection of approach is considered by many factors and input gathered from many stakeholders. Combining practices from both types of methodologies could be beneficial in certain situation, use plan driven for a major program or project and then use Agile for sub-projects or sub-components and use Agile for the project but plan driven techniques for project governance and stage-gates.
11