case study on system development life cycle

• Skip to main content
• Skip to quick search
• Skip to global navigation
• Submissions

A Case Study of the Application of the Systems Development Life Cycle (SDLC) in 21 st Century Health Care: Something Old, Something New?

Permissions : This work is licensed under a Creative Commons Attribution 3.0 License. Please contact [email protected] to use this work in a way not covered by the license.

For more information, read Michigan Publishing's access and usage policy .

The systems development life cycle (SDLC), while undergoing numerous changes to its name and related components over the years, has remained a steadfast and reliable approach to software development. Although there is some debate as to the appropriate number of steps, and the naming conventions thereof, nonetheless it is a tried-and-true methodology that has withstood the test of time. This paper discusses the application of the SDLC in a 21st century health care environment. Specifically, it was utilized for the procurement of a software package designed particularly for the Home Health component of a regional hospital care facility. We found that the methodology is still as useful today as it ever was. By following the stages of the SDLC, an effective software product was identified, selected, and implemented in a real-world environment. Lessons learned from the project, and implications for practice, research, and pedagogy, are offered. Insights from this study can be applied as a pedagogical tool in a variety of classroom environments and curricula including, but not limited to, the systems analysis and design course as well as the core information systems (IS) class. It can also be used as a case study in an upper-division or graduate course describing the implementation of the SDLC in practice.

INTRODUCTION

The systems development life cycle, in its variant forms, remains one of the oldest and yet still widely used methods of software development and acquisition methods in the information technology (IT) arena. While it has evolved over the years in response to ever-changing scenarios and paradigm shifts pertaining to the building or acquiring of software, its central tenants are as applicable today as they ever were. Life-cycle stages have gone through iterations of different names and number of steps, but at the core the SDLC is resilient in its tried-and-true deployment in business, industry, and government. In fact, the SDLC has been called one of the two dominant systems development methodologies today, along with prototyping (Piccoli, 2012). Thus, learning about the SDLC remains important to the students of today as well as tomorrow.

This paper describes the use of the SDLC in a real-world heath care setting involving a principle component of a regional hospital care facility. The paper can be used as a pedagogical tool in a systems analysis and design course, or in an upper-division or graduate course as a case study of the implementation of the SDLC in practice. First, a review of the SDLC is provided, followed by a description of the case study environment. Next, the application of the methodology is described in detail. Following, inferences and observations from the project are presented, along with lessons learned. Finally, the paper concludes with implications for the three areas of research, practice, and pedagogy, as well as suggestions for future research.

The SDLC has been a part of the IT community since the inception of the modern digital computer. A course in Systems Analysis and Design is requisite in most Management Information Systems programs (Topi, Valacich, Wright, Kaiser, Nunamaker, Sipior, and de Vreede, 2010). While such classes offer an overview of many different means of developing or acquiring software (e.g., prototyping, extreme programming, rapid application development (RAD), joint application development (JAD), etc.), at their heart such programs still devote a considerable amount of time to the SDLC, as they should. As this paper will show, following the steps and stages of the methodology is still a valid method of insuring the successful deployment of software. While the SDLC, and systems analysis and design in general, has evolved over the years, at its heart it remains a robust methodology for developing software and systems.

Early treatises of the SDLC promoted the rigorous delineation of necessary steps to follow for any kind of software project. The Waterfall Model (Boehm, 1976) is one of the most well-known forms. In this classic representation, the methodology involves seven sequential steps: 1) System Requirements and Validation; 2) Software Requirements and Validation; 3) Preliminary Design and Validation; 4) Detailed Design and Validation; 5) Code, Debug, Deployment, and Test; 6) Test, Preoperations, Validation Test; and 7) Operations, Maintenance, Revalidation. In the original description of the Boehm-Waterfall software engineering methodology, there is an interactive backstep between each stage. Thus the Boehm-Waterfall is a combination of a sequential methodology with an interactive backstep (Burback, 2004).

Other early works were patterned after the Waterfall Model, with varying numbers of steps and not-markedly-different names for each stage. For example, Gore and Stubbe (1983) advocated a four-step approach consisting of the study phase, the design phase, the development phase, and the operation phase (p. 25). Martin and McClure (1988) described it as a multistep process consisting of five basic sequential phases: analysis, design, code, test, and maintain (p. 18). Another widely used text (Whitten, Bentley, and Ho, 1986) during the 1980s advocated an eight-step method. Beginning with 1) Survey the Situation, it was followed by 2) Study Current System; 3) Determine User Requirements; 4) Evaluate Alternative Solutions; 5) Design New System; 6) Select New Computer Equipment and Software; 7) Construct New System; and 8) Deliver New System.

Almost two decades later, a book by the same set of authors in general (Whitten, Bentley, and Dittman, 2004) also advocated an eight step series of phases, although the names of the stages changed somewhat (albeit not significantly). The methodology proceeded through the steps of Scope definition, Problem analysis, Requirements analysis, Logical design, Decision analysis, Physical design and integration, Construction and testing, and ending with Installation and delivery (p. 89). It is interesting to note that nearly 20 years later, the naming conventions used in the newer text are almost synonymous with those in the older work. The Whitten and Bentley (2008) text, in its present form, still breaks up the process into eight stages. While there is no consensus in the naming (or number) of stages (e.g., many systems analysis and design textbooks advocate their own nomenclature (c.f. Whitten, Bentley, and Barlow (1994), O’Brien (1993), Taggart and Silbey (1986)), McMurtrey (1997) reviewed the various forms of the life cycle in his dissertation work and came up with a generic SDLC involving the phases of Analysis, Design, Coding, Testing, Implementation, and Maintenance.

Even one of the most current and popular systems analysis and design textbooks (Kendall and Kendall, 2011) does not depart from tradition, emphasizing that the SDLC is still primarily comprised of seven phases. Although not immune to criticism, Hoffer, George, and Valacich (2011) believe that the view of systems analysis and design taking place in a cycle continues to be pervasive and true (p. 24). Thus, while the SDLC has evolved over the years under the guise of different combinations of naming conventions and numbers of steps or stages, it remains true to form as a well-tested methodology for software development and acquisition. We now turn our attention to how it was utilized in a present-day health care setting.

Case Study Setting

The present investigation regards the selection of a software package by a medium-size regional hospital for use in the Home Health segment of their organization. The hospital (to be referred to in this monograph by a fictitious name, General Hospital) is located in the central portion of a southern state in the USA, within 30 minutes of the state capital. Its constituents reside in the largest SMSA (standard metropolitan statistical area) in the state and consist of both rural, suburban, and city residents. The 149-bed facility is a state-of-the-art institution, as 91% of their 23 quality measures are better than the national average (“Where to Find Care”, 2010). Services offered include Emergency Department, Hospice, Intensive Care Unit (ICU), Obstetrics, Open Heart Surgery, and Pediatrics. Additional components of General Hospital consist of an Imaging Center, a Rehabilitation Hospital, Four Primary Care Clinics, a Health and Fitness Center (one of the largest in the nation with more than 70,000 square feet and 7,000 members), a Wound Healing Center, regional Therapy Centers, and Home Care (the focal point of this study).

There are more than 120 physicians on the active medical staff, over 1,400 employees and in excess of 100 volunteers (“General Hospital”, 2010). In short, it is representative of many similar patient care facilities around the nation and the world. As such, it provides a rich environment for the investigation of using the SDLC in a 21 st century health care institution.

Home Health and Study Overview

Home Health, or Home Care, is the portion of health care that is carried out at the patient’s home or residence. It is a participatory arrangement that eliminates the need for constant trips to the hospital for routine procedures. For example, patients take their own blood pressure (or heart rate, glucose level, etc.) using a device hooked up near their bed at home. The results are transmitted to the hospital (or in this case, the Home Health facility near General Hospital) electronically and are immediately processed, inspected, and monitored by attending staff.

In addition, there is a Lifeline feature available to elderly or other homebound individuals. The unit includes a button worn on a necklace or bracelet that the patient can push should they need assistance (“Home Health”, 2010). Periodically, clinicians (e.g., nurses, physical therapists, etc.) will visit the patient in their home to monitor their progress and perform routine inspections and maintenance on the technology.

The author was approached by his neighbor, a retired accounting faculty member who is a volunteer at General Hospital. He had been asked by hospital administration to investigate the acquisition, and eventual purchase, of software to facilitate and help coordinate the Home Health care portion of their business. After an initial meeting to offer help and familiarize ourselves with the task at hand, we met with staff (i.e., both management and the end-users) at the Home Health facility to begin our research.

THE SDLC IN ACTION

The author, having taught the SAD course many times, recognized from the outset that this particular project would indeed follow the stages of the traditional SDLC. While we would not be responsible for some of the steps (e.g., testing, and training of staff), we would follow many of the others in a lockstep fashion, thus, the task was an adaptation of the SDLC (i.e., a software acquisition project) as opposed to a software development project involving all the stages. For students, it is important to see that they benefit from understanding that the core ideas of the SDLC can be adapted to fit a “buy” (rather than “make”) situation. Their knowledge of the SDLC can be applied to a non-development context. The systematic approach is adaptable, which makes the knowledge more valuable. In this project, we used a modified version of the SDLC that corresponds to the form advocated by McMurtrey (1997). Consequently, we proceed in this monograph in the same fashion that the project was presented to us: step by step in line with the SDLC.

Problem Definition

The first step in the Systems Development Life Cycle is the Problem Definition component of the Analysis phase. One would be hard-pressed to offer a solution to a problem that was not fully defined. The Home Health portion of General Hospital had been reorganized as a separate, subsidiary unit located near the main hospital in its own standalone facility. Furthermore, the software they were using was at least seven years old and could simply not keep up with all the changes in billing practices and Medicare requirements and payments. The current system was not scalable to the growing needs and transformation within the environment. Thus, in addition to specific desirable criteria of the chosen software (described in the following section), our explicit purpose in helping General was twofold: 1) to modernize their operations with current technology; and 2) to provide the best patient care available to their clients in the Home Health arena.

A precursor to the Analysis stage, often mentioned in textbooks (e.g., Valacich, George, and Hoffer, 2009) and of great importance in a practical setting, is the Feasibility Study. This preface to the beginning of the Analysis phase is oftentimes broken down into three areas of feasibility:

• Technical (Do we have the necessary resources and infrastructure to support the software if it is acquired?)
• Economic (Do we have the financial resources to pay for it, including support and maintenance?)
• Operational (Do we have properly trained individuals who can operate and use the software?).

Fortunately, these questions had all been answered in the affirmative before we joined the project. The Director of Information Technology at General Hospital budgeted $250,000 for procurement (thus meeting the criteria for economic feasibility); General’s IT infrastructure was more than adequate and up to date with regard to supporting the new software (technical feasibility); and support staff and potential end users were well trained and enthusiastic about adopting the new technology (operational feasibility). Given that the Feasibility Study portion of the SDLC was complete, we endeavored forthwith into the project details.

Requirements Analysis

In the Requirements Analysis portion of the Analysis stage, great care is taken to ensure that the proposed system meets the objectives put forth by management. To that end, we met with the various stakeholders (i.e., the Director of the Home Care facility and potential end-users) to map out the requirements needed from the new system. Copious notes were taken at these meetings, and a conscientious effort to synthesize our recollections was done. Afterwards, the requirements were collated into a spreadsheet for ease of inspection (Exhibit 1). Several key requirements are described here:

MEDITECH Compatible: This was the first, and one of the most important requirements, at least from a technological viewpoint. MEDITECH (Medical Information Technology, Inc.) has been a leading software vendor in the health care informatics industry for 40 years (“About Meditech”, 2009). It is the flagship product used at General Hospital and is described as the number one health care vendor in the United States with approximately 25% market share (“International News”, 2006). All Meditech platforms are certified EMR/EHR systems (“Meditech News”, 2012). “With an Electronic Health Record, a patient's record follows her electronically. From the physician's office, to the hospital, to her home-based care, and to any other place she receives health services, and she and her doctors can access all of this information and communicate with a smartphone or computer” (“The New Meditech”, 2012). Because of its strategic importance to General, and its overall large footprint in the entire infrastructure and day-to-day operations, it was imperative that the new software would be Meditech-compatible.

Point of Care Documentation: Electronic medical record (EMR) point-of-care (POC) documentation in patients' rooms is a recent shift in technology use in hospitals (Duffy, Kharasch, Morris, and Du, 2010). POC documentation reduces inefficiencies, decreases the probability of errors, promotes information transfer, and encourages the caregiver to be at the bedside or, in the case of home care, on the receiving end of the transmission.

OASIS Analyzer: OASIS is a system developed by the Centers for Medicare & Medicaid Services (CMS), formerly an agency of the U.S. Department of Health and Human Services, as part of the required home care assessment for reimbursing health care providers. OASIS combines 20 data elements to measure case-mix across 3 domains–clinical severity, functional status and utilization factors (“Medical Dictionary”, 2010). This module allows staff to work more intelligently, allowing them to easily analyze outcomes data in an effort to move toward improved clinical and financial results (“Butte Home Health”, 2009). Given its strategic link to Medicare and Medicaid reimbursement, OASIS Analyzer was a “must have” feature of the new software.

Physician Portal: The chosen software package must have an entryway for the attending, resident, or primary caregiver physician to interact with the system in a seamless fashion. Such a gateway will facilitate efficient patient care by enabling the physician to have immediate access to critical patient data and history.

Other “Must Haves” of the New Software: Special billing and accounts receivable modules tailored to Home Health; real-time reports and built-in digital dashboards to provide business intelligence (e.g., OASIS Analyzer); schedule optimization; and last, but certainly not least, the system must be user friendly.

Desirable, But Not Absolutely Necessary Features: Security (advanced, beyond the normal user identification and password type); trial period available (i.e., could General try it out for a limited time before fully committing to the contract?).

Other Items of interest During the Analysis Phase: Several other issues were important in this phase:

• Is the proposed solution a Home Health-only product, or is it part of a larger, perhaps enterprise-wide system?
• Are there other modules available (e.g., financial, clinical, hospice; applications to synchronize the system with a PDA (Personal Digital Assistant) or smart phone)?
• Is there a web demo available to view online; or, even better, is there an opportunity to participate in a live, hands-on demonstration of the software under real or simulated conditions?

We also made note of other observations that might be helpful in selecting final candidates to be considered for site visits. To gain insight into the experience, dependability, and professionalism of the vendors, we also kept track of information such as: experience (i.e., number of years in business); number of clients or customers; revenues; and helpfulness (return e-mails and/or phone calls within a timely manner or at all).

Finally, some anecdotal evidence was gathered to help us evaluate each vendor as a potential finalist. For instance, Vendor A had an Implementation/Installation Team to assist with that stage of the software deployment; they also maintained a Knowledge Base (database) of Use Cases/List Cases describing the most frequently occurring problems or pitfalls. Vendor C sponsored an annual User Conference where users could share experiences with using the product, as well as provide feedback to be incorporated into future releases. To that end, Vendor C also had a user representative on their Product Advisory Board. Vendor E offered a “cloud computing” choice, in that the product was hosted in their data center. (A potential buyer did not have to choose the web-enabled solution.) Vendor E’s offering was part of an enterprise solution, and could be synchronized with a PDA or smart phone.

As previously noted, for this particular case study of software selection, the researchers did not have to proceed through each step of the SDLC since the software products already existed. Thus, the Design stage of the SDLC has already been carried out by the vendors. In a similar vein, the coding, testing, and debugging of program modules had too been performed by each vendor candidate. Thus, after painstakingly analyzing all the wares, features, pros and cons, and costs and benefits associated with each product, we were now ready to make a choice: we would whittle our list of five potential vendors down to the two that we felt met our needs and showed the most interest and promise.

The principle investigators arranged another meeting with the primary stakeholders of General Hospital’s Home Health division. After all, although we had done the research, they were the ones that would be using the system for the foreseeable future. As such, it only made sense that they be heavily involved. This is in line with what is put forth in systems analysis and design textbooks: user involvement is a key component to system success. Having carefully reviewed our research notes, in addition to the various brochures, websites, proposals, communications, and related documents from each of our shortlist of five vendors, together as a group we made our decision. We would invite Vendor B for a site visit and demonstration.

Vendor B was very professional, courteous, prompt, and conscientious during their visit. One thing that greatly supported their case was that their primary business model focused on Home Health software. It was, and still is, their core competency. In contrast, one other vendor (not on our original short list of five) came and made a very polished presentation, in the words of the Director. However, this company was a multi-billion dollar concern, of which Home Health software was only a small part. Thus the choice was made to go with Vendor B.

Ironically, this seller’s product was not Meditech compatible, which was one of the most important criteria for selection. However, through the use of a middleware company that had considerable experience in designing interfaces to be used in a Meditech environment, a suitable arrangement was made and a customized solution was developed and put into use. The middleware vendor had done business with General before and, therefore, was familiar with their needs.

Implementation

As is taught in SAD classes, the implementation stage of the SDLC usually follows one of four main forms. These are, according to Valacich, George, and Hoffer (2009): 1) Direct Installation (sometimes also referred to as Direct Cutover, Abrupt, or Cold Turkey method) where the old system is simply removed and replaced with the new software, perhaps over the weekend; 2) Parallel Installation, when the old and new systems are run side-by-side until at some point (the “go live” date) use of the former software is eliminated; 3) Single Location Installation (or the Pilot approach) involves using one site (or several sites if the software rollout is to be nationwide or international involving hundreds of locations) as beta or test installations to identify any bugs or usage problems before committing to the new software on a large scale; and 4) Phased Installation, which is the process of integrating segments of program modules into stages of implementation, ensuring that each block works before the whole software product is implemented in its entirety.

The Home Care unit of General Hospital utilized the Parallel Installation method for approximately 60 days before the “go live” date. Clinicians would “double enter” patient records and admissions data into both the old and new systems to ensure that the new database was populated, while at the same time maintaining patient care with the former product until its disposal. The Director of the Home Care facility noted that this process took longer than anticipated but was well worth it in the long run. Once the “go live” date was reached the new system performed quite well, with a minimal amount of disruption.

Training of staff commenced two weeks before the “go live” date. Of the approximately 25 users, half were trained the first week and the rest the next. Clinicians had to perform a live visit with one of their patients using the new system. Thus they would already have experience with it in a hands-on environment before switching to the new product and committing to it on a full-time basis.

It is again worth noting that the implementation method, Parallel Installation, follows from the SDLC and is what is taught in modern-day SAD courses. Thus, it was satisfying to the researchers that textbook concepts were being utilized in “real world” situations. It also reinforced that teaching the SDLC was in line with current curriculum guidelines and should continue.

Maintenance/Support

Software upgrades (called “code loads” by the vendor) are performed every six weeks. The Director reported that these advancements were not disruptive to everyday operations. Such upgrades are especially important in the health care industry, as changes to Medicare and billing practices are common occurrences. The Director also noted that all end users, including nurses, physical therapists, physicians, and other staff, were very happy with the new system and, collectively, had no major complaints about it. General Hospital expects to use the software for the foreseeable future, with no plans to have to embark on another project of this magnitude for quite some time.

Many inferences and observations were gleaned by both the researchers and hospital staff during the course of the investigation. First, we all learned that we must “do our homework”; that is, much research and analysis had to be performed to get up to speed on the project. For instance, while the principle investigators both had doctoral degrees in business administration, and one of them (the author) had taught the systems analysis and design course for over ten years at two different institutions, neither of us had any practical experience in the Home Health arena. Thus, we had to familiarize ourselves with the current environment as well as grasp an understanding of the criteria set forth by the stakeholders (both end-users and management). This was an important lesson learned, because we teach our students (in the SAD class) that they must not only familiarize themselves with the application at hand, but they must also interact with the users. Much research has been conducted in the area of user involvement and its relationship to system success (e.g., Ives and Olson, 1984; Baroudi, Olson, and Ives, 1986; Tait and Vessey, 1988). Therefore it was satisfying, from a pedagogical standpoint, to know that concepts taught in a classroom setting were being utilized in a real-world environment.

It was also very enlightening, from the standpoint of business school professors, to see how the core functional areas of study (e.g., marketing, management, accounting, etc., not to mention MIS) were also highly integral to the project at hand. During our research on the various vendor companies, we were subjected to a myriad of different marketing campaigns and promotional brochures, which typically touted their wares as the “best” on the market. Key, integral components (such as billing, scheduling, business intelligence, patient care, electronic medical records (EMR), etc.) that are critical success factors in almost any business were promoted and we were made keenly aware of their strategic importance. Again, this was very rewarding from the point of view from business school professors: we were very pleased that our graduates and students are learning all of these concepts (and more) as core competencies in the curriculum.

Finally, probably the most positive outcome from the project was that patient care will be improved as a result of this endeavor. Following that, it was enlightening that an adaptation of the SDLC was applied to a healthcare setting and it achieved positive results. This showed that the SDLC, in part or in whole, is alive and well and is an important part of the MIS world in both practice and academia. In addition, key outcomes regarding each were identified and are elaborated upon in the following section.

IMPLICATIONS FOR PRACTICE, RESEARCH AND PEDAGOGY

Implications for practice.

This project, and case study, was an application of pedagogy on a real-world systems analysis project. As such, it has implications for practice. First, it showed that concepts learned in a classroom environment (such as the SDLC in the systems analysis and design course) can be effectively applied in a business (or in our case, a health care) environment. It was very satisfying for us, as business school professors, to see instructional topics successfully employed to solve a real-world problem. For practitioners, such as any organization looking to acquire a software package, we hope that we have shown that if one applies due diligence to their research effort that positive outcomes can be achieved. Our findings might also help practitioners appreciate that tried and true methods, such as the SDLC, are applicable to projects of a similar nature, and not just academic exercises to fulfill curriculum requirements. We find this among the most gratifying implications.

Implications for Research

This project could be used as the beginning of a longitudinal study into the life cycle of the Home Health software product selected. It is customary to note that maintenance can consume half of the IS budget when it comes to software, especially large-scale systems (Dorfman and Thayer, 1997). It would be interesting to track this project, in real time, to see if that is indeed the case. Furthermore, an often-neglected phase of the SDLC is the stage at the very end: disposal of the system. By following the present study to the end, it would be enlightening (from all three viewpoints of research, practice, and pedagogy) to see what happens at the end of the software’s useful life. Additional future research might investigate the utilization of the SDLC in different contexts, or even other settings with the healthcare arena.

Implications for Pedagogy

Insights for the sad course.

After learning so much about real-world software acquisition throughout this voluntary consulting project, the author has utilized it in classroom settings. First, the obvious connection with the SAD course was made. To that end, in addition to another semester-long project they work on in a group setting, the students pick an application domain (such as a veterinary clinic, a dentist’s office, a movie rental store, etc.) and perform a research effort not unlike the one described in this monograph. Afterwards, a presentation is made to the class whereby three to five candidate vendors are shown, along with the associated criteria used, and then one is chosen. Reasons are given for the selection and additional questions are asked, if necessary. This exercise gives the students a real-world look at application software through the lens of the SDLC.

While some SAD professors are able to engage local businesses to provide more of a “real-world” application by allowing students to literally develop a system, such an endeavor was not possible at the time of this study. The benefits of such an approach are, or course, that it provides students “real world” experience and applying concepts learned in school to practical uses. The drawback is that it requires a substantial commitment from the business and oftentimes the proprietors pull back from the project if they get too busy with other things. Thus, the decision was made to allow students to pick an application domain, under the assumption that they had been contracted by the owners to acquire a system for them.

Such an exercise enables students to engage in what Houghton and Ruth (2010) call “deep learning”. They note that such an approach is much more appropriate when the learning material presented involves going beyond simple facts and into what lies below the surface (p. 91). Indeed, this particular exercise for the SAD students was not rote memorization of facts at a surface level; it forced them to perform critical thinking and analysis at a much greater depth of understanding. Although the students were not able to complete a “real world” project to the extent that other educators have reported (e.g., Grant, Malloy, Murphy, Foreman, and Robinson (2010), the experience did allow students to tackle a contemporary project and simulate the solving of it with real-world solutions. This gave them a much greater appreciation for the task of procuring software than just reading about it in textbooks. The educational benefits of using real-world projects are well established both in the United States (Grant et al., 2010) and internationally (Magboo and Magboo, 2003).

From an IS curriculum standpoint, this form of exercise by SAD students helps bridge the well-known gap between theory and practice (Andriole, 2006). As was shown in this monograph, the SDLC is a theory that has widespread application in practice. The project performed by students in the SAD class reinforces what Parker, LeRouge, and Trimmer (2005) described in their paper on alternative instructional strategies in an IS curriculum. That is, SAD is a core component of an education in information systems, and there is a plethora of different ways to deliver a rich experience, including the one described here.

Insights for IS Courses, SAD and non-SAD

Other insights gained, by the SAD students as well as the core MIS course, have to do with what the author teaches during the requisite chapter on software. In class, I present this topic as “the software dilemma”. This description is tantamount to the recognition that when acquiring software, businesses must make one of three choices (in general). The options are “make” versus “buy” versus “outsource” when it comes to acquiring software. (There is also a hybrid approach that involves customizing purchased software.)

Briefly explained, the “make” option presupposes that the organization has an IT staff that can do their own, custom, programming. The “buy” alternative relates to what was described in this paper, in that General Hospital did not have the resources to devote to developing software for their Home Health segment, and as such enlisted the researchers to assist in that endeavor. The “outsource” choice alludes to several different options available, under this umbrella, on the modern-day IT landscape. The decision to outsource could range from an application service provider (ASP) delivering the solution over the internet (or the “cloud”) to complete transfer of the IT operation to a hosting provider or even a server co-location vendor.

Thus, a project like this one could be used in the core MIS course to further illustrate problems and potential pitfalls faced by businesses, small and large, when it comes to software acquisition. Instructors could use the features of this case study to focus on whatever portion of it they thought best: project management, budgeting, personnel requirements, marketing, etc. It could even be used in a marketing class to investigate the ways in which vendors, offering similar solutions to standard problems, differentiate themselves through various marketing channels and strategies.

Furthermore, the case study is ripe for discussion pertaining to a plethora of business school topics, from economics and accounting to customer relationship management. The case is especially rich fodder for the MIS curriculum: not only systems analysis and design, but programming and database classes can find useful, practical, real-world issues surrounding this case that can be used as “teaching tools” to the students.

Finally, a case study like this one could even be used in an operations management, or project management, setting. The discovery of issues, such as those raised in this paper, could be fruitful research for both undergraduate and graduate students alike. A team project, along with a group presentation as the finale, would also give students much-needed experience in public speaking and would help prepare them for the boardrooms of tomorrow.

Two business school professors, one an MIS scholar and the other retired from the accounting faculty, were called upon by a local hospital to assist with the procurement of software for the Home Health area. These academics were up to the challenge, and pleasantly assisted the hospital in their quest. While both researchers hold terminal degrees, each learned quite a bit from the application of principles taught in the classroom (e.g., the SDLC) to the complexities surrounding real-world utilization of them. Great insights were gained, in a variety of areas, and have since been shown as relevant to future practitioners (i.e., students) in the business world. It is hoped that others, in both academe and commerce, will benefit from the results and salient observations from this study.

• About Meditech (2009) Retrieved on May 19, 2010 from http://www.meditech.com/AboutMeditech/homepage.htm
• Andriole, S. (2006) Business Technology Education in the Early 21 st Century: The Ongoing Quest for Relevance . Journal of Information Technology Education , 5, 1-12.
• Baroudi, J., Olson, M.. and Ives, B. (1986, March) An Empirical Study of the Impact of User Involvement on System Usage and Information Satisfaction. Communications of the ACM , 29, 3, 232-238. http://dx.doi.org/10.1145/5666.5669
• Boehm, B. W. (1976, December) Software Engineering. IEEE Transactions on Computers , C-25, 1226-1241. http://dx.doi.org/10.1109/TC.1976.1674590
• Burback, R. L. (2004) The Boehm-Waterfall Methodology, Retrieved May 20, 2010 from http://infolab.stanford.edu/~burback/watersluice/node52.html
• Butte Home Health & Hospice Works Smarter with CareVoyant Healthcare Intelligence (2009) Retrieved May 21, 2010 from http://www.carevoyant.com/cs_butte.html?fn=c_cs
• Dorfman, M. and Thayer, R. M. (eds.) (1997) Software Engineering, IEEE Computer Society Press, Los Alamitos, CA.
• Duffy, W. J. RN, Morris, J., CNOR; Kharasch, M. S. MD, FACEP; Du, H. MS (2010, January/March) Point of Care Documentation Impact on the Nurse-Patient Interaction. Nursing Administration Quarterly , 34, 1, E1-E10.
• “General Hospital” (2010) Conway Regional Health System . Retrieved on May 18, 2010 from http://www.conwayregional.org/body.cfm?id=9
• Gore, M. and Stubbe, J. (1983) Elements of Systems Analysis 3 rd Edition, Wm. C. Brown Company Publishers, Dubuque, IA.
• Grant, D. M., Malloy, A. D., Murphy, M. C., Foreman, J., and Robinson, R. A. (2010) Real World Project: Integrating the Classroom, External Business Partnerships and Professional Organizations. Journal of Information Technology Education , 9, IIP 168-196.
• Hoffer, J. A., George, J. F. and Valacich, J. S. (2011) Modern Systems Analysis and Design, Prentice Hall, Boston.
• “Home Health” (2010) Conway Regional Health System . Retrieved on May 18, 2010 from http://www.conwayregional.org/body.cfm?id=31
• Houghton, L. and Ruth, A. (2010) Making Information Systems Less Scrugged: Reflecting on the Processes of Change in Teaching and Learning. Journal of Information Technology Education , 9, IIP 91-102.
• “International News” (2006) Retrieved on May 19, 2010 from http://www.meditech.com/aboutmeditech/pages/newsinternational.htm
• Ives, B. and Olson, M. (1984, May) User Involvement and MIS Success: A Review of Research. Management Science , 30, 5, 586-603. http://dx.doi.org/10.1287/mnsc.30.5.586
• Kendall, K. and Kendall, J. E. (2011) Systems Analysis and Design, 8/E, Prentice Hall , Englewood Cliffs, NJ.
• Magboo, S. A., and Magboo, V. P. C. (2003) Assignment of Real-World Projects: An Economical Method of Building Applications for a University and an Effective Way to Enhance Education of the Students. Journal of Information Technology Education , 2, 29-39.
• Martin, J. and McClure, C. (1988) Structured Techniques: The Basis for CASE (Revised Edition), Englewood Cliffs, New Jersey, Prentice Hall.
• McMurtrey, M. E. (1997) Determinants of Job Satisfaction Among Systems Professionals: An Empirical Study of the Impact of CASE Tool Usage and Career Orientations, Unpublished doctoral dissertation, Columbia, SC, University of South Carolina.
• “Medical Dictionary” (2010) The Free Dictionary . Retrieved May 21, 2010 from http://medical-dictionary.thefreedictionary.com/OASIS
• “Meditech News” (2012) Retrieved April 1, 2012 from http://www.meditech.com/AboutMeditech/pages/newscertificationupdate0111.htm
• O’Brien, J. A. (1993) Management Information Systems: A Managerial End User Perspective, Irwin, Homewood, IL.
• Parker, K. R., Larouge, C., and Trimmer, K. (2005) Alternative Instructional Strategies in an IS Curriculum. Journal of Information Technology Education , 4, 43-60.
• Piccoli, G. (2012) Information Systems for Managers: Text and Cases, John Wiley & Sons, Inc., Hoboken, NJ.
• Taggart, W. M. and Silbey, V. (1986) Information Systems: People and Computers in Organizations, Allyn and Bacon, Inc., Boston.
• Tait, P. and Vessey, I. (1988) The Effect of User Involvement on System Success: A Contingency Approach. MIS Quarterly , 12, 1, 91-108. http://dx.doi.org/10.2307/248809
• “The New Meditech” (2012) Retrieved April 1, 2012 from http://www.meditech.com/newmeditech/homepage.htm
• Topi, H., Valacich, J., Wright, R., Kaiser, K., Nunamaker Jr, J., Sipior, J., and de Vreede, G.J. (2010) IS 2010: Curriculum Guidelines for Undergraduate Degree Programs in Information Systems. Communications of the Association for Information Systems , 26, 1, 1-88.
• Valacich, J.S., George, J. F., and Hoffer, J. A. (2009) Essentials of System Analysis and Design 4 th Ed., Prentice Hall , Upper Saddle River, NJ.
• “Where to Find Care” (2010) Retrieved on May 18, 2010 from http://www.wheretofindcare.com/Hospitals/Arkansas-AR/CONWAY/040029/CONWAY-REGIONAL-MEDICAL-CENTER.aspx
• Whitten, J. L. and Bentley, L. D. (2008) Introduction to Systems Analysis and Design 1 st Ed., McGraw-Hill, Boston.
• Whitten, J. L., Bentley, L. D., and Barlow, V. M. (1994) Systems Analysis and Design Methods 3 rd Ed. Richard D. Irwin, Inc., Burr Ridge, IL.
• Whitten, J. L., Bentley, L. D., and Dittman, K. C. (2004) Systems Analysis and Design Methods 6 th Ed., McGraw Hill Irwin, Boston.
• Whitten, J. L., Bentley, L. D., and Ho, T. I. M. (1986) Systems Analysis and Design, Times Mirror/Mosby College Publishing, St. Louis.

Human-System Integration in the System Development Process: A New Look (2007)

Chapter: 5 case studies, 5 case studies.

T his chapter provides three examples of specific system development that illustrate application of human-system integration (HSI) methods in the context of the incremental commitment model (ICM). The examples are drawn from the committee’s collective experience and specific application of the concepts developed during our work to these particular projects. They represent projects at three stages of development: the early stages of planning, in mid-development, and fully realized.

The first example involves the development of unmanned aerial systems and identifies numerous HSI issues in these systems that will require solution. This example provides a “notional” application of human factors methods and potential implementation of the incremental commitment model. The case study illustrates the theme of designing to accommodate changing conditions and requirements in the workplace. Specifically, it addresses the issue of adapting current unmanned aerial systems to accommodate fewer operators, with individual operators controlling multiple vehicles. The hypothetical solutions to this problem reveal the potential costs of reliance on automation, particularly prior to a full understanding of the domain, task, and operator strengths and limitations. This case study also reveals the tight interconnection between the various facets of human-system integration, such as manpower, personnel, training, and design. In other words, answering the “how many operators to vehicles” question necessarily impacts design, training, and personnel decisions.

The second example focuses on a large-scale government implementation of port security systems for protection against nuclear smuggling. The example discusses the HSI themes and incremental application of methods

during the iterative development of the system. This case is useful for illustrating application of human factors methods on a risk-driven basis, as they tend to be applied as needed over time in response to the iterative aspects of defining requirements and opportunities, developing design solutions, and evaluation of operational experience.

The third example describes development of an intravenous infusion pump by a medical device manufacturer. This example is the most detailed and “linear” of the three cases, in that it follows a sequential developmental process; the various systems engineering phases are discussed in terms of the human factors methods applied during each phase. This case study illustrates the successful implementation of well-known HSI methods, including contextual inquiry, prototyping and simulations, cognitive walkthroughs for estimating use-error-induced operational risks, iterative design, and usability evaluations that include testing and expert reviews. The importance of the incremental commitment model in phased decision making and the value of shared representations is also highlighted.

Each of these examples is presented in a somewhat different format, as appropriate to the type of development. This presentation emphasizes one broad finding from our study, which is that a “one size” system development model does not fit all. The examples illustrate tailored application of HSI methods, the various trade-offs that are made to incorporate them in the larger context of engineering development, and the overall theme of reducing the risk that operational systems will fail to meet user needs.

UNMANNED AERIAL SYSTEMS

Unmanned aerial systems (UASs) or remotely piloted vehicles (RPVs) are airplanes or helicopters operated remotely by humans on the ground or in some cases from a moving air, ground, or water vehicle. Until recently the term “unmanned aerial vehicle” (UAV) was used in the military services in reference to such vehicles as Predators, Global Hawks, Pioneers, Hunters, and Shadows. The term “unmanned aerial system” acknowledges the fact that the focus is on much more than a vehicle. The vehicle is only part of a large interconnected system that connects other humans and machines on the ground and in the air to carry out tasks ranging from UAS maintenance and operation to data interpretation and sensor operation. The recognition of the system in its full complexity is consistent with the evolution from human-machine design to human-system design, the topic of this report. It highlights an important theme of this book: the need for methods that are scalable to complex systems of systems.

Unmanned aerial systems are intended to keep humans out of harm’s way. However, humans are still on the ground performing maintenance, control, monitoring, and data collection functions, among others. Reports

from the Army indicate that 22 people are required on the ground to operate, maintain, and oversee a Shadow UAS (Bruce Hunn, personal communication). In addition, there is a dearth of UAS operators relative to the current need in Iraq and Afghanistan, not to mention the U.S. borders. The growing need for UAS personnel, combined with the current shortage, points to another theme of this report: the need for human-system integration to accommodate changing conditions and requirements in the workplace.

In addition, this issue has strong ties to questions of manning. The manning questions are “How many operators does it take to operate each unmanned aerial system? Can one modify the 2:1 human to machine ratio (e.g., two humans operating one UAS) to allow for a single operator and multiple aircraft (e.g., 1:4)?” Automation is often proposed as a solution to this problem, but the problem can be much more complex. Automation is not always a solution and may, in fact, present a new set of challenges, such as loss of operator situation awareness or mode confusion. Furthermore, the manning question is a good example of how HSI design touches other aspects of human-system integration, such as manpower, personnel, and training. That is, the question of how many vehicles per operator is not merely one of automation, but also involves the number and nature of the operators in question.

A Hypothetical Case

This example is based on an ongoing debate about the manning question, which has not been fully resolved. Therefore some aspects of the case are hypothetical, yet not improbable. In this example we assume that the objective of the design is to change the operator to UAS ratio from 2:1 to 1:4. That is, instead of two operators for one UAS there will be one operator for four UASs. This operator to UAS ratio is a requirement of the type that may be promulgated by the Department of Defense with minimal HSI input. It could be too late for human-system integration, which needs to be fully integrated into the engineering life cycle before system requirements have been determined. It could be too late in the sense that up-front analysis might have revealed that an effective 1:4 ratio is beyond the capabilities of current humans and technology under the best of circumstances. If this is the case, then there is a huge risk of designing a system that is doomed to fail. Even worse, this failure may not reveal itself until the right operational events line up to produce workload that breaks the system.

In our example, we present another scenario. The design of a UAS with a 1:4 ratio of operator to system is carried through the ICM development process to illustrate the potential role of human-system integration and one of the themes of this book. The Department of Defense is one of many

critical stakeholders in this scenario, all of whom are to be considered in the satisficing process that ensues.

Human-System Integration in the Context of the Incremental Commitment Model

In the earliest exploration phases of ICM development, the problem space and concept of operations are defined, and concept discovery and synthesis take place. Table 5-1 provides highlights of the entire example. It is often the case that human-system integration is not brought into the development cycle at this point, although at great risk. Up-front analyses, such as interviews of UAS operators, observations of operations of 2:1 systems, examination of mishap reports, understanding of the literature and data, an analysis of the 2:1 workload, event data analysis targeted at communications in the 2:1 UAS system, application of models of operator workload, and work flow analysis are all methods that could be used to explore the HSI issues in the current UAS system.

There is much that could come from this kind of up-front analysis. One hypothetical possibility is that the up-front HSI analyses could determine that UAS workload is not constant but peaks in target areas where photos need to be taken or in situations in which the route plan needs to change.

One of the key principles of ICM development is risk management , including risk-driven activity levels and anchor point commitment milestones. What are the risks if human-system integration is not considered early in the development life cycle? In this case, the formal requirements that are established may target workload reduction incorrectly. For example, autopilot automation might be developed to help to get multiple UASs from point A to point B and so on. This might have the effect of reducing workload when a reduction was not needed, while providing no relief from the high-workload tasks. Ultimately the neglect of up-front human-system integration could result in a system that is ineffective or prone to error. Consideration of risks like these should guide system development.

What if there is not enough time to interview UAS operators and to do a thorough job in the exploration phase? There is also risk associated with application of costly up-front techniques. The up-front methods used often during the exploration phase of the life cycle can be tailored to meet time and budget constraints—another theme of this book. For example, in this case in which the manning question is the issue and automation appears to be a promising solution, it would make sense to focus on aspects of the task that may be automated and the workload associated with each. One caveat is that decisions on how to scope and tailor the methods require some HSI expertise in order to target the aspects of human-system integration that promise the most risk reduction.

As system development progresses, other principles of ICM development come into play, including incremental growth of system development and stakeholder commitment. This part of the development life-cycle synthesis leads to construction, invention, or design that is iteratively refined as it is evaluated. HSI activities that would be useful at this point include function allocation and the development of shared representations, such as storyboards and prototypes.

Based on the previous finding of fluctuating workload, it may be decided that human intervention is needed at target areas and during route changes, but that the single operator can handle only one of these peak-workload tasks at a time. It may also be determined that, although automation could handle the routine flight task, an even more important place for automation is in the hand-off between the flight tasks and the human planning/replanning operation. The automation would therefore serve a scheduling and hand-off function, allocating complex tasks to the human operator as they arise and in order of priority (e.g., priority targets first). There could also be automation that serves as a decision aid for the targeting task.

Because only one nonroutine task can be handled at a time under the 1:4 scenario, it may also be decided that operators should be relieved of the flight functions completely but be on call for hand-offs from automation. For example, four controllers could handle the prioritized hand-offs from the automation, much as air traffic controllers handle multiple planes in a sector. Note that this new design and staffing plan are completely different in terms of operator roles and tasks from the former 2:1 operation. It is human-system integration that guided the allocation of tasks to human and machine; without it there would have been many other possibilities for automation that may not have produced the same end-state.

As the ICM development continues, the system engineers will go from working prototypes to product development, beta testing, product deployment, product maintenance, and product retirement. But there is continual iteration along the way. The incremental growth in the automation for scheduling, hand-offs, and targeting would occur in parallel with the next iteration’s requirements and subsystem definitions (i.e., concurrent engineering). Incremental growth will be influenced by stakeholder commitment. The HSI methods in the later stages include interviews and observations in conjunction with the newly designed system and usability testing. Some of the same methods used in up-front analysis (e.g., event data analysis, participatory analysis) can be again used and results contrasted with those of the earlier data collection.

The goal of human-system integration at this stage is to verify that the situation for the user has improved and that no new issues have cropped up in the interim. For instance, it may be determined from testing that the targeting decision aid is not trusted by the human operator (a stakeholder)

TABLE 5-1 Example of Human-System Integration for UASs in the Context of the Risk-Driven Spiral

and as a result is not used (a risk). Through iterations, a new design will be tested or the decision aid will be completely eliminated (i.e., stakeholder satisficing).

Conclusion and Lessons Learned

In this example, human-system integration plays a major role throughout the design process and is critical in the early stages before requirements are established. It can be integrated throughout the design life cycle with other engineering methods. It is also clear that the HSI activities serve to reduce human factors risks along the way and make evident the human factors issues that are at stake, so that these issues can be considered as they trade off with other design issues.

This example illustrates several lessons regarding human-system integration and system design:

The importance and complexity of the “system” in human-system integration compared with “machine” or “vehicle.”

Design concerns are often linked to manpower, personnel, and training concerns.

Up-front analysis and HSI input in early exploration activities is critical.

Methods can be tailored to time and money constraints, but HSI expertise is required to do so.

Risks are incurred if human-system integration is not considered or if it is considered late. In this case the risk would be a system that is not usable and that ultimately leads to catastrophic failure.

PORT SECURITY

The U.S. Department of Homeland Security (DHS) is in the process of implementing a large-scale radiation screening program to protect the country from nuclear weapons or dirty bombs that might be smuggled across the border through various ports of entry. This program encompasses all land, air, and maritime ports of entry. Our example focuses on radiation screening at seaports, which have a particularly complex operational nature. Seaports are structured to facilitate the rapid offloading of cargo containers from ocean-going vessels, provide temporary storage of the containers, and provide facilities for trucks and trains to load containers for transport to their final destination. The operation involves numerous personnel, includ-

FIGURE 5-1 RPM security screening at seaports involves multiple tasks, displays, and people.

ing customs and border protection (CBP) officers for customs and security inspection, terminal personnel, such as longshoremen for equipment operation, and transport personnel, such as truck drivers and railroad operators. Figure 5-1 illustrates the steps involved in the radiation screening process.

Design and deployment of radiation portal monitoring (RPM) systems for seaport operations engages the incremental commitment model for ensuring commitments from the stakeholders and to meet the fundamental technical requirement of screening 100 percent of arriving international cargo containers for illicit radioactive material.

This example illustrates aspects of the ICM process with specific instances of human-system integration linked to concurrent technical activities in the RPM program. The development of RPM systems for application in the seaport environment entails an iterative process that reflects the overall set of themes developed in this book. We discuss how these themes are reflected in the engineering process.

Human-System Integration in the Context of Risk-Driven Incremental Commitments

The human factors design issues encountered in this program are very diverse, ranging from fundamental questions of alarm system effectiveness at a basic research level, to very practical and time-sensitive issues, such as the most appropriate methods of signage or traffic signaling for controlling

the flow of trucks through an RPM system. HSI methods have been applied on a needs-driven basis, with risk as a driver for the nature of the application. With the issue of alarm system effectiveness, for example, it was recognized early in the program that reducing system nuisance alarms is an important issue, but one that requires a considerable amount of physics research and human factors display system modeling and design. The ICM process allowed early implementation of systems with a higher nuisance alarm rate than desirable while pursuing longer term solutions to problems involving filtering, new sensors, and threat-based displays. The nuisance alarm risk was accepted for the early implementations, while concurrent engineering was performed to reduce the alarm rate and improve the threat displays for implementation in later versions.

A contrasting example involves traffic signage and signaling. Since the flow of cargo trucks through port exits is a critical element of maintaining commercial flow, yet proper speed is necessary for RPM measurement, methods for proper staging of individual vehicles needed to be developed. Most ports involve some type of vehicle checkout procedure, but this could not be relied on to produce consistent vehicle speed through the RPM systems. Instead, the program engaged the HSI specialty to assist in developing appropriate signage and signaling that would ensure truck driver attention to RPM speed requirements.

HSI Methods Tailored to Time and Budget Constraints

Since the RPM program focus is homeland security, there has been schedule urgency from the beginning. The need for rapid deployment of RPM systems to maximize threat detection and minimize commercial impact has been the key program driver, and this has also influenced how the HSI discipline has been applied. The primary effect of program urgency and budgetary limitations has been to focus HSI efforts in work domain analysis, the modeling of human-system interactions, and theory-based analysis rather than experiment.

The work domain analysis has typically focused on gaining a rapid understanding of relatively complicated seaport operations in order to evaluate technology insertion opportunities and to better understand design requirements. In contrast to work domain analysis oriented toward cognitive decision aids, which requires time-intensive collaboration with subject matter experts, the RPM analysis worked at a coarser level to characterize staff functions and interactions, material flow, and operational tempo. Similarly, modeling of human-system interactions (such as responding to a traffic light or an intercom system) was performed at the level of detail necessary to facilitate design, rather than a comprehensive representation of operator cognitive processes—this was not required to support engineering.

Theory-based analysis of alarm system effectiveness has been conducted on a somewhat longer time scale, since the problem of human response to alarms is more complex. This work consisted of adapting traditional observer-based signal detection theory, in which the human is an active component of the detection system, to RPM systems in which the human operator evaluates the output of a sensor system that detects a threat precondition. Various threat probability analyses have been conducted in this effort, and they can be used to guide subsequent advanced RPM designs. This work has been guided by empirical studies, but it has not required an independent data collection effort.

Shared Representations Used to Communicate

The rapid-paced nature of the RPM program places a premium on effective communication between human-system integration and the engineering disciplines. In this program, fairly simple communication mechanisms that use graphics or presentation methods adapted from engineering have the best chance of successful communication. For example, it is important to evaluate the human error risks associated with new security screening systems so that mitigation approaches can be designed. One approach to describing this to the engineering community might be to simply borrow existing taxonomies from researchers in the field, such as Reason (1990). Alternatively, a more graphic and less verbose approach is to represent the approach as a fault tree, shown in Figure 5-2 . This type of representation is immediately recognizable to the engineering community and is less subject to interpretation than abstract descriptions of error typologies.

FIGURE 5-2 General model of human error analysis for security screening used as a shared representation to communicate the concept to engineering staff.

FIGURE 5-3 Graphical representation of work flow with a threat-based RPM display.

Human-system integration has used graphics to convey fairly abstract design ideas to the engineering staff, as shown in Figure 5-3 . This display conveys the concept of a threat likelihood display, which informs the RPM operator about the contents of a vehicle based on processing algorithms. The graphic contrasts the eight-step process shown in Figure 5-1 , with a four-step screening process, illustrating the functional utility of the display in a direct way.

Accommodation to Changing Conditions and Workplace Requirements

The RPM program started with a set of baseline designs for seaports that involved a cargo container passing through an exit gate. As the program expanded to a wider range of port operations, numerous variations in the container-processing operations became apparent. In some instances, the traffic volume is so low that the costs of installing a fixed installation are too high; alternatively, trenching limits or other physical constraints may preclude a fixed portal. Operational differences, such as moving containers direct to rail cars, also present challenges for design.

FIGURE 5-4 Standard truck exit RPM system (left), mobile RPM system (middle), and straddle carrier operation (right).

Figure 5-4 illustrates several variants of RPM operational configurations that have HSI implications. The truck exit shown in the figure is a standard design that accommodates the majority of seaport operations as they are currently configured. In order to accommodate reconfiguration and low volume, a mobile RPM system has been developed, as shown above. For ports at which straddle carriers are used to move containers directly to rail, solutions are currently being evaluated. Human-system integration has been directly responsible for operations studies of straddle carrier operation to discern technology insertion opportunities. The critical issue for seaports is that current operations do not predict future operations; the rapid expansion of imports will fundamentally alter how high-volume ports process their cargo, and HSI studies will be an important element of adapting the security screening technologies to evolving operational models.

Scalable Methods

The RPM program is large in scale—involving geographically distributed installations on a nationwide basis, multiple personnel, government agencies and private-sector stakeholders—and seaports are an element of

the nation’s critical infrastructure. To make an effective contribution in this context, human-system integration has focused on problems of an aggregate nature that affect multiple installations. The methods generally employed, such as work domain analysis, probabilistic risk modeling, and timeline analysis, are applicable at an individual operator, work group, or port-wide level. Scalability is inherent in the overall goals of method application (i.e., discerning general operational constraints and potential design solutions); in the process there are requirements for “one-off” tailored solutions, but the fundamental goal is to provide generic solutions.

Principles of System Development

The development of RPM systems for application in the seaport environment has entailed an iterative process that reflects the system development principles described in this book. This section discusses how these principles are reflected in the engineering process.

Success-Critical Stakeholder Satisficing

As mentioned above, this program involves the private sector (seaport terminal management and labor), local public agencies such as port authorities, local and national transportation companies such as railroads, federal government agencies (DHS), federal contractors, and, from time to time, other federal law enforcement agencies, such as the Federal Bureau of Investigation. The issues and requirements of all need to be addressed in RPM deployments. The dual program goals of maximizing threat detection and minimizing impact on commerce define the parameters for stakeholder satisficing.

Incremental Growth of System Definition and Stakeholder Commitment

The objective of minimal disruption to ongoing seaport operations and the need to identify traffic choke points and screening opportunities require considerable up-front analysis, as well as continuing evaluation of impact as individualized deployments are designed. The general activities in this category include

initial site surveys to identify choke points.

operational process analysis to identify traffic flow and screening procedures for individual seaport sites.

adaptation of baseline screening systems to specific seaport site constraints.

continued monitoring and evaluation of impact, including nuisance alarm rates and traffic flow, from design through deployment.

modification of RPM system elements as required to meet security and operational missions.

This process generally involves initial stakeholder meetings to establish the relationships necessary to adapt the technologies to individual operations. Based on information gathered in operational studies, conceptual designs (50-percent level) are proposed, reviewed, and revised as a more detailed understanding of requirements and impacts is obtained. This leads to more refined definitions of implementation requirements and operational impacts, which in turn lead to commitment at the 90-percent design review.

Risk Management

The multiple operational personnel involved in port security and seaport operations necessarily entails a variety of human factors risks when new technology is introduced. One of the major initial risks involved consideration of staffing, as customs and border protection authorities have not typically placed officers on site at seaports. A number of options for operating security equipment were evaluated, and the decision was made that CBP would staff the seaport sites with additional schedule rotations. This reduced the risk of relying on nonlaw enforcement personnel but increased the cost to the government (a trade-off). Other risks include generally low workload associated with processing alarms (a trade-off of boredom and cost, but physical presence is guaranteed), the gradual erosion of alarm credibility based on the exclusive occurrence of nuisance alarms (a trade-off of high sensitivity of detection system with potential for reduced effectiveness), risks of labor disputes as more complex technology is introduced that may be seen as infringing on private-sector territory (a trade-off of the risk of a complex labor situation with the need for security screening), and transfer of training procedure incompatibilities from one location to another (i.e., procedures vary considerably from one site to another, and staff rotate among these locations—a trade-off of procedural variability with the human ability to adapt).

HSI activities tend to be deployed in this program based on continuing assessment of risks associated with individual seaport deployments. For example, HSI operational studies of straddle carrier cargo operations were undertaken midway through seaport deployments, when it was recognized that existing technology solutions could not be adapted to that type of operation. The risk of using existing technology was that seaport operations would need to fundamentally change—this would lead to an unacceptable

impact on commerce. Thus operational studies were undertaken to identify potential technology insertion opportunities that would minimize the risk of commercial impact.

Concurrent System Definition and Development

The RPM program involves substantial concurrent engineering activity. The initial deployments have utilized relatively low-cost, high-sensitivity but low-resolution sensors made of polyvinyl toluene. These sensors are highly sensitive to radioactive material but tend to generate nuisance alarms because of low resolution of the type of radioactive material (naturally occurring versus threat material). While this yields high threat sensitivity, it is also nonspecific and creates a larger impact on commerce due to nuisance alarms and the need for secondary inspections.

However, development of advanced spectroscopic portals (ASPs) that utilize high-resolution sensors is taking place concurrently with the installation of lower resolution portals and will be deployed subsequently. These portals will be able to identify specific radioactive isotopes and will help to reduce nuisance alarms that create an adverse impact on commerce. Concurrent human factors research concerning threat-based displays will be used for developing appropriate end-user displays for the new systems.

“NEXT-GENERATION” INTRAVENOUS INFUSION PUMP

The next-generation infusion pump is a general-purpose intravenous infusion pump (IV pump) designed primarily for hospital use with secondary, limited-feature use by patients at home. The device is intended to deliver liquid medications, nutrients, blood, and other solutions at programmed flow rates, volumes, and time intervals via intravenous and other routes to a patient. The marketed name is the Symbiq™ IV Pump. The device will offer medication management features, including medication management safety software through a programmable drug library. The infuser will also have sufficient memory to support extensive tracking logs and the ability to communicate and integrate with hospital information systems. The infuser will be available as either a single-channel pump or a dual-channel pump. The two configurations can be linked together to form a 3- or 4-channel pump. The infuser includes a large touchscreen color display and can be powered by either A/C power or rechargeable batteries.

To ensure that the infuser has an easy-to-use user interface, the development of the product was based on a user-centered design approach. As part of the user-centered design approach, the team involved potential users at each phase in the design cycle. During the first phase, the team conducted interviews with potential users and stakeholders, including nurses, anes-

thesiologists, doctors, managers, hospital administrators, and biomedical technicians to gather user requirements. The team also conducted early research in the form of contextual observations and interviews in different clinical settings in hospitals as a means to understand user work flow involving infusion pumps. The information from these initial activities was used in the conceptual development phase of the next-generation infusion pump. Iterative design and evaluation took place in the development of each feature. Evaluations included interviews, usability testing in a laboratory setting, usability testing in a simulated patient environment, testing with low-fidelity paper prototypes, and testing with high-fidelity computer simulation prototypes. Computer simulations of the final user interface of each feature were used in focus groups to verify features and to obtain additional user feedback on ease of use before the final software coding began. In the final phases of development, extensive usability testing in simulated patient environments was conducted to ensure design intent has been implemented and that ease of use and usability objectives were met. Throughout the development process, iterative risk analysis, evaluation, and control were conducted in compliance with the federally regulated design control process (see Figures 5-5 and 5-6 ).

Motivation Behind the Design

The primary motivation was to design a state-of-the-art infusion pump that would be a breakthrough in terms of ease of use and improved patient safety. Over recent decades, the quality of the user interface in many IV pump designs has fallen under scrutiny due to many human factors–related issues, such as difficulty in setting up and managing a pump’s interface through careful control and display interplay. In the past 20 years, the type, shape, and use of pumps have been, from outward appearances, very similar and not highly differentiated among the different medical device manufacturers. In fall 2002, Hospira undertook a large-scale effort to redesign the IV pump. Their mission was to create a pump that was easier to set up, easier to manage, easier to oversee patient care, and easier to use safely to help the caregiver prevent medication delivery errors. There was a clear market need for a new-generation IV pump. The Institute of Medicine in 2000 estimated 98,000 deaths a year in the United States due to medical errors (Institute of Medicine, 2000).

The User-Centered Design Process in the Context of the Incremental Commitment Model

The Symbiq™ IV Pump followed a classic user-centered design process, with multiple iterations and decision gates that are typically part of the in-

FIGURE 5-5 Two channel IV pumps with left channel illuminated. Photographs courtesy of Hospira, Inc.

FIGURE 5-6 IV tube management features. Photographs courtesy of Hospira, Inc.

cremental commitment model of product development. Risk management was a central theme in the development, both in terms of reducing project completion and cost risks and managing the risk of adverse events to patients connected to the device. Many of the interim project deliverables, such as fully interactive simulations of graphical user interfaces (GUI), were in the form of shared representations of the design, so that all development team members had the same understanding of the product requirements during the development cycle.

Following a classic human factors approach to device design, the nurse user was the primary influence on the design of the interface and the design of the hardware. Physicians and home patient users were also included in the user profiles. Hospira embarked on a multiphase, user-centered design program that included more than 10 user studies, in-depth interviews, field observations, and numerous design reviews, each aimed at meeting the user’s expectations and improving the intelligence of the pump software aimed at preventing medication errors.

Preliminary Research

Much preliminary work needed to be done in order to kick off this development. A well-known management and marketing planning firm was hired to lead concept analysis in which the following areas were researched:

Comparison of the next-generation pump and major competitors, using traditional strengths/weaknesses/opportunities methodology, included the following features:

Physical specifications

Pump capabilities, e.g., number of channels

Programming options

Set features

Pressure capabilities

Management of air in line

Biomedical indicators

Competitive advantages of the next-generation pump were identified in the following areas:

Bar code reading capability with ergonomic reading wand

Small size and light weight

Standalone functional channels (easier work flow, flexible regarding number of pumping channels)

Extensive drug library (able to set hard and soft limits for the same drug for different profiles of use)

High-level reliability

Clear mapping of screen and pumping channels

Vertical tubing orientation that is clear and simple

An extensive competitive analysis was undertaken, against the five largest market leaders. Task flows and feature lists and capabilities were created. A prioritization of the possible competitive advantage features and their development cost estimates was generated and analyzed.

Business risks were examined using different business case scenarios and different assumptions about design with input from the outside management consultants. Engineering consultants assisted Hospira with input on technical development issues and costs, including pump mechanisms, software platforms, and display alternatives.

Extensive market research was conducted as well to identify market windows, market segment analyses, pricing alternatives, hospital purchasing decision processes, and the influence of outside clinical practice safety groups. Key leaders in critical care were assembled in focus groups and individually to assess these marketing parameters. This process was repeated. Key outcomes were put into the product concept plan and its marketing product description document. This document also captured current and future user work needs and the related environments.

The concept team reached a decision gate with the concurrence of the management steering committee. The project plan and budget were approved and development began. Again, business risks were assessed. This step is typical in an ICM development approach.

Design Decisions

A fundamental architecture decision was reached to have an integrated design with either one or two delivery channels in a single integrated unit. Two or more integrated units could themselves be connected side by side in order to obtain up to four IV channel lines. This alternate was chosen over the competing concept of having modular pumping units that would interconnect and could be stacked onto one master unit to create multiple channels. The integrated master unit approach won out based on problems uncovered from the market research, such as a higher likelihood of lost modular units, inventory problems, and reduced battery life.

Feature Needs and Their Rationale

Based on the preliminary market research and on an analysis of medical device reports from the Food and Drug Administration (FDA) as well as complaints data from the Hospira customer service organization, the Marketing Requirements Document was completed and preliminary decisions were made to include the features described in this section. Field studies and contextual inquiry were planned as follow-on research to verify the need for these features and to collect more detail on how they would be designed.

Types of programmable therapies. Decisions were made to offer a set of complex therapies in addition to the traditional simple therapies usually offered by volumetric IV pumps. The traditional simple therapies were

continuous delivery for a specified period of time (often called mL/Hr delivery).

weight-based dosing, which requires entering the patient’s weight and the ordered drug delivery rate.

bolus delivery (delivery of a dose of medication over a relatively short period of time).

piggyback delivery (the delivery type that requires Channel A delivery suspension while Channel B delivers and then its resumption when Channel B completes).

The more complex therapies included

tapered therapy (ramping up and down of a medicine with a programmed timeline. It is sometimes used for delivery of nutritional and hydration fluids, called total parenteral nutrition).

intermittent therapy (delivery of varying rates of medication at programmed time intervals).

variable time delivery.

multistep delivery.

Business risks were examined to understand the sales consequences of including these features of therapy types to address the issue of stakeholder satisficing.

Medication libraries with hard and soft dosage limits. Research uncovered that several outside patient safety advocate agencies, including the Emergency Care Research Institute and the Institute for Safe Medical Practices were recommending only IV pumps with safety software consisting of upper and lower dosage limits for different drugs as a function of the

programmed clinical care area in a hospital. (Clinical care areas include emergency room, intensive care unit, oncology, pediatrics, transplants, etc.) It became clear that it would have been imperative to have safety software in the form of medication libraries that were programmed by each hospital to have soft limits (which could be overridden by nurses with permission codes) and hard limits (that could under no circumstances be overridden). It was decided at this time that separate software applications would need to written that would be used by hospital pharmacy and safety committees to enter drugs in a library table with these soft and hard limits, which would vary by clinical care area in the hospital. This is an example of incremental growth and stakeholder commitment in the design process.

Large color touch screen. A human factors literature review was conducted to create a list of advantages and disadvantages of various input and display technologies. This research was supplemented with engineering data on the costs and reliabilities of these technologies. Again, business risks were examined, including reliability of supply of various display vendors. After much research and debate, the list of choices was narrowed to three vendors of touch-sensitive color LCD displays.

This was a breakthrough, in the sense that no current on-market IV pumps were using color touchscreen technology. A large 8.4-inch diagonal color LCD display with resistive touchscreen input was selected for further testing. A resistive touchscreen was believed to reduce errors due to poor screen response to light finger touch forces.

Another issue that required some data from use environment analysis was the required angle of view and display brightness under various use scenarios. Subsequent contextual inquiry data did verify the need for viewing angles of at least +/- 60 degrees horizontal viewing and +/- 30 degrees vertical viewing angles. The minimum brightness or luminance levels were verified at 35 candelas per square meter. A business risk analysis examined the trade-offs between a large touchscreen display and the conflicting customer desire for small footprint IV pumps. The larger display size of 8.4-inch diagonal would allow larger on-screen buttons to minimize use errors due to inadvertent selection of adjacent on-screen buttons as well as allowing larger more readable on-screen text. Again, human factors research literature and standards on display usability were included in these decisions.

Special alarms with melodies. FDA medical device reports and customer complaint data reinforced the need for more effective visual and auditory alarms to alert IV pump users to pump fault conditions, such as air in line, occlusion in IV tubing, pending battery failure, IV bag nearly empty or unsafe dosage rates for a particular drug in a specific critical care area.

The team also decided to adopt the recommendations of the International Electrotechnical Commission (IEC) for an international standard for medical device auditory alarms to use unique melody patterns for IV pumps to distinguish these devices from other critical care devices, such as ventilators and vital sign patient monitors. These auditory alarms were later subjected to extensive lab and field studies for effectiveness and acceptability.

An early beta test in actual hospital settings with extended use subsequently showed user dissatisfaction with the harshness of some of the alarm melodies. The IEC standard had purposely recommended a discordant set of tone melodies for the highest alarm level, but clinicians, patients, and their families complained that they were too harsh and irritating. Some clinicians complained that they would not use these IV pumps at all, unless the alarms were modified. Or worse, they would permanently disable the alarms, which would create a very risky use environment.

This outcome highlights a well-known dilemma for human factors: lab studies are imperfect predictors of user behavior and attitudes in a real-world, extended-use setting. The previous lab usability studies were by their very nature short-duration exposures to these tones and showed that they were effective and alerting, but they did not capture long-term subjective preference ratings. A tone design specialist was engaged who redesigned the tones to be more acceptable, while still being alerting, attention grabbing, and still in compliance with the IEC alarm standard for melodies. Subsequent comparative usability evaluations (group demonstrations and interviews) demonstrated the acceptability of the redesigned melodies. This is a prime example of design iteration and concurrent system definition and development.

Semiautomatic cassette loading. Another early decision involved choosing between a traditional manual loading of the cassette into the IV pump or a semiautomated system, in which a motor draws a compartment into the pumping mechanism, after the clinician initially places the cassette into the loading compartment. The cassette is in line with the IV tubing and IV bag containing the medication. The volumetric pumping action is done through mechanical fingers, which activate diaphragms in the plastic cassette mechanism. Customer complaint history suggested the need for the semiautomated system to avoid use error in loading the cassette and to provide a fail-safe mechanism to close off flow in the IV line except when it was inserted properly into the IV pump.

A major problem with earlier cassette-based volumetric IV pump systems was the problem of “free flow,” in which medication could flow uncontrolled into a patient due to gravitational forces, with the possibility of severe adverse events. Early risk analysis and evaluation were done from both a business and use-error safety perspective to examine the benefit of

the semiautomated loading mechanism. Later usability testing and mechanical bench testing validated the decision to select the semiautomated loading feature.

A related decision was to embed a unique LED-based lighting indication system into the cassette loading compartment that would signal with colored red, yellow, and green lights and steady versus flashing conditions the state of the IV pump in general and specifically of the cassette loading mechanism. The lights needed to be visible from at least 9 feet to indicate that the IV pump is running normally, pump is stopped, cassette is improperly loaded, cassette compartment drawer is in the process of activation, etc.

Special pole mounting hardware. Again, data from the FDA medical device reports and customer complaints indicated the need for innovative mechanisms for the mounting of the IV pump on poles. Later contextual inquiry and field shadowing exercises validated the need for special features allowing for the rapid connection and dismounting of the IV pump to the pole via quick release/activation mechanisms that employed ratchet-like slip clutches. Subsequent ergonomics-focused usability tests of hardware mechanisms validated the need and usability of these design innovations for mounting on both IV poles and special bed-mounted poles, to accommodate IV pumps while a patient’s bed is being moved from one hospital department to another.

Risk analyses for business and safety risks were updated to include these design decisions. Industrial design models were built to prototype these concepts, and these working prototypes were subjected to subsequent lab-based usability testing. Again, these actions are examples of stakeholder satisficing, incremental growth of system definition, and iterative system design.

Stacking requirements. Given the earlier conceptual design decision to have an integrated IV pump rather than using add-on pumping channel modules, decisions were needed on how integrated IV pumps could be stacked together to create additional channels. A concomitant decision was that the integrated IV pump would be offered with either one or two integrated channels. Based on risk assessment, it was decided to allow side-by-side stacking to allow the creation of a 4-channel system when desired. The 4-channel system would be electronically integrated and allow the user interface to operate as one system. Again, trade-off analyses of risks were made against the competing customer need for a smaller device size footprint. A related design decision was to have an industrial design that allowed handles for easy transportation, but would also allow stable vertical stacking, while the units are stored between uses in the biomedi-

cal engineering department. Market research clearly indicated the need for vertical stacking in crowded storage areas. To facilitate safe storage of the pumps, the special pole clamps were made removable.

Tubing management. A well-known use-error problem of tangled and confusing IV tubing lines was addressed in the housing design by including several holders for storing excess tubing. Notches were also included to keep tubes organized and straight to reduce line-crossing confusion. These same holders were built as slight protrusions that protected the touchscreen from damage and inadvertent touch activation, if the pump were to be laid on its side or brushed against other medical devices.

Many other preliminary design decisions were made in these early stages that were based on both business and use-error risk analysis. In all cases, these decisions were verified and validated with subsequent data from usability tests and from field trials.

Design Process Details

The development of the Symbiq™ IV Pump followed the acknowledged best practices iterative user-centered design process as described in medical device standards (ANSI/AAMI HE 74:2001, IEC 60601-1-6:2004, and FDA human factors guidance for medical device design controls). The following sections are brief descriptions of what was done. Table 5-2 outlines the use of these human factors techniques and some areas for methodology improvements.

Contextual Inquiry

Contextual inquiry was done by multiple nurse shadowing visits to the most important clinical care areas in several representative hospitals. Several team members spent approximately a half-day shadowing nurses using IV pumps and other medical devices and observing their behaviors and problems. A checklist was used to record behaviors and, as time permitted, ask about problem areas with IV pumps and features that needed attention during the design process. Subsequent to the field visits, one-on-one interviews with nurses were conducted to explore in depth the contextual inquiry observations. These observations and interviews were used to generate the following elements:

task analyses

use environment analyses

user profiles analyses

Figure 5-7 shows an example of one of many task flow diagrams generated during the task analyses phases of the contextual inquiry.

Setting Usability Objectives

Quantitative usability objectives were set based on data from the contextual inquiry, user interviews, and the previous market research. Early use-error risk analysis highlighted tasks that were likely to have high risk, with particular attention to setting usability objectives to ensure that these user interface design mitigations were effective. Experience with earlier IV pump designs and user performance in usability tests also influenced the setting of these usability objectives. The objectives were primarily based on successful task performance measures and secondarily on user satisfaction measures. Examples of usability objectives were

90 percent of experienced nurses would be able to insert the cassette the first time while receiving minimal training; 99 percent would be able to correct any insertion errors.

90 percent of first-time users with no training would be able to power the pump off when directed.

90 percent of experienced nurses would be able to clear an alarm within 1 minute as first-time users with minimal training.

80 percent of patient users would rate the overall ease of use of the IV pump 3 or higher on a 5-point scale of satisfaction with 5 being the highest value.

Early Risk Management

Many rounds of iterative risk analysis, risk evaluation, and risk control were initiated at the earliest stages of design. The risk-management process followed recognized standards in the area of medical device design (e.g., ISO 14971:2000, see International Organization for Standardization, 2000a). The risk analysis process was documented in the form of a failure modes and effects analysis (FMEA), which is described in more detail in Chapter 8 . Table 5-3 presents excerpts from the early Symbiq™ FMEA. Business and project completion risks were frequently addressed at phase review and management review meetings.

The concept of risk priority number (RPN) was used in the operation risk assessment for the Symbiq™ infusion system. RPN is the resulting product of multiplying fault probability times risk hazard severity times probability of detecting the fault. A maximum RPN value is typically 125, and decision rules require careful examination of mitigation when the RPN

TABLE 5-2 Methodology Issues and Research Needs

FIGURE 5-7 Illustrative task flow diagram from the task analysis.

values exceed a value of 45. RPN values between 8 and 45 require an explanation or justification of how the risk is controlled.

The product requirements document (PDR) was formally created at this point to describe the details of the product design. It was considered a draft for revision as testing and other data became available. It was based on the customer needs expressed in the marketing requirements document. This document recorded the incremental growth of system definitions and stakeholder commitment and served as a shared representation of the design requirements for the development team.

Many prototypes and simulations were created for evaluation:

Hardware models and alternatives considered

hardware industrial design mock-ups

early usability tests of hardware mock-ups.

Paper prototypes for graphical user interfaces with wireframes consisting of basic shapes, such as boxes and buttons without finished detail graphic elements.

GUI simulations using Flash™ animations. 1

Early usability tests with hardware mock-ups and embedded software that delivered the Flash™ animations to a touchscreen interface that was integrated into the hardware case.

Flash animations are excellent examples of shared representations because they were directly used in the product requirements document to specify to software engineering exactly how the GUI was to be developed. All team discussions regarding GUI design were focused exclusively on the Flash animation shared representations of the Symbiq™ user interface.

Integrated Hardware and Software Models with Integrated Usability Tests

As noted earlier, the usability tests performed later in the development cycle were done with integrated hardware mock-ups and software simulations. Usability test tasks were driven by tasks with high-risk index values in the risk analysis, specifically the FMEA. Tasks were also included that had formal usability objectives associated with them. Although the majority of usability test tasks were focused on the interaction with the touchscreen-

TABLE 5-3 Excerpts from Symbiq™ Failure Modes and Effects Analysis (FMEA)

based graphical user interface, critical pump-handling tasks were included as well, such as IV pump mounting and dismounting on typical IV poles.

Tests of Alarm Criticality and Alerting

The initial alarm formative usability studies, described earlier, had the goal of selecting alarms that would be alerting, attention getting, and properly convey alarm priority, as well as communicating appropriate actions. These formative studies evaluated the subject’s abilities to identify and dis-

criminate among different visual alarm dimensions, including colors, flash rates, and text size and contrast. For auditory alarms, subjects were tested on their ability to discriminate among various tones with and without melodies and among various cadences and tone sequences for priority levels and detectability. Subjects were asked to rate the candidate tones relative to a standard tone, which was given a value of 100. The standard was the alternating high-low European-style police siren. Subjective measures were also gathered on the tones using the PAD rating system, standing for perceived tone pleasure, arousal, and dominance, as well as perceived criticality. Data

from these studies enabled the team to make further incremental decisions on system definitions for both visual and auditory alarms and alerts.

Tests of Display Readability

Another set of early formative usability tests was conducted to validate the selection of the particular LCD touchscreen for readability and legibility. During the evaluation it was determined that the screen angle (75 degrees) and overall curvature were acceptable. The screen could be read in all tested light conditions at a 15-foot viewing distance.

Iterative Usability Tests

As noted, a series of 10 usability studies were conducted iteratively as the design progressed from early wireframes to the completed user interface with all the major features implemented in a working IV pump. In one of the intermediate formative usability tests, a patient simulator facility was used at a major teaching hospital. Users performed a variety of critical tasks in a simulated room in an intensive care unit, in which other medical devices interacted and produced noises and other distractions. The prototype IV pump delivered fluid to a mannequin connected to a patient monitor that included all vital signs. As the pump was programmed and subsequently changed (e.g., doses titrated), the software-controlled patient mannequin would respond accordingly. The patient simulator also introduced ringing telephones and other realistic conditions during the usability test. This test environment helped in proving the usability of visual alarms and tones, as well as the understandability and readability of the visual displays. Final summative usability tests demonstrated that the usability objectives for the pump were achieved.

Focus Groups

Focus groups of nurses were also used as part of the usability evaluation process. These were used to complement the task-based usability tests. Many of the focus groups had a task performance component. Typically the participants would perform some tasks with new and old versions of design changes, such as time entry widgets on the touchscreen, and then convene to discuss and rate their experiences. This allowed a behavioral component and addressed one of the major shortcomings of typical focus groups, that they focus only on opinions and attitudes and not behaviors.

Field Studies

Field studies in the form of medical device studies have also been incorporated in the design process. Thoroughly bench-tested and working beta versions of the IV pump were deployed in two hospital settings. The hospitals programmed drug libraries for at least two clinical care areas. The devices were used for about 4 weeks. Surveys and interviews were conducted with the users to capture their real-world experiences with the pump. Data from the pump usage and interaction memory were also analyzed and compared with original doctor’s orders. This study revealed a number of opportunities to make improvements, including the problem with the perceived annoyance of the alarm melodies and the data entry methods for entering units of medication delivery time (e.g., hours or minutes).

Instructions for Use Development and Testing

Usability testing was also conducted on one of the sets of abbreviated instructions called TIPS cards. These cards serve as reminders for how to complete the most critical tasks. These usability studies involved 15 experienced nurses with minimal instructions performing 9 tasks with the requirement that they read and use the TIPS cards. Numerous suggestions for improvement in the TIPS cards themselves as well as the user interface came from this work, including how to reset the air-in-line alarm and how to address the alarm and check all on-screen help text for accuracy.

Validation Usability Tests

Two rounds of summative usability testing were conducted, again with experienced nurses performing critical tasks identified during the task analysis, including those with higher risk values in the risk analysis. The tasks were selected to simulate situations that the nurses may encounter while using the IV pump in a hospital setting. The tasks included selecting a clinical care area, programming simple deliveries, adding more volume at the end of an infusion, setting a “near end of infusion” alarm, titration, dose calculations, piggyback deliveries, intermittent deliveries, using standby, programming a lock, adjusting the alarm volume, and responding to messages regarding alarms.

Usability objectives were used as acceptance criteria for the summative validation usability tests. The study objectives were met. The calculated task completion accuracy was 99.66 percent for all tasks for first-time nurse users with minimal training. The null hypothesis that 80 percent of the participants would rate the usability 3 or higher on a 5-point scale in the overall categories was met. There were a few minor usability problems

uncovered that were subsequently fixed without major changes to the user interface or that affected critical safety-related tasks.

Federal regulations on product design controls require that a product’s user interface be validated with the final working product in a simulated work environment. In this instance, the working product was used in a laboratory test, but without having the device connected to an actual patient. Bench testing is also a part of validation to ensure that all mechanical and electrical specifications and requirements have been met.

Revised Risk Analysis

As part of the incremental commitment model, the risk analysis was iterated and revised as the product development matured. FMEAs were updated for three product areas, which were safety-critical risks associated with the user interface, the mechanical and electrical subsystems, and the product manufacturing process. Explicit analysis of the business risks and the costs of continued financial commitment to the funding of development were also incremented and reviewed at various management and phase reviews.

Product Introduction

Product introduction planning included data collection from initial users to better understand remaining usage issues that can be uncovered only during prolonged usage in realistic clinical conditions. The many cycles of laboratory-based usability testing typically are never detailed enough or long enough to uncover all usability problems. The plan is to use the company complaint handling and resolution process (e.g., corrective action and preventive action) to address use issues if they arise after product introduction.

Life-Cycle Planning

The product was developed as a platform for the next generation of infusion pump products. As such, there will be continued business risk assessment during the life cycle of this first product on the new platform as well as on subsequent products and feature extensions.

Summary of Design Issues and Methods Used

This infusion pump incorporated the best practices of user-centered design in order to address the serious user interface deficiencies of previous infusion pumps. The development process took excellent advantage of the

detailed amount of data that is derived from an integrated HSI approach and used it to improve and optimize the safety and usability of the design. Because of these efforts, the Symbiq™ IV Pump won the 2006 Human Factors and Ergonomics Society award for best new product design from the product design technical group.

This case study also illustrates and incorporates the central themes of this report:

Human-system integration must be an integral part of systems engineering.

Begin HSI contributions to development early and continue them throughout the development life cycle.

Adopt a risk-driven approach to determining needs for HSI activity (multiple applications of risk management to both business and safety risks).

Tailor methods to time and budget constraints (scalability).

Ensure communication among stakeholders of HSI outputs (shared representations).

Design to accommodate changing conditions and requirements in the workplace (the use of iterative design and the incremental commitment model).

This case study also demonstrates the five key principles that are integral parts of the incremental commitment model of development: (1) stakeholder satisficing, (2) incremental growth of system definition and stakeholder commitment, (3) iterative system development, (4) concurrent system definition and development, and (5) risk management—risk-driven activity levels.

This page intentionally left blank.

In April 1991 BusinessWeek ran a cover story entitled, "I Can't Work This ?#!!@ Thing," about the difficulties many people have with consumer products, such as cell phones and VCRs. More than 15 years later, the situation is much the same—but at a very different level of scale. The disconnect between people and technology has had society-wide consequences in the large-scale system accidents from major human error, such as those at Three Mile Island and in Chernobyl.

To prevent both the individually annoying and nationally significant consequences, human capabilities and needs must be considered early and throughout system design and development. One challenge for such consideration has been providing the background and data needed for the seamless integration of humans into the design process from various perspectives: human factors engineering, manpower, personnel, training, safety and health, and, in the military, habitability and survivability. This collection of development activities has come to be called human-system integration (HSI). Human-System Integration in the System Development Process reviews in detail more than 20 categories of HSI methods to provide invaluable guidance and information for system designers and developers.

READ FREE ONLINE

Welcome to OpenBook!

You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

Do you want to take a quick tour of the OpenBook's features?

Show this book's table of contents , where you can jump to any chapter by name.

...or use these buttons to go back to the previous chapter or skip to the next one.

Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

Switch between the Original Pages , where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

To search the entire text of this book, type in your search term here and press Enter .

Share a link to this book page on your preferred social network or via email.

View our suggested citation for this chapter.

Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

Get Email Updates

Do you enjoy reading reports from the Academies online for free ? Sign up for email notifications and we'll let you know about new publications in your areas of interest when they're released.

The Ultimate Guide to Understanding and Using a System Development Life Cycle

By Kate Eby | June 27, 2017

• Share on Facebook
• Share on LinkedIn

Link copied

There is a lot of literature on specific systems development life cycle (SDLC) methodologies, tools, and applications for successful system deployment. Not just limited to purely technical activities, SDLC involves process and procedure development, change management, identifying user experiences, policy/procedure development, user impact, and proper security procedures. Books such as David Avison and Guy Fitzgerald’s Information Systems Development and Alan Daniels and Don Yeates’ Basic Systems Analysis , delve into the intricacies of information systems development lifecycles.  This article will provide an in-depth analysis of the history, definition, phases, benefits, and disadvantages, along with solutions that support the system development life cycle.

What Is a System Development Life Cycle?

In order to understand the concept of system development life cycle, we must first define a system. A system is any information technology component - hardware, software, or a combination of the two. Each system goes through a development life cycle from initial planning through to disposition. Some methodologies provide the necessary framework to guide the challenging and complex process with an aim to avoid costly mistakes and expedite development, all of which have the same goal of moving physical or software-based systems through phases.

A system development life cycle is similar to a project life cycle. In fact, in many cases, SDLC is considered a phased project model that defines the organizational, personnel, policy, and budgeting constraints of a large scale systems project. The term “project” implies that there is a beginning and an end to the cycle and the methods inherent in a systems development life cycle strategy provide clear, distinct, and defined phases of work in the elements of planning, designing, testing, deploying, and maintaining information systems.

Those involved in the SDLC include the c-suite executives, but it is the project/program managers, software and systems engineers, users, and the development team who handle the multi-layered process. Each project has its own level of complexity in planning and execution, and often within an organization, project managers employ numerous SDLC methods. Even when an enterprise utilizes the same methods, different project tools and techniques can differ dramatically.

History and Origin of the System Development Lifecycle

Completely defined in 1971, the term originated in the 1960s when mainframe computers filled entire rooms and a pressing need developed to define processes and equipment centered on building large business systems. In those days, teams were small, centralized, and users were ‘less’ demanding. This type of scenario meant that there was not a true need for refined methodologies to drive the life cycle of system development. However, technology has evolved, systems have become increasingly complex, and users have become accustomed to well-functioning technology. Models and frameworks have been developed to guide companies through an organized system development life cycle. Today, the traditional approaches to technology system development have been adjusted to meet the ever-changing, complex needs of each unique organization and their users. Below you will find sequential steps to SDLC, but each company will vary in their process.

The Phases of SDLC

The SDLC framework provides a step-by-step guide through the phases of implementing both a physical and software based system. A variety of models are available, but whether utilizing the oldest method of SDLC, the waterfall method , adopting an Agile method , or employing a hybrid of several methods, all methods embrace a phased iterative structure that you can adapt to your organization’s needs.  You may find phases with varying naming conventions, but these are the most common stages of SDLC. Organizations may adopt any, all, or a variation of these phases:

• Analysis/Feasibility: For an SDLC strategy to work there should be a strong idea of what deficiencies exist in the current structure and the goals for the new approach. A feasibility study determines if you can or should accomplish the goals of the plan. Information is gathered and analyzed to identify what technical assets, personnel, and training is already in place and utilized. The study also inventories what is needed to augment or replace, and at what cost. During this phase you determine the overall project scope, including economic, operational and human factors, identify key personnel, and develop timelines. 
• Planning/Requirements: A plan can include adapting a current system to meet new needs or developing a completely new system. This phase defines user requirements, identifies needed features, functions, and customizations, and investigates overall capabilities
• Design: Once you make the plan and identify costs, systems, and user requirements, a detailed system design can begin that includes features and other documentation. The architects can then build a sample framework.
• System Development: An approved design is the catalyst for authorizing development for the new or augmented system. Some say that this is the most robust part of the life cycle. During this phase, developers write code and you construct and fine-tune technical and physical configurations. 
• Testing: Users are brought in to test before deployment to identify areas of concern or improvement.
• Deployment: The system is put into a production environment and used to conduct business.
• Maintenance: The cyclical nature of SDLC recognizes that the process of change and upgrading are constant. Carry out the replacement of outdated hardware/software, security upgrades, and continuous improvement on a regular basis. 
• Evaluation:  An often overlooked element of any large scale system roll-out is the evaluation process, which supports the continuous improvement of the system. The team continuously reviews what is working and what is in need of improvement. This can mean recommending additional training, procedures, or upgrades.
• Disposition/Disposal/End-of-Life: A well-rounded life cycle identifies and decommissions surplus or obsolete assets at the end of their life cycle. Included in this phase is the secure retrieval of data and information for preservation, as well as, the physical disposition of an asset.

Following each phase of a system development life cycle the team and project manager may establish a baseline or milestones in the process. The baseline may include start date, end date, phase/stage duration, and budget data. These baseline assists the project manager in monitoring performance.

There is an increased interest in system security at all levels of the life cycle, that include the elements of confidentiality, information availability, the integrity of the information, overall system protection, and risk mitigation . Aligning the development team and the security team is a best practice that ensures security measures are built into the various phases of the system development life cycle. For example, SAMM, the Software Assurance Maturity Model is a framework that aids organizations in evaluating their software security practices, building security programs, demonstrating security improvements, and measuring security-related activities. In addition, governance and regulations have found their way into technology, and stringent requirements for data integrity impact the team developing technology systems. Regulations impact organizations differently, but the most common are Sarbanes-Oxley, COBIT, and HIPAA.

Each company will have their own defined best practices for the various stages of development. For example, testing may involve a defined number of end users and use case scenarios in order to be deemed successful, and maintenance may include quarterly, mandatory system upgrades.

Benefits of a Well-Defined System Development Life Cycle

There are numerous benefits for deploying a system development life cycle that include the ability to pre-plan and analyze structured phases and goals. The goal-oriented processes of SDLC are not limited to a one-size-fits-all methodology and can be adapted to meet changing needs. However, if well-defined for your business, you can:

• Have a clear view of the entire project, the personnel involved, staffing requirements, a defined timeline, and precise objectives to close each phase.  
• Base costs and staffing decisions on concrete information and need.  
• Provide verification, goals, and deliverables that meet design and development standards for each step of the project, developing extensive documentation throughout. 
• Provide developers a measure of control through the iterative, phased approach, which usually begins with an analysis of costs and timelines.  
• Improve the quality of the final system with verification at each phase.

Disadvantages of a Structured System Development Life Cycle

In these same areas, there are some who find disadvantages when following a structured SDLC. Some of the downfalls include:

• Many of the methods are considered inflexible, and some suffer from outdated processes. 
• Since you base the plan on requirements and assumptions made well ahead of the project’s deployment, many practitioners identify difficulty in responding to changing circumstances in the life cycle. 
• Some consider the structured nature of SDLC to be time and cost prohibitive.
• Some teams find it too complex to estimate costs, are unable to define details early on in the project, and do not like rigidly defined requirements.
• Testing at the end of the life cycle is not favorable to all development teams. Many prefer to test throughout their process.
• The documentation involved in a structured SDLC approach can be overwhelming.
• Teams who prefer to move between stages quickly and even move back to a previous phase find the structured phase approach challenging.

Another Form of SDLC: The Software Development Life Cycle

When the word “systems” is replaced with the word “software,” it creates another version of SDLC. The Software Development Life Cycle follows an international standard known as ISO 12207 2008. In this standard, phasing similar to the traditional systems development life cycle is outlined to include the acquisition of software, development of new software, operations, maintenance, and disposal of software products. An identified area of growing concern and increased adoption continues to revolve around the need for enhanced security functionality and data protection. Like systems development life cycle, discussed previously, there are numerous methods and frameworks that you can adopt for software development including:

• The Waterfall Method is a steady sequence of activity that flows in a downward direction much like its name. This traditional engineering process that closes each phase upon completion is often criticized for being too rigid.
• The V-Shaped Model is an adaptation of Waterfall that has testing as an integral part to close each phase.
• The Prototype Method advocates a plan to build numerous software methods that allow different elements to be “tried-out” before fully developing them. The Prototype method can increase “buy-in” by users/customers. 
• Rapid Application Development (RAD) is a hybrid of the prototype method, but works to de-emphasize initial planning to rapidly prototype and test potential solutions.
• The Spiral Method provides more process steps, which are graphically viewed in a spiral formation and is generally credited to provide greater flexibility and process adaptation.
• Agile Methods are software-based systems that provide feedback through an iterative process and include Kanban , Scrum , Extreme Programming (XP) , and Dynamic systems development method (DSDM).

Other models and methods include Synchronize and Stabilize, Dynamic Systems Development (DSDM), Big Bang Model, Fountain, and Evolutionary Prototyping Model, among others. Each has elements of a defined stepped process with variations to adapt for flexibility. Choosing the right SDLC method is critical for the success of your development project as well as for your business. There is not a hard and fast rule that you must choose only a single methodology for each project, but if you are to invest in a methodology and supporting tools, it is wise to utilize them as much as possible. To choose the right methodology you must first:

• Understand the various methodologies, their advantages, and disadvantages.
• Become familiar with the team dynamics, stakeholders involved, and the projects you will be managing.
• Compare the methodologies to the criteria your team has defined and business facts – size of your team, type of technology projects, complexity of projects, etc. The methodology should be easy for the team to understand and learn. 
• Share the decision and reasoning with your team and stakeholders.

Project Managing the System Development Life Cycle

The iterative and phased stages of an SDLC benefit from the leadership of a dedicated project manager. The major goal of an SDLC is to provide cost effective and appropriate enhancements or changes to the information system that meet overall corporate goals. The project manager is responsible for executing and closing all the linear steps of planning, building, and maintaining the new or improved system throughout the process. 

Other elements for the project manager involve administration of human elements including communication, change management strategies, and training, initiating and driving the planning for the project, setting and monitoring goals, providing avenues for communication and training, and keeping track of budgets and timelines. The project manager is the overall control agent for a strong SDLC process.

Software Solutions That Support the System Development Life Cycle

SDLC products from software vendors promise organizational clarity, modern process development procedures, legacy application strategies, and improved security features. Many options provide customized or integrated solutions. Vendors such as Oracle, Airbrake, and Veracode provide software development solutions in their complete enterprise software offerings. Many of these vendors also have a strong focus on identifying and de-bugging systems that may support the process of testing in software development life cycles. In many cases, SDLC teams utilize a variety of software solutions to support the varying stages. For example, requirements may be gathered, tracked and managed in one solution while testing use cases may take place in a completely different solution. 

Regardless of the process implemented and the tools used, all require the crucial element of documentation to support findings, close iterative phases, and to analyze success. Today’s increasing demand for data and information security also factor into the overall planning, training, testing, and deployment of a system. However, one of the most important elements of success of any SDLC method continues to be in the initial planning, followed by choosing the appropriate framework and method, and finally sticking to, deploying, and maintaining a robust project plan.

Start Managing Your System Development Life Cycle with a Helpful Template

Project managers in charge of SDLC need the right tools to help manage the entire process, provide visibility to key stakeholders, and create a central repository for documentation created during each phase. One such tool is Smartsheet, a work management and automation platform that enables enterprises and teams to work better. 

With its customizable spreadsheet interface and powerful collaboration features, Smartsheet allows for streamlined project and process management. Use Smartsheet’s SDLC with Gantt template to get started quickly, and help manage the planning, development, testing, and deployment stages of system development. Create a timeline with milestones and dependencies to track progress, and set up automated alerts to notify you as anything changes. Share your plan with your team and key stakeholders to provide visibility, and assign tasks to individuals to ensure nothing slips through the cracks.

Try the Smartsheet SDLC template for free, today.

Create Your SDLC Plan in Smartsheet

A Better Way to Manage System and Software Development Life Cycles

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time.  Try Smartsheet for free, today.

Discover why over 90% of Fortune 100 companies trust Smartsheet to get work done.

• System Design Tutorial
• What is System Design
• System Design Life Cycle
• High Level Design HLD
• Low Level Design LLD
• Design Patterns
• UML Diagrams
• System Design Interview Guide
• Crack System Design Round
• System Design Bootcamp
• System Design Interview Questions
• Microservices
• Scalability

System Development Life Cycle

The System Development Life Cycle (SDLC) provides a well-structured framework that gives an idea, of how to build a system. It consists of steps as follows – Plan, Analyze, Design, Develop, Implement and Maintain. In this article, we will see all the stages of system development.

Important Topics for the System Development Life Cycle

Stage 1: Plan

Stage 2: analyze, stage 3: design, stage 4: develop, stage 5: implement, stage 6: maintain, how is system development life cycle different from system design life cycle, significance of system design in system development life cycle.

We will delve into the significance of each stage, emphasizing the critical role played by System Design in the overall process.

Stages (Phases) of System Development Life Cycle

The System Development Life Cycle encompasses a series of interconnected stages that ensure a systematic approach to system development. The stages include Planning, Analysis, Design, Development, Implementation, and Maintenance. Each stage contributes to the successful completion of the system, with System Design serving as a crucial component.

The Planning stage lays the groundwork for the entire SDLC. It involves identifying the system’s goals, defining project scope, setting objectives, establishing timelines, and determining available resources. Planning ensures that the development process aligns with organizational needs and sets a clear direction for subsequent stages.

During the Analysis stage, the focus is on gathering and understanding the requirements of the system. This includes conducting interviews, studying existing processes, and identifying stakeholders’ needs. The gathered information serves as a basis for designing a system that meets users’ expectations and addresses organizational challenges.

System Design is a critical stage in the SDLC, where the requirements gathered during the Analysis phase are translated into a detailed technical plan. It involves designing the system’s architecture, database structure, and user interface, and defining system components. The Design stage lays the foundation for the subsequent development and implementation phases.

The Development stage involves the actual coding and programming of the system. Based on the design specifications, developers write code, create database structures, and implement necessary functionalities. Rigorous testing and quality assurance are performed to ensure the system’s accuracy, performance, and adherence to the design requirements.

This stage involves deploying the developed system into the production environment. This includes activities such as system installation, data migration, training end-users, and configuring necessary infrastructure. Implementation requires careful planning and coordination to minimize disruptions and ensure a smooth transition from the old system to the new one.

Maintenance is an ongoing stage that involves monitoring, managing, and enhancing the system’s performance and functionality. It includes activities such as bug fixes, updates, security patches, and addressing user feedback. Regular maintenance ensures the system remains reliable, secure, and adaptable to changing business needs.

Let’s explore the key differences between the System Development Life Cycle and the System Design Life Cycle in a more narrative form:

• System Development Life Cycle: Encompasses the entire process of developing and managing an information system, from initial planning to system retirement and maintenance.
• System Design Life Cycle: Focuses specifically on the design aspect within the broader System Development Life Cycle. It deals with the detailed planning and creation of system architecture, components, and modules.
• System Development Life Cycle: Comprises various phases, including planning, analysis, design, implementation, and maintenance. Each phase contributes to the overall development and management of the system.
• System Design Life Cycle: Emphasizes phases such as preliminary design, detailed design, implementation, testing, and maintenance. The primary focus is on the detailed planning and creation of design specifications.
• System Development Life Cycle: Provides a comprehensive framework for the entire system development process. It addresses aspects beyond design, including user requirements, system functionality, coding, and ongoing maintenance.
• System Design Life Cycle: Concentrates on the design aspect, specifically creating detailed specifications for system components, architecture, and user interfaces. It places a strong emphasis on the planning and structuring of the system.
• System Development Life Cycle: Aims to guide the development process from the conceptualization of the system to its implementation, testing, deployment, and ongoing maintenance.
• System Design Life Cycle: Aims to create detailed design specifications and plans that serve as a blueprint for the development team. It focuses on translating high-level requirements into actionable design elements.
• System Development Life Cycle: Involves a wide range of stakeholders, including users, business analysts, developers, testers, and maintenance personnel, across various phases of the life cycle.
• System Design Life Cycle: Primarily involves designers, architects, and developers in the creation of detailed design specifications and plans. Collaboration with other stakeholders occurs, but the emphasis is on the design team.
• System Development Life Cycle: Embraces an iterative approach with feedback loops to accommodate changes and improvements throughout the life cycle. Users and stakeholders are involved in providing continuous feedback.
• System Design Life Cycle: Is also iterative, with the design evolving based on feedback from testing, integration, and the need for design adjustments.
• System Development Life Cycle: Outputs a fully developed, tested, and maintained information system that meets user requirements and business objectives.
• System Design Life Cycle: Outputs detailed design specifications, architectural plans, and guidelines that serve as a basis for the development team to implement and test the system.
• System Development Life Cycle: Spans the entire life cycle of the system, and the timeframe can vary from months to years, depending on the complexity of the project.
• System Design Life Cycle: Focuses on the design within shorter timeframes, as part of the broader system development process.

In essence, while System Development Life Cycle provides a holistic view of the system development process, System Design Life Cycle narrows its focus to the detailed planning and creation of the system’s design components. Both are integral to successful system development, with the latter playing a crucial role in translating high-level requirements into actionable design elements.

System Design is a crucial stage in the SDLC as it bridges the gap between requirements analysis and system development. It transforms user needs and functional specifications into a detailed technical plan that guides the development team. Proper system design ensures that the developed system aligns with the desired functionality, performance, and scalability requirements.

Please Login to comment...

Similar reads.

• System Design
• How to Delete Discord Servers: Step by Step Guide
• Google increases YouTube Premium price in India: Check our the latest plans
• California Lawmakers Pass Bill to Limit AI Replicas
• Best 10 IPTV Service Providers in Germany
• Content Improvement League 2024: From Good To A Great Article

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

• DOI: 10.3998/JSAIS.11880084.0001.103
• Corpus ID: 55905746

A Case Study of the Application of the Systems Development Life Cycle (SDLC) in 21st Century Health Care: Something Old, Something New?

• Mark E. McMurtrey
• Published 2013
• Medicine, Computer Science

17 Citations

Empirical study of software development life cycle and its various models, software process models: a review and analysis, nutes prols: specification of an environment for prototyping and evolving ehr data collection systems, public and private healthcare organisations: a socio-technical model for identifying cybersecurity aspects, addressing the complexity of mobile app design in hospital setting with a tailored software development life cycle model, improvement of the software systems development life cycle of the credit scoring process at a financial institution through the application of systems engineering, research methodology as sdlc process in image processing, the proposed guest verification information system design for the residential complexes, guidelines and recommendations for developing interactive ehealth apps for complex messaging in health promotion, how designer think about designing an augmented reality app for the study of central nervous system, 22 references, making information systems less scrugged: reflecting on the processes of change in teaching and learning, systems analysis and design methods, modern systems analysis and design, the effect of user involvement on system success: a contingency approach, real world project: integrating the classroom, external business partnerships and professional organizations, user involvement and mis success: a review of research, an empirical study of the impact of user involvement on system usage and information satisfaction, information systems for managers: texts and cases, point of care documentation impact on the nurse‐patient interaction, introduction to systems analysis and design (2nd ed.), related papers.

Showing 1 through 3 of 0 Related Papers

• General & Introductory Computer Science
• Programming & Software Development

Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle

ISBN: 978-0-470-86194-3

September 2004

Ian F. Alexander , Neil Maiden

• Extending the scenario method beyond interface design, this important book shows developers how to design more effective systems by soliciting, analyzing, and elaborating stories from end-users
• Contributions from leading industry consultants and opinion-makers present a range of scenario techniques, from the light, sketchy, and agile to the careful and systematic
• Includes real-world case studies from Philips, DaimlerChrysler, and Nokia, and covers systems ranging from custom software to embedded hardware-software systems

Neil Maiden is a Reader and Head of the Centre for Human-Computer Interface Design, in City University's School of Informatics, London UK. He is co-founder and treasurer of the British Computer Society Requirements Engineering Specialist Group.

• Product Prototyping
• Design Engineering
• Software Development
• Web Application Development
• Mobile App Development
• Front End Development
• Microsoft Development
• Remote Teams
• Data Engineering
• Cloud & Infrastructure
• Cybersecurity
• Logistics & Distribution
• Finance & Insurance
• Retail & eCommerce
• Real Estate & Construction
• Travel & Hospitality
• Communication, Media & Entertainment
• Education / eLearning
• Delivery Models
• Engagement Models
• Hire PHP Developers
• Hire Laravel Developers
• Hire CodeIgniter Developers
• Hire NodeJs Developers
• Hire ExpressJS Developers
• Hire Java Spring Boot Developers
• Hire iOS Developers
• Hire Android Developers
• Hire Swift Developers
• Hire Kotlin Developers
• Hire Flutter Developers
• Hire Angular Developers
• Hire React JS Developers
• Hire Knockout JS Developers
• Hire WordPress Developers
• Hire Shopify Developers
• Hire Magento Developers
• Hire Asp.net Developers
• Hire C# Developers
• Hire .Net Core Developers
• Hire Xamarin Developers
• Hire Ionic Developers
• Hire React Native Developers
• Hire PWA Developers
• Inventory & Warehouse
• Procurement
• Maintenance & Service
• Financial Accounting
• Smart Station
• Vehicle Tracking System
• Transport Management
• Sales & Invoice
• Production Management
• Visitor Management
• Smart Assist
• DMS Solutions
• Multivendor Portal
• Employee Performance
• Recruitment Management
• Payroll Management Solution
• Smart Estate
• AI Assistant

Warehouse Management streamlines storage, logistics for efficient and accurate supply chain operations.

It streamlines procurement processes, optimizing efficiency and cost-effectiveness.

CMMS software streamlines maintenance tasks, optimizing asset management and workflows.

This software automates tracking, improving workforce efficiency and accuracy.

It simplifies financial tasks, ensuring accuracy and efficient bookkeeping processes.

Smart Stations optimize services with technology, enhancing user experience and efficiency.

Vehicle tracking software enhances fleet management, ensuring efficiency and security.

This tools provide rapid assistance, ensuring quick and reliable support.

It streamlines logistics, ensuring efficient and reliable supply chain management.

Streamline HR tasks with our efficient management solution for businesses.

Efficient invoicing solution for seamless financial management and streamlined transactions.

Optimize production with our advanced and intuitive Production Management Software.

Manage visitor's entry and check-in process with our prior approvals by using advanced visitor management solutions.

Let the dev team virtually analyze your digital solutions and resolve the issues using an AR-Based Smart Assistance Solution.

Manage and organize all the important files smartly and securely with our intelligently designed DMS system.

Empower diverse sellers and buyers with a seamless Multivendor Marketplace Portal for streamlined transactions.

Precision in employee management, from goal-setting to continuous feedback, fostering excellence effortlessly.

Efficient solution for streamlining the hiring process for successful talent acquisition and management.

Simplify payroll processes, automate calculations, and ensure compliance with our intuitive solution.

Gated community access control ensures security by restricting entry, enhancing safety, and fostering a private environment.

From streamlining tasks to scheduling meetings, our Rockeye AI Assistance offers personalized support, boosting productivity.

Congratulations Hidden Brains team, You should be proud of your accomplishments. You have an amazing team of...

Mr. Joseph S. United States

• Our Infrastructure
• Development Methodology
• Certifications
• Career Overview
• Media Coverage
• Events & Celebrations
• Client Testimonials

Best Practices for System Development Life Cycle

Table of Contents

Prompt understanding of SDLC methodologies is important for both project managers and developers. The simple cause is that today’s modern time is all about accomplishing the client’s demands . 

Do you know that around 40% of consumers have consistently switched retailers or businesses to receive the required services? This behavioral paradigm has affected the brand value and competitiveness of enterprises. Thus, implementing a system development life cycle helps achieve a competitive advantage. Almost all software development companies follow the System Development Life Cycle model to build supreme quality products and project’s progress simultaneously. 

Video Caption: Software Development Lifecycle

This 5-minute video explains thoroughly for the SDLC. The enterprise owners, project managers, and developers can check this video to know the specifications. All your queries will be answered from the detailed sections of this blog. Read it entirely to know the specific details of the Guide to System Development Life Cycle.

Overview of System Development Life Cycle

This blog is a detailed description of the knowledge of project managers, developers, and IT professionals. The IT project managers will get an idea of the project’s efficiency. The SDLC models share a blueprint of the software product that needs to be developed according to specific project requirements.

Several project risks need to be resolved by the team before the software product is deployed to the client’s space. The most important one is the timelines that need to be met. The client satisfaction is only achieved when the project is delivered on time and with the appropriateness.

SDLC Benefits are as follows:

1. apprehensible framework.

The development team that utilizes the SDLC models provides a clear framework for planning, executing, and managing software projects, helping teams understand the stages involved and their specific roles.

Such a framework also allows companies to mitigate potential risks. Performance, cost, compliance, communication, and formation of effective business strategy are some of the risks from which businesses need to get a prominent solution. Since project specifications are shared with the whole team, everyone comes on the same page.

2. Assured Quality

The top reason why SDLC models are used for the accomplishment of a project is that with regular testing methods, software is built with assured quality. User requirements and quality standards both are met. Another reason for receiving supreme quality is better resource management . The project manager will not have to worry about the last-minute resource allocation as all the constraints are already met.

3. Technical Documentation

Of course, there are several software tools available to create documentation but a structured system development life cycle model allows the team to create the best documentation . This helps the clients to clearly understand a project and also for the team about the features & functionalities that have been added to the project. 

There is one more point that we need to add which is the project maintenance. The system development life cycle models allow the project managers to amend the software if in case the client modifies the system requirements.

The importance of system development life cycle models in summarized form is that they allow the project managers to sophisticate the whole software development process to achieve successful project outcomes.

Want to build Scalable and single-page web applications?

How to Utilize Each Stage of SDLC for Achieving Business Success

Enterprise works according to short and long-term goals. The purpose of discussing the models here is to inform the project managers and dedicated development team to enhance the business operations . There are basically seven crucial stages of software development that have to be followed by the dedicated development team.

1. Planning

The existing problems of the software are addressed and that of the customer. The preliminary requirements are crucial to gather to avoid any concerns later. The project managers can plan out to the best of the requirements in the segment manner. The resource requirements, early-stage validity, and requirements assurance are done. 

2. Analysis

It is important to complete effective market research at this stage to understand the basics of accomplishing the project. The second is to generate the system requirements that have to be included while developing software. The last one is to set concrete goals.

3. Designing

System designing is always done according to the specific client requirements. The important aspect is the full stack development. The databases, user interface & usability, networking , and core features of the software are designed in this stage. Consider this stage as a kind of prototype that needs to be submitted to the clients. 

4. Development

In this stage, programming languages and frameworks are used for Software Product Development . Project specifications and requirements are thoroughly accomplished in this stage. The developers make use of the best IDE to ensure that the coding is done efficiently. The enterprises can hire angular developers to build interactive single-page applications. 

Also Read: How to Build Single Page Applications [Cost + Features]

When the application is ready, it has to be tested several times to ensure its quality. Software testing is essential to determine whether the code is running correctly or not. The quality assurance personnel keep a check on the code . The project managers are responsible for checking whether quality assurance is done. This can include manual or automated testing procedures.

6. Implementation

The last second stage is the implementation of the software application in the client’s space. Deployment has to be done for the software product once it is ready and free from all errors . The various System Development Life Cycle models allow a dedicated development team to work enthusiastically to implement the software in the client’s space.

7. Maintenance

The work of a dedicated development team is not over after developing a software product, they have to continue to make iterations according to the client’s requirements. This step is crucial for ensuring that the software is working properly. The last but most important stage of the system development life cycle is maintenance. The client interactions are vital when it comes to maintaining the software application.

After a thorough understanding of the various stages, allow us to share a detailed description of discrete System Development Life Cycle models that can be used for effective software development. Kindly note that a project manager plays a crucial role in accomplishing all these stages. The personnel guide the team in the Development Methodologies that need to be followed for building the supreme software applications.

Need a team that dedicates their full efforts to your vision?

Description of Various System Development Life Cycle Models

Project managers create a project outline or blueprint according to which the project development begins. Enterprises must make a critical choice for selecting a particular SDLC model . Here is a list of the discrete system development life cycle models.

There are discrete life cycle models but we have discussed the common and most used in this section. 

1. Waterfall Model

Each level is started after the completion of the previous one to create a sophisticated software model. The enterprises are able to create a supreme quality software product when using this model. Waterfall is the oldest and most reliable software development lifecycle model. The enterprises can choose this model if they want to create a quality product. Some of the benefits of the waterfall model are as follows:

• Easy Project Management
• Effective Documentation
• Good for small, medium-sized, and large scale Projects

2. Spiral Model

The spiral model is an iterative process of software development in which rapid iterations are made to create a prototype. The initial software product is released after the required modifications are made. The spiral model is preferred by many developers and enterprises should also select this SDLC model to build an efficient software system . Some of the benefits of the spiral model are as follows: 

• Prototype can be iterated simultaneously with customer feedback 
• Promote Risk and Project Management 
• Best for Complex Projects

3. Agile Model

Quick iterations are possible in the agile model. The client’s feedbacks are taken into consideration to provide the best software produc t. This is also known as the scrum model in which the customer can interact with the project managers to make suitable changes.

The prominent reason for implementing the System Development Life Cycle model is to develop the software with ease and to accomplish the ever-changing requirements of customers. However, SDLC Techniques are beneficial to mitigate the project risks and to ensure quality software development. Some of the benefits of the spiral model are as follows:

• Ensures flexibility in software development 
• Risk Mitigation helps to improve customer satisfaction
• Reduces time-to-market and delivers customer-centric software products

Also Read: 7 DevOps Lifecycle Phases with Case Studies and Tools

What are the Various Types of Software Development?

Digital transformation and continuously changing demands of the client’s enterprises have to develop discrete kinds of applications. Some of the common are shared below:

1. Web Application Development

Websites, web applications, or portals that run on browsers are covered under this heading. Enterprises that want to take Web Application Development Services must be cleared with the project requirements.

2. Database Development

Many enterprises have an aim to opt for backend development for in-house business processes or to accomplish specific requirements of the clients. The enterprises can Hire Dedicated Developers who can complete the DBMS development.

3. Mobile App Development

The GSMA connections reached 396.0 Million in the beginning of 2024 in the United States. This shows that Mobile App Development is a basic need of the clients and that of the businesses. The companies must ensure that the mobile apps have interactive UI/UX to attract potential customers .

4. API Development

For clients who want real-time data, API Development is required. The enterprises must coordinate properly with the clients to ensure that all the preliminary requirements are integrated carefully into the development.

5. Embedded Software Development

Usually, embedded systems are used in the automotive industry or for robotics. Such a system is actually a blend of software and hardware to help enterprises in real-time tracking and more functionalities. With the rise of the Internet of Things technology, embedded systems are in trend. 

Also Read: 15+ Top Software Development Trends to Look for in 2024

After going through the blog above, the project managers will surely get an idea that by following the trends they can get the below-listed benefits:

• Staying ahead of the competitors
• Reduced cybersecurity threats
• Increased Productivity

But they should also be aware of the bottlenecks that clash with the dedicated development team during the System Development Life Cycle phases. 

What are the Challenges in Implementing the SDLC?

Enterprises that select Web Application Development Services definitely face several challenges. Some of these are shared below:

1. Resource Allocation

The continuous changes in customer requirements affect the software product development process. In most cases, the requirements are unclear which disrupts the project’s progress.

2. Lack of Team Collaboration

The team must communicate properly to be on the same page in the software development process. As we have already discussed many project management tools can be utilized for collaborating effectively.

3. Inadequate Documentation

A clear technical document has to be created to analyze the project issues and the ways it has been resolved. The improved decisions cannot be taken if there is inadequate documentation for a particular project.

4. Technological Advancements

For example, if the client asks to include artificial intelligence solutions in the software product but then they also want to add AR/VR features then it will be a concern for the developers. This can also lead to integration challenges.

The project complexities can be reduced when the above challenges are strictly taken into consideration by the project managers. Moreover, each member of a dedicated development team must take the credibility of providing the best quality work from their end.

Wondering to Choose Prompt Software Solutions?

This is to conclude that the System Development Life Cycle should be followed as an essential part of the software development process. The SDLC Techniques are beneficial to integrate security features in the application that is built with assured quality. The enterprises must select the SDLC models according to their project requirements, team size, and business goals. 

These are better than the traditional approaches that lack in communication and to properly integrate the features/functionalities as per the specific customer requirements. However, choosing the appropriate software development company would be profitable considering modern software development needs. 

How Hidden Brains Can Help in implementing SDLC?

We have a team of talented developers and professionals who can provide consultation according to your project. We are your trusted app development partner. Our focus is to bring solutions to your customers than a simple app. We have been driving the app revolution for businesses for more than a decade.

Our team of dedicated mobile app developers in India and designers has years of extensive experience catering to wide verticals of sectors worldwide. We have helped multiple renowned brands globally to taste disruption with our app solutions.

Frequently Asked Questions 

The blog has shared detailed information about System Development Life Cycle models, phases, and challenges. In this section, you will find answers to your specific queries. 

Why System Development Life Cycle is Important?

As we have discussed in the blog, the System Development Life Cycle helps provide a framework. This enhances the quality of a software product and helps in mitigating project risks. Enterprises that want to accomplish bigger projects must opt for this process. 

How to Select the Right SDLC Model?

The project managers have to strategically think about the model. Some of the essential factors include: 

1. Project Size 2. Cost 3. Experience of the Dedicated Development Team  4. Potential Project Risks 5. Project Timelines

The team leaders and managers have to play an efficient role in selecting the appropriate System Development Life Cycle model to build feasible applications.

List the Tools Required for System Development

The enterprises need to have various project management tools to ensure that the software development process is accomplished in the desired manner. These are: 

1. Project Management Software such as Zoho and Trello  2. Frameworks such as Node.js, Angular JS, .NET Core, and Laravel  3. Documentation Tools such as GitHub

How to Ensure Successful Software Product Delivery?

First of all, the project managers must be aware that until the project deployment, there will be a handful of changes that have to be done. However, SDLC models ensure that disruption is minimized and the software is updated with several iterations.

To ensure successful project delivery, the project managers must continuously be in contact with the client or the project stakeholders. SDLC models allow open communication to solve the issues smoothly and at the earliest. Best practices include clear documentation, regular communication, stakeholder involvement, and iterative development to adapt to changing needs.

You can also check our other services:

Hire PHP Developers In India ,  Hire Flutter Developers In India ,  Hire React Native Developers In India ,  Hire Android App Developers In India ,  Hire iOS App Developers In India ,  Hire ReactJs Developers In India ,  Hire NodeJs Developers In India ,  Hire AngularJs Developers In India ,  Software Product Development Company In India ,  Mobile App Development Company In India , Angular Development Company In India , Laravel Development Company In India , iOS App Development Company In India , Android App Development Company in India

Leverage our technology expertise for custom applications and API's as well application rewrites. Driven by emerging technologies in open source, AI, automation, IoT and big data.

Platform solutions, consulting expertise and seasoned advisory for defining and executing AI services. These can be internal operational improvements or external support and services.

Quick turn around of individuals and teams within our core disciplines. Exceptional technical vetting and retention with global location and time zone coverage. Flex utilization for certain roles.

• Strategy & Ideation
• UX/UI Design
• Integration & APIs
• Quality Assurance
• Support and Hosting Services
• Custom SaaS Dev and Cloud Services
• Telehealth Software
• EHR Software
• EMR Software
• Medical Software
• Engagements
• Mobile Apps
• Mobile Testing
• React Native
• Objective-C
• Ruby on Rails
• About Intersog
• Why Intersog
• Leadership Team
• Letter from the CEO
• Team Management
• Software Dev Blogs
• IT Strategy
• Coding Tips
• IT News and Trends
• White Papers
• Strategy & Ideation
• Integration/APIs
• MVP Development
• Backend Development
• Agriculture
• IT Cost Calculator
• Software Development

Agile Software Development Life Cycle: Case Study

Learn more about our agile software development life cycle from our Mitsubishi case study.

Any software development project, either big or small, requires a great deal of planning and steps that divide the entire development process into several smaller tasks that can be assigned to specific people, completed, measured, and evaluated. Agile Software Development Life Cycle (SDLC), is the process for doing exactly that – planning, developing, testing, and deploying information systems. The benefit of agile SDLC is that project managers can omit, split, or mix certain steps depending on the project’s scope while maintaining the efficiency of the development process and the integrity of the development life cycle. 

Today, we are going to examine a software development life cycle case study from one of Intersog’s previous projects to show how agility plays a crucial role in the successful delivery of the final product. Several years back, we worked with Mitsubishi Motors helping one of the world’s leading automotive manufacturers to develop a new supply chain management system. With the large scope of the project, its complex features, and many stakeholders relying on the outcomes of the project, we had to employ an agile approach to ensure a secure software development life cycle.

Business Requirements

Mitsubishi Motors involves many stakeholders and suppliers around the world, which makes its supply chain rather complex and data-heavy. That is why timely improvements are crucial for the proper functioning of this huge system and a corporation as a whole. Over the years of functioning, the old supply chain has been accumulating some noticeable frictions that resulted in the efficiency bottlenecks, and Intersog offered came ups with just the right set of solutions to make sufficient solutions that would help Mitsubishi ensure a coherent line of communication and cooperation with all the involved suppliers.

• The Power of Generative AI: Enhancing Business Strategies

Previously, Mitsubishi used an outdated supply chain management system that involved a large number of spreadsheets that required a lot of manual input. Considering a large number of stakeholders, the problem of synchronization has been a pressing one as well – different stakeholders would input the data at different speeds and at different times of day, which created a degree of confusion among suppliers. Though the system has been sufficient for a long time, the time has come to eliminate all the redundancies and streamline data input. 

The legacy system has been partially automated and ran on the IBM AS400 server, which allows for impressive flexibility, but it no longer sufficed for Mitsubishi’s growing needs. The main requirement, thus, was to create a robust online supply chain solution that would encompass the entire logistics process starting with auto parts and steel suppliers and ending with subcontractors and car dealerships around the world. That being said, Mitsubishi did not want to completely change the system, they opted for overhaul, and we came up with the idea of an integrated web application that was meant to function in conjunction with a DB2 base that was already used on the IBM AS400 server. 

IT Architecture and Agile SDLC

Mitsubishi employs a series of guidelines and rules on how to build, modify, and acquire new IT resources, which is why Intersog had to be truly agile to adapt to the client’s long-established IT architecture. Adapting to the requirements of the client, and especially to the strict regulations of the IT architecture of large corporations like Mitsubishi requires knowledge, flexibility, and strong industry expertise. Each software development company has its own architecture standards and frameworks for building new systems but many face difficulties when working with the existing systems and modifying them to the new requirements.

Intersog has no such problems. We approached Mitsubishi’s case with strong industry expertise and flexibility to account for all the client’s needs and specifications of the existing system. Obviously, following the client’s architecture regulations requires a profound understanding of said regulations, which is why information gathering is an integral phase of the software development life cycle.

Requirements Gathering

The requirements gathering phase can take anywhere from just a couple of days to several weeks. Working with complex and multi-layered legacy systems like the one used by Mitsubishi requires serious analysis and information gathering. In the case of Mitsubishi, our dedicated team had to gain a clear understanding of how the legacy system functions, create new software specifications, map out the development process, gather and create all the necessary documentation, track all the issues related to the functioning of the legacy system, outline the necessary solutions, and allocate all the resources to achieve the project’s goals in the most efficient manner. 

Working on the Mitsubishi project, our team has been gathering all the required information for up to 4 weeks. This included a profound examination of the legacy system, mapping out all of its flaws and specifications, bridging the gaps between the current state of the system and the requirements of the client, and outlining the development process. 

• The Future of Healthcare: Impact of AI Data Analytics

The design stage includes all the integral decisions regarding the software architecture, its makeover, the tech frameworks that would be used in the system’s rework. During this stage, developers discuss the coding guidelines, the tools, practices, and runtimes that will help the team meet the client’s requirements. Working with large corporations like Mitsubishi, a custom software development team has to work closely with the company’s own developers to better understand the specifics of the architecture and create a design that reflects all the requirements. 

After all the requirements are gathered, we initiated the design stage based on all of the client’s specifications and came up with a number of solutions that matched Mitsubishi’s specs:

• Convenient data model meant to optimize data duplication;
• Permission system that differentiated the users by their access levels;
• Appealing user interface mockup to improve the comfortability of user-system interaction;
• Integration with the legacy RPG system;
• Notifications for the partners to keep them up with the important activities.

This set of essential solutions has been discussed and approved in the course of the design stage that lasted for 2 months. During this stage, Intersog and Mitsubishi development teams worked closely to come up with the solutions that matched the client’s requirements to the tee. Proper functioning of the supply chain is vital for the entire corporation, which is why it was critical to do everything flawlessly. 2 months might seem like quite a timeline, but for this case study on software development life cycle, it was not that long considering how complex Mitsubishi’s legacy system was. 

Solution Development

After approving the solution design, the team can move to develop those solutions. That’s the core of the entire project, a stage at which the teams meet the goals and achieve the outcomes set during previous stages. The success of the development stage depends heavily on how good a job the teams did during the design stage – if everything was designed with laser precision, the team can expect few if any, surprises during the development stage. 

What happens during the development stage is the teams coding their way towards the final product based on decisions that have been made earlier. With Mitsubishi, we followed the guidelines we came up with earlier and implemented a set of essential solutions:

• We built a convenient data model that minimizes the risk of human error by reducing redundant and repetitive data entry and duplication. 
• Improved Mitsubishi’s security system to differentiate the users by their level of access and give them the respective level of control over the data.
• Added the notifications for the users so that they could react to the relevant changes faster.
• Designed an appealing and comfortable user interface using the AJAX framework to make the user-system interaction more comfortable and time-efficient. 
• Deployed the platform running on the IBM AS400 server with the integration of DB2 databases.
• Integrated the existing RPG software into the new system.
• Migrated the existing spreadsheets and all the essential data into the new system.

All of these solutions took us 6 months to implement, which is rather fast for a project of such scale. Such a time-efficiency was possible only thanks to the huge amount of work we’ve done throughout the research and design stages. The lesson to learn from these software development life cycle phases for the example case study is that the speed of development would depend heavily on how well you prepare. 

Depending on the scale of the project, you might be looking at different timelines for the development stage. Small scale projects can be finished in a matter of weeks while some of the most complicated solutions might take more than a year to finish. In the case of the Mitsubishi project, it was essential for the client to get things done faster. Rushing things up is never a good idea, but you can always cut your development timeline by doing all the preparation work properly and having a clear understanding of what needs to be done and in which order.

Quality Assurance                   

Quality assurance is as vital for your project’s success as any other stage; this is where you test your code, assess the quality of solutions, and make sure everything runs smoothly and according to plan. Testing helps you identify all the bugs and defects in your code and eliminate those in a timely manner. Here at Intersog, we prefer testing our software on a regular basis throughout the development process. This approach helps us to identify the issues on the go and fix them before they snowball into serious problems. 

That’s it, quality assurance is a set of procedures aimed at eliminating bugs and optimizing the functioning of the software solutions. Here at Intersog, we run both manual and automated tests so that we can be truly sure of the quality of solutions we develop for our clients. With Mitsubishi, we ran tests throughout the development process and after the development stage was over. It took us an additional month to test all the solutions we’ve developed, after which we were ready for the implementation stage.

Would you like to learn more

about talent solutions

Integration and Support

Following the testing, and once we are sure all the solutions work flawlessly, the development team gets to the implementation stage. Also known as the integration stage, this is where we integrate the new solution into the client’s pre-existing ecosystem. Basically, you are putting new gears into a complex mechanism that has been functioning for many years, and it is essential to make sure all of those gears fit perfectly. 

With such a complex system as the one employed by Mitsubishi and a vast amount of accumulated data, our developers had to be incredibly precise not to lose anything. We are talking about surgical precision because Mitsubishi’s suppliers amassed thousands upon thousands of spreadsheets full of critical data on supplies, material and product deliveries, accounting data, and more. All of that had to be carefully integrated with the new automated solution. 

After 2 months, the solutions have been fully integrated with Mitsubishi’s existing ecosystem. Intersog usually backs the clients up by offering support and maintenance services to ensure flawless functioning of the system over time, but this time, our client was fully capable of maintaining the new system on their own. As said, Mitsubishi has its own development team that is able to take care of the system maintenance, so that our cooperation was finished after the integration stage. 

Final Thoughts and Outtakes

A software development life cycle depends on many factors that are unique for each company. In the case of Mitsubishi, we’ve managed to get things done in just under a year, which is rather fast for a project of such an immense scale. Different projects have different life cycles, and it depends on the scale, the client’s ability to explain their needs, and the development team’s ability to understand those needs, gather all the necessary information, design the appropriate set of solutions, develop said solutions, ensure their quality, and implement them fast.

Related Posts

Software development blogs intersog gains game-changer status on clutch, software development blogs the persistent challenge of tech talent acquisition, software development blogs 10 best locations for outsourcing software development projects.

This website uses these cookies:

• Agile, DevOps and software development methodologies

systems development life cycle (SDLC)

• Alexander S. Gillis, Technical Writer and Editor

The systems development life cycle (SDLC) is a conceptual model used in  project management  that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. SDLC can apply to technical and non-technical systems. In most use cases, a system is an IT technology such as hardware and software. Project and program managers typically take part in SDLC, along with system and software engineers, development teams and end-users.

Every hardware or software system will go through a development process which can be thought as an iterative process with multiple steps. SDLC is used to give a rigid structure and framework to define the phases and steps involved in the development of a system.

SDLC is also an abbreviation for Synchronous Data Link Control and software development life cycle. Software development life cycle is a very similar process to systems development life cycle, but it focuses exclusively on the development life cycle of software.

SDLC models

Various SDLC methodologies have been developed to guide the processes involved, including the original SDLC method, the Waterfall model. Other SDLC models include rapid application development ( RAD ), joint application development ( JAD ), the fountain model, the  spiral model , build and fix, and synchronize-and-stabilize. Another common model today is called Agile software development .

Frequently, several models are combined into a hybrid methodology. Many of these models are shared with the development of software, such as waterfall or agile. Numerous model frameworks can be adapted to fit into the development of software.

In SDLC, documentation is crucial, regardless of the type of model chosen for any application, and is usually done in parallel with the development process. Some methods work better for specific kinds of projects, but in the final analysis, the most crucial factor for the success of a project may be how closely the particular plan was followed.

Steps in SDLC

SDLC can be made up of multiple steps. There is no concrete set number of steps involved. Around seven or eight steps appear commonly; however, there can be anywhere from five upwards to 12. Typically, the more steps defined in an SDLC model, the more granular the stages are.

In general, an SDLC methodology follows these following steps:

• Analysis: The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
• Plan and requirements: The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement. Other factors defined include needed features, functions and capabilities.
• Design: The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications and security issues.
• Development: The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use.
• Testing: All aspects of performance must be tested. If necessary, adjustments must be made at this stage. Tests performed by quality assurance ( QA ) teams may include systems integration and system testing .
• Deployment: The system is incorporated in a production environment. This can be done in various ways. The new system can be phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
• Upkeep and maintenance: This step involves changing and updating the system once it is in place. Hardware or software may need to be upgraded, replaced or changed in some way to better fit the needs of the end-users continuously. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

Other steps which may appear include project initiation, functional specifications, detailed specifications, evaluation, end-of-life and other steps that can be created by splitting previous steps apart further.

 Advantages and disadvantages of SDLC

Benefits of abiding by a clearly defined SDLC model include:

• Having a clear view of an entire project, workers involved, estimated costs and timelines.
• Gives project managers a projected base cost of the project.
• Goals and standards are clearly defined.
• Developers can move back a step if something does not go as expected.

Disadvantages, however, can include:

• Due to assumptions made at the beginning of a project, if an unexpected circumstance complicates the development of a system, then it may stockpile into more complications down the road. As an example, if newly installed hardware does not work correctly, then it may increase the time a system is in development, increasing the cost.
• Some methods are not flexible.
• It can be complicated to estimate the overall cost at the beginning of a project.
• Testing at the end of development may slow down some development teams.

Continue Reading About systems development life cycle (SDLC)

• What you need to know about the ALM methodology
• The System Development Life Cycle: A Phased Approach to Application Security
• How should I implement a disaster recovery process in my SDLC approach?
• Learn IT: Software development

Related Terms

Dig deeper on agile, devops and software development methodologies.

What is the software development lifecycle (SDLC)?

What is computer-aided software engineering (CASE)?

Green code - New Relic: GreenOps sprouts new shoots

Waterfall vs. Agile methodology: Differences and examples

Increased use of multi-cloud environments is creating a need for specialized observability methods and tools for tracking and ...

Don't be caught unprepared for the exam. Take advantage of these study tips from the author of 'The Official CompTIA Cloud+ ...

FinOps strategies can help enterprises manage cloud costs and monitor cloud usage patterns. But is it better to outsource or ...

Rust or Ruby? Go or Groovy? As the competitive IT landscape evolves, developers can enhance their skills and career potential by ...

Authorization is a critical security component of a microservices architecture. Follow these five guiding principles to deploy ...

Managing microservices without API gateways might be uncommon, but not unheard of. Consider the benefits, downsides and available...

VMware Tanzu now offers a single UI for Cloud Foundry and Kubernetes, a feature years in the making, but the improvement could ...

There are key stages to manage infrastructure as code, from source control to deployment. Here's how these functions can be ...

With Puppet, organizations can manage configurations and simplify the DevOps process. Learn how it works, and see if it's the ...

More companies today hire developers who work remotely. Follow these steps for an efficient remote onboarding process for devs, ...

GPTScript enables programmers to use natural language syntax and tap into OpenAI when building apps. Here's a basic GPTScript ...

Generic variables give the TypeScript language versatility and compile-time type safety that put it on par with Java, C# and C++....

Compare Datadog vs. New Relic capabilities including alerts, log management, incident management and more. Learn which tool is ...

Many organizations struggle to manage their vast collection of AWS accounts, but Control Tower can help. The service automates ...

There are several important variables within the Amazon EKS pricing model. Dig into the numbers to ensure you deploy the service ...

The System Development Life Cycle, Explained (+MCQs)

Publish date:

December 31, 2022

Updated on:

August 8, 2024

Written by:

Octavia Drexler

Polina Tibets

TABLE OF CONTENTS

The System Life Cycle ( SDLC ) is a process used by software developers and IT professionals to create, maintain, and improve computer systems. SDLC is a project management method that ensures software development progresses methodically from idea to successful operation through a series of structured steps.

The Structure of the System Development Life Cycle

You can compare the System Life Cycle to an assembly line. Each step is undertaken to build the desired system, while also ensuring its quality and reliability. The structure of the SDLC can differ from one project/ organization to another. However, it usually follows a similar pattern, comprised of seven steps:

Development

Integration and testing, implementation, operations and maintenance.

In some exceptions, the stages of SDLC also include an eighth phase and a ninth phase:

• Evaluation (where the team collects feedback and evaluates the system against the initial objectives.)
• Disposal (where you discontinue the information system to make the transition to a new system.)

However, for this article, we will only discuss the generally-accepted seven stages. At the end of our introduction to the stages of the SDLC, you will also find 10 multiple-choice questions you can use to test what you've just learned.

It is worth noting that the System Life Cycle does not replace or compete with Agile methodologies . Rather, most people use the concept of an umbrella term to denote the workflow process used in a range of methodologies/models such as Waterfall, Agile, Spiral, Rapid Prototyping, Incremental, and so on. In other words, models that fall under the "SDLC" umbrella range from agile to iterative to sequential. The difference between different models doesn't lie in whether or not they include the seven stages of SDLC, but in how you approach them.

Before we dive into the more in-depth explanations of each SDLC phase, keep in mind that "system development" and " software development " aren't the same. The two terms share multiple similarities, but the main difference lies in the fact that system development takes a more holistic, complex view of an application.

Planning (Preliminary Analysis)

The Planning phase of the System Life Cycle includes identifying the project's needs, as well as its objectives and goals. At this stage, you will have to run a detailed analysis of these goals, to determine whether or not they are achievable. Furthermore, you will also have to assess whether or not you need a new system to achieve your business goals.

You will have to start by gathering all the necessary information and have an in-depth understanding of the current system. Include all system-related documentation and user feedback in your research — and remember to also run a cost-benefit analysis (to ensure that the project is financially sound).

Analysis and Requirements Definition

The Analysis stage of the SDLC is where you will take the Planning (or Preliminary Analysis, as it's sometimes called) to the next level. In this phase, you will break down the high-level objectives of the project into actual functions of the system and you will identify potential solutions. You will also write down high-level documentation to further analyze the system's requirements and identify any gaps between the current and desired product.

The System Design stage is where you'll work out all the details of the project. This involves creating a detailed specification of the system, including user interface design, data structures and storage formats, as well as protocols for communication. Furthermore, it involves creating screen layouts, process diagrams, business rules, and sometimes even pseudocode. You'll also include multiple stakeholders in this stage, such as the client, the designer, the business analyst, and so on.

This is the most straightforward SDLC stage (and what most people see). In this phase, you will develop the code that makes up the system. This involves using programming languages and tools, as well as sticking to a specific methodology (like Scrum, Kanban, Waterfall, Agile, or sometimes a combination thereof). Most times, the project manager and the actual development team are most hands-on in this stage of the System Life Cycle — but depending on your chosen methodology, you might have to set up regular client meetings and leadership updates to ensure everyone's in the loop on the progress.

The Integration and Testing phase of the SDLC is where you integrate all the pieces of the system. The entire stage involves connecting databases, servers, and code snippets to ensure that the project is running properly. It also involves testing the system to make sure that it operates as expected.

The Implementation phase of the System Life Cycle is all about making a detailed specification and being certain that it runs as expected. At this stage, you'll publish your project and start getting the first users for your information system. Keep in mind that you might also have to consider launch events and beta tests before the product is out in the open.

Operations and Maintenance is the last stage of SDLC. This is the phase where you make sure that the system continues running properly and that it caters to all its users' needs. As such, it also involves troubleshooting issues, ensuring the system doesn't become obsolete, and making changes as needed. This phase is ongoing and you should never neglect it, as it is a significant part of the System Development Life Cycle.

The System Development Life Cycle: Multiple-Choice Questions

Want to test your knowledge of the SDLC? Here are some MCQs to help you out:

Which phase of the System Life Cycle involves gathering all the necessary information for understanding the requirements of the system?

A. Planning

B. Analysis and Requirements

D. Development

During which phase of the System Development Life Cycle do you create a detailed specification of the system?

C. Development

D. Implementation

What is the last stage of the System Life Cycle?

A. Maintenance

B. Implementation

Which of the following is the broader, more comprehensive, and more complex term to use when defining software development processes?

C. System Development Life Cycle

D. Software Development Life Cycle

Which phase of the System Life Cycle involves deploying the system and making sure it runs as expected?

B. Integration and Testing

C. Implementation

D. Maintenance

Is the client involved in the Development stage of the Systems Development Life Cycle?

A. Absolutely no

B. Yes, depending on the specific SDLC model

C. Only at the beginning

D. Only when you have questions

What does SDLC stand for?

A. System Dynamics Life Cycle

B. Software Dynamics Life Cycle

C. System Design Life Cycle

D. System Development Life Cycle

Once you deliver the project, there's nothing else you need to do.

C. Depends on the project specifications

D. Depends on the client's requirements and budget

Business Analysts are never involved in the SDLC process.

C. Depends on the project objectives

D. Depends on the client’s budget

At which stage of the SDLC do you assess if you need a new system or not?

D. None of the options

Answer Key: 1A, 2B, 3A, 4C, 5C, 6B, 7D, 8B, 9B, 10D.

Q1. What is the Product Life Cycle MCQ?

Product Life Cycle MCQ is a multiple-choice question format that you can use to assess your understanding of the product life cycle. As for the product life cycle, it is the cycle through which a product goes from its initial concept to its eventual expiration. It’s worth mentioning that product life cycle and system development life cycle are not interchangeable terms. The former term is for the process of bringing a product from concept to market, while the latter refers to the entire process of creating an information system.

Q2. What is an SDLC MCQ example?

An SDLC MCQ example could be the following: “Which phase of the System Life Cycle involves gathering ensuring the system does not go obsolete?"

Answer: D. Maintenance

Q3. What is a test case in SDLC?

A test case in SDLC is a set of conditions, variables, and steps you use to verify the functionality of an application or system. Usually, you will write this in document format and use it during the testing phase of the SDLC process. Its main goal is to help identify any potential errors or issues with the system to guarantee a successful implementation.

Enjoyed the article?

Like it and let us know what you think, so we can create more content tailored to your interests.

VP of HR Client Strategy

Octavia is on a mission to drexlerize the undrexlerified, which, as narcissistic as it may sound, is actually not that self-centered (and neither is she, on most days). She is a marketer with nearly a decade of experience behind, over, through, and around her (like an aura, that is). She is also super-duper passionate about marketing tech products and translating techy gibberish into human language.

This is why, for the better half of her career, Octavia has been working with a variety of SaaS businesses around the world (give or take her sabbatical year in Agro-Tech, which she will tell you about five minutes into meeting her, somewhere in between confessing her passion for Leonard Cohen and Seth Godin, and complaining about sleepless nights she cannot really quit).

Aside from marketing and writing (d’oh), Octavia enjoys reading, science-fiction-y stuff, trying out new tools, and contemplating the inevitable moment AI will finally take over the world. She’s also into pretty bad music (not super-bad, but bad enough for people of good taste to raise a suspicious eyebrow).

She also has no idea why she wrote this entire piece in third-person, but it’s 1 AM, so she’ll leave it like this.

Full-Stack Development Team vs. Specialists: Weighing the Pros & Cons

The developer pool is filled with diverse talent, but you need to assess your requirements before hiring either a full-stack development team or specialists. We succinctly explored both and suggest which you should consider.

Agile Software Development Cycle: The Ultimate Guide for Tech Leaders

Find out everything you need to know about the Agile Software Development cycle with our comprehensive guide for CTOs. Learn the six stages of the SDLC.

Software Development KPIs: Measuring Metrics That Matter

Learn how to measure your team's performance using software development KPIs and discover how to improve productivity, quality, and reliability in your teams

Join the Pangea.ai community.

• eLibrary Home
• eLibrary Login

Home > Journals > AIS Journals > JSAIS > Vol. 1 (2013) > Iss. 1

The Journal of the Southern Association for Information Systems

A case study of the application of the systems development life cycle (sdlc) in 21st century health care: something old, something new.

Mark E. McMurtrey , University of Central Arkansas Follow

The systems development life cycle (SDLC), while undergoing numerous changes to its name and related components over the years, has remained a steadfast and reliable approach to software development. Although there is some debate as to the appropriate number of steps, and the naming conventions thereof, nonetheless it is a tried-and-true methodology that has withstood the test of time. This paper discusses the application of the SDLC in a 21st century health care environment. Specifically, it was utilized for the procurement of a software package designed particularly for the Home Health component of a regional hospital care facility. We found that the methodology is still as useful today as it ever was. By following the stages of the SDLC, an effective software product was identified, selected, and implemented in a real-world environment. Lessons learned from the project, and implications for practice, research, and pedagogy, are offered. Insights from this study can be applied as a pedagogical tool in a variety of classroom environments and curricula including, but not limited to, the systems analysis and design course as well as the core information systems (IS) class. It can also be used as a case study in an upper-division or graduate course describing the implementation of the SDLC in practice.

10.3998/jsais.11880084.0001.103

Recommended Citation

McMurtrey, M. E. (2013). A Case Study of the Application of the Systems Development Life Cycle (SDLC) in 21st Century Health Care: Something Old, Something New?. The Journal of the Southern Association for Information Systems, 1, 14-25. https://doi.org/10.3998/jsais.11880084.0001.103

Since July 12, 2017

• Journal Home
• About This Journal
• Aims & Scope
• Editorial Board
• Publication Ethics Statement
• SPECIAL ISSUE Call For Papers
• Submit Article
• Most Popular Papers
• Receive Email Notices or RSS

Special Issues:

• SPECIAL ISSUE: Information Systems in the Time of Covid

Advanced Search

ISSN: 2325-3940

Home | About | FAQ | My Account | Accessibility Statement

Privacy Copyright

SDLC: System Development Life Cycle

For years now, the Software Development Life Cycle, or SDLC for short, has cemented itself as the de-facto process to help build information systems, systems engineering, and software engineering from the ground up by encompassing key phases that can be grouped in planning, implementation, and maintenance of the system solution . 

The SDLC has grown to be critical thanks to its standardized phases that manage a balancing act between costs, quality, and time to meet modern business demands, urgency, complexity, and to top it off, with tight budgets.

Table of contents:

What is system development life cycle , why should you have a system development life cycle in place.

• The SDLC Phases.
• SDLC: Methodologies of System Development.
• SDLC Roles.
• Conclusion.

Let’s briefly explain. In general, SDLC is a closed loop in which each stage affects the actions in subsequent ones and provides clear information for future stages. To answer specific questions and ensure consistency in your development process, usually, all six stages try to effectively and consistently influence each other.

But before we run and take off by explaining each of the SDLC phases, let’s first define what a system is. By industry standards, a system is a combination of hardware, software, and human resources that perform the assigned tasks of collecting, processing, and displaying information. 

Within that context, the SDLC helps the system come to fruition. Some may wonder why it’s so important to develop and operate information systems in a cyclical fashion and to that, we can find the answer as it’s traced back to the constant changes in conditions in which the information system is located that influence the outcome of the system.

Whether it’s upgrading to new hardware, updating software development tools, increasing user requirements, or scaling the amount of information in the business environment and domain areas, a system’s life cycle always consists of planning, implementing, and maintaining. Of course, through iterative processes and changing business demands, there are now more phases involved including analysis, design, development, testing, and decommissioning or transition to a new information system, all of which have become crucial and can be used depending on the nature of each project.

We’re living in an Agile world where the Agile methodology has taken over most software development projects as it helps create products iteratively and flexibly to navigate and manage requirements of information systems with ease and effectiveness. The Agile methodology can work in harmony with the SDLC process by pairing phases with iteration frameworks. 

As a result, each stage will have roles of project participants who will take an active role in their tasks. In this article, we will focus on the main project roles which include the project manager, analyst, architect, developer, tester, and DevOps . It’s worth noting that each project participant plays an important role across the SDLC and they all have a direct impact on the overall wellbeing of projects. 

Alleviating software development complexity is chief among the key best practices for developing software. To that end, using the SDLC process goes a long way in compartmentalizing and breaking down robust tasks, into smaller, more manageable tasks that are easier to measure and achieve. Thanks to its framework of structured phases, those involved in the SDLC can help shape the project and manage it in a more streamlined fashion. 

In addition to these reasons, it’s also extremely valuable to have an SDLC in place when developing software as it helps transform an idea project into a fully-fledged, functional, and fully operational system. The SDLC covers both the technical and operational aspects of building software, encompassing activities such as process and procedure development, change management, policy development, user experience, impact, and adherence to security regulations.

It is very easy to explain the system development life cycle using the analogy of pouring water into glasses. When water is poured from one glass to another, in the end, if done carefully, you will still have a full glass of water without losing a drop. At each stage, you will transfer the most valuable information throughout the project, focusing on the goals and objectives of the project, and making changes to the project where necessary to improve the user experience.

To top it off, the SDLC process helps plan ahead of time and analyze the structured phases and goals of a specific project so it becomes easier to tackle, delegate, and address. Goal-oriented processes don’t follow a one-size-fits-all methodology; instead, they are responsive and quick to adapt to changing user and requirement needs, which is why a thorough plan goes a long way in defining costs and staffing decisions, providing clear goals and deliverables, measuring performance, and validating each phase of the life cycle to improve quality. 

The importance of the software development cycle comes first in any software development process. The quality, lead time, and budget of the output product depend on properly-constructed cycles. This will save the team efforts of programmers, testers, and PMs while increasing the survivability of the product in the conditions of real user operations. Next, we will cover the main phases involved in the System Development Life Cycle to review what each entails.

The SDLC Phases

The SDLC phases are designed in a way that progressively develops or alters a system across its life cycle. If followed through from beginning to end, the SDLC will help deploy a fully-operational, high-quality system that meets and/or exceeds client requirements, all within the specified time and budget constraints. 

Next, we’ll be dissecting each of the SDLC phases.

Setting a strong foundation and defining a clear understanding of a project is crucial to the success of any information system. For this reason, the SDLCs first phase is planning where stakeholders and all parties involved in the project participate to clearly define requirements and the nature of what the information system will need to solve. The planning phase helps delineate all subsequent tasks so they can be planned and budgeted for accordingly. 

To achieve a comprehensive planning cycle, members of the project need to have a deep understanding of what tasks the future information system needs to solve. With that foundation as context, the quality and time spent on the planning phase have a direct correlation to the success of the project. 

In this phase, the team defines the key components of the project at a high level, they define the environment in which the information system will operate along with the necessary technical, budget, and human resources required to complete the project. 

Analysis 

Once a thorough plan is set in place, next comes the analysis phase. This crucial phase is where project members dive deep and define the technical requirements of the system so they can be properly addressed. 

The analysis phase in SDLC allows you to receive feedback and support from relevant internal and external stakeholders. At the same time, you will need to think broadly about who your potential users will be. At this stage, you will include your clients, designers, management team, programmers, testers, and other technical team members. In general, this stage is all about answering the question: “What problems need to be solved?”

Also, during the analysis phase, the team defines the inputs and outputs of the data flow in and out of the system by undertaking a thorough system analysis of the business processes that need to be covered and solved by the future system. 

This phase is closely tied to documenting all the project specifications and the team usually takes sufficient time to properly document each detail for future reference.

Progressing down the SDLC, the next phase that typically follows analysis is the design phase. In this phase, all the documentation that the team created in the analysis phase is used to develop the actual technical documentation of the project. This could be a statement of work in corporate or SRS in IEEE830 format.

In the design phase, project members define the structure of project components as well as key elements of the system by defining the interfaces that will exchange data within the workflow. It’s very common for the project teams to use UML diagrams in the design phase to design the system’s architecture.

Development 

Ah, what many consider the pièce de résistance, the development phase. By far, one of the richest phases in the SDLC process, the development phase is used to write the actual code of the system’s software, develop and deploy the system’s hardware, configure cloud systems, implement interaction protocols, and prepare the primary test data. So, you can see why it’s such a big deal.

During the development phase, thanks to the UML diagrams that were built in the design phase, project teams carefully implement the system’s architecture in program code by creating methods and algorithms for information processing, preparing the project outputs, and building a monitoring system for the system. 

Testing and deployment

Right after the development phase, comes testing and deployment. What does this phase entail, really? Well, for any system to work as intended, it needs to be thoroughly tested and tested again until the results match the expected outcome.

This phase is crucial as it directly impacts the quality of the outputs as it’s where the Quality Assurance (QA) team takes assertive steps to verify and validate the elements of the information system across multiple software testing scenarios, be it through a black box or white box testing. 

In this phase, the QA team also helps improve code coverage through automated tests and using resources from both the backend and the frontend of the system. Here, the QA team also carries out trial runs to collect system behavior data for insights on what can be improved or tweaked for a superior user and system experience. 

Once the production environment is thoroughly tested, it’s primed to be deployed and out into the world. Typically, this task is performed by the DevOps team with the help of CI/CD methodology. Also, deployment entails the implementation of cloud services, hardware, monitoring systems, the configuration of maintenance protocols of complex data, security measures, and data access restrictions.

Maintenance

The SDLC doesn’t necessarily stop once the system is out living and breathing. What comes next is the maintenance phase where the project teams carefully assess the system to help reduce the cost of operation and maintenance through several methods like feedback collection, error detection and elimination, and optimal performance standards.

For example, a system’s maintenance may also include the tracking and monitoring of the system's security, eliminating potential risks and threats, assembling a list of functionalities that need to be updated, adapting the system to environment changes and new business requirements, and more. 

Read more about the SDLC phases in this article .

SDLC: Methodologies of System Development

SDLC is not an isolated process, in fact, there are many methodologies available that are paired successfully to meet unique project needs. Each methodology has its distinctive collection of pros and cons that should be weighed down to decide which aspect or trait will yield the best results for an SDLC project. 

In general, SDLC in information systems is defined by a model and described in the form of a methodology. The life cycle model or paradigm defines the overall organization and, as a rule, its main phases and principles of transition between them. The methodology or method determines the set of actions, their detailed content, and the roles/responsibilities of specialists at all stages of the selected software development model.

From Agile to Waterfall as the most prominent methodologies that can be tied to the SDLC effort, there are other noteworthy options to consider including the prototyping model, the iterative model, the spiral model, the v-shape model, Scrum, Kanban, the fountain model, the build and fix model, the Rapid Application Development (RAD) model, and many more. 

Let’s dissect some of the most widely used SDLC methodologies next.

Waterfall is something of a staple in the SDLC sphere. Many associate this methodology with a traditional way of doing things, following a sequential and linear approach to developing software. 

Thanks to this systematic and rigidly standardized approach, Waterfall consists of a series of stages and each one needs to be completed before moving on to the next one, without exceptions. A typical and straightforward Waterfall workflow includes requirements, design, execution, testing, and release.

Rapid application development (RAD)

Adaptive and fast by nature, the RAD model puts less emphasis on planning and more on adaptive tasks. What do we mean by this? RAD favors rapid prototypes as a means to substitute development and testing cycles, making it one of the most popular SDLC models for software as it allows for rapid software development without the need to develop schedules at the beginning of each dev cycle.

RAD’s development model was first conceived back in the 80s to solve the need of developers looking for a more effective solution than the traditional Waterfall. One of the biggest faults of the Waterfall methodology, and one that most developers complain about, is the complexity to change core functions and software features. In RAD, the development evolution is continuous and flexible to suit changing business needs, which is a must in today’s modern environment.

Prototyping

When you hear the word prototype, if you’re like us, your mind wanders off to miniature airplanes or cars that we sometimes referred to as prototypes.

Well, in the context of software development, it’s not too far from the truth. The prototyping model builds prototypes or small replicas of the software to emulate how the final product will behave with all the functioning aspects built to behave as expected.

By having the product emulate expected behavior on a small scale and in a controlled environment, it’s easier for developers to visualize components to ensure the software solves the needs it was designed for. 

Prototyping has different variants which are typically grouped as throwaway or evolutionary. Throwaway prototypes create replicas of the software that will eventually be discarded while evolutionary prototypes create a robust replica that will continuously be refined until it reaches its final version.

Spiral 

Considered one of the most popular methodologies for SDLC, the Spiral model is an exceptional solution for risk handling. This model’s key differentiator is its diagrammatic visualization which resembles that of a spiral with many loops across the spiral which can vary from project to project. 

Each loop within the spiral is called a phase and they can be defined based on the needs of the project managers in terms of risks. Another interesting aspect of the spiral model is its radius which represents the costs of the project while the angular dimension sheds light on the progress being made on the project in each current phase. 

Many project managers favor the spiral model for large and complex projects because it leverages the phases of Waterfall but splits them into planning, risk assessment, and prototype building, making it a hybrid of sorts that works especially well in these types of projects.

In our book, and we might be a little biased, Agile is the methodology that developers favor the most out of all the methodologies out there. 

Famous for its iterative approach to software development that offers rapid-fire progress, Agile is a framework that fosters highly collaborative environments between all the teams involved in a project.

It’s dynamic, adaptive, flexible, lightweight, and extremely responsive, working in sprints with a defined time period to complete small and highly manageable tasks, thus reducing the time in which software goes live. Through and through, Agile is an advocate of adaptive planning, evolutionary development, continuous improvement, responsiveness, flexibility, and quick delivery.

Kanban, Scrum, or Agile : read more to see which model works better in which case.

Iterative and incremental

The iterative and incremental SDLC model does its name honor. This model is kicked off with a small set of requirements which is then enhanced iteratively with evolving versions until you reach a final product that’s ready to be implemented and deployed. The iterative and incremental model is the answer to Waterfall’s many faults; for example, the iterative life cycle starts by specifying and implementing only a portion of the software, which is then reviewed to dictate which features will follow next.

In short, the iterative and incremental model works through multiple, repeated, and incremental cycles so developers can pinpoint which areas to improve based on previous deployments of the software.

An extended arm of the Waterfall methodology, the v-model executes processes sequentially in an upward fashion, which in visual context resembles the letter V.  Some refer to the v-model as the verification and validation model thanks to its foundation of testing phases for each development phase. In short, every piece of software development is associated with a testing phase.

One thing to note about the v-model is that no phase can start until the previous one is completed including a corresponding testing exercise. 

The beauty of software development is that methodologies can be combined to create a hybrid solution that distinctively addresses the unique needs of a project. Usually, organizations prefer to trust system analysts to make that decision and select the best-suited methodology or combination of models. 

Next, we’re going to explore the roles of a system analyst and an information system architect to better understand what each role entails, how they uphold the standards of the SDLC, and the valuable skills they need to have as they are an integral part of any software project’s success.

System Analyst

System Analysts are knowledgeable in analysis and design techniques to solve business problems via information technology. Oftentimes, system analysts are tasked with identifying opportunity area gaps and generating organizational improvements to reach specific goals. Overall, the System Analyst is a professional who has strong interpersonal, technical, analytical, and management skills.

The System Analyst works on high-level system reviews to assess if systems and infrastructures operate effectively and efficiently. System analysts research problems, find or develop solutions, recommend a course of action, communicate and coordinate with stakeholders, choose resources, and design action plans to reach a goal and meet predefined requirements. They are experts at studying a system, process, or procedure to come up with the best solutions.

Ideally, System Analysts are highly skilled and knowledgeable in multiple operating systems, hardware configurations, programming languages, and software and hardware platforms. They are usually involved from the beginning stages of a project and up until the post-evaluation review of the solution. In short, this type of professional is known for being able to help transform requirements into technical design specifications by understanding and determining how to solve a problem with a diverse selection of platforms, protocols, software, hardware, and communication outlets.

Information System Architect

The Information System Architect architects the project across its life cycle; In short, this professional designs the software architecture and defines the main interfaces and key elements of the information system as a whole.

Within the SDLC framework, the Information System Architect takes on highly active roles during the planning, analysis, and design phases, and acts as a companion role in all other phases of development. 

The Information System Architect is responsible for selecting the high-level tech stack and component structure of the future solution. Once the technologies and components are selected, the architect proceeds to determine the implementation patterns and components to then create a thorough description of the interaction protocols, programming languages, frameworks, data storage systems, and cloud systems. 

In the later stages of the SDLC, the architect systematically reviews the system’s requirements, maintains close communication with the client, supervises the architectural aspects of the system at all stages of implementation and testing, and modulates any reengineering or refactoring efforts of the system.

Project Manager

As a multilayered role, the Project Manager is in charge of managing and overseeing the end-to-end SDLC effort, allocating resources and handling other operational tasks such as financials, planning, and more. They are typically tasked with selecting the right project management methodology with full ownership of the methodology components. 

Project managers are also responsible for keeping stakeholders in the loop of everything that’s happening with a project by engaging with them regularly and keeping communication channels open and flowing. This professional is also tasked with developing and employing best practices and standards for project documentation as well as comprehensive documentation of requirements. Additionally, project managers must also carefully evaluate the risks of the project across every phase and craft contingency plans to mitigate or reduce risks as much as possible.

Software Developer

Integral to the success of any SDLC project, the developer writes project code and integrates system elements into a cohesive end product. Developers are responsible for developing the system architecture with assistance from the System Architect, evaluating and carefully selecting the right tech stack based on unique project needs. 

Developers help develop scripts for automated testing and fix any system flaws or defects as testers identify them.

Tester (QA)

The project is as good as it is thoroughly tested, which is why the tester's role is critical in any SDLC effort. Testers test the software and validate that it’s behaving as intended as well as approving the beta version release once it’s properly tested and retested.

In the first SDLC phases, testers design and develop a test plan with a specific set of acceptance tests based on which decisions will determine the product’s transition to the next development phase and the criteria for defects in subsequent testing iterations. 

Testers typically use both black and white box testing, and take an active role when writing QA automation scripts with developers.

DevOps Engineer

DevOps engineers are IT professionals who work side-by-side with developers and other IT personnel to look after and guide code releases and deployments. DevOps professionals play a key role in the SDLC effort, especially in the planning and system operation components. 

Early in the project, DevOps professionals engage in project planning in concert with the system architect and system analyst to help select the optimal CI/C tools and cloud-based solutions that meet the unique needs of the information system. DevOps professionals are acutely aware of project requirements and use them as the foundation behind every technology, architecture, and tool selection. 

DevOps professionals also work side-by-side with developers and testers to help monitor the end product across its cloud infrastructure, scalability, and load. This unique role frequently moves several times throughout SDLC phases, formulating requirements for the system along the way for the next development cycle, and upholding SDLC standards.

Time and again, it’s been proven that projects not only benefit but thrive by following a standardized set of steps to achieve a final result. Cue the Software Development Life Cycle which allows the team to work on manageable phases until the project is released. By doing so, teams establish a systematic fashion to go about creating new solutions to existing problems in a controlled and standardized manner. 

Before embarking on a new project, it’s important to identify how the SDLC will cover and satisfy the overall requirements to deliver the best results. Next, you can select the best SDLC methodology or a combination of methodologies to help you address the best approach to execute the SDLC. 

At Svitla Systems , we have expert teams of specialists who are knowledgeable in all the major SDLC methodologies, as well as the latest and most successful methods to help you build a powerful information system.

Related articles

Partner with Svitla and fill out the form below for more information!

At Svitla Systems we sure are experts on how to deploy SDLC smoothly. With top-notch developers who are extremely knowledgeable on the SDLC methodology, we can provide you the right environment where software thrives and comes to life.

Your message is received. Svitla's sales manager of your region will contact you to discuss how we could be helpful.

Guide to System Development Life Cycle

• Custom Software Development
• Guide to System...

What is the System Development Life Cycle?

7 stages of the system development life cycle, basic 6 sdlc methodologies, benefits of sdlc, possible drawbacks of sdlc.

If you’re a developer or project manager, an understanding of the most up-to-date SDLC methodologies is a powerful tool. It empowers you to speed up the development process, cut costs, leverage the full creative capacity of your team, and more.

With that in mind, Intellectsoft’s best experts have created a complete guide to the system development life cycle. You’ll learn about its core meaning and phases, major software engineering methodologies , and the most important benefits it can provide during project development.

Special attention has been given to the characteristics of each of the seven SDLC phases because a thorough understanding of these different stages is required to implement both new and modified software systems.

Ready to maximize the efficiency of your systems development life cycle? Let’s dive in. 

The system development life cycle or SDLC is a project management model used to outline, design, develop, test, and deploy an information system or software product. In other words, it defines the necessary steps needed to take a project from the idea or concept stage to the actual deployment and further maintenance.

SDLC represents a multitude of complex models used in software development. On a practical level, SDLC is a general methodology that covers different step-by-step processes needed to create a high-quality software product. 

There are seven separate SDLC stages . Each of them requires different specialists and diverse skills for successful project completion. Modern SDLC processes have become increasingly complex and interdisciplinary .

That is why it’s highly recommended that project managers engage a dedicated team of professional developers . Such a team will possess enough expertise and knowledge to launch a first-class software product that perfectly corresponds to all your expectations, needs, and goals.

Let’s take a look at the core tasks associated with each of the different phases of the development life cycle.

1. Planning Stage – What Are the Existing Problems?

Planning is one of the core phases of SDLC . It acts as the foundation of the whole SDLC scheme and paves the way for the successful execution of upcoming steps and, ultimately, a successful project launch.

In this stage, the problem or pain the software targets is clearly defined. First, developers and other team members outline objectives for the system and draw a rough plan of how the system will work. Then, they may make use of predictive analysis and AI simulation tools at this stage to test the early-stage validity of an idea. This analysis helps project managers build a picture of the long-term resources required to develop a solution, potential market uptake, and which obstacles might arise. 

At its core, the planning process helps identify how a specific problem can be solved with a certain software solution. Crucially, the planning stage involves analysis of the resources and costs needed to complete the project, as well as estimating the overall price of the software developed.

Finally, the planning process clearly defines the outline of system development. The project manager will set deadlines and time frames for each phase of the software development life cycle , ensuring the product is presented to the market in time.

2. Analysis Stage – What Do We Want?

Once the planning is done, it’s time to switch to the research and analysis stage. 

In this step, you incorporate more specific data for your new system. This includes the first system prototype drafts, market research, and an evaluation of competitors. 

To successfully complete the analysis and put together all the critical information for a certain project, developers should do the following:

• Generate the system requirements. A Software Requirement Specification (SRS) document will be created at this stage. Your DevOps team should have a high degree of input in determining the functional and network requirements of the upcoming project.
• Evaluate existing prototypes.  Different prototypes should be evaluated to identify those with the greatest potential. 
• Conduct market research. Market research is essential to define the pains and needs of end-consumers. In recent years, automated NLP (natural language processing) research has been undertaken to glean insights from customer reviews and feedback at scale. 
• Set concrete goals. Goals are set and allocated to the stages of the system development life cycle . Often, these will correspond to the implementation of specific features.

Most of the information generated at this stage will be contained in the SRS. This document shapes the strict regulations for the project and specifies the exact software model you will eventually implement.

3. Design Stage – What Will the Finished Project Look Like?

The next stage of a system development project is design and prototyping. 

This process is an essential precursor to development. It is often incorrectly equated with the actual development process but is rather an extensive prototyping stage. 

This step of the system development life cycle can significantly eliminate the time needed to develop the software. It involves outlining the following: 

• The system interface
• Core software features (including architecture like microservices) 
• User interface and usability
• Network and its requirement

As a rule, these features help to finalize the SRS document as well as create the first prototype of the software to get the overall idea of how it should look like.

Prototyping tools, which now offer extensive automation and AI features, significantly streamline this stage. They are used for the fast creation of multiple early-stage working prototypes, which can then be evaluated. AI monitoring tools ensure that best practices are rigorously adhered to.

4. Development Stage – Let’s Create the System

In the development stage of SDLC, the system creation process produces a working solution. Developers write code and build the app according to the finalized requirements and specification documents.

This stage includes both front and back-end development. DevOps engineers are essential for allocating self-service resources to developers to streamline the process of testing and rollout, for which CI/CD is typically employed. 

This phase of the system development life cycle is often split into different sub-stages, especially if a microservice or miniservice architecture, in which development is broken into separate modules, is chosen. 

Developers will typically use multiple tools, programming environments, and languages (C++, PHP, Python, and others), all of which will comply with the project specifications and requirements outlined in the SRS document. 

5. Testing Stage – Is It the Exact One We Needed?

The testing stage ensures the application’s features work correctly and coherently and fulfill user objectives and expectations. 

This process involves detecting the possible bugs, defects, and errors, searching for vulnerabilities, etc . , and can sometimes take up even more time compared to the app-building stage.

There are various approaches to testing, and you will likely adopt a mix of methods during this phase. Behavior-driven development, which uses testing outcomes based on plain language to include non-developers in the process, has become increasingly popular. 

Similarly, automated and cloud-based platforms, which simulate testing environments, take a significant amount of manual time out of this stage of the system development life cycle. Selenium, a browser testing tool, is one popular example of such a platform. 

6. Integration and Implementation Stage – How Will We Use It?

Once the product is ready to go, it’s time to make it available to its end users and deploy it to the production environment. 

At this stage, the software undergoes final testing through the training or pre-production environment, after which it’s ready for presentation on the market.

It is important that you have contingencies in place when the product is first released to market should any unforeseen issues arise. Microservices architecture, for example, makes it easy to toggle features on and off. And you will likely have multiple rollback protocols. A canary release (to a limited number of users) may be utilized if necessary. 

7. Maintenance Stage – Let’s Make the Improvements

The last but not least important stage of the SDLC process is the maintenance stage, where the software is already being used by end-users.

D uring the first couple of months, developers might face problems that weren’t detected during initial testing, so they should immediately react to the reported issues and implement the changes needed for the software’s stable and convenient usage.

This is particularly important for large systems, which usually are more difficult to test in the debugging stage.

Automated monitoring tools, which continuously evaluate performance and uptime and detect errors, can assist developers with ongoing quality assurance. This is also known as “instrumentation.”

Now that you know the basic SDLC phases and why each of them is important, it’s time to dive into the core methodologies of the system development life cycle.

These are the approaches that can help you to deliver a specific software model with unique characteristics and features. Most developers and project managers opt for one of these 6 approaches. Hybrid models are also popular.

Let’s discuss the major differences and similarities of each.

Waterfall Model

This approach implies a linear type of project phase completion, where each stage has its separate project plan and is strictly related to the previous and next steps of system development.

Typically, each stage must be completed before the next one can begin, and extensive documentation is required to ensure that all tasks are completed before moving on to the next stage. This is to ensure effective communication between teams working apart at different stages. 

While a Waterfall model allows for a high degree of structure and clarity, it can be somewhat rigid. It is difficult to go back and make changes at a later stage. 

Iterative Model

The Iterative model incorporates a series of smaller “waterfalls ,” where manageable portions of code are carefully analyzed, tested, and delivered through repeating development cycles. Getting early feedback from an end user enables the elimination of issues and bugs in the early stages of software creation.

The Iterative model is often favored because it is adaptable , and changes are comparatively easier to accommodate. 

Spiral Model

The Spiral model best fits large projects where the risk of issues arising is high. Changes are passed through the different SDLC phases again and again in a so-called “spiral” motion.

It enables regular incorporation of feedback, which significantly reduces the time and costs required to implement changes.

Verification and validation methodology requires a rigorous timeline and large amounts of resources. It is similar to the Waterfall model with the addition of comprehensive parallel testing during the early stages of the SDLC process.

The verification and validation model tends to be resource-intensive and inflexible. For projects with clear requirements where testing is important, it can be useful. 

The Big Bang Model

Mostly used for creating and delivering a wide range of ideas, this model perfectly fits the clients who don’t have a clear idea or vision of what their final product should look like.

A more concrete vision of project completion is gained via delivering different system variations that may more accurately define the final output. 

While it is usually too expensive for the delivery of large projects, this SDLC methodology perfectly works for small or experimental projects.

Agile Model

The Agile model prioritizes collaboration and the implementation of small changes based on regular feedback. The Agile model accounts for shifting project requirements, which may become apparent over the course of SDLC. 

The Scrum model, which is a type of time-constrained Agile model, is popular among developers. Often developers will also use a hybrid of the Agile and Waterfall model, referred to as an “Agile-Waterfall hybrid . ”

As you can see, different methodologies are used depending on the specific vision, characteristics, and requirements of individual projects. Knowing the structure and nuances of each model can help to pick the one that best fits your project.

Having covered the major SDLC methodologies offered by software development companies, let’s now review whether they are actually worth employing. 

Here are the benefits that the system development life cycle provides:

• Comprehensive overview of system specifications, resources, timeline, and the project goals
• Clear guidelines for developers
• Each stage of the development process is tested and monitored
• Control over large and complex projects
• Detailed software testing
• Process flexibility
• Lower costs and strict time frames for product delivery
• Enhanced teamwork, collaboration, and shared understanding

Just like any other software development approach, each SDLC model has its drawbacks:

• Increased time and costs for the project development if a complex model is required
• All details need to be specified in advance
• SDLC models can be restrictive
• A h igh volume of documentation which can slow down projects
• Requires many different specialists
• Client involvement is usually high
• Testing might be too complicated for certain development teams

While there are some drawbacks, SDLC has proven to be one of the most effective ways for successfully launching software products. 

Alternative development paradigms, such as rapid application development (RAD), may be suitable for some projects but typically carry limitations and should be considered carefully. 

The system development life cycle (SDLC) is a complex project management model that encompasses system or software creation from its initial idea to its finalized deployment and maintenance.

SDLC comprises seven different stages: planning, analysis, design, development, testing, implementation, and maintenance. All are necessary for delivering a high-quality and cost-effective product in the shortest time frame possible.

Learning about major methodologies of SDLC, along with their benefits and drawbacks, enables you to set up effective system development processes that deliver the best possible outcomes. 

At Intellectsoft, we know how important an effective project management strategy is. Our developers and specialists have a track record of building innovative software solutions that perfectly fit our clients’ business goals and requirements.

If you’re looking for a reliable software development company to turn your idea into a top-quality software product, contact our team today.

What are the 7 phases of SDLC?

The typical stages of the system development life cycle are planning and feasibility, requirements analysis, design and prototyping, software development, system testing, implementation, and maintenance.

Alternatively, the processes described above are sometimes split into 5 phases of the system development life cycle: planning, design, implementation, maintenance, and follow-up testing.

What is the most popular SDLC model?

The Agile approach is probably the most widely used SDLC model. Hybrid models are also common. At Intellectsoft , we are proficient with a wide range of models.

What are the latest SDLC innovations?

Automation and AI are transforming the way developers approach SDLC. DevOps processes have also had a significant impact. Intellectsoft works at the cutting edge of SDLC tech and can help you implement it in your organization.

YOU MIGHT ALSO LIKE

Developing construction estimating software, how to choose a software development company: fundamental do’s and don’ts, how to create a successful mvp: a blueprint for startups, mobile app development trends of 2023, the importance of user experience in software development, cloud computing in software development.

Something went wrong. Send form again, please.

Thank you for your response!

We have sent an email to acknowledge receipt of your request. In the event that you have not received our email, we kindly suggest checking your spam folder or alternatively, contacting us directly at [email protected]

What’s Next?

• We will send a short email notifying you that we successfully received your request and started working on it.
• Our solution advisor analyzes your requirements and will reach back to you within 3 business days.
• We may sign an optional mutual NDA within 1-2 business days to make sure you get the highest confidentiality level.
• Our business development manager presents you an initial project estimation, ballpark figures, or our project recommendations within approximately 3-5 days.

Request a Free Quote

We have offices in:, contact us request a free quote, thank you for your message.

We will get in touch with you regarding your request within one business day.

To read this content please select one of the options below:

Please note you do not have access to teaching notes, the system development life cycle and digital library development.

OCLC Systems & Services: International digital library perspectives

ISSN : 1065-075X

Article publication date: 6 November 2007

The purpose of this article is to develop an understanding of the system development lifecycle and its role in managing the development of digital library systems.

Design/methodology/approach

The article provides a conceptual analysis of the system development lifecycle within the context of digital library system development.

The system development lifecycle concept has been broadly applied to system development projects for many years. Project teams developing digital library systems can be more effective if they understand the expectations and outcomes of each phase of the system development lifecycle.

Originality/value

For librarians that do not have a formal system development background, this article provides a concise and to‐the‐point overview of the various stages of the system development lifecycle and the relationship of each phase to the development of a digital library system.

• Digital libraries
• Library systems

Cervone, H.F. (2007), "The system development life cycle and digital library development", OCLC Systems & Services: International digital library perspectives , Vol. 23 No. 4, pp. 348-352. https://doi.org/10.1108/10650750710831484

Emerald Group Publishing Limited

Copyright © 2007, Emerald Group Publishing Limited

Related articles

All feedback is valuable.

Please share your general feedback

Report an issue or find answers to frequently asked questions

Contact Customer Support

GHG emission quantification and reduction pathway of subway shield tunnel engineering: a case study on Guangzhou Metro, China

• Research Article
• Published: 31 August 2024

Cite this article

• Huanyu Wu 1 , 2 , 3 ,
• Kehua Yang 1 , 2 ,
• Kunyang Chen   ORCID: orcid.org/0000-0003-4406-4869 1 , 3 , 4 ,
• Wenwen Zhou 1 , 2 ,
• Tao Yu 5 &
• Kai Wang 6  

The shield method is a commonly used construction technique in subway tunnel engineering. However, studies on greenhouse gas (GHG) emissions specifically in subway shield tunnel engineering are lacking. This study aims to investigate the GHG emission characteristics and GHG reduction pathways during the construction period of subway shield tunnels. Firstly, based on the life cycle assessment (LCA) method, a greenhouse gas (GHG) emission quantification model for the shield tunnel construction period was developed using a multi-level decomposition of construction. Then, the GHG emission level and intensity during the construction period of a case project are quantified, and its emission characteristics and GHG reduction potential points are assessed. Finally, a comprehensive path for GHG reduction in subway shield tunnel engineering is proposed. The research results indicate that constructing 1 km of subway shield tunnel can generate 19,294.28 t CO 2 eq. Among these, material production element dominates the emissions with a percentage of 89.05%, while transportation and mechanical construction elements contribute 1.81% and 9.14%, respectively. From the structure perspective, the main structure contributes 88.73% of total emissions, while the ancillary structure contributes 11.27%. Among them, the working shaft and tunnel segments are the main sources of emissions for the main structure, accounting for 23.65% and 65.08%, respectively. Connecting channel and end reinforcement are the main emission sources of the ancillary structures, accounting for 43.63% and 31.30%, respectively. These findings provide a scientific foundation for the environmentally friendly transformation of urban railway development regarding pursuing “carbon peaking and carbon neutrality” strategic goals.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Subscribe and save.

• Get 10 units per month
• Download Article/Chapter or eBook
• 1 Unit = 1 Article or 1 Chapter
• Cancel anytime

Price includes VAT (Russian Federation)

Instant access to the full article PDF.

Rent this article via DeepDyve

Institutional subscriptions

Explore related subjects

• Environmental Chemistry

Data availability

The datasets on which the conclusions of the paper rely are presented in the Appendix.

Abbreviations

Greenhouse gas

Life cycle assessment

Life cycle inventory

Life cycle impact assessment

Carbon dioxide equivalent

International Organization for Standardization

Intergovernmental Panel on Climate Change

Global warming potential

Acidification potential

Eutrophication potential

Harm to human health

Photochemical oxidant production potential

Ahn C, Xie H, Lee SH, Abourizk S, Peña-Mora F (2012) Carbon footprints analysis for tunnel construction processes in the preplanning phase using collaborative simulation. In Construction Research Congress 2010: Innovation for Reshaping Construction Practice (1538–1546). DOI: https://doi.org/10.1061/41109(373)154

AzariJafari H, Yahia A, Amor MB (2016) Life cycle assessment of pavements: reviewing research challenges and opportunities. J Clean Prod 112:2187–2197. https://doi.org/10.1016/j.jclepro.2015.09.080

Article   Google Scholar  

Buschka M, Bischof J, Meier-Dotzler C, Lang W (2021) Developing non-residential building stock archetypes for LCI—a German case study of office and administration buildings. Int J Life Cycle Assess 26:1735–1752. https://doi.org/10.1007/s11367-021-01963-5

Chaturvedi V, Kim SH (2015) Long term energy and emission implications of a global shift to electricity-based public rail transportation system. Energy Policy 81:176–185. https://doi.org/10.1016/j.enpol.2014.11.013

Chen KY, Chen XS, Wang L, Yang WS, Qiu T, Su D, Wu HY (2023) Low-carbon effects of constructing a prefabricated subway station with temporary internal supports: an innovative case of Shenzhen, China. J Clean Prod 426:139023. https://doi.org/10.1016/j.jclepro.2023.139023

Article   CAS   Google Scholar  

Chen KY, Duan HB, Zhang Y et al (2022b) Research on carbon emission intensity and reduction potential in Guangzhou metro shield tunnel construction phase. Tunnel Constr 42(12):2064 (in Chinese)

Google Scholar  

Chen R, Li LX, Yang K, Ren F, Xi CG, Lin Y, Zheng H (2022a) Quantitative methods for predicting underground construction waste considering reuse and recycling. Environ Sci Pollut Res 29:3394–3405. https://doi.org/10.1007/s11356-021-15858-3

Chen XL, Zhang XM, Chen J, Hu T, Wan C, Long LD, Yang F (2022c) Green construction optimization of ultrasmall clearance tunnel based on carbon emission evaluation. China J Highw Transp (01):59–70. https://doi.org/10.19721/j.cnki.1001-7372.2022.01.006 (in Chinese)

Cheng H, Madanat S, Horvath A (2016) Planning hierarchical urban transit systems for reductions in greenhouse gas emissions. Transp Res Part D Transp Environ 49:44–58. https://doi.org/10.1016/j.trd.2016.08.033

China Association of Metro (2022) Urban rail transit statistics annual report. (in Chinese) https://www.camet.org.cn/tjxx/11944 . Accessed 14th November 2023

Chohan IM, Ahmad A, Sallih N, Bheel N, Ali M, Deifalla AF (2023) A review on life cycle assessment of different pipeline materials. Results Eng:101325. https://doi.org/10.1016/j.rineng.2023.101325

Compilation Rules of Construction Machines and Equipment Shift Cost in Guangdong Province, China, 2018. (in Chinese) https://www.gd.gov.cn/attachment/0/381/381883/2721956.pdf . Accessed 16th November 2023

Comprehensive Quota of Urban Rail Transit Engineering in Guangdong Province (Volumes 6 to 10), China, 2021. (in Chinese) https://zfcxjst.gd.gov.cn/ Accessed 16th November 2023

Farahzadi L, Kioumarsi M (2023) Application of machine learning initiatives and intelligent perspectives for CO 2 emissions reduction in construction. J Clean Prod 384:135504. https://doi.org/10.1016/j.jclepro.2022.135504

Gao XJ (2013) Study on carbon emission assessment and integratedoptimal control methods for urban rail transit system. Beijing Jiaotong University, Dissertation (in Chinese)

GB/T 51366-2019 (n.d.). Calculation Standard for Building Carbon Emission. Beijing, China: Construction Industry Press. (in Chinese) http://www.weboos.cn:8083/assets/basicStandard/std_1540035.pdf . Accessed 16th November 2023

González-Gil A, Palacin R, Batty P (2013) Sustainable urban rail systems: strategies and technologies for optimal management of regenerative braking energy. Energy Convers Manag 75:374–388. https://doi.org/10.1016/j.enconman.2013.06.039

Griswold JB, Madanat S, Horvath A (2013) Tradeoffs between costs and greenhouse gas emissions in the design of urban transit systems. Environmental Research Letters 8(4):044046. https://doi.org/10.1088/1748-9326/8/4/044046

Guo C, Xu JF, Zhang JP (2020) Calculation method and prediction model of carbon emissions from tunnel construction. Tunnel Constr:1140–1146 (in Chinese)

Harwatt H, Tight M, Timms P (2011) Personal transport emissions within London: exploring policy scenarios and carbon reductions up to 2050. Int J Sustain Transp 5(5):270–288. https://doi.org/10.1080/15568318.2010.506586

Huang LZ, Bohne RA, Bruland A, Jakobsen PD, Lohne J (2015) Life cycle assessment of Norwegian road tunnel. Int J Life Cycle Assess 20:174–184. https://doi.org/10.1007/s11367-014-0823-1

Huang Y, Guo HX, Xie PC, Liao CP, Zhao DQ (2017) Study on carbon emission reduction calculation of subway travel take Guangzhou as an example. Prog Climate Change Res 13(03):284–291 (in Chinese)

Huo TF, Li XH, Cai WG, Zuo J, Jia FY, Wei HF (2020) Exploring the impact of urbanization on urban building carbon emissions in China: evidence from a provincial panel data model. Sustain Cities Soc 56:102068. https://doi.org/10.1016/j.scs.2020.102068

IPCC (Intergovernmental Panel on Climate Change), 2013. Climate change 2013: the physical Construction Industry Press. https://www.ipcc.ch/2013/01/30/ipcc-publishes-full-report-climate-change-2013-the-physical-science-basis/ . Accessed 16th November 2023

ISO 14040:2006. Environmental Management - Life Cycle Assessment - Principles and Framework International Organization for Standardization, Geneve (2006) https://www.iso.org/standard/37456.html . Accessed 16th November 2023

ISO 14044:2006. Environmental Management - Life Cycle Assessment - Requirements and Guidelines. International Organization for Standardization, Geneve (2006) https://www.iso.org/standard/38498.html . Accessed 16th November 2023

Jia JM, Ren F, Wei X, Gao YH, Qi G, Li F, Li M, Guo CG (2022) Applying rail transit construction waste to make building materials: using the theory of sustainable development. Environ Sci Pollut Res 29:29663–29681. https://doi.org/10.1007/s11356-021-17821-8

Karunaratne S, Dharmarathna D (2022) A review of comprehensiveness, user-friendliness, and contribution for sustainable design of whole building environmental life cycle assessment software tools. Build Environ 212. https://doi.org/10.1016/j.buildenv.2022.108784

Khan H, Liu W, Khan I (2022) Environmental innovation, trade openness and quality institutions: an integrated investigation about environmental sustainability. Environ Dev Sustain 24:3832–3862. https://doi.org/10.1007/s10668-021-01590-y

Lederer J, Ott C, Brunner PH, Ossberger M (2015) The life cycle energy demand and greenhouse gas emissions of high-capacity urban transport systems: a case study from Vienna’s subway line U2. Int J Sustain Transp 10(2):120–130. https://doi.org/10.1080/15568318.2013.869704

Lee JH, Shim JA, Kim KJ (2016) Analysis of environmental load by work classification for NATM tunnels. KSCE J Civ Environ Eng Res 36:307–315. https://doi.org/10.12652/Ksce.2016.36.2.0307

Li QS, Bai Y, Li L (2015) Research on the influence factors and measures of low-carbon in the construction stage of shield tunnel. Mod Tunnel Technol (03):1–7. https://doi.org/10.13807/j.cnki.mtt.2015.03.001 (in Chinese)

Li Y, He Q, Luo X, Zhang YR, Dong L (2018a) Calculation of life-cycle greenhouse gas emissions of urban rail transit systems: a case study of Shanghai Metro. Resour Conserv Recycl 128:451–457. https://doi.org/10.1016/j.resconrec.2016.03.007

Li Y, Hou X, Zhang W et al (2018b) Integration of life cycle assessment and statistical analysis to understand the influence of rainfall on WWTPs with combined sewer systems. J Clean Prod 172:2521–2530. https://doi.org/10.1016/j.jclepro.2017.11.158

Lin R, Ren J (2021) Overview of multi-criteria decision analysis and its applications on energy systems. In: Ren J (ed) Energy Systems Evaluation (Volume 2). Green Energy and Technology. Springer, Cham. https://doi.org/10.1007/978-3-030-67376-5_1

Chapter   Google Scholar  

Madanat S, Horvath A, Mao C, Cheng H (2016). Potential greenhouse gas emission reductions from optimizing urban transit networks. open access publications from the University of California. https://escholarship.org/uc/item/25x1b693 . Accessed 26 May 2024

Miliutenko S, Åkerman J, Björklund A (2012) Energy use and greenhouse gas emissions during the life cycle stages of a road tunnel - the Swedish case Norra Länken. Eur J Transp Infrastruct Res 12. https://doi.org/10.18757/ejtir.2012.12.1.2948

Murugesan K, Subramanian SNS, Sekar A, Ravichandran PT (2023) Energy consumption analysis of different geometries of precast tunnel lining segment numerically. Environ Sci Pollut Res 30:46475–46488. https://doi.org/10.1007/s11356-023-25472-0

Rahman A, Farrok O, Haque MM (2022) Environmental impact of renewable energy source based electrical power plants: solar, wind, hydroelectric, biomass, geothermal, tidal, ocean, and osmotic. Renew Sustain Energy Rev 161:112279. https://doi.org/10.1016/j.rser.2022.112279

Robati M, Daly D, Kokogiannakis G (2019) A method of uncertainty analysis for whole-life embodied carbon emissions (CO2-e) of building materials of a net-zero energy building in Australia. J Clean Prod 225:541–553. https://doi.org/10.1016/j.jclepro.2019.03.339

Rodríguez R, Pérez F (2021) Carbon foot print evaluation in tunnelling construction using conventional methods. Tunn Undergr Space Technol 108:103704. https://doi.org/10.1016/j.tust.2020.103704

Salehi M, Jalalian M, Vali Siar MM (2017) Green transportation scheduling with speed control: trade-off between total transportation cost and carbon emission. Comput Ind Eng 113:392–404. https://doi.org/10.1016/j.cie.2017.09.020

Schanes K, Giljum S, Hertwich E (2016) Low carbon lifestyles: a framework to structure consumption strategies and options to reduce carbon footprints. J Clean Prod 139:1033–1043. https://doi.org/10.1016/j.jclepro.2016.08.154

Shi X, Wang X, Yang J, Sun Z (2016) Electric vehicle transformation in Beijing and the comparative eco-environmental impacts: a case study of electric and gasoline powered taxis. J Clean Prod 137:449–460. https://doi.org/10.1016/j.jclepro.2016.07.096

Stasiulaitiene I, Martuzevicius D, Abromaitis, et al. (2016) Comparative life cycle assessment of plasma-based and traditional exhaust gas treatment technologies. J Clean Prod 112:1804–1812. https://doi.org/10.1016/j.jclepro.2015.01.062

Struckl W, Wimmer W (2007). Green Line—strategies for environmentally improved railway vehicles. In Advances in life cycle engineering for sustainable manufacturing businesses: Proceedings of the 14th CIRP Conference on Life Cycle Engineering, Waseda University, Tokyo, Japan, June 11th–13th, 2007 (pp. 77-82). Springer London.

Suh S, Tomar S, Leighton M, Kneifel J (2014) Environmental performance of green building code and certification systems. Environ Sci Technol 48(5):2551–2560. https://doi.org/10.1021/es4040792

Tavakol-Davani H, Rahimi R, Burian SJ, Pomeroy CA, McPherson BJ, Apul D (2019) Combining hydrologic analysis and life cycle assessment approaches to evaluate sustainability of water infrastructure: uncertainty analysis. Water 11(12):2592. https://doi.org/10.3390/w11122592

Wang HY (2023) Research on the calculation and prediction of carbon emission during the construction period of Guangxi motorway. Guangxi University, Dissertation (in Chinese)

Wang XW, Duan ZY, Wu LS, Yang DY (2015) Estimation of carbon dioxide emission in highway construction: a case study in southwest region of China. J Clean Prod, Carbon Emissions Reduction: Policies, Technologies, Monitoring, Assessment and Modeling 103:705–714. https://doi.org/10.1016/j.jclepro.2014.10.030

Wang YS, Huang XH, Yan H (2019) Quantitative analysis of embodied carbon emission in metro shield tunnel. J Civ Eng Manag (03):12–18+47. https://doi.org/10.13579/j.cnki.2095-0985.2019.03.033 (in Chinese)

Wu H, Zuo J, Yuan H, Zillante G, Wang J (2023) Investigation of the social and economic impacts of cross-regional mobility of construction and demolition waste in Australia. Resour Conserv Recycl 190:106814. https://doi.org/10.1016/j.resconrec.2022.106814

Xiao SY, Ma ZD (2018) Application of construction engineering construction carbon emission calculation method in shield construction-an example of Zhuhai Hengqin super large diameter shield construction. Constr Econ (01):36–42. https://doi.org/10.14181/j.cnki.1002-851x.201801036 (in Chinese)

Xu JF (2022) Research on carbon emission calculation method and prediction model for road tunnel construction. Southwest Jiaotong University, Dissertation (in Chinese)

Zhao JJ, Kou L, Jiang ZL, Lu N, Wang B, Li QS (2022) A novel evaluation model for carbon dioxide emission in the slurry shield tunnelling. Tunn Undergr Space Technol 130:104757. https://doi.org/10.1016/j.tust.2022.104757

Zhao R, Liu YY, Zhang N, Huang T (2017) An optimization model for green supply chain management by using a big data analytic approach. J Clean Prod, Special Volume on Improving natural resource management and human health to ensure sustainable societal development based upon insights gained from working within ‘Big Data Environments’ 142:1085–1097. https://doi.org/10.1016/j.jclepro.2016.03.006

Download references

Acknowledgements

The authors would like to thank the Shenzhen Science and Technology Innovation Commission Project (No. 20220811111306001) and the Research Project of Shenzhen THSWARE Technology Co., Ltd.—Tunnel Engineering Carbon Emissions Calculation and GHG reduction Path Research (No. 2023238).

This work was financially supported by the Shenzhen Science and Technology Innovation Commission Project (No. 20220811111306001) and the Research Project of Shenzhen THSWARE Technology Co., Ltd.—Tunnel Engineering Carbon Emissions Calculation and GHG reduction Path Research (No. 2023238).

Author information

Authors and affiliations.

College of Civil and Transportation Engineering, Shenzhen University, Shenzhen, 518060, China

Huanyu Wu, Kehua Yang, Kunyang Chen & Wenwen Zhou

Sino-Australia Joint Research Center in BIM and Smart Construction, Shenzhen University, Shenzhen, 518061, China

Huanyu Wu, Kehua Yang & Wenwen Zhou

National Key Laboratory for Intelligent Construction and Maintenance of Extreme Environment Geotechnical and Tunnel Engineering, Shenzhen, 518061, China

Huanyu Wu & Kunyang Chen

Shenzhen Key Laboratory of Green, Efficient and Intelligent Construction of Underground Subway Station, Shenzhen, China

Kunyang Chen

Shenzhen TH SWARE Technology Co., Shenzhen, 518057, China

Shaanxi Railway Institute, Weinan, 714000, Shanxi, China

You can also search for this author in PubMed   Google Scholar

Contributions

All authors contributed to the study conception and design. Methodology and funding acquisition were handled by Huanyu Wu. Data collation and visualization were undertaken by Kunyang Chen, Kehua Yang, and Wenwen Zhou. The first draft of the manuscript was written by Huanyu Wu and Kehua Yang, and all authors commented on previous versions of the manuscript. Writing (review and editing) and conceptualization were performed by Kunyang Chen. Supervision and resources were provided by Tao Yu and Kai Wang. All authors read and approved the final manuscript.

Corresponding author

Correspondence to Kunyang Chen .

Ethics declarations

Ethical approval.

Not applicable

Consent to participate

Consent for publication, competing interests.

The authors declare no competing interests.

Additional information

Responsible Editor: Philippe Loubet

Publisher’s note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendix 1 Calculation table of material production element

• a Sourced from Standard for building carbon emission calculation: GB/T 51366-2019 ( n.d. ) and the local GaBi database
• b Sourced from literature calculations (Wang et al. 2019 ; Chen et al. 2022a , 2022b , 2022c )

Appendix 2 Calculation table of the transportation element

• The GHG emission factors for diesel lorries and rail transport are 0.179 and 0.010 kg CO 2 eq/(t·km), respectively ( Standard for building carbon emission calculation GB/T 51366-2019 ( n.d. ))

Appendix 3 Calculation table of mechanical construction element

• GHG emission factors of 3.096, 2.925, and 0.8042 (kg CO 2 eq/unit) for diesel, gasoline, and electric energy, respectively (Chen et al. 2022a , 2022b , 2022c )

Appendix 4. Table of GHG emissions by sub-project

• M for material production; T for transportation; C for mechanical construction machinery

Rights and permissions

Springer Nature or its licensor (e.g. a society or other partner) holds exclusive rights to this article under a publishing agreement with the author(s) or other rightsholder(s); author self-archiving of the accepted manuscript version of this article is solely governed by the terms of such publishing agreement and applicable law.

Reprints and permissions

About this article

Wu, H., Yang, K., Chen, K. et al. GHG emission quantification and reduction pathway of subway shield tunnel engineering: a case study on Guangzhou Metro, China. Environ Sci Pollut Res (2024). https://doi.org/10.1007/s11356-024-34826-1

Download citation

Received : 03 January 2024

Accepted : 23 August 2024

Published : 31 August 2024

DOI : https://doi.org/10.1007/s11356-024-34826-1

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Subway shield tunnel
• GHG emissions
• GHG reduction pathway
• Find a journal
• Publish with us
• Track your research

Information

• Author Services

Initiatives

You are accessing a machine-readable page. In order to be human-readable, please install an RSS reader.

All articles published by MDPI are made immediately available worldwide under an open access license. No special permission is required to reuse all or part of the article published by MDPI, including figures and tables. For articles published under an open access Creative Common CC BY license, any part of the article may be reused without permission provided that the original article is clearly cited. For more information, please refer to https://www.mdpi.com/openaccess .

Feature papers represent the most advanced research with significant potential for high impact in the field. A Feature Paper should be a substantial original Article that involves several techniques or approaches, provides an outlook for future research directions and describes possible research applications.

Feature papers are submitted upon individual invitation or recommendation by the scientific editors and must receive positive feedback from the reviewers.

Editor’s Choice articles are based on recommendations by the scientific editors of MDPI journals from around the world. Editors select a small number of articles recently published in the journal that they believe will be particularly interesting to readers, or important in the respective research area. The aim is to provide a snapshot of some of the most exciting work published in the various research areas of the journal.

Original Submission Date Received: .

• Active Journals
• Find a Journal
• Proceedings Series
• For Authors
• For Reviewers
• For Editors
• For Librarians
• For Publishers
• For Societies
• For Conference Organizers
• Open Access Policy
• Institutional Open Access Program
• Special Issues Guidelines
• Editorial Process
• Research and Publication Ethics
• Article Processing Charges
• Testimonials
• Preprints.org
• SciProfiles
• Encyclopedia

Article Menu

• Subscribe SciFeed
• Recommended Articles
• Google Scholar
• on Google Scholar
• Table of Contents

Find support for a specific problem in the support section of our website.

Please let us know what you think of our products and services.

Visit our dedicated information section to learn more about MDPI.

JSmol Viewer

A new stochastic petri net modeling approach for the evolution of online public opinion on emergencies: based on four real-life cases, 1. introduction, 2. literature review, 2.1. public opinion on emergencies, 2.1.1. influencing factors of public opinion on emergencies, 2.1.2. the stages of evolution of public opinion on emergencies, 2.1.3. modeling of public opinion on emergencies, 2.1.4. empirical evidence for critical incident cases, 2.2. summary, 3. methods and design, 3.1. stages in the evolution of public opinion, 3.1.1. formation period, 3.1.2. diffusion period, 3.1.3. explosion period, 3.1.4. declining period, 3.2. modeling, 3.2.1. model design, 3.2.2. constructing the spn model, 3.2.3. spn model isomorphic to a markov chain, 3.3. indicator selection and calculation methodology, 4. case studies, 4.1. overview of cases, 4.2. model parameterization, 4.3. analyzing results, 4.3.1. evolutionary leaps, 4.3.2. complexity, 4.3.3. key nodes, 4.3.4. evolutionary efficiency, 4.3.5. length of implementation, 4.4. discussion, 5. conclusions, author contributions, data availability statement, conflicts of interest.

• Lin, Y.; Xie, X.; Zhang, D. Analysis of online public opinion evolution under the influence of complex interaction behaviors. Chin. J. Manag. Sci. 2020 , 28 , 212–221. [ Google Scholar ]
• Guan, X.; Zhang, Z.; Zhang, S. Evolution Mechanism of The Ecological Dissemination System of Internet Public Opinion. In LISS 2014: Proceedings of 4th International Conference on Logistics, Informatics and Service Science ; Springer: Berlin/Heidelberg, Germany, 2015. [ Google Scholar ]
• Wang, N.; Lv, X.L. Research on emotional analysis of netizens and topic distribution under public health emergencies: —A Case Study of COVID-19. In Proceedings of the 2020 International Conference on Public Health and Data Science (ICPHDS), Guangzhou, China, 20–22 November 2020. [ Google Scholar ] [ CrossRef ]
• Fang, S.; Zhao, N.; Chen, N.; Xiong, F.; Yi, Y. Analyzing and Predicting Network Public Opinion Evolution Based on Group Persuasion Force of Populism. Phys. A Stat. Mech. Its Appl. 2019 , 525 , 809–824. [ Google Scholar ] [ CrossRef ]
• Liu, Y.; Liu, R.; Li, R. Public Opinion Guidance and Science and Technology Dissemination for Public Health Emergencies. Disaster Manag. 2013 , 133 , 303–309. [ Google Scholar ] [ CrossRef ]
• Yao, C.; He, G. Key Nodes Analysis of Microblogging Public Opinion Spread About Public Emergencies-Such As The Missed Malaysia Flight MH370. In Proceedings of the 2015 International Conference on Modeling, Simulation and Applied Mathematics, Phuket, Thailand, 23–24 August 2015. [ Google Scholar ] [ CrossRef ]
• Yang, F.; Sun, T. Who has set whose agenda on social media? A dynamic social network analysis of Tweets on Paris attack. Commun. Q. 2021 , 69 , 341–363. [ Google Scholar ] [ CrossRef ]
• Lim, S.; Berry, F.S.; Lee, K.-H. Stakeholders in the same bed with different dreams: Semantic network analysis of issue interpretation in risk policy related to mad cow disease. J. Public Adm. Res. Theory 2016 , 26 , 79–93. [ Google Scholar ] [ CrossRef ]
• Levitan, K.B. Information resources as “Goods” in the life cycle of information production. J. Am. Soc. Inf. Sci. 1982 , 33 , 44–54. [ Google Scholar ] [ CrossRef ]
• Li, S.; Liu, Z.; Li, Y. Temporal and spatial evolution of online public sentiment on emergencies. Inf. Process. Manag. 2020 , 57 , 102177. [ Google Scholar ] [ CrossRef ] [ PubMed ]
• Zhang, Y.; Chen, N.; Du, W.; Yao, S.; Zheng, X. A New Geo-Propagation Model of Event Evolution Chain Based on Public Opinion and Epidemic Coupling. Int. J. Environ. Res. Public Health 2020 , 17 , 9235. [ Google Scholar ] [ CrossRef ]
• Li, Y.; Shen, X. Spread of Online Public Opinion of Animal Epidemic Emergency: A Case Study of the H7N9 Incident Based on Healthcare Data Analytics. J. Healthc. Eng. 2021 , 2021 , 1512742. [ Google Scholar ] [ CrossRef ]
• Zhang, J.; Chen, Y.; Zhao, Y.; Wolfram, D.; Ma, F. Public health and social media: A study of Zika virus-related posts on Yahoo! Answers. J. Assoc. Inf. Sci. Technol. 2020 , 71 , 282–299. [ Google Scholar ] [ CrossRef ]
• Chen, J.; Du, S.; Yang, S. Mining and Evolution Analysis of Network Public Opinion Concerns of Stakeholders in Hot Social Events. Mathematics 2022 , 10 , 2145. [ Google Scholar ] [ CrossRef ]
• Burkholder, B.T.; Toole, M.J. Evolution of complex disasters. Lancet 1995 , 346 , 1012–1015. [ Google Scholar ] [ CrossRef ]
• Liu, Y.; Zhu, J.; Shao, X.; Adusumilli, N.C.; Wang, F. Diffusion patterns in disaster-induced internet public opinion: Based on a Sina Weibo online discussion about the ‘Liangshan fire’ in China. Environ. Hazards 2020 , 20 , 163–187. [ Google Scholar ] [ CrossRef ]
• Qiu, Q.; He, J.; Chen, H.; Qiu, J. Research on The Evolution Law of Emergency Network Public Opinion. In Proceedings of the 2019 12th International Symposium on Computational Intelligence and Design (ISCID), Zhejiang, China, 1 December 2019. [ Google Scholar ] [ CrossRef ]
• He, M.; Zhang, D.; Wang, H.; Li, X.; Fang, P. Public Opinion Evolution Model with The Variable Topology Structure Based on Scale Free Network. Acta Phys. Sin. 2010 , 59 , 5175–5181. [ Google Scholar ]
• Pohl, D.; Bouchachia, A.; Hellwagner, H. Social media for crisis management: Clustering approaches for sub-event detection. Multimed. Tools Appl. 2015 , 74 , 3901–3932. [ Google Scholar ] [ CrossRef ]
• Lan, Y.; Dong, X.; Zeng, R.; Qi, Z. Research on effects model of derived of network public opinion from the perspective of information alienation. J. Intell. 2015 , 34 , 139–143. [ Google Scholar ]
• Zhang, Y.; Feng, Y. Two-layer coupled network model for topic derivation in public opinion propagation. China Commun. 2020 , 17 , 176–187. [ Google Scholar ] [ CrossRef ]
• Zhou, D.; Shi, L.; Wang, B.; Xu, H.; Huang, W. Are Your Comments Positive? A Self-Distillation Contrastive Learning Method for Analyzing Online Public Opinion. Electronics 2024 , 13 , 2509. [ Google Scholar ] [ CrossRef ]
• Lai, J.; Yang, X.; Luo, W.; Zhou, L.; Li, L.; Wang, Y.; Shi, X. RumorLLM: A Rumor Large Language Model-Based Fake-News-Detection Data-Augmentation Approach. Appl. Sci. 2024 , 14 , 3532. [ Google Scholar ] [ CrossRef ]
• Cheng, Q.; Zhang, Y.; Li, Y. Topic Relevance of Public Health Emergencies Influence Internet Public Opinion Resonance: Simulation Based on Langevin’s Equation. Math. Probl. Eng. 2021 , 2021 , 5818346. [ Google Scholar ] [ CrossRef ]
• Yang, K.; Miao, R. Research on Evolution Model and Crisis Prevention and Control of New Media Public Opinion. In Proceedings of the 2017 International Conference on Education Innovation and Social Science (ICEISS 2017), Jinan, China, 19 November 2017. [ Google Scholar ]
• Wang, L.; Wang, K.; Wu, J. Public Opinion Propagation and Evolution of Public Health Emergencies in Social Media Era: A Case Study of 2018 Vaccine Event. Data Anal. Knowl. Discov. 2019 , 3 , 42–52. [ Google Scholar ]
• Lian, S.; Li, Z. Public opinion guidance and communication mechanism innovation of public health events based on the multitask learning network in the internet era. Mob. Inf. Syst. 2022 , 2022 Pt 4 , 7106054.1–7106054.8. [ Google Scholar ] [ CrossRef ]
• Li, W.; Zeng, F.; Zhou, W.; Chen, Z. Internet public opinion diffusion mechanism in public health emergencies: Based on entropy flow analysis and dissipative structure determination. Front. Public Health 2021 , 9 , 731080. [ Google Scholar ] [ CrossRef ] [ PubMed ]
• Zhang, Y.; Xie, Y.; Shi, V.; Yin, K. Dynamic Characteristics and Evolution analyses of Information Dissemination Theme of Social Networks under Emergencies. Behav. Sci. 2023 , 13 , 282. [ Google Scholar ] [ CrossRef ]
• Cui, P.; He, Y. Research on The Dissemination and Response of Network Public Opinion of Emergency Events in Colleges Based on Crowd Intelligence Thinking. Open J. Soc. Sci. 2019 , 7 , 281. [ Google Scholar ] [ CrossRef ]
• Ye, P.; Liu, L. Factors Influencing College Students’ Behaviors of Spreading Internet Public Opinions on Emergencies in Universities. Inf. Discov. Deliv. 2021 , 50 , 75–86. [ Google Scholar ] [ CrossRef ]
• Tan, K.; Xie, L.; Lin, L. Research on The Evolution Path of Public Opinion in Environmental Emergencies. E3S Web Conf. 2021 , 257 , 03059. [ Google Scholar ] [ CrossRef ]
• Zhang, L.; Wei, J.; Boncella, R.J. Emotional communication analysis of emergency microblog based on the evolution life cycle of public opinion. Inf. Discov. Deliv. 2020 , 48 , 151–163. [ Google Scholar ] [ CrossRef ]
• Medina-Garcia, S.; Medina-Marin, J.; Montaño-Arango, O.; Gonzalez-Hernandez, M.; Hernandez-Gress, E.S. A Petri Net Approach for Business Process Modeling and Simulation. Appl. Sci. 2023 , 13 , 11192. [ Google Scholar ] [ CrossRef ]
• Zhu, H.; Liu, G.; Yu, Z.; Li, Z. Detectability in Discrete Event Systems Using Unbounded Petri Nets. Mathematics 2023 , 11 , 3862. [ Google Scholar ] [ CrossRef ]
• Saadaoui, I.; Labed, A.; Li, Z.; El-Sherbeeny, A.M.; Du, H. Language-Based Opacity Verification in Partially Observed Petri Nets through Linear Constraints. Mathematics 2023 , 11 , 3880. [ Google Scholar ] [ CrossRef ]
• Ma, D.; Zhang, C.; Zhao, L.; Huang, Q.; Liu, B. An analysis of the Evolution of Public Sentiment and Spatio-Temporal Dynamics Regarding Building Collapse Accidents Based on Sina Weibo Data. ISPRS Int. J. Geo-Inf. 2023 , 12 , 388. [ Google Scholar ] [ CrossRef ]
• Yang, S.; Liu, S.; Su, K.; Chen, J. A Rumor Propagation Model Considering Media Effect and Suspicion Mechanism under Public Emergencies. Mathematics 2024 , 12 , 1906. [ Google Scholar ] [ CrossRef ]
• Li, W.; Shen, H.; Huang, Z.; Yang, H. Research on the Dynamical Behavior of Public Opinion Triggered by Rumor Based on a Nonlinear Oscillator Model. Entropy 2023 , 25 , 1614. [ Google Scholar ] [ CrossRef ]
• Lu, Y. The Influence of Cognitive and Emotional Factors on Social Media Users’ Information-Sharing Behaviors during Crises: The Moderating Role of the Construal Level and the Mediating Role of the Emotional Response. Behav. Sci. 2024 , 14 , 495. [ Google Scholar ] [ CrossRef ]
• Gomes, L.; Natário, D.; Costa, A.; Barros, J.-P.; Campos-Rebelo, R. Event-Based Modeling of Input Signal Behaviors for Discrete-Event Controllers. Appl. Sci. 2024 , 14 , 5289. [ Google Scholar ] [ CrossRef ]
• Zuberek, W.M. Performance evaluation using unbound timed Petri nets. In Proceedings of the 3rd International Workshop on Petri Nets and Performance Models, Kyoto, Japan, 11–13 December 1989; pp. 180–186.
• Molly, M.K. Discrete Time Stochastic. IEEE Trans. Softw. Eng. 1985 , 31 , 417–423. [ Google Scholar ] [ CrossRef ]

Click here to enlarge figure

Share and Cite

Guo, C.; Song, Y. A New Stochastic Petri Net Modeling Approach for the Evolution of Online Public Opinion on Emergencies: Based on Four Real-Life Cases. Systems 2024 , 12 , 333. https://doi.org/10.3390/systems12090333

Guo C, Song Y. A New Stochastic Petri Net Modeling Approach for the Evolution of Online Public Opinion on Emergencies: Based on Four Real-Life Cases. Systems . 2024; 12(9):333. https://doi.org/10.3390/systems12090333

Guo, Chen, and Yinghua Song. 2024. "A New Stochastic Petri Net Modeling Approach for the Evolution of Online Public Opinion on Emergencies: Based on Four Real-Life Cases" Systems 12, no. 9: 333. https://doi.org/10.3390/systems12090333

Article Metrics

Article access statistics, further information, mdpi initiatives, follow mdpi.

Subscribe to receive issue release notifications and newsletters from MDPI journals