Software Development Model (LeeAnn and Andrea to further develop)
Phase 1. Requirements collection - Goal: to gather and document business requirements
Develop user stories for what you WANT the software to do
Gather Business Requirements and create a Charter, based on NACHC template and including stakeholders, assumptions, high-level system requirements
Phase 2. Design - Goal: to translate software development requirements into design
Write Software Requirements Document (see Table 1)
Phase 3. Software development -Goal: To build the actual software
Phase 4. Testing - Goal: To ensure the software meets requirements
Phase 5. Deployment - Goal: To deliver completed software to users
Phase 6: Continuous Improvement - Goal: To add, revise, improve functionality per user needs
Table 1
Image Added
Date:
Andrea and LeeAnne
We each know what the other is thinking for software development process and user acceptance testing.
We have identified any needs/gaps in knowledge (should UAT be designed by or done by a consultant? HealthFlow does not have this strength).
Assignment – watch 1-2 videos from Linked in Learning or read a web site that explains the process of UAT.
Date:
Possible discussion topics:
Review Kathy’s comments
Discuss typical software development process - what we do, what HealthFlow does, where to find information.
Andrea ask LeeAnn for help with questionnaire
Discuss learnings from LinkedIn Learning and web research (see notes below)
Invite Sarah P to talk about what she would do differently and critique the plan?
Andrea’s notes and thoughts prompted by Linked In Learning
There is a standard software development process. HealthFlow takes direction from us, but we are not equipped, experienced, or using a traditional software development process on our end. Example of STEVE (State and Territorial Exchange of Vital Events) -I managed a major overhaul and was guided through the process by the software developers. There is a whole process starting with requirements gathering. LeeAnn dis-covered that in her thinking process, i.e., asking potential users what they want rather than starting with what we think they need.
