Week 5 – Milestone Four

MIS600

Executive Summary

The goal behind the Hospital Electronic Records Application (HERA) is to revolutionize the way we communicate between hospitals, doctors, patients, and health care. Our mission is to create and develop a subscription based access which allows users to access medical records and data instantly on a global platform, and can be accessed via computers, tablets, phones, etc. We believe that there is a high demand for this type of access database, and the need for the ability to incorporate integration with third-party social media. We plan on becoming the new standard for all state and federal medical websites.

There are currently other software products, which has similar features such as electronic heath records, scheduling, and medical billing. HERA is keeping the customer in mind, by providing all of these services, and taking further steps by incorporating other portals (scheduling, inquiries, and consulting). Being that most people spend a majority of their time on applications such as Facebook, Instagram, etc., we feel that this will become the new standard for medical data access. We are also trying to follow all state/federal guidelines and requirements to make our application a better solution, but also more cost effective as we can customize the appearance and use to better suite their needs.

Our growth will be based off being able to work with existing platforms, and being able to migrate existing records into our database, as well as being able to create custom modules if necessary. Our initial funding requirements are targeted at $100K, with sponsorship from a medical based funding project that believes in our idea, providing the initial funding. We have teams in place to provide building and testing of application, focus teams to give input (making sure that our application is complete and all necessary details included), as well as deployment teams towards the final product completion. We also plan on using consulting teams to work closely with different hospitals, doctors, and pharmacies, whom we will offer a significant discount on the final product for their time. Making constant adjustments during the test phase will ensure that we will have the most complete package application before the final release.

Project Charter (Scope Statement)

Project Value Statement

Hospital Electronic Records Application (HERA) is a software application, which is being developed for healthcare systems and healthcare providers across all disciplinarians who are dissatisfied with their current mismatch of technology solutions that are inconvenient to access and lack portability. HERA provides ease of access to patient health records with interoperability features that allows for easier patient management. HERA provides one-stop HIPPA compliant solutions for all patient management needs unlike current solutions that require multiple applications for each hospital/specialty department. HERA also incorporates the patient by adding scheduling and communication platforms.

Our consulting teams work closely with the hospital, doctors and pharmacies gathering necessary process flow input to ensure that our application will be as successful as possible. Once the application is ready to be deployed, our experienced team provides onsite training and support until operations are running smoothly. The largest return on investment (ROI) HERA customers see is patient satisfaction and increased quality of care, while having many processes now being automated. This saves time and money when you do not have to have staff doing it manually. Having healthcare providers communicate directly using our application, whether it’s viewing old lab results or reviewing a patient’s medication list, allows the patient to focus on what they need to do for their health instead of trying to remember all the paperwork and details that may be difficult to retain. Healthcare providers can focus less on trying to translate what the patient is trying to communicate and focus on the facts that are before them.

Project Strategy Statement

Our product, the Hospital Electronic Records Application (HERA) is a subscription-based electronic medical records (EMR) web application, which allows hospitals, doctors, and health care providers, to house, store, and access medical data under one roof. Our objective is become the standard of medical data housing at both the state and government level, allowing access at different levels, depending on the clientele. Our product is unique, as we are incorporating what no other software has, which allows access via different platforms (computers, phones, and tablets). HERA will also allow third-party access (i.e. Facebook, Instagram, etc.) to check/schedule appointments, have doctor visits/meetings via Facetime, as well as fill and check the status of prescriptions online. We figure since most people use social media applications constantly, this will make patients more apt to use the application. Our competitive edge is the value in our product, which can be customized to your needs, at a fraction of the price of our competitor’s software.

With HERA being a web based application (with storage and access using the Cloud), it can be accessed anywhere in the United States, geographically as long as you have Internet access. Focusing on the US side first, we want to be able to provide a complete package within our subscription (rather than offering add on modules), which provides:

Customization if the key to achieving a fully-integrated system that allows your practice to maximize revenue potential, reduce operating costs, and boost operations efficiency and effectiveness. Allowing patients to use this portal to be reminded of appointments, access test results, connect with their insurance providers, and monitor the medical records, will allow the medical process to become more streamlined versus the inconveniences of long telephone calls and medical resources being wasted.

• 24 hour, unlimited access and support
• Application which run on all platforms of software (iOS, Windows)
• Competitive pricing for database storage of your locations medical records, with redundant Cloud server storage and backups to ensure 99.9% uptime
• HIPPA complaint
• E-Prescribing medications
• Efficient and effective solutions for creating custom templates, create practice-specific reports, medical billing.
• Integration alerts, which can notify staff when actions are needed, such as follow-up appointments, pending insurance claims, coordination of special care.

HERA has the potential to improve patient experiences and positively impact cash flow and profit margins for physicians and private practice providers. By providing social media integration, we feel that this will enhance the customer experience and usage, being that people use applications such as Facebook on a daily basis. We feel we will be the pioneers in the social media market, being that we are researching trends, and will target marketing to actual patients who feel that our application will revolutionize the way they seek medical insurance and care at their leisure and convenience. By forecasting these trends, we are ahead of the existing EMR and EHR applications.

Project Methodology

The methodology used for HERA projects will be an agile approach. By releasing a service line at a time, for example, hospitals first, then laboratories and so on, it will enable an incremental roll out process that doesn’t shock current systems. Agile approaches benefits are “ensuring successful completion of a project by adjusting the important resources of time, cost, quality and scope. When these four control variable are properly included in planning, there is a state of balance between the resources and the activities needed to complete the project (Kendall & Kendall, 2013, pg. 11).” Below is a figure that outlines the steps taken during the agile approach to ensure successful implementation of HERA.

Figure 1. Five stages of agile modeling (Kendall & Kendall, 2013, pg. 12)

Business Requirements and Rules

Functional Requirement

User Interface Requirements

• 1.0 Application Access
• The Application will be used by all web users, which can be obtained by, sign up without any cost.
• Application is solely the responsibility of the Medical organization (like Hospital, Pharmacies, LABs, and Healthcare insurance)
• The security method of application is divided into 4 Line group which will be implemented as follows:
• Line I: Head User will be the super user; they will have all the access. This user is entitled to have access to do all updates and modifications to the Application.
• Line II: Admin
• The Admin User is the next level of Head user. They will be eligible to access only when the Head user will approve their ID. The Admin will be able to add or modify some category from the application. This user can remove user posts and ban registered user or regular user.
  • Line III: Registered User
  • These Users are basically the patient who needs medical services from Hospitals, Pharmacies, LABs and Healthcare insurance. But the register used must have a valid account. The Registered User will able to access the personal page, which will show their profile information. They can access the non-restricted area.
  • Line IV: Browsing User.
  • The users who have not registered will be called Browsing User. They can be any person who is browsing the site either registered or not. These users can see the reviews and services of Medical organization but cannot post comments.
  • Each Registered User Home page.
  • These users are the first main user and will have a personalized profile page
  • The profile page will include:
  • Name
  • User Name
  • Email
  • Address
  • Phone Number
  • Membership status (Head User, Admin user, Registered User, User)
  • List of Doctors, Hospital, Lab used in past
  • History of comments on products and categories
  • Your work
  • Alert of upcoming your life Upon registering,
  • These users will become the registered user once they make an account in our Web application by providing information asked above. These Users will be able to update their Name, Email, Address, and Phone and other personal information latter on as well.
  • In case Registered User forgets their login details, they can retrieve or reset the information through their email and Client for support.
  • Registered user are not entitled to open any of the medical organization personal records not the medical reports of any other patients. They can access only their record.
  • Head Users
  • Each head user will be provided their interface, where they can give access to their staff, Head user would be Hospital head of department, Pharmacies Head of Department, LAB Head of Department, Heath Insurance Head of Department
  • They will be able to approve the events, advertisement, camps Promotions, comments, rating.
  • Admin User
  • Each Admin user would be the employee of Head user department and hold a specific ID.
  • This user is able to make, delete and edit the specific category, remove user posts and ban users.
  • These user can interact with other category Admin through this application,
  • Hospital Staff can interact with LAB staff or Pharmacy.
  • Hospital staff can send and receive message to registered user (patient)
  • Lab send and receive reports to Hospital staff
  • 2.0 Landing Page of all users.
  • The Landing page will be same for all 4 types of users:
  • The Landing Page (LP) is the home page of HERA web application.
  • The Landing Page will contain:
  • The logo of HERA
  • Sign in or signup button
  • Search box
  • Category listing (Menu)
  • Application navigation
  • Medical organization information click button
  • About application information
  • Help
  • Sitemap
  • Copyright, Privacy, and Site Usage information.
  • User Sign in Page, when user press on sign in it will ask some information
  • User will enter Username and password
  • Once successful sign in done, the user will be redirected back to the LP. This time on landing page their name will be shown along with the ability to enter their personal profile page.
  • If a login attempt is unsuccessful, the user will get three opportunities to enter a correct username/password combination before the account is locked. If the account is locked, the Application will send an email to the registered email address for the account containing a link to reset the password. The account will remain locked until the user follows that link or a Head User manually unlocks the account.
  • User Signup
  • Users can become Registered Users by clicking on the link to register.
  • To become a Registered User, they must enter their first and last names, gender, age group, zip code, and a valid, confirmable email address.
  • The gender, age group, and zip code will be compiled to track the habits of site usage by demographic.
  • Other information can be collected, as determined by the Client, but will not be required.
  • Once a user has successfully submitted the registration form, they will receive an email with a link. Upon clicking the link, their account will be created (to which they will be automatically redirected), and a confirmation email sent to them.
  • User Personal Page
  • 2.5.1 Here registered used can accept following things
  • Search for any (Doctors, Pharmacy, LAB)
  • Distance ( 5 to 50 miles from registered user Zip code)
  • Rating up to 5 stars
  • Under insurance (yes or no)
  • Make appointment
  • Ask for prescription
  • Get the medical reports
  • Ask to send prescription to the pharmacy within the user Zip code
  • The results will be shown with more refine search option.
  • Head user and Admin User Sign in, these users will get an employee ID and Head Users are allowed to give access to Admin user.
  • Landing Page would be same as registered user only they can see Employee ID there.
  • Check, make edit and cancel appointment
  • Review latest medical research
  • Latest medical books
  • Alert on new or modified law change
  • Interact with other Head user staff
  • Company policies
  • Holidays
  • Events and social Gathering
  • User Signup: These authority is given to the Admin user and Admin User Id or Head user ID will generate
  • User Personal Page
  • Here registered used can accept following things
  • Search for any (Doctors, Pharmacy, LAB and Patient information)
  • Messages from colleagues.
  • Ask, deny and approve requests
  • Advertise the organization
  • Make, edit and cancel the appointment
  • Send prescription to the Pharmacy
  • Receive medical reports from LAB
  • Grant/Deny access to see the medical reports
  • Organize their work
  • Schedule meeting and conferences.
  • Interact with patients and give advices when asked
  • Make groups and approve patient group.
  • Help, Site Map, Legal Information
  • The Help function will include a Frequently Asked Question (FAQ) section, email links to the Client, and tutorials on site usage.
  • The Site Map will give a text and graphical layout of the site.
  • The Legal information will be standard text, provided by the Company and modified by the Client as necessary. The Company shall not be responsible for the content or implications of any posted legal information in the Application.
  • 3.0 Advertising
  • Data Gathering
  • In order to provide statistical analysis to potential Advertisers, the Application will store demographics collected via the registration process, tracked individually for users, and compiled for export to a report format.
  • The Head User of all the Medical organization will make the determination as to whether the information collected will be used as another revenue stream, or kept private.
  • Advertisement display
  • Advertisers will be able to have a logo displayed at the top of each Medical organization page, user profile pages, and site map. Ads will not be shown on the LP, the help page, or any legal information page.
  • That will be displayed on a rotating basis, display frequency to be determined by the Client.
  • On the pages, the ads will also be displayed via a vertical banner on the left-hand side of the page. Other ad locations will be used once the final Application design has been created and reviewed by the Client. However, the Medical Organization must approve additions of more advertisement space, as extra programming time could extend the length and cost of the project.
  • The Client will arrange the method of, collection of, and determination of how Advertisers are chosen and the cost of advertisements.
  • A logo upload method will be created, as well as a page for each Register Advertiser to manage their uploaded logos. Additional functionality on this page will need to be discussed as it could delay the project and incur additional costs.
  • 4.0 Social Networking (Group Page)
  • On each organization page, Registered Users will be able to add information about the services and their feedback. But it must be approved by a Head or a Admin User first.
  • Comments can be made in a review section of each service. Comments made by Registered Users who are in a private group will be shown only if the group Admin allows them to be shown.
  • Ratings for Hospital, Pharmacy, LAB and insurance staff will be shown, as well as all public reviews.
  • Registered Users will be able to create groups, accessible to all invited Registered Users. The groups, by default, will be private. The groups can add various categories and services of their comparison list for discussion.
  • 5.0 Medical Organization and Services pages
  • Services
  • Services will be displayed via a common template.
  • The attributes displayed on each template will be variant, dependent upon the attributes determined for that specific organizational service type.
  • The average rating, number of reviews and a Medical service description will show on the Organization page. The product description, specifications, and attributes can be toggled (made visible or not) on and off.
  • Design
  • Medical Organization Like all Hospitals, Pharmacies, LAB and Health insurance
  • Medical organization services Category pages will display a listing
  • It is based on Medical organization demand.
  • 5.2.3 The service Category pages will show a thumbnail of the products, which will include, rating and number of reviews.

System Interface Requirements

• 6.0 User Interface
• UI will have some navigation and sub-navigation functions.
• 2Have user registration, user login, and user profile pages.
• Methods to retrieve and reset passwords.
• Search the Medical services.
• Check the distance from home and medical organization.
• • 7.0 Volume, Capacity, Performance
  • The Application will be designed to handle numerous simultaneous requests and database transactions. The load handling capability of the web server is the responsibility of the hosting Medical Organization service provider.

Operational Requirement

• 8.0 System Hardware Or Software
• No hardware and software required for this application, It can be run on their own office system, mobile, laptops and Tablets.
• 9.0 Database
• The Application will use a MSSQL (SQL Server) database for all transactions.
• Secured Data (Medical records) of patient.
• 10.0 Security
  • 10.1 ASP.NET security methods and protocol will be implemented within the Application.
  • 11.0 Network
  • Not Applicable
  • 12.0 Platform Specific
  • Not Applicable Operational Requirements

Business Process flow chart

• 13.0 Schedule
• Not Applicable
• 14.0 Support/Help Desk
• Medical organization (like Hospitals, Pharmacies, LABs and Healthcare Insurance) will handle all non-technical support issues at their end.
• HERA will handle all technical issues related to Application functionality.
• Medical organization’s hosting provider will handle all website technical issues.
• The Medical organization will determine, at no cost, which party is responsible for the issue at hand.

Constraints and Assumption

ESTIMATE OF EFFORT

• 15.0 Scope
• If the project scope deviates the document will also be revised. The change in scope must be approved by all partied in order to be included in the implemented product. Any change in scope may increase the project complete date. The Medical organization may also suggest additional changes.
• 16.0 Resource Availability
• The Client will be readily available for questions.
• 2Risks
• No known risks at this time. Open Issues No known issues at this time

Data Design

• All the information is present in Business Proposal for an estimate. Changes may happen and will be reflected here, and may vary from the Business Proposal.
• Planning- 6 hours
• Gather requirements
• Assemble Business and Technical Design Documents Establish
• Schedule
• Programming 57 hours
• Installation of Software
  • Testing
  • Implementation 5 hours
  • Installation of files
  • Post-Implementation System Testing
  • Training 3 hours
  • Document Procedures Demonstrate
  • Application Use
  • Total hours required: 71 hours
  • TECHNICAL DESIGN
  • 17.0 Base Functionality Design
  • 17.1. The data access will be handled by the Data Access layer.
  • 17.2. Business rules will be applied in the Business Rule layer, and the user interface layer will handle user interface information.
  • 17.3.Each layer will be designed to allow overall portability,
  • 17.4.Serializable objects will be created to move the data between the layers.

Process Model

• 18.0 Database Design Parameters
• 19.0 Serialized Objects 19.1 Objects will be used to while moving data between the interface, business and database layers. These objects will be created using and XSD schema. The objects and the source XML will reside on the web server. The directory will contain the source XSD schema as well as the created Serialized object. All serialized objects for this project will be named with the prefix ‘Comp’ to identify them with the Application function of the business.
• Business Processing/Rule Design
• To Be Determined
• Output design
• 20.0 Report Design/Layout
• 21.0 Message Implementation User Interface Design
  • UI Design
  • 22.0 Login
  • System Architecture and Environment
  • 23.0 Application Security Levels
  • 23.1 Application security levels will be created from user input. Security group is predetermined. There will be a password access for sensitive healthcare patients records
  • 23.2 User
  • Everybody will get general access to the Application.
  • 23.3 Registered User
  • 23.3.1 This group will have User access as well as the following functionalities:
  • Post reviews, comments, and attributes
  • Make changes to personal profile
  • Create or join groups
  • 23.4 Admin
  • 23.4.1 This group has Registered User access as well as:
  • Approve/Remove Posts
  • Temporarily ban Registered Users
  • Modify product and category detail
  • 23.5 Head User
  • 23.5.1 This group has Admin access as well as:
  • Modify all content in the content management system
  • Add or remove Admin.
  • Permanently ban any user
  • Restore any user
  • Add new Services.
  • Approve/deny services suggestions

Agile Process Model

The tasks are divided into time boxes or small time frame to deliver specific features for a release. Each project is broken down into many ‘Iterations’, as described in the figure 1. Iteration length should be same between 2 weeks to 8 weeks. The project is broken down into 10 releases they may extend on project demand. We are assuming each iteration period is 4 weeks. Team will select and decide to work on iteration with communication with client and on priority basis. At first iteration will release a working application. At the end of each iteration period, the team will increment and update the features committed to the client.

Figure 1

Work Flow

Application Process Activities

• Communication with client
• Requirement Identification
• Feasibility Check
• Requirement Analyzing
• Make of design
• Developing the software
• Testing the developed software
  • If customer is satisfied and application is free of error the Implement it otherwise repeat all the steps

The application model is understandable, visible and supportable.

Constrains

• Specification
• Development
• Validation
• Evolution
• Requirement of web application
• Evolve to application medium from informational medium.
• Lead to short development time.
  • Get own development process model
  • Adoption of software engineering process model
  • Using short development cycle, because time is less and have to capture market fast.
  • Systematic development process
  • Handling change in requirement, due to unstable, critical and new emerging requirement, and to understand unknown business.
  • Lead the integration issues
  • Phases of Process Model
  • Step 1: Creation of Product Backlog
  • Must include
  • Importance of a user story.
  • Initial estimate
  • How to demo.
  • May include
  • Track
  • Components
  • Requestor
  • Bug Tracking ID
  • Step 2: Sprint Planning and Sprint Backlog Creation
  • Sprint Duration (not more than 2 weeks)
  • Release working application
  • Client Feedback
  • Cooperation between stakeholders and team members.
  • Defines the appropriate labor costs.
  • Select the most important user stories
  • Solve user story
  • Working on the Sprint. Scrum Meetings
  • (As shown in the figure 2)
  • Track the current working process
  • Everyday Scrum meetings
  • Burn down chart
  • X-axis representation and Y-axis display with JIRA
  • Draw conclusions about the current speed of work
  • Step 4: Testing and Product Demonstration
  • The team creates a review and demonstrates the results of their work. On this basis the stakeholders take a decision about further project changes.
  • Step 5: Retrospective and Next Sprint Planning
  • Discuss the results and determine the ways how to improve development process
  • Team conclusion

Recourses required

• Carefully identification of requirement
• Check the feasibility and suitability of project in terms of software hardware requirement cost and time.

Logical Entity Relationship Diagram

• People
• Software
• Hardware
• Equipment’s
• Time
• Money

Physical Entity Relationship Diagram

UML Use Case Diagram

UML Sequence Diagram for Use Cases

UML Class Diagram

System Alternatives Assessment

Technical Requirements & Assumptions

Technical Assumption

Technical Requirement

• Cross-browser /platform support (IE, Firefox, Chrome, Safari – PC and Mac)
• Mobile support (for advanced smartphones – iPhone, iPad, Android or when possible for older text based phones). We will let the chosen system that meets all other criteria best, set our minimum level of device support.
• System will allow changes to minimum and maximum reservation times.
• To support user id authentication
• For locally hosted solutions
• Acceptable level of documentation for user
• Robust development community, reputation, or customer supplied support.
  • Statistics and reporting.
  • The system should be built using free open source software (FOSS) if locally hosted.
  • If hosted, the system should be built using an application framework, rather than a hard-coded. This will help the programmers to account for differences in operating systems, interfaces and displays.

Databases: MS SQL, ORACLE, and MySQL

Content and Document Management Systems: SharePoint 2013, Drupal 7

Configuration and change management tools: MS Visual Studio Team foundation

Programing languages and frameworks: Java, J2EE, ASP. NET, Struts, Hibernate, XML, PHP,

SQL, PL/SQL, JavaScript, R, SPSS

Web and application servers: Apache, MS IIS, ORACLE (BEA) Web Logic

Collaboration and portal technologies: MS SharePoint 2013

Business Intelligence & Reporting: MS Reporting services, SpagoBI and Jasper reports

Survey tools: Lime survey

Statistics tools: Google Urchin, Piwik

Office tools: Microsoft Office 2013, Adobe CS 6,

Operating systems: Windows 8.1, Windows Server 2012, and Linux

Back office tools: MS System Center (SCCM), MS Data Protection Manager (DPM).

Access Requirements

Our main clients are Head users and Admin users they are subscribed customers are applicable to create, edit and delete the application display message.

Users who will access the application are:

Head users (Subscribed users)

Admin Users (Subscribed users)

Registered Users (Free users)

Browsing Users (Free users)

Analysis of Needs vs. Capabilities for Contractors

Two local hospitals have opted to test HERA as their medical record solution to help their patients have the capability to access their medical records and make appointments and checkups. Our two test hospitals, we will call “X” and “Z”, have been keeping their records on a localized database server. They have no remote online access (to doctors, health care providers, or patients), and often have problems running queries. Both hospitals feel that they feel they have too much clerical staff, non-productive work procedures, and constant mistakes when accessing records and setting up appointments with their current database. Implementing the proper (or updating current) hardware, and making sure that each location has the proper firewalls and security software, HERA will bring vast improvements in the hospitals methodology, and give Internet capabilities.

In order for HERA to be successful, the following requirements must be made:

Both hospitals will have a project management team, which will work with Sean Takeda, directly, and collaboratively, to make sure that

Reference

IV.C.2f-3 International Dairy Agreement (without Annex) (15 April 1994). (n.d.). International Law & World Order, 1-6. doi:10.1163/ilwo-ivc2f-3

ALATechSource Follow. (2012, September 12). Sample Project Requirements Document – Library Blog. Retrieved February 02, 2018, from https://www.slideshare.net/ALATechSource/sample-project-requirements-document-library-blog

Joshua Flewelling, Developer at Smartbox IT Solutions Follow. (2009, January 28). Project Business Requirements Document. Retrieved February 02, 2018, from https://www.slideshare.net/joshuaflewelling/Smartbox-IT-Solutions-BusinessTechnical-Design

Business Process Modeling Approaches and Diagrams. (n.d.). Systems Analysis & Design Fundamentals: A Business Process Redesign Approach, 79-106. doi:10.4135/9781452224794.n5

http://www.conceptdraw.com/samples/resource/images/solutions/business-process-diagrams/BUSINESS-PROCESS-DIAGRAMS-Business-Process-Application-Development-Process.png

Gurendo, D. (2018, January 25). Scrum Methodology Phases which Help in Agile SDLC Process: 5 Key Steps. Retrieved February 02, 2018, from https://xbsoftware.com/blog/software-development-life-cycle-sdlc-scrum-step-step/

Ashok Mohanty, Reader at College of Engineering and Technology, Bhubaneswar Follow. (2012, September 29). Software development, process model, requirement engineering, srs, st… Retrieved January 27, 2018, from https://www.slideshare.net/amohanty01/software-engineering-14515160?qid=27c06a2c-ceb3-4873-b8fd-d7c4a55ee4b6&v=&b=&from_search=4

Udemy Follow. (2017, September 15). Lecture-2: Web development application development process model. Retrieved January 27, 2018, from https://www.slideshare.net/mubashiragujjar/lecture2-web-development-application-development-process-model?qid=27c06a2c-ceb3-4873-b8fd-d7c4a55ee4b6&v=&b=&from_search=22

Software Engineering Process Models by Computer Education for all Unit 2. (2015, October 15). Retrieved January 27, 2018, from https://www.youtube.com/watch?v=kwsKr1MObxs

Home. (n.d.). Retrieved January 27, 2018, from http://istqbexamcertification.com/what-is-agile-methodology-examples-when-to-use-it-advantages-and-disadvantages/

Eichberg, M. (n.d.). Figure 2f from: Irimia R, Gottschling M (2016) Taxonomic revision of Rochefortia Sw. (Ehretiaceae, Boraginales). Biodiversity Data Journal 4: e7720. https://doi.org/10.3897/BDJ.4.e7720. Introduction to Software Engineering. doi:10.3897/bdj.4.e7720.figure2f

https://stg-tud.github.io/eise/WS11-EiSE-12-Software_Process_Models.pdf

(2018, January 12). Retrieved January 27, 2018, from https://docs.servicenow.com/bundle/kingston-it-business-management/page/product/agile-development/concept/agile-development-process-flow.html

Mostafa, S. (2013) e-health card diagram. Retrieved from: https://creately.com/diagram/example/hdwjt0aw/E-Health%20Card