Work Breakdown
Project journal
|
Sl No. |
Date |
Activity |
Explanation |
Status |
|
1 |
20/ 5/ 2018 |
Work breakdown |
All the activities for the entire project will be developed |
Completed |
|
2 |
23/ 5/ 2018 |
To – Be design |
After analysing the situation it is important to consider the flow of the activity |
Completed |
|
3 |
24/ 5/ 2018 |
Changes identification |
Identifying and analysing the feasibility of the new changes |
Completed |
|
4 |
26/ 5/ 2018 |
Acceptance criteria identification |
Identifying and analysing the acceptance criteria |
Completed |
|
5 |
27/ 5/ 2018 |
Application architecture development |
Proposing an architecture that can bring maximum output |
Completed |
|
6 |
28/ 5/ 2018 |
Report to client |
Developing a report for the client |
Completed |
|
7 |
31/ 5/ 2018 |
Agile and waterfall differences |
Analysing which is the best approach |
Completed |
Following is the work breakdown structure:
|
WBS |
Task Name |
|
1 |
Development of patient care system |
|
1.1 |
Project initiation phase |
|
1.1.1 |
Analysing project requirements |
|
1.1.2 |
Planning and development of project |
|
1.1.3 |
Undertaking feasibility analysis |
|
1.2 |
Project planning phase |
|
1.2.1 |
Scheduling project tasks |
|
1.2.2 |
Estimation of resources |
|
1.2.3 |
Resource allocation |
|
1.2.4 |
Development of communication plan |
|
1.2.5 |
Allocation of tasks to the project team members |
|
1.3 |
Project Execution Phase |
|
1.3.1 |
Device deployment |
|
1.3.2 |
Project prototype development |
|
1.3.3 |
Testing of accounting software |
|
1.3.3.1 |
Accounting database development |
|
1.3.3.2 |
Database connection |
|
1.3.3.3 |
Response time testing |
|
1.3.3.4 |
Query testing |
|
1.3.3.5 |
Transferring data |
|
1.3.3.6 |
Acceptance testing |
|
1.3.3.7 |
Software testing |
|
1.3.3.8 |
Testing data warehouse |
|
1.3.3.9 |
Connection testing |
|
1.4 |
Project closure |
|
1.4.1 |
Post project review |
|
1.4.2 |
Stakeholder sign off |
|
1.4.3 |
Project review |
Figure 1: WBS
(Source: Created by Author)
Figure 2: To- be design diagram
(Source: Created by Author)
The above to-be model presents the demonstration for the proposed system functioning and how it will beneficial for the organization to utilize the services and provide better services to the organization.
The proposed system will be completely transforming the current situation of the organization with an automated and online service. The proposed model describe how automatically, the organization will be able to utilize the application of the services and bring maximum output.
This will be the first page opening for the new users allowing them to register the system
Figure 3: Screen design for new users
(Source: Created by Author)
Figure 4: Screen design for specialist
(Source: Created by Author)
The proposed system would only be acceptable of the users will be able to utilize all the existing options and services and the customers are satisfied with the delivery and outcomes of the project. The system should enhance the revenue by 10% and automating the entire process without hampering the quality and standard of the project.
Figure 5: Application architecture
(Source: Created by Author)
The application architecture will be divided among the different layers comprising of three different functionalities that will be helpful in managing the application of the system in the real life and allowing the users to effectively and efficiently utilize the services.
The system being proposed is capable of automating the entire process of communication between the doctor and the patients and avail the services those were being proposed earlier. Clients will be able to avail the services in much efficient and effective manner.
|
Agile model |
Waterfall model |
|
Segregates the growth of the project lifecycle within sprints |
Divided the project in many phases |
|
Waterfall can be rigid |
Agile can be flexible |
|
Focus on the improvement of the overall software quality |
There is no scope of change |
|
Allows changes |
Changes are not acceptable |
|
Follows iterative development |
Everything is accomplished in single phase |
|
Test plan review after the sprint |
Test plan review during the testing phase |
|
Project details can be altered |
Detail description will be needing the waterfall software development |
References
De Thurah, A., Stengaard?Pedersen, K., Axelsen, M., Fredberg, U., Schougaard, L.M., Hjollund, N.H., Pfeiffer?Jensen, M., Laurberg, T.B., Tarp, U., Lomborg, K. and Maribo, T., 2018. Tele?Health Followup Strategy for Tight Control of Disease Activity in Rheumatoid Arthritis: Results of a Randomized Controlled Trial. Arthritis care & research, 70(3), pp.353-360.
Fleisher, C. S., & Bensoussan, B. E. (2015). Business and competitive analysis: effective application of new and classic methods. FT Press.
Goetsch, D.L. and Davis, S.B., 2014. Quality management for organizational excellence. Upper Saddle River, NJ: pearson.
Gollenia, L.A., 2016. Business transformation management methodology. Routledge.
Greenhalgh, T., Procter, R., Wherton, J., Sugarhood, P., Hinder, S. and Rouncefield, M., 2015. What is quality in assisted living technology? The ARCHIE framework for effective telehealth and telecare services. BMC medicine, 13(1), p.91.
Hair Jr, J. F., Wolfinbarger, M., Money, A. H., Samouel, P., & Page, M. J. (2015). Essentials of business research methods. Routledge.
Hall, J.L. and McGraw, D., 2014. For telehealth to succeed, privacy and security risks must be identified and addressed. Health Affairs, 33(2), pp.216-221.
Hiekata, K., Mitsuyuki, T., Goto, T. and Moser, B.R., 2016, October. Design of Software Development Architecture Comparison of Waterfall and Agile Using Reliability Growth Model. In ISPE TE (pp. 471-480).
Hornstein, H.A., 2015. The integration of project management and organizational change management is now a necessity. International Journal of Project Management, 33(2), pp.291-298.
Kanaane, R., Akabane, G., Peterossi, H. and Endler, D.C.N., 2015. Organizational change management in a strategic perspective. American Journal of Management, 15(2), p.88.
Kaufman, H., 2017. The limits of organizational change. Routledge.
Komai, S., Saidi, H. and Nakanishi, H., 2016. Man-Hour Comparison Between Two Methods of Agile and Waterfall in IT System Development. INNOVATION AND MANAGEMENT, p.1707.
Mahadevan, L., Kettinger, W.J. and Meservy, T.O., 2015. Running on Hybrid: Control Changes when Introducing an Agile Methodology in a Traditional” Waterfall” System Development Environment. CAIS, 36, p.5.
Mitsuyuki, T., Hiekata, K., Goto, T. and Moser, B., 2017. Evaluation of Project Architecture in Software Development Mixing Waterfall and Agile by Using Process Simulation. Journal of Industrial Integration and Management, 2(02), p.1750007.
Serrador, P. and Pinto, J.K., 2015. Does Agile work?—A quantitative analysis of agile project success. International Journal of Project Management, 33(5), pp.1040-1051.
Steinke, G.H., Al-Deen, M.S. and LaBrie, R.C., 2017. NNOVATING INFORMATION SYSTEM DEVELOPMENT METHODOLOGIES WITH DESIGN THINKING. In Proceedings of the 5th International Conference on Applied Innovations in IT (pp. 51-55).
Vijayasarathy, L.R. and Butler, C.W., 2016. Choice of software development methodologies: Do organizational, project, and team characteristics matter?. IEEE Software, 33(5), pp.86-94
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
