Anda di halaman 1dari 11

The MHC-PMC Report

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 statement of study case


The study case is about MHC-PMS. The medical information system maintains information about patients suffering from mental health problems and the treatment problem that they have received. Most mental health patient do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems. To make is easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centers.

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

Appraisal of plan-driven document

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.

Appraisal of agile planning document


Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

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

Comparison of plan-driven and agile planning


Plan-driven development is an approach to software engineering where the development process is planned in detail. It bases on engineering project management and can be thought of as the traditional way of managing large software project. Plan-driven software development uses structure to control risk, but agile software development uses flexibility to control risk. Management team that work well with plan-driven approaches also tend to work well with Agile approaches, however, management teams that lack the ability to work well with plan-driven approaches may lack the discipline required of Agile.

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.

Discipline Process model

Plan-driven Waterfall

Agile planning Iterative and


8

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

Minimum upfront architecture and design work.

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,

documentation, planning, culture, future.

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

Anda mungkin juga menyukai