PG 175 to 187
CHAPTER 9: Systems Development Life Cycle: Nursing Informatics and Organizational Decision Making
CHAPTER 9: Systems Development Life Cycle: Nursing Informatics and Organizational Decision Making
Permalink: https://eaziessay.com/chapter-9-system…-decision-making/
Dee McGonigle and Kathleen Mastrian
Objectives
1. Describe the systems development life cycle (SDLC).
2. Explore selected approaches to SDLC.
3. Assess interoperability and its importance in addressing and meeting the challenges of implementing the HITECH Act in health care.
4. Reflect on the past to move forward into the future to determine how new systems will be developed, integrated, and made interoperable in health care.
Key Terms
· » Computer-aided software engineering
· » Dynamic system development method
· » Health management information system
· » Hospital information system
· » MoSCoW
· » Object-oriented systems development
· » Rapid application development
· » Systems development life cycle
Introduction
The following case scenario demonstrates the need to have all of the stakeholders involved from the beginning to the end of the systems development life cycle (SDLC). Creating the right team to manage the development is key. Various methodologies have been developed to guide this process. This chapter reviews the following approaches to SDLC: waterfall, rapid prototyping or rapid application development (RAD), object-oriented system development (OOSD), and dynamic system development method (DSDM). When reading about each approach, think about the case scenario and how important it is to understand the specific situational needs and the various methodologies for bringing a system to life. As in this case, it is generally necessary or beneficial to use a hybrid approach that blends two or more models for a robust development process.
As the case demonstrates, the process of developing systems or SDLC is an ongoing development with a life cycle. The first step in developing a system is to understand the problems or business needs. It is followed by understanding the solution or how to address those needs; developing a plan; implementing the plan; evaluating the implementation; and, finally, maintenance, review, and destruction. If the system needs major upgrading outside of the scope of the maintenance phase, if it needs to be replaced because of technological advances, or if the business needs change, a new project is launched, the old system is destroyed, and the life cycle begins anew.
SDLC is a way to deliver efficient and effective information systems (ISs) that fit with the strategic business plan of an organization. The business plan stems from the mission of the organization. In the world of health care, its development includes a needs assessment for the entire organization, which should include outreach linkages (as seen in the case scenario) and partnerships and merged or shared functions. The organization’s participating physicians and other ancillary professionals and their offices are included in thorough needs assessments. When developing a strategic plan, the design must take into account the existence of the organization within the larger healthcare delivery system and assess the various factors outside of the organization itself, including technological, legislative, and environmental issues that impact the organization. The plan must identify the needs of the organization as a whole and propose solutions to meet those needs or a way to address the issues.
CASE SCENARIO
Envision two large healthcare facilities that merge resources to better serve their community. This merger is called the Wellness Alliance, and its mission is to establish and manage community health programming that addresses the health needs of the rural, underserved populations in the area. The Wellness Alliance would like to establish pilot clinical sites in five rural areas to promote access and provide health care to these underserved consumers. Each clinical site will have a full-time program manager and three part-time employees (a secretary, a nurse, and a doctor). Each program manager will report to the wellness program coordinator, a newly created position within the Wellness Alliance.
Because you are a community health nurse with extensive experience, you have been appointed as the wellness program coordinator. Your directive is to establish these clinical sites within 3 months and report back in 6 months as to the following: (1) community health programs offered, (2) level of community involvement in outreach health programs and clinical site–based programming, (3) consumer visits made to the clinical site, and (4) personnel performance.
You are excited and challenged, but soon reality sets in: You know that you have five different sites with five different program managers. You need some way to gather the vital information from each of them in a similar manner so that the data are meaningful and useful to you as you develop your reports and evaluate the strengths and weaknesses of the pilot project. You know that you need a system that will handle all of the pilot project’s information needs.
Your first stop is the chief information officer of the health system, a nurse informaticist. You know her from the health management information system mini-seminar that she led. After explaining your needs, you share with her the constraint that this system must be in place in 3 months when the sites are up and running before you make your report. When she begins to ask questions, you realize that you do not know the answers. All you know is that you must be able to report on which community health programs were offered, track the level of community involvement in outreach health programs and clinical site–based programming, monitor consumer visits made to the clinical site, and monitor the performance of site personnel. You know that you want accessible, real-time tracking, but as far as programming and clinical site–related activities are concerned, you do not have a precise description of either the process or procedures that will be involved in implementing the pilot, or the means by which they will gather and enter data.
The chief information officer requires that you and each program manager remain involved in the development process. She assigns an information technology (IT) analyst to work with you and your team in the development of a system that will meet your current needs. After the first meeting, your head is spinning: The IT analyst has challenged your team not only to work out the process for your immediate needs, but also to envision what your needs will be in the future. At the next meeting, you tell the analyst that your team does not feel comfortable trying to map everything out at this point. He states that there are several ways to go about building the system and software by using the SDLC. Noticing the blank look on everyone’s faces, he explains that the SDLC is a series of actions used to develop an IS. The SDLC is similar to the nursing process, in which the nurse must assess, diagnose, plan, implement, evaluate, and revise. If the plan developed in this way does not meet the patient’s need or if a new problem arises, the nurse either revises and updates the plan or starts anew. Likewise, you will plan, analyze, design, implement, operate, support, and secure the proposed community health system.
The SDLC is an iterative process—a conceptual model that is used in project management describing the phases involved in building or developing an IS. It moves from assessing feasibility or project initiation, to design analysis, to system specification, to programming, to testing, to implementation, to maintenance, and to destruction—literally from beginning to end. As the IT analyst describes this process, once again he sees puzzled looks. He quickly states that even the destruction of the system is planned—that is, how it will be retired, broken down, and replaced with a new system. Even during upgrades, destruction tactics can be invoked to secure the data and even decide if servers are to be disposed of or repurposed. The security people will tell you that this is their phase, where they make sure that any sensitive information is properly handled and decide whether the data are to be securely and safely archived or destroyed.
After reviewing all of the possible methods and helping you to conduct your feasibility and business study, the analyst chooses the DSDM. This SDLC model was chosen because it works well when the time span is short and the requirements are fluctuating and mainly unknown at the outset. The IT analyst explains that this model works well on tight schedules and is a highly iterative and incremental approach that stresses continuous user input and involvement. As part of this highly iterative process, the team will revisit and loop through the same development activities numerous times; this repetitive examination provides ever-increasing levels of detail, thereby improving accuracy. The analyst explains that you will use a mockup of the hospital information system (HIS) and design for what is known; you will then create your own mini-system that will interface with the HIS. Because time is short, the analysis, design, and development phases will occur simultaneously while you are formulating and revising your specific requirements through the iterative process so that they can be integrated into the system.
The functional model iteration phase will be completed in 2 weeks based on the information that you have given to the analyst. At that time, the prototype will be reviewed by the team. The IT analyst tells you to expect at least two or more iterations of the prototype based on your input. You should end with software that provides some key capabilities. Design and testing will occur in the design and build iteration phase and continue until the system is ready for implementation, the final phase. This DSDM should work well because any previous phase can be revisited and reworked through its iterative process.
One month into the SDLC process, the IT analyst tells the team that he will be leaving his position at Wellness Alliance. He introduces his replacement. She is new to Wellness Alliance and is eager to work with the team. The initial IT analyst will be there 1 more week to help the new analyst with the transition. When he explains that you are working through DSDM, she looks a bit panicky and states that she has never used this approach. She has used the waterfall, prototyping, iterative enhancement, spiral, and object-oriented methodologies—but never the DSDM. From what she heard, DSDM is new and often runs amok because of the lack of understanding as to how to implement it appropriately. After 1 week on the project, the new IT analyst believes that this approach was not the best choice. As the leader of this SDLC, she is growing concerned about having a product ready at the point when the clinical sites open. She might combine another method to create a hybrid approach with which she would be more comfortable; she is thinking out loud and has everyone very nervous.
The IT analyst reviews the equipment that has arrived for the sites and is excited to learn that the computers were ordered from Apple. They will be powerful and versatile enough for your needs.
Two months after the opening of the clinical sites, you, as the wellness program coordinator are still tweaking the system with the help of the IT analyst. It is hard to believe how quickly the team was able to get a robust system in place. As you think back on the process, it seems so long ago that you reviewed the HIS for deficiencies and screen shots. You reexamined your requirements and watched them come to life through five prototype iterations and constant security updates. You trained your personnel on its use, tested its performance, and made final adjustments before implementation. Your own stand-alone system that met your needs was installed and fully operational on the Friday before you opened the clinic doors on Monday, 1 day ahead of schedule. You are continuing to evaluate and modify the system, but that is how the SDLC works: It is never finished, but rather constantly evolving.
SDLC can occur within an organization, be outsourced, or be a blend of the two approaches. With outsourcing, the team hires an outside organization to carry out all or some of the development. Developing systems that truly meet business needs is not an easy task and is quite complex. Therefore, it is common to run over budget and miss milestones. When reading this chapter, reflect on the case scenario and in general the challenges teams face when developing systems.
CHAPTER 9: Systems Development Life Cycle: Nursing Informatics and Organizational Decision Making
Waterfall Model
The waterfall model is one of the oldest methods and literally depicts a waterfall effect—that is, the output from each previous phase flows into or becomes the initial input for the next phase. This model is a sequential development process in that there is one pass through each component activity from conception or feasibility through implementation in a linear order. The deliverables for each phase result from the inputs and any additional information that is gathered. There is minimal or no iterative development where one takes advantage of what was learned during the development of earlier deliverables. Many projects are broken down into six phases ( Figure 9-1 ), especially small- to medium-size projects.
Figure 9-1 Waterfall Phases
Feasibility
As the term implies, the feasibility study is used to determine whether the project should be initiated and supported. This study should generate a project plan and estimated budget for the SDLC phases. Often, the TELOS strategy —technological and systems, economic, legal, operational, and schedule feasibility—is followed. Technological and systems feasibility addresses the issues of technological capabilities, including the expertise and infrastructure to complete the project. Economic feasibility is the cost–benefit analysis, weighing the benefits versus the costs to determine whether the project is fiscally possible and worth undertaking. Formal assessments should include return on investment. Legal feasibility assesses the legal ramifications of the project, including current contractual obligations, legislation, regulatory bodies, and liabilities that could affect the project. Operational feasibility determines how effective the project will be in meeting the needs and expectations of the organization and actually achieving the goals of the project or addressing and solving the business problem. Schedule feasibility assesses the viability of the time frame, making sure it is a reasonable estimation of the time and resources necessary for the project to be developed in time to attain the benefits and meet constraints. TELOS helps to provide a clear picture of the feasibility of the project.
Analysis
During the analysis phase, the requirements for the system are teased out from a detailed study of the business needs of the organization. As part of this analysis, work flows and business practices are examined. It may be necessary to consider options for changing the business process.
Design
The design phase focuses on high- and low-level design and interface and data design. At the high-level phase, the team establishes which programs are needed and ascertains how they will interact. At the low-level phase, team members explore how the individual programs will actually work. The interface design determines what the look and feel will be or what the interfaces will look like. During data design, the team critically thinks about and verifies which data are required or essential.
The analysis and design phases are vital in the development cycle, and great care is taken during these phases to ensure that the software’s overall configuration is defined properly. Mockups or prototypes of screenshots, reports, and processes may be generated to clarify the requirements and get the team or stakeholders on the same page, limiting the occurrence of glitches that might result in costly software development revisions later in the project.
Implement
During this phase, the designs are brought to life through programming code. The right programming language, such as C++, Pascal, Java, and so forth, is chosen based on the application requirements.
Test
The testing is generally broken down into five layers: (1) the individual programming modules, (2) integration , (3) volume, (4) the system as a whole, and (5) beta testing. Typically, the programs are developed in a modular fashion, and these individual modules are then subjected to detailed testing. The separate modules are subsequently synthesized, and the interfaces between the modules are tested. The system is evaluated with respect to its platform and the expected amount or volume of data. It is then tested as a complete system by the team. Finally, to determine if the system performs appropriately for the user, it is beta tested. During beta testing, users put the new system through its paces to make sure that it does what they need it to do to perform their jobs.
Maintain
Once the system has been finalized from the testing phase, it must be maintained. This could include user support through actual software changes necessitated through use or time.
According to Isaias and Issa ( 2015 ), “one common trait covers all the variations of this model: It is a sequential model. Each of its stages must be entirely concluded before the next can begin” (p. 23). The main lack of iterative development is seen as a major weakness, according to Purcell ( 2007 ). No projects are static, and typically changes occur during the SDLC. As requirements change, there is no way to address them formally using the waterfall method after project requirements are developed. The waterfall model should be used for simple projects when the requirements are well known and stable from the outset.
Rapid Prototyping or Rapid Application Development
As technology advances and faster development is expected, rapid prototyping , also known as rapid application development (RAD), provides a fast way to add functionality through prototyping and user testing. It is easier for users to examine an actual prototype rather than documentation. A rapid requirements-gathering phase relies on workshops and focus groups to build a prototype application using real data. This prototype is then beta tested with users, and their feedback is used to perfect or add functionality and capabilities to the system ( Figure 9-2 ).
Figure 9-2 Rapid Application Development (RAD) or Rapid Prototyping
According to Alexandrou ( 2016 ), “RAD (rapid application development) proposes that products can be developed faster and of higher quality” (para. 1). The RAD approach uses informal communication, repurposes components, and typically follows a fast-paced schedule. Object-oriented programming using such languages as C++ and Java promotes software repurposing and reuse.
The major advantage is the speed with which the system can be deployed; a working, usable system can be built within 3 months. The use of prototyping allows the developers to skip steps in the SDLC process in favor of getting a mockup in front of the user. At times, the system may be deemed acceptable if it meets a predefined minimum set of requirements rather than all of the identified requirements. This rapid deployment also limits the project’s exposure to change elements. Unfortunately, the fast pace can be its biggest disadvantage in some cases. Once one is locked into a tight development schedule, the process may be too fast for adequate testing to be put in place and completed. The most dangerous lack of testing is in the realm of security.
The RAD approach is chosen because it builds systems quickly through user-driven prototyping and adherence to quick, strict delivery milestones . This approach continues to be refined and honed, and other contemporary manifestations of RAD continue to emerge in the agile software development realm.
Object-Oriented Systems Development
The object-oriented systems development model blends SDLC logic with object-oriented modeling and programming power ( Stair & Reynolds, 2016 ). Object-oriented modeling makes an effort to represent real-world objects by modeling the real-world entities or things (e.g., clinic, patient, account, nursing or healthcare professional) into abstract computer software objects. Once the system is object oriented, all of the interactions or exchanges take place between or among the objects. The objects are derived from classes, and each object is comprised of data and the actions that can be enacted on that data. Class hierarchy allows objects to inherit characteristics or attributes from parent classes, which fosters object reuse, resulting in less coding. The object-oriented programming languages, such as C++ and Java, promote software repurposing and reuse. Therefore, the class hierarchy must be clearly and appropriately designed to reap the benefits of this SDLC approach, which uses object-oriented programming to support the interactions of objects.
For example, in the case scenario, a system could be developed for the Wellness Alliance to manage the community health programming for the clinic system being set up for outreach. There could be a class of programs, and well-baby care could be an object in the class of programs; programs is a relationship between Wellness Alliance and well-baby care. The program class has attributes, such as clinic site, location address, or attendees or patients. The relationship itself may be considered an object having attributes, such as pediatric programs. The class hierarchy from which all of the system objects are created with resultant object interactions must be clearly defined.
The OOSD model is a highly iterative approach. The process begins by investigating where object-oriented solutions can address business problems or needs, determining user requirements, designing the system, programming or modifying object modeling (class hierarchy and objects), implementing, user testing, modifying, and reimplementing the system, and ends with the new system being reviewed regularly at established intervals and modifications being made as needed throughout its life.
Permalink: https://eaziessay.com/chapter-9-system…-decision-making/
Dynamic System Development Method
The dynamic system development method is a highly iterative and incremental approach with a high level of user input and involvement. The iterative process requires repetitive examination that enhances detail and improves accuracy. The DSDM has three phases: (1) preproject, (2) project life cycle (feasibility and business tudies, functional model iteration, design and build iteration, and implementation), and (3) postproject.
In the preproject phase, buy-in or commitment is established and funding is secured. This helps to identify the stakeholders (administration and end users ) and gain support for the project. In the second phase, the project’s life cycle begins. This phase includes five steps: (1) feasibility, (2) business studies, (3) functional model iteration, (4) design and build iteration, and (5) implementation ( Figure 9-3 ).
Figure 9-3 Dynamic System Development Method (DSDM)
Copyright 2014 Agile Business Consortium Limited. Reproduced by kind permission.
In steps 1 and 2, the feasibility and business studies are completed. The team ascertains if this project meets the required business needs while identifying the potential risks during the feasibility study. In step 1, the deliverables are a feasibility report, project plan, and a risk log. Once the project is deemed feasible, step 2, the business study, is begun. The business study extends the feasibility report by examining the processes, stakeholders, and their needs. It is important to align the stakeholders with the project and secure their buy-in because it is necessary to have user input and involvement throughout the entire DSDM process. Therefore, bringing them in at the beginning of the project is imperative.
Using the MoSCoW approach, the team works with the stakeholders to develop a prioritized requirements list and a development plan. MoSCoW stands for “Must have, Should have, Could have, and Would have.” The “must have” requirements are needed to meet the business needs and are critical to the success of the project. “Should have” requirements are those that would be great to have if possible, but the success of the project does not depend on them being addressed. The “could have” requirements are those that would be nice to have met, and the “would have” requirements can be put off until later; these may be undertaken during future developmental iterations. Timeboxing is generally used to develop the project plan. In timeboxing, the project is divided into sections, each having its own fixed budget and dates or milestones for deliverables. The MoSCoW approach is then used to prioritize the requirements within each section; the requirements are the only variables because the schedule and budget are set. If a project is running out of time or money, the team can easily omit the requirements that have been identified as the lowest priority to meet their schedule and budget obligations. This does not mean that the final deliverable, the actual system, would be flawed or incomplete. Instead, because the team has already determined the “must have” or “should have” items, it still meets the business needs. According to Haughey ( 2010 ), the 80/20 rule, or Pareto principle, can be applied to nearly everything. The Pareto principle states that 80% of the project comes from 20% of the system requirements; therefore, the 20% of requirements must be the crucial requirements or those with the highest priority. One also must consider the pancake principle: The first pancake is not as good as the rest, and one should know that the first development will not be perfect. This is why it is extremely important to clearly identify the “must have” and “should have” requirements.
In the third step of the project life cycle phase, known as functional model iteration, the deliverables are a functional model and prototype ready for user testing. Once the requirements are identified, the next step is to translate them into a functional model with a functioning prototype that can be evaluated by users. This could take several iterations to develop the desired functionality and incorporate the users’ input. At this stage, the team should examine the quality of the product and revise the list requirements and risk log. The requirements are adjusted, the ones that have been realized are deleted, and the remaining requirements are prioritized. The risk log is revised based on the risk analysis completed during and after prototype development.
The design and build iteration step focuses on integrating functional components and identifying the nonfunctional requirements that need to be in the tested system. Testing is crucial; the team will develop a system that the end users can safely use on a daily basis. The team will garner user feedback and generate user documentation. These efforts provide this step’s deliverable, a tested system with documentation for the next and final phase of the development process.
In the final step of the project life cycle phase, known as implementation, deliverables are the system (ready to use), documentation, and trained users. The requirements list should be satisfied, along with the users’ needs. Training users and implementing the approved system is the first part of this phase, and the final part consists of a full review. It is important to review the impact of the system on the business processes and to determine if it addressed the goals or requirements established at the beginning of the project. This final review determines if the project is completed or if further development is necessary. If further development is needed, preceding phases are revisited. If the project is complete and satisfies the users, then it moves into maintenance and ongoing development.
The final phase is labeled “postproject.” In this phase, the team verifies that the system is functioning properly. Once verified, the maintenance schedule is begun. Because the DSDM is iterative, this postproject phase is seen as ongoing development and any of the deliverables can be refined. This is what makes the DSDM such an iterative development process.
DSDM is one of an increasing number of agile methodologies being introduced, such as Scrum and Extreme Programming. These new approaches address the organizational, managerial, and interpersonal communication issues that often bog down SDLC projects. Empowerment of teams and user involvement enhance the iterative and programming strengths provided in these SDLC models.
Computer-Aided Software Engineering Tools
When reviewing SDLC, the computer-aided software engineering (CASE) tools that will be used must be described.
CASE tools promote adherence to the SDLC process since they automate several required tasks; this provides standardization and thoroughness to the total systems development method ( Stair & Reynolds, 2016 ). These tools help to reduce cost and development time while enriching the quality of the product. CASE tools contain a repository with information about the system: models, data definitions, and references linking models together. They are valuable in their ability to make sure the models follow diagramming rules and are consistent and complete.
The various types of tools can be referred to as upper-CASE tools or lower-CASE tools. The upper-CASE tools support the analysis and design phases, whereas the lower-CASE tools support implementation. The tools can also be general or specific in nature, with the specific tools being designed for a particular methodology.
Two examples of CASE tools are Visible Analyst and Rational Rose. According to Andoh-Baidoo, Kunene, and Walker ( 2009 ), Visible Analyst “supports structured and object-oriented design (UML),” whereas Rational Rose “supports solely object-oriented design (UML)” (p. 372). Both tools can “build and reverse database schemas for SQL and Oracle” and “support code generation for pre-.NET versions of Visual Basic” (p. 372). Visible Analyst can also support shell code generation for pre-.NET versions of C and COBOL, whereas Rational Rose can support complete code for C++ and Java. In addition, Andoh-Baidoo et al. found that Rational Rose “[p]rovides good integration with Java, and incorporates common packages into class diagrams and decompositions through classes” (p. 372).
CASE tools have many advantages, including decreasing development time and producing more flexible systems. On the down side, they can be difficult to tailor or customize and use with existing systems.
Open Source Software and Free/Open Source Software
Another area that must be discussed with SDLC is open source software (OSS). An examination of job descriptions or advertisements for candidates shows that many ISs and IT professionals need a thorough understanding of SDLC and OSS development tools (e.g., PHP, MySQL, and HTML). With OSS, any programmer can implement, modify, apply, reconstruct, and restructure the rich libraries of source codes available from proven, well-tested products.
As Karopka, Schmuhl, and Demski ( 2014 ) noted,
Free/Libre Open Source Software (FLOSS) has been successfully adopted across a wide range of different areas and has opened new ways of value creation. Today there are hundreds of examples of successful FLOSS projects and products. . . . Especially in times of financial crisis and austerity the adoption of FLOSS principles opens interesting alternatives and options to tremendously lower total cost of ownership (TCO) and open the way for a continuous user-driven improvement process. (para. 6)
To transform health care, it is necessary for clinicians to use information systems that can share patient data ( Goulde & Brown, 2006 ; NORC, 2014 ). This all sounds terrific and many people wonder why it has not happened yet, but the challenges are many. How does one establish the networks necessary to share data between and among all healthcare facilities easily and securely? “Healthcare IT is beginning to adopt open source software to address these challenges” (Goulde & Brown, p. 4). Early attempts at OSS ventures in the healthcare realm failed because of a lack of support or buy-in for sustained effort, technologic lags, authority and credibility, and other such issues. “Spurred by a greater sense of urgency to adopt IT, health industry leaders are showing renewed interest in open source solutions” (Goulde & Brown, p. 5).
Karopka et al., ( 2014 ) concluded that
North America has the longest tradition in applying FLOSS-HC delivery. It is home of many mature, stable and widely disseminated FLOSS applications. Some of them are even used on a global scale. The deployment of FLOSS systems in healthcare delivery is comparatively low in Europe. (para. 48)
Health care is realizing the benefits of FLOSS. According to Goulde and Brown ( 2006 ), “other benefits of open source software—low cost, flexibility, opportunities to innovate—are important but independence from vendors is the most relevant for health care” (p. 10).
Interoperability
Interoperability , the ability to share information across organizations, will remain paramount under the HITECH Act. The ability to share patient data is extremely important, both within an organization and across organizational boundaries ( Figure 9-4 ).
Figure 9-4 Interoperability
According to the Health Information and Management Systems Society (HIMSS; Murphy, 2015 ), “an acceptable 2015 [interoperability standards] Advisory and more complete 2016 Advisory will not be achievable without the inclusion of health IT security standards” (para. 4). Few healthcare systems take advantage of the full potential of the current state of the art in computer science and health informatics ( HIMSS, 2010 ). The consequences of this situation include a drain on financial resources from the economy, the inability to truly mitigate the occurrence of medical errors, and a lack of national preparedness to respond to natural and manmade epidemics and disasters. HIMSS has created the Integration and Interoperability Steering Committee to guide the industry on allocating resources to develop and implement standards and technology needed to achieve interoperability (para. 2).
As we enter into SDLCs, we must be aware of how this type of development will affect both our own healthcare organization and the healthcare delivery system as a whole. In an ideal world, we would all work together to create systems that are integrated within our own organization while having the interoperability to cross organizational boundaries and unite the healthcare delivery system to realize the common goal of improving the quality of care provided to consumers.
Summary
At times during the SDLC, new information affects the outputs from earlier phases; the development effort may be reexamined or halted until these modifications can be reconciled with the current design and scope of the project. At other times, teams are overwhelmed with new ideas from the iterative SDLC process that result in new capabilities or features that exceed the initial scope of the project. Astute team leaders will preserve these ideas or initiatives so they can be considered at a later time. The team should develop a list of recommendations to improve the current software when the project is complete. This iterative and dynamic exchange makes the SDLC robust.
As technology and research continue to advance, new SDLC models are being pioneered and revised to enhance development techniques. The interpretation and implementation of any model selected reflect the knowledge and skill of the team applying the model. The success of the project is often directly related to the quality of the organizational decision making throughout the project—that is, how well the plan was followed and documented. United efforts to create systems that are integrated and interoperable will define the future of health care.
CHAPTER 9: Systems Development Life Cycle: Nursing Informatics and Organizational Decision Making
THOUGHT-PROVOKING QUESTIONS
1. Reflect on the SDLC in relation to the quality of the organizational decision making throughout the project. What are some of the major stumbling blocks faced by healthcare organizations?
2. Why is it important for all nurses and healthcare professionals to understand the basics of how information systems are selected and implemented?
References
1. Alexandrou, M. (2016). Rapid application development (RAD) methodology. Infolific. Retrieved from http://www.infolific.com/technology/methodologies/rapid-application-development
2. Andoh-Baidoo, F., Kunene, K., & Walker, R. (2009). An evaluation of CASE tools as pedagogical aids in software development courses. 2009 SWDSI Proceedings. Retrieved from http://www.swdsi.org/swdsi2009/Papers/9K10.pdf
3. Goulde, M., & Brown, E. (2006). Open source software: A primer for health care leaders. Protocode. Retrieved from http://www.protecode.com/an-open-source-world-a-primer-on-licenses-obligations-and-your-company
4. Haughey, D. (2010). Pareto analysis step by step. Project Smart. Retrieved from http://www.projectsmart.co.uk/pareto-analysis-step-by-step.html
5. Health Information and Management Systems Society (HIMSS). (2010). Interoperability & standards. Retrieved from http://www.himss.org/library/interoperability-standards?navItemNumber=13323
6. Isaias, P. & Issa, T. (2015). High level models and methodologies for information systems. New York, NY: Springer.
7. Karopka, T., Schmuhl, H., & Demski, H. (2014). Free/Libre open source software in health care: A review. Healthcare Informatics Research, 20(1), 11–22. PMCID: PMC3950260
8. Murphy, K. (2007). HIMSS has ideas for 2015 interoperability standards advisory. HealthIT Interoperability. Retrieved from http://healthitinteroperability.com/news/himss-has-ideas-for-2015-interoperability-standards-advisory
9. NORC. (2014). Data sharing to enable clinical transformation at the community level: IT takes a village. Retrieved from http://www.healthit.gov/sites/default/files/beacondatasharingbrief062014.pdf
10. Purcell, J. (2007). Comparison of software development lifecycle methodologies. SANS Institute. Retrieved from https://software-security.sans.org/resources/paper/cissp/comparison-software-development-lifecycle-methodologies
11. Stair, R., & Reynolds, G. (2016). Principles of information systems (12th ed.). Boston, MA: Cengage Learning.