case study on software development life cycle

• AI Strategy
• AI Automation
• AI Data Analytics
• AI Discovery Workshop

• Technology Consulting
• Product Ideation
• Intersog Talent Solutions
• IT Staff Augmentation

• Custom Software Development
• Big Data Development
• IoT App Development
• API Development and Integration
• Software Development Outsourcing
• Web Application Development
• Mobile App Development
• Android App Development
• iOS App Development
• Mobile App Testing
• UX and UI Design
• Quality Assurance
• Support and Hosting
• Chatbot Development
• SaaS Dev and Cloud
• MVP for Startups
• Digital Commerce
• Telemedicine
• Medical Software
• Case Studies
• Agriculture
• Data Analytics
• Digital Marketing
• Entertainment
• Mobile Apps
• Mobile Games
• Productivity
• Wearable Tech
• Whitepapers
• About Intersog
• Why Intersog
• Leadership Team
• Letter from the CEO
• Software Development
• White Papers

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.

• Building an AI-First Strategy: Key Steps for Business Transformation

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 Conversational AI in Customer Engagement

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 leveraging ai data analytics: marketing strategies for success, software development blogs intersog gains game-changer status on clutch, software development blogs the persistent challenge of tech talent acquisition.

This website uses these cookies:

• 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.

We offer competitive, and committed software engineers for hire.

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

Download Free PDF

A Case Study on Identifying Software Development Lifecycle and Process Framework

This paper analyzes and determines which software development lifecycle and process framework would be appropriate in the following case studies: Microsoft office business unit, Denver Baggage, Avionics development, and Department of Transportation. The analysis for decision takes into consideration the stakeholders involved, the targeted audience, technology, business drivers, culture, time/schedule, resources, scope, and quality.

Related papers

International Conference on Enterprise Information Systems, 2010

ACM SIGSOFT Software Engineering Notes, 2010

This history column article provides a tour of the main software development life cycle (SDLC) models. (A lifecycle covers all the stages of software from its inception with requirements definition through to fielding and maintenance.) System development lifecycle models have drawn heavily on software and so the two terms can be used interchangeably in terms of SDLC, especially since software development in this respect encompasses software systems development. Because the merits of selecting and using an SDLC vary according to the environment in which software is developed as well as its application, I discuss three broad categories for consideration when analyzing the relative merits of SDLC models. I consider the waterfall model before the other models because it has had a profound effect on software development, and has additionally influenced many SDLC models prevalent today. Thereafter, I consider some of the mainstream models and finish with a discussion of what the future co...

The trends of increasing technical complexity of the systems coupled with the need for repeatable and predictable process methodologies have driven system developers to establish system development models. With the growing operations of organizations, the need to automate the various activities increased. So, it was felt that some standard and structural procedure or methodology be introduced in the industry so that the transition from manual to automated system became easy. The concept of system lifecycle models came into existence that emphasized on the need to follow some structured approach towards building new or improved system. Many models were suggested like waterfall, prototype, rapid application development, V-shaped etc. In this paper, we focus on the comparative analysis of these Software Development Life Cycle Models. A software development process, also known as a software development life cycle (SDLC), is a structure imposed on the development of a software product. I...

Software Development Lifecycle, or SDLC, is a project management process for the software industry with various approaches and methodologies during the lifetime of a software system, from its inception to the end-of-life date. If it is appropriately utilized during the lifecycle of a software or program, it can cause minimum backlashes for stakeholders, developers, and customers involved by managing resources and functioning efficiently. This paper delves deeper and tries to explain their concepts briefly.

Currently, software industries are using different SDLC (software development life cycle) models which are designed for specific purposes. The use of technology is booming in every perspective of life and the software behind the technology plays an enormous role. As the technical complexities are increasing, successful development of software solely depends on the proper management of development processes. So, it is inevitable to introduce improved methodologies in the industry so that modern human centred software applications development can be managed and delivered to the user successfully. So, in this paper, we have explored the facts of different SDLC models and perform their comparative analysis.

International Journal of Scientific Research in Computer Science, Engineering and Information Technology, 2020

Software Development is one of the most powerful, vital, and the need for an hour in today's generation. Every organization, industries, small firms, institutes, etc. require the software for the functionality of their system and reducing the manual work or the traditional work, which used to be insecure and had more errors. SDLC is all about the minimization of the risk and failure and maximization of the quality of the product. To make the development works in a step by step procedure and precisely SDLC came into existence. The SDLC defines the framework that includes different activities and tasks to be carried out during the software development process. There are many types of SDLC models, which have their advantages and disadvantages and will work as per their needs.

Lhee Sagoe Press, 2023

Buku-buku tentang filsafat sudah banyak sekali, bahkan melimpah baik yang ditulis dalam bahasa Indonesia, apalagi dalam bahasa asing. Namun disayangkan buku-buku filsafat tersebut hanya mengulang-ngulang dan mekoleksi pemikiran berbagai tokoh-tokoh filsafat terkemuka baik dari Barat ataupun Islam. Kebanyakan buku-buku itu menuliskan pokok-pokok pemikiran filosof, seperti filsafat ontology, epistemology ataupun axiology. Akibatnya pembaca buku-buku filsafat, apalagi pemula, akan memahami filsafat adalah suatu cabang pengetahuan yang sangat abstrak dan melangit, jauh dari probelamatika dan aktifitas sehari-hari. Sikap sinis dan bosanpun kebanyakan menimpa pembaca tersebut, karena dianggap filsafat adalah kajian yang tidak ada kaitan langsung dengan aktifitas sehari. Filsafat terapan (Applied Philosophy) menjadi petspektif teori dalam menyusun buku ini. Meskipun cabang filsafat inimasih relatif baru, namun penulis merasa filsafat terapan ini sangat penting bagi penyelesaian problematika kehidupan sehari-hari.di Aceh. Hal ini dikarenakan Aceh secara histori dibangun atas asumsi-asumsi filsafat sebagaimana filsafat sufi Syeikh Hamzah Al-Fansuri menjadi filsafat hidup masyarakat Aceh. Apalagi, problematika di Aceh saat ini berkisar pada masalah-masalah filosofis, misalnya konseptualisasi ahl al-sunnah wa al-jama`ah, Rateb siribei versus tastafi, krisisnya identitas budaya dan lainnya. Kajian filsafat terapan berbeda jauh dengan filsafat murni, jika filsafat murni hanya terfokus kepada pembahasan ontologi, epistemologi dan aksiologi yang melangit, maka filsafat terapan memberikan perspektif yang membumi kepada ruang lingkup kajiannya Hoffmaster (1989). Misalnya Aceh, mempertanyakan apakah hakikat realitas (ontologi) Aceh? bagaimana kita harus memikirkannya secara ilmiah (epistemologi)? Apa nilai Aceh baik dalam level budaya, moral, seni, hingga standar norma sosial ideal lainnya? Menurut Brenda Almond, pendekatan filsafat ini mencakupi bidang–bidang praktis, seperti: lingkungan, kedokteran, pengetahuan ilmiah, teknik, politik, hukum, ekonomi dan pendidikan. Senanda dengan Brenda, Baier ( 1985); Jonsen and Toulmin (1988); Juengst (1989) Hoffmaster (1989) juga melihat bahwa pengunaan nalar filsafat dalam di atas konstruktif bagi pengembangan ilmu tersebut sekaligus berguna bagi pengembangan ilmu filsafat itu sendiri (Kuhn, T.S.: 1970) . Karena buku ini menjadikan Aceh sebagai objek aplikasi nalar filsafat,dengan realitas sosial di Aceh. Karena itu maka diperlukan penyesuaian ruang-lingkupnya menjadi bidang logika Aceh, seni budaya, sejarah, pendidikan dan pemikiran Islam. Topik-topik inilah yang menjadi sajian buku ini. Dengan menggunakan teori Brenda Almond tadi, buku filsafat ini sengaja dihadirkan untuk membuktikan bahwa berfilsafat itu tidak melangit dan akan mengarahkan pembaca untuk dapat berfilsafat secara dalam menyikapi problematika sehari-hari. Dalam buku ini pembaca akan menemukan bagaimana filsafat itu dapat berguna dalam menghadapi problem sosial, member solusi dari problematika masyarakat dan bermamfaat dalam mengkritisi realitas yang kebanyakan dibaluti tipu daya muslihat.Untuk tujuan tersebut, buku ini dibagi kepada lima bagian.

For writing help, reach me on: [email protected]

Edizioni ETS, 2023

XXV World Congress of Philosophy, 2024

Nova Linda, 2020

mamang, 2019

Archaism and Innovation: Studies in Middle Kingdom Egypt, edited by David P. Silverman, William Kelly Simpson and Josef Wegner, pp. 319-339, 2009

Electronic British Library Journal, 2017, study 4, 2017

TURKISH JOURNAL OF MATHEMATICS, 2016

DOAJ (DOAJ: Directory of Open Access Journals), 2013

Journal of Medical Case Reports, 2010

Advances in Digestive Medicine, 2016

Journal of Vacuum Science & Technology A: Vacuum, Surfaces, and Films, 2018

Sociological Perspectives, 2019

European Respiratory Journal, 2011

Related topics

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024

• Software Engineering Tutorial
• Software Development Life Cycle
• Waterfall Model
• Software Requirements
• Software Measurement and Metrics
• Software Design Process
• System configuration management
• Software Maintenance
• Software Development Tutorial
• Software Testing Tutorial
• Product Management Tutorial
• Project Management Tutorial
• Agile Methodology
• Selenium Basics

Computer Aided Software Engineering (CASE)

Computer-aided software engineering (CASE) is the implementation of computer-facilitated tools and methods in software development. CASE is used to ensure high-quality and defect-free software. CASE ensures a check-pointed and disciplined approach and helps designers, developers, testers, managers, and others to see the project milestones during development. 

CASE can also help as a warehouse for documents related to projects, like business plans, requirements, and design specifications. One of the major advantages of using CASE is the delivery of the final product, which is more likely to meet real-world requirements as it ensures that customers remain part of the process. 

CASE illustrates a wide set of labor-saving tools that are used in software development. It generates a framework for organizing projects and to be helpful in enhancing productivity. There was more interest in the concept of CASE tools years ago, but less so today, as the tools have morphed into different functions, often in reaction to software developer needs. The concept of CASE also received a heavy dose of criticism after its release. 

What is CASE Tools?

The essential idea of CASE tools is that in-built programs can help to analyze developing systems in order to enhance quality and provide better outcomes. Throughout the 1990, CASE tool became part of the software lexicon, and big companies like IBM were using these kinds of tools to help create software. 

Various tools are incorporated in CASE and are called CASE tools, which are used to support different stages and milestones in a software development life cycle. 

Types of CASE Tools:

• Diagramming Tools:  It helps in diagrammatic and graphical representations of the data and system processes. It represents system elements, control flow and data flow among different software components and system structures in a pictorial form. For example, Flow Chart Maker tool for making state-of-the-art flowcharts.  
• Computer Display and Report Generators:  These help in understanding the data requirements and the relationships involved. 
• (i) Accept 360, Accompa, CaseComplete for requirement analysis. 
• (ii) Visible Analyst for total analysis.   
• Central Repository:  It provides a single point of storage for data diagrams, reports, and documents related to project management.
• Documentation Generators:  It helps in generating user and technical documentation as per standards. It creates documents for technical users and end users.  For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.  
• Code Generators:  It aids in the auto-generation of code, including definitions, with the help of designs, documents, and diagrams.
• Tools for Requirement Management: It makes gathering, evaluating, and managing software needs easier.
• Tools for Analysis and Design : It offers instruments for modelling system architecture and behaviour, which helps throughout the analysis and design stages of software development.
• Tools for Database Management: It facilitates database construction, design, and administration.
• Tools for Documentation: It makes the process of creating, organizing, and maintaining project documentation easier.

Advantages of the CASE approach: 

• Improved Documentation: Comprehensive documentation creation and maintenance is made easier by CASE tools. Since automatically generated documentation is usually more accurate and up to date, there are fewer opportunities for errors and misunderstandings brought on by out-of-current material.
• Reusing Components: Reusable component creation and maintenance are frequently facilitated by CASE tools. This encourages a development approach that is modular and component-based, enabling teams to shorten development times and reuse tested solutions.
• Quicker Cycles of Development: Development cycles take less time when certain jobs, such testing and code generation, are automated. This may result in software solutions being delivered more quickly, meeting deadlines and keeping up with changing business requirements.
• Improved Results : Code generation, documentation, and testing are just a few of the time-consuming, repetitive operations that CASE tools perform. Due to this automation, engineers are able to concentrate on more intricate and imaginative facets of software development, which boosts output.
• Achieving uniformity and standardization:  Coding conventions, documentation formats and design patterns are just a few of the areas of software development where CASE tools enforce uniformity and standards. This guarantees consistent and maintainable software development.

Disadvantages of the CASE approach: 

• Cost: Using a case tool is very costly. Most firms engaged in software development on a small scale do not invest in CASE tools because they think that the benefit of CASE is justifiable only in the development of large systems.
• Learning Curve: In most cases, programmers’ productivity may fall in the initial phase of implementation, because users need time to learn the technology. Many consultants offer training and on-site services that can be important to accelerate the learning curve and to the development and use of the CASE tools.
• Tool Mix: It is important to build an appropriate selection tool mix to urge cost advantage CASE integration and data integration across all platforms is extremely important.

Conclusion:

In today’s software development world, computer-aided software engineering is a vital tool that enables teams to produce high-quality software quickly and cooperatively. CASE tools will probably become more and more essential as technology develops in order to satisfy the demands of complicated software development projects.

Similar Reads

• Software Engineering

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

The Seven Phases of the Software Development Life Cycle

The Software Development Life Cycle (SDLC) consists of seven essential phases—Planning, Requirements Analysis, Design, Coding, Testing, Deployment, and Maintenance—that ensure successful software development, from concept to continuous improvement.

In the realm of software development, the Software Development Life Cycle (SDLC) is akin to the architectural plan or methodology used in house construction. It's a crucial process that outlines methodology for development cycles that create effective, high-quality software from concept to launch, and even thereafter.

However, the SDLC isn't just about coding. It's a complete guide involving seven key phases that help teams navigate through the twists and turns of software creation, ensuring no aspect is overlooked. From initiation to the maintenance phase post-deployment, each phase presents distinct tasks and objectives.

Why are each of these phases relevant? Consider them as checkpoints with project management associated with each software project. They ensure we're on the right path, creating software that not only meets users' needs but also accomplishes business goals. For instance, the planning phase clarifies what the software should do. The design phase sketches out its implementation and deliverables. The testing phase examines if everything functions as expected and so on.

Let’s examine the seven phases of the software development life cycle, shining light on how a digital product or application journeys from idea to execution.

Phase 1: Planning

The initial stage of software development, Planning, involves defining the software's purpose and scope, much like pinpointing our destination and plotting the best route. We uncover the tasks at hand during this phase and strategize for efficient execution.

The team collaborates to understand the end-users' needs and the goals the software should meet. Essentially, we ask, "What problem will this software solve?" and "What value will it offer to the user?"

A feasibility study also takes place during the Planning phase. Developers and product teams evaluate technical and financial challenges that might affect the software's development or success.

So, what transpires in this phase? Key documents such as the Project Plan and Software Requirement Specification (SRS) are created. These guides detail the software's functions, necessary resources, possible risks , and a project timeline.

The Planning phase fosters effective communication and collaboration within the team. By defining clear roles, responsibilities, and expectations, it lays a solid foundation for an efficient software development process.

Phase 2: Requirements Analysis

Phase 2 of the SDLC, Requirements Analysis, seeks to identify and record the precise requirements of the final users. In this phase, the team is looking to answer, "What are the expectations of our users from our software?" This is called requirements gathering.

The project team collects information from stakeholders, including analysts, users, and clients. They conduct interviews, surveys, and focus groups to understand the user's expectations and needs. The process involves not only asking the right questions but also accurately interpreting the responses.

After collecting the data, the team analyzes it, distinguishing the essential features from the desirable ones. This analysis helps the team understand the software's functionality, performance, security, and interface needs.

These efforts result in a Requirements Specification Document. It outlines the software's purpose, features, and functionalities, acting as a guide for the development team and providing cost estimates if needed. To ensure its reliability, the document is validated for accuracy, comprehensiveness, and feasibility.

The success of the Requirements Analysis phase is pivotal for the entire project. Done right, it leads to a software solution that meets users' needs and exceeds their expectations.

Phase 3: Design

The Design phase is all about building the framework. The development team is responsible for software engineering and outlines the software's functionality and aesthetic. This ultimately results in the software product. The emphasis lies on outlining the software's structure, navigation, user interfaces, and database design. This phase ensures that the software is user-friendly and performs its tasks efficiently.

So, what tasks does the team undertake? Key activities include crafting data flow diagrams, constructing entity-relationship diagrams, and designing user interface mock-ups. The team also identifies system dependencies and integration points. They also set the software's limitations, such as hardware constraints, performance requirements, and other system-related factors.

The culmination of these tasks is an exhaustive Software Design Document (SDD). This document serves as the roadmap for the team during the coding phase. It meticulously details the software's design, from system architecture to data design, and even user interface specifics.

The Design phase is the link between the software's purpose (established in the Planning and Requirements Analysis phases) and its execution (defined in the coding phase). It's an essential step in creating software that works efficiently and provides an excellent user experience.

Phase 4: Coding

The Coding phase in the Software Development Life Cycle (SDLC) is when engineers and developers get down to business and start converting the software design into tangible code.

This development phase aims to develop software that is functional, efficient, and user-friendly. Developers use an appropriate programming language, Java or otherwise, to write the code, guided by the SDD and coding guidelines. This document, acting as a roadmap, ensures the software aligns with the vision set in earlier phases.

Another key aspect of this phase is regular code reviews. Team members carefully examine each other's work to identify any bugs or inconsistencies. These meticulous assessments uphold high code standards, ensuring the software's reliability and robustness. This phase also includes preliminary internal testing to confirm the software's basic functionality.

At the end of this phase, a functional piece of software comes to life. It embodies the planning, analyzing, and designing efforts of the preceding stages. Though it may not be flawless, it represents a significant stride towards a valuable software solution.

Phase 5: Testing

Consider the Testing phase of the SDLC as a stringent quality inspection on a production line. It is when vulnerabilities are uncovered. Software testing involves a thorough examination of the software for any bugs or glitches that might have slipped through during coding. The aim is to ensure flawless software operation before it reaches the end-users. And even identify opportunities for enhancement.

The testing process begins by setting clear parameters in line with the software's requirements. This includes identifying the necessary software conditions, and outlining diverse scenarios to examine these conditions. This step aids in creating an efficient testing strategy.

After establishing test cases, developers and engineers should rigorously test the software . They should conduct various types of tests, including unit testing, security testing, integration testing, system testing, and acceptance testing. These tests range from scrutinizing individual components to ensuring the seamless operation of the entire system.

When a test reveals a bug, it is documented in detail, noting its symptoms, reproduction method, and its influence on the software. These bugs are then sent back to the developers for rectification. Once the required fixes are implemented, the software re-enters the testing phase for validation. This process is a cycle of persistent refinement until the software complies with all predetermined parameters.

The Testing phase is instrumental in ensuring the software's robustness and reliability.

Phase 6: Deployment

After crafting a product with precision, it's time to present it to the users by pushing to the production environment. The Deployment phase involves rolling out the meticulously tested and fine-tuned software to its end-users.

A specific strategy is executed for the software's deployment to ensure minimal disruption to the user experience. Depending on the software and its audience, we might use different methods such as Big Bang, Blue-Green, or Canary deployments .

However, deployment isn't just about launching the software. It's about ensuring users can operate it with ease. This responsibility might involve creating user manuals, conducting training sessions, or offering on-site support. 

The Deployment phase doesn't signal the end, but rather a notable milestone. It signifies the shift from a project phase to a product phase, where the software begins to fulfill its purpose.

Phase 7: Maintenance

In the Software Development Life Cycle, the maintenance phase is characterized by constant assistance and improvement, which guarantees the software's best possible functioning and longevity and ensures it meets customer expectations.

The primary focus is to adapt to the software's changing needs. This adaptation involves responding to user feedback, resolving unexpected issues, and upgrading the software based on users' evolving requirements. It's a continuous process of refining and adapting, much like a gardener tending to their garden.

Maintenance tasks encompass frequent software updates, implementing patches, and fixing bugs. User support is also a crucial component, offering help and guidance to users facing difficulties with the software.

The maintenance phase also considers long-term strategies, for instance, upgrading or replacing the software. This decision depends on the software's lifecycle and technological progress. Similar to a homeowner contemplating a renovation or selling their house, the software might require a complete revamp or phase-out to stay relevant and valuable.

Frequent SDLC Models

The Software Development Life Cycle (SDLC) encompasses various models that outline the processes involved in software development and maintenance. Here are seven commonly used SDLC models:

Waterfall Model

This is a linear and sequential approach where each phase must be completed prior to moving on to the next step. The phases include requirements, design, implementation, testing, deployment, and maintenance.

Iterative Model

This model involves repetitive cycles of development, allowing for feedback and improvement in each iteration. Phases are often repeated until the final product is achieved with success.

Incremental Model

This is more of an incremental model that divides the system into small, manageable parts (also known as increments) with each increment representing a portion of the entire system's functionality. In this approach, each increment is developed and delivered separately.

Spiral Model

The spiral model incorporates elements of both iterative and incremental models. In this model, development progresses in a spiral fashion through repeating cycles of planning, risk analysis, engineering, and critical evaluation.

V-Model (Verification and Validation Model)

Consider this an extension of the waterfall model that emphasizes the relationship between development stages and testing stages. In this model, each development stage has a corresponding testing phase.

Agile Model

The agile methodology is an iterative and incremental approach that emphasizes flexibility and collaboration between cross-functional teams. When implementing an agile model, requirements and solutions evolve through collaboration and adaptation to change.

RAD Model (Rapid Application Development)

This is not about giving fellow surfers props after riding a killer wave. Alternatively, the RAD model focuses on rapid prototyping and quick feedback from end-users. It involves user feedback and iterations to rapidly refine and enhance the software.

It's important to note that these models are not mutually exclusive, and development teams often use a combination of methodologies tailored to the project's specific needs. Factors such as project requirements, budget, timeline, and flexibility determine the choice of an SDLC model.

The Essential Steps in Software Development

We've thoroughly examined the seven crucial phases of the Software Development Life Cycle. Each phase - from planning to maintenance, adds value by generating a software solution fitting users' requirements and meeting objectives. While the SDLC provides an effective pathway, adaptability is critical. Is this a large project or a small project? Adapting to your needs is key. Are you prepared for this systematic yet flexible method? To learn more about how Feature Management & Experimentation can help your engineering team work more efficiently, contact us here . From feature flags to automated rollout monitoring, Split by Harness can help your engineering team ship more great products.

Similar Blogs

When to use feature flags.

Software Development Life Cycle (SDLC): A Comprehensive Guide to the Full Process

Introduction

The Software Development Life Cycle (SDLC) is a fundamental framework in the realm of software engineering, orchestrating the process of developing software systematically and efficiently. It serves as the backbone of software creation, ensuring that the end product is not only functional but also meets the highest standards of quality and satisfies user requirements. In this guide, we delve into the full extent of the SDLC, exploring its significance, scope, and how it forms the cornerstone of any successful software development project. The SDLC, in its entirety, is a multi-phase process encompassing everything from initial concept to final deployment, ensuring a structured, efficient pathway for transforming an idea into a fully operational software product.

Understanding SDLC

At its core, the Software Development Life Cycle (SDLC) is a methodology that provides a structured and standardized process for developing software. It encompasses several distinct phases, each with its own set of activities and goals, designed to guide the development team from initial planning to the final release of the product. By breaking down the development process into manageable stages, the SDLC ensures that software is developed in a controlled and systematic way, reducing the likelihood of project overruns, budget breaches, and failure to meet user requirements. This methodology not only enhances the efficiency and productivity of the development team but also significantly improves the quality and reliability of the final product. In the subsequent sections, we will explore the specific phases of the SDLC, the various methodologies available, and how they can be best applied to different types of software development projects.

Phases of the Software Development Life Cycle

Understanding the phases of the Software Development Life Cycle (SDLC) is essential for the streamlined and successful creation of software .

• Requirement analysis. This phase involves thoroughly understanding and documenting what the software needs to do. It's about gathering all the specific details about what the software is expected to accomplish and the conditions under which it must operate.
• Design. In this stage, the software's overall structure and its finer details are planned out. This includes deciding on the software architecture, the technologies to be used, how different parts of the software will interact, and the user interface design.
• Implementation (or coding). This is where the actual creation of the software happens. Developers write the code to build the software based on the design specifications established in the previous phase.
• Testing. After the software is developed, it goes through rigorous testing to find and fix any issues or bugs. The aim is to ensure that the software is error-free and meets all the requirements laid out in the first phase.
• Deployment. Once the software is tested and ready, it's released and deployed for use. This can involve installing the software in a live environment, making it available for download, or rolling it out to users in stages.
• Maintenance. Post-deployment software needs to be maintained. This involves regular updates, fixing any new bugs that arise, and possibly adding new features or enhancements to keep the software relevant and functioning smoothly.

Each phase plays a critical role in ensuring the development process is organized and efficient, leading to the creation of high-quality software that meets user needs.

Popular SDLC Models

In the diverse landscape of software development methodologies, various SDLC models stand out for their unique approaches to software creation. Each model is tailored to different project requirements and organizational workflows. Let's explore some of the most prominent SDLC models, including their characteristics, advantages, disadvantages, and examples where applicable:

Waterfall Model

• Description: The Waterfall Model is a linear and sequential approach to software development. Each phase in the model must be completed before the next one begins.
• Characteristics: It involves clear project objectives and stable project requirements.
• Pros: Simplicity in management due to its structured approach.
• Cons: Inflexibility to changes; not ideal for complex, ongoing projects.

Example: Often used in manufacturing and construction projects where changes are less likely once the project development starts.

Agile Methodology

• Description: Agile is an iterative and incremental process focused on collaboration, customer feedback, and small, rapid releases.
• Characteristics: Emphasis on adaptability to changing project requirements and frequent product delivery.
• Pros: High product quality, flexibility, and customer satisfaction.
• Cons: It can be time-consuming and requires significant customer involvement.

Example: Software companies developing consumer-facing applications often use Agile to rapidly adjust to market demands.

Spiral Model

• Description: This model combines iterative development with elements of the Waterfall model, focusing on risk assessment.
• Characteristics: Emphasis on early detection of risks and changes in the project.
• Pros: Effective for large, complex, and high-risk projects.
• Cons: Can be costly and complex; not suitable for small projects.

Example: Used in large-scale software projects like enterprise resource planning (ERP) systems.

• Description: Scrum is a subset of Agile, primarily focused on managing and streamlining the iterative process in a small team.
• Characteristics: It involves regular stand-up meetings (scrums), sprints (short development cycles), and reviews.
• Pros: Enhances team productivity and handles complex projects effectively.
• Cons: Requires experienced team members and can lead to scope creep if not carefully managed.

Example: Many tech startups and agile software development teams use Scrum to manage rapidly changing development projects.

• Description: The V-Model extends the Waterfall model by adding a strong emphasis on testing in each development phase.
• Characteristics: Known for its simple and straightforward approach with a strong focus on testing at every stage.
• Pros: Greater chances of success compared to the Waterfall model due to early test planning.
• Cons: Still inflexible and not suitable for complex projects.

Example: Often used in smaller-scale projects where requirements are well-defined and unlikely to change.

Selecting the right SDLC model is crucial and depends on various factors like project size, complexity, and specific requirements. Each model offers a different path to software development, and understanding their nuances enables teams to choose the most effective approach for their project.

Best Practices in SDLC with Examples

Implementing best practices in the Software Development Life Cycle (SDLC) is vital for the success of a software project. Here are some of these best practices with examples to illustrate their application:

Effective planning and requirements analysis. This involves thoroughly understanding user needs and project objectives. It's crucial to spend adequate time in this phase to prevent costly changes later.

• Example: A software company developing a mobile app conducts extensive market research, user interviews, and surveys to understand user needs and preferences before starting the design process.

Realistic time and resource estimation. Accurately estimating the time and resources needed is key to keeping the project on schedule and within budget.

• Example: An IT project manager uses historical data from past projects and adjusts for current project complexities to estimate timeframes and resource allocation accurately.

Risk management. Identify potential risks early in the project and develop strategies to mitigate them.

• Example: A development team identifies potential risks, such as technology changes or delays in dependencies early in the project, and creates a mitigation plan, like having backup resources or technology alternatives.

Clear and regular communication. Frequent and clear communication among team members and stakeholders is vital to align expectations and address issues promptly.

• Example: Regular stand-up meetings and communication channels like Slack or Google Meet are used by a project team to keep everyone informed and address issues as they arise.

Iterative development and continuous testing. Implementing iterative development allows for regular feedback and easier incorporation of changes. Continuous testing ensures that issues are identified and resolved early in the development process.

• Example: A web development team adopts Agile methodology, producing work in two-week sprints, and incorporates continuous testing to catch issues early.

Documentation. Proper documentation at all stages of SDLC is critical for keeping track of the development process and for future maintenance and updates.

• Example: A software development team maintains an updated wiki or shared document repository that includes project specifications, design documents, and user guides.

Quality assurance. Implementing quality assurance practices throughout the SDLC helps in delivering a high-quality product.

• Example: A QA team is involved from the start of the project, ensuring quality is a focus through each phase of the SDLC, not just during the testing phase.

User-centric approach. Focusing on user experience and user interface design is crucial for the success of the software.

• Example: An e-commerce website focuses on user experience by involving UX/UI designers to create intuitive and user-friendly interfaces.

Post-deployment support and feedback incorporation. After deployment, ongoing support and incorporating user feedback are essential for continual improvement of the software.

• Example: After launching a new feature in their software, the company sets up a system to collect user feedback and quickly addresses any issues or bugs reported.

Implementing these best practices with practical examples like these can significantly enhance the efficiency, effectiveness, and quality of the software development process.

Challenges in Implementing SDLC

Implementing the SDLC is not without its challenges. These challenges need to be recognized and addressed to ensure the smooth execution of a software development project:

• Managing changing requirements. One of the biggest challenges is dealing with changing client requirements during the development process.
• Time and budget overruns. Keeping a project within its time frame and budget can be difficult due to unforeseen complexities and issues.
• Resource allocation and team dynamics. Efficiently allocating resources and managing team dynamics is critical, especially in large and complex projects.
• Technology integration. Integrating new technologies or existing systems can pose significant challenges in terms of compatibility and stability.
• Security and compliance. Ensuring that the software complies with all security standards and regulations is increasingly important and challenging.
• Quality control. Maintaining a high level of quality throughout the development process can be challenging, particularly as projects become more complex.
• Adapting to new methodologies. Keeping up with evolving SDLC methodologies and integrating them into existing practices can be a challenge for many organizations.
• Stakeholder engagement. Effectively engaging stakeholders and managing their expectations throughout the project lifecycle is crucial for project success.

Understanding and addressing these best practices and challenges is key to navigating the complexities of the SDLC and achieving successful software development outcomes.

The full Software Development Life Cycle is a comprehensive process that spans from the initial idea to the final product and beyond. Understanding its phases, methodologies, best practices, and challenges is crucial for anyone involved in software development. As technology continues to advance, so too will the methodologies and practices within the SDLC, requiring continuous learning and adaptation.

Comments (0)

By Clicking on the Button, I Agree to the Processing of Personal Data and the Terms of Use of the Platform .

Latest Posts

Blockchain's ability to ensure tamper-proof bookings, secure transactions, and transparent peer-to-peer interactions is revolutionizing how travelers interact with service providers globally.

In this article, we'll explore how blockchain is transforming the e-commerce industry and what lies ahead for 2024-2025.

Do You Have any Questions?

Leave your details - we will contact you to answer all your questions