Understanding SDLC and STLC

Table of Contents

Training Objective:

HOMEWORK ASSIGNMENT:

Duration:

Video Training Resources:

Opening Remarks

Introduction (10 minutes):

SDLC and STLC (60-90 minutes):

Understanding SDLC

Case Study

Case Study Recap

SDLC Approaches

1. Requirements gathering and analysis
2. Design:
3. Implementation:
4. Testing:
5. Deployment:
6. Maintenance:

SDLC Models

Waterfall Model

V-Model

Iterative Model

Spiral Model

Agile Model

Understanding STLC (10-30 minutes):

Principles of testing

Test Events or Methods

STLC Deliverables

• Test requirements
• Test Plan Components
• Requirement Traceability Matrix
• Test closure report is
• Incident report

Real World Testimonies

Case Study

Context

Challenge

Solution

Assumptions

Closing Remarks (10 minutes):

Assessment: (1 hour)

Training Objective:

The objective of this training module is to provide more knowledge on the software development life cycle (SDLC) and the software testing life cycle (STLC). The software testing life cycle is one of the phases of SDLC.

By the end of this training, every student should have a clear understanding of the two software life cycle methodologies. It is my expectation that you are familiarized with the processes of the development and testing life cycles. The primary benefit of this training is for test analysts who need to how to be a team player on a software test project.

HOMEWORK ASSIGNMENT:

Read about STLC.

Duration:

Half a day (2-3 hours of lecture time)

Section 1

Video Training Resources:

Opening Remarks

Hello and thank you for your interest in learning about Software Development and Testing Life Cycles. This training module is intended to cover more detail on two methodologies. These methodologies are general frameworks for software development and testing. They describe the overall process of developing, testing, and maintaining software.

By the end of this lesson, you will be able to differentiate between SDLC and STLC, understand the phases or stages, describe the importance of each methodology and how they are implemented.

Duration: 90 minutes

Materials:

                Visual aids – PowerPoint and Videos

                                ○ Handouts or slides summarizing the key points of SDLC and STLC

                                ○ Case study or practical example for applying the concepts

• EHR Software (Electronic Health Records) or Health care product
• Popular Solutions: Epic, ModMed, NextGen Healthcare HER, EHR Your Way, WebPT. Cerner, Pabau, TherapyNotes, Meditech EHR
• Alternate Approach: #1) Requirement Gathering and Analysis · #2) Design · #3) Implementation or Coding · #4) Testing · #5) Deployment · #6) Maintenance.
• Common Approach: #1) Planning · #2) Design · #3) Implementation or Coding · #4) Testing · #5) Deployment · #6) Maintenance
• Buy Approach: #1) Analysis · #2) Implementation · #3) Testing · #4) Deployment · #5) Maintenance
• Buy scenario versus a develop or upgrade scenario

                                ○ Open book assessment

Introduction (10 minutes):

STLC and SDLC interact in an important way. One is a subordinate to the other. It is rare that SDLC exists in a project without STLC. SDLC refers to a sequence of activities during the software development process, whereas STLC refers to a sequence of activities during the software testing phase of SDLC.

SDLC (Software Development Life Cycle) is a process used by software development teams to design, develop, and maintain high-quality software. It is a structured approach that breaks down the entire software development process into a series of phases or stages. Please allow the possibility of using these words interchangeably. Each stage has a set of tasks and deliverables. Each task must be completed, and then the next stage can begin.

But there are several different ways that SDLC is implemented. I urge caution here. SDLC has what we can call models to choose from for implementation. The most common models implemented include the waterfall model, the V-model, the iterative model, the spiral model, and the agile model. We will cover more detail later in this training.

The SDLC model that a team chooses to follow will depend on several factors. The factors include the size and complexity of the project, the team’s resources and expertise, the type of software being developed or implemented, the project’s goals, and how clear are the requirements.

Now STLC is not as broad a process or methodology as SDLC. With STLC, Software Testing Life Cycle, the scope is the testing stage of SDLC. The Software Testing Life Cycle is a process used only by the testing team. Be aware that both SDLC and STLC are cycles. That will become more apparent to you as we dive into more on the subject. For now, remember that STLC is a subset of SDLC, and it can begin early in the SDLC cycle.

Software Development Life Cycle Diagram

Let us take a moment to absorb the concept that SDLC and STLC are cycles. The understanding should be that they are sequences of tasks that can repeat. The repetition can happen at the end of the cycle or somewhere in one of the stages. That depends on how the methodology is implemented which we are about to walk through. In the SDLC cycle you can see in the diagram that “Testing” is one of the tasks that in its own process is another cycle. Of course, as I mentioned this process is accomplished by the test team alone whereas the other SDLC tasks are accomplished primarily by the development team.  The test team will have some involvement in other tasks if invited.

One more thing. It is normal for the test team to invite the development team into defect review meetings to help with what is known as the bug life cycle. We covered this in the introductory training module and will have another training session on this subject.

Now take a moment to visualize the STLC methodology diagram. It shows the cycle of tasks. It is important to note that it can begin with the maintenance stage or the Requirements stage. When the project ends and there is a need to do modify the production application this is known as the maintenance stage. Test activities will start with its own maintenance stage. This work is necessary to update test cases to meet the application modification requirements. The requirements stage of STLC is then minimized to verification.

In the STLC all stages are adjusted based on the scope requirements identified through planning. Note that the STLC maintenance and Execution stages can be iterative or repetitious. Why? Because the test team is dependent on what happens in the maintenance project just like the new development project.

At this point I would like to manage your expectations, especially with the STLC. It is possible in the real world that “the test team” is you alone. Just like it is possible that the execution of test cases is less than an hour worth of test time. In contrast, it is possible that the manual test team is large, and the number of test cases is several hundred. So, the work involved in each stage can span over a few hours to a few days or months even. If you are being interviewed for a contract, they will tell you upfront if it is a long-term opportunity. That may be a clue.

Software Test Life Cycle Diagram

SDLC and STLC (60-90 minutes):

When I say that SDLC or Software Development Life Cycle is a methodology or framework let’s be certain we are picturing the same thing. We are talking about an approach to accomplishing something. We are also talking about an agenda we follow. The approach and agenda we follow for developing or implementing software is done in a cyclical fashion. The cycle includes stages.

Understanding SDLC

The stages of SDLC are typically seven. But I caution you to understand that the history of what comprises those stages is ever-changing. The changes are not because of agreement issues. The changes are necessary to suit the changes in project demand. When a project is underway, the initial objectives can impose changes to how the project should be approached. For example, a project whose objective is bent on purchasing and implementing a commercial or open-source business application is different than a normal project. The project calls for changes in what stages are required. It drops some stages and increases the scope of the first stage.

Let me introduce you to a case study. First, what is it and why do you use it? A case study is research used to generate an understanding of a complex issue in its real-life context. I want to introduce to you a case study completed several years ago by a professor at the University of Central Arkansas. I have shortened the document for the purpose of using it in this course.

Case studies are used to measure your analytic skills, problem-solving abilities, communication skills and ability to deliver quality and results. This exercise will also help to determine how you prioritize and organize your test work in the future.

Case Study

This case study should be given credit to a professor named Mark McMurtrey.  He is noted for some 14 publications. He wrote this case study about SDLC at the time their staff was looking into purchasing a health care product and installing it for their staff use. It was an expensive endeavor with a budget of $250,000 dollars. So, they were interested in controlling cost by using a methodology for what he called an acquisition project.

I am going to pull some excerpts from the case study and integrate it into my version of the short case study. Here is the first excerpt: The author recognized from the outset that this 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.

Resulting from their Analysis stage work they wrote the following:

Analysis

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.

Please note that these items mentioned should serve as important requirements. And someone should pursue clarifying them to know exactly what functional requirements will meet those business needs. The next excerpt is:

A precursor to the Analysis stage, often mentioned in textbooks 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 for 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. 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. All Meditech platforms are certified EMR/EHR systems. “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”. 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.

As they continued with Analysis and Requirements, the team proceeded to review several software market products that might achieve what the believed the flagship product could do to solve their problem definition.

Here is more from the case study:

Design

As previously noted, for this 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 Choice

The principal 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 were 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.

Ironically, this seller’s product was not Meditech compatible, which was one of the most important criteria for selection. However, using 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 classes, the implementation stage of the SDLC usually follows one of four main forms.

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.

Once the product went into a production status and the old system was retired, the Maintenance stage kicked into action. Here is some of that information:

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.

Case Study Recap

It is important in reviewing even this subset of the case study that using SDLC for managing a development project has its challenges. But the methodology is adaptable. The framework would not still be around if it was too rigid to follow. No two projects are exactly alike. Stages may need adjusting in terms of scope. Some stages may not be necessary for some projects. Where repetition may occur could change. What may need to be emphasized may vary depending on the priorities.

This case study serves to describe conditions that put a demand on the framework. First, it was not a development project but an acquisition project. They chose not to emphasize testing requirements. And they chose not to have an ETL (“Extract, Transform, and Load.”) project. They chose to have a parallel implementation approach for product delivery and give time to the staff to manually load the data into the new application.

We have enough information from the case study to believe the project was a success. And here is a final excerpt from the case study talking about putting this case study into practice:

Implications for Practice

This project, and case study, was an application of tutoring 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) can be effectively applied in a business 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.

I hope you found this case study to be helpful in getting a better understanding of how to relate your test role and thinking to a development project. Even though this project elected to cut testing out of the budget. It is likely that the maintenance stage post-production was frequent enough and maybe involved enough to require some level of testing.

SDLC Approaches

So, let’s dig a little deeper into the SDLC framework. Earlier I mentioned some stages that define SDLC. In this chart it identifies three approaches to defining SDLC stages. There are other variations that define the stages as seven where requirements gathering, and analysis are split. In the common approach analysis is replaced with planning.

Based on the case study, the stages change significantly. Even the testing stage is down to some smoke testing instead of a full test cycle. The maintenance stage in the buy approach is also different. Because the software is managed externally, there usually are scheduled maintenance some frequent and some infrequent. The scope of STLC is also diminished to some level of smoke testing where it is just enough testing to verify the application is responsive and functioning.

Choosing from the alternate approach we can go deeper into the stages in the following way. The main stages of the SDLC can include:

1. Requirements gathering and analysis: This is the first stage, where the software development team works with the customer to understand their requirements and define the scope of the project. The customer may work on a set of requirements and present them to the development team. In some cases, the two teams will work together to clarify business requirements and then formalize functional requirements.
2. Design: In this stage, the software development team creates a detailed design of the software, including the architecture, user interface, and data structures. These outputs can act as deliverables to the customer and the test team, if the test team is on staff at this time.
3. Implementation: If the customer and stakeholders of the project are in agreement, the project moves on to the implementation stage. Then the software development team starts coding the software, based on the design.
4. Testing: As the software becomes ready for testing, this is a critical stage of the project. The software is tested as components or as a whole entity to ensure that it meets the customer’s requirements and works as expected. This stage helps identify and fix defects in the software before it is released to the end-users.
5. Deployment: Deployment is a stage where the software is deployed to the customer’s environment and made available for use. The turnover to production is associated with the term “go live”. After go-live and before the customer has full access, the test team is called upon to conduct smoke testing to verify the status of the application. In some cases, regression testing may be done as well. The challenge is when an application is in production, there are user permissions set in place that make it difficult for test cases that conduct update activities. So, it is sometimes allowed before the final turnover to the customer.
6. Maintenance: After the software is deployed, the software development team provides ongoing maintenance and support to ensure that the software continues to meet the customer’s needs. Change requirements are handled at this time. These requirements may include operating system updates, customer improvements and fixes. The test team is called upon sometimes to go through the entire test cycle or some version of it to make sure the applications is still meeting expectations. Maintenance is an ongoing activity for the life span of the application.

It’s important to note that the SDLC is an iterative process, meaning that the stages may be repeated as needed until the software is of high quality and meets the customer’s needs. This is one of the key benefits of SDLC.

Another benefit of the SDLC is that it helps ensure that the software is delivered on time and within budget. By following a structured approach, software development teams can better manage the development process and avoid unexpected delays or cost overruns.

Software Development Life Cycle is beneficial as a framework which guides software development from conception to retirement. The stages of SDLC get us through the conception status to a retirement status. The stages alone do not guarantee the success of conception to retirement. That is why we need to understand how to implement SDLC as was demonstrated by the case study.

SDLC Models

I mentioned earlier that SDLC is employed in several flavors. It is implemented by using various models. There are several different SDLC models to choose from, including the waterfall model, the V-model, the iterative model, the spiral model, and the agile model.

Waterfall Model

The waterfall model is a linear, sequential approach to software development. It has distinct stages that must be completed in order: requirements gathering and analysis, design, implementation, testing, and maintenance. Each stage is completed before moving on to the next, and each stage’s output serves as the input for the next stage. Testing is typically handled at the end of the development process, after all other stages have been completed. This can lead to delays and rework if issues are discovered during testing. I have been on test teams that are allowed to participate with the developers during their development. In this alternative approach the test team can participate in unit testing and prepare test cases earlier in the project cycle. It gives testing teams a chance to discover defects early and work with developers to achieve good results.

SDLC Waterfall Model

V-Model

The V-model is an extension of the waterfall model. It is also a linear, sequential approach, but it places greater emphasis on testing. In the V-model, each stage of the development process has a corresponding testing stage. For example, the requirements’ gathering stage has a corresponding stage of requirements testing, the design stage has a corresponding stage of design testing, and so on. The idea of this SDLC approach is truly focused on getting testing events designed long before the test event is scheduled. For example, when requirements are being reviewed and finalized by the development team, the test team is preparing acceptance test cases, which is the last test event during STLC.

The actual test events begin after the coding is completed. In the diagram you can see that the test team spend their time preparing test cases for each STLC test stage planned. When the coding is completed, they start with unit testing, move on to integration testing, then system testing, and finally acceptance testing.

The V-Model SDLC approach is also known as the Verification and Validation model. It is normal to hear these terms associated with this test model. Verification is a process of determining if the software is designed and developed according to specified requirements. Meanwhile Validation is the process of checking if the software has met the customer’s expectations. The processes are both about certifying or confirming the test results and serve to prove what was expected.

The V-Model should be used for small-sized projects where requirements are well defined, and changes are minimal to none. The V-Model is chosen when technical resources are available with the right skillset. That means it’s better to have test analysts with ample experience.

SDLC V-Model

Iterative Model

The iterative model of SDLC is an approach that involves repeating a series of stages repeatedly until the desired outcome is achieved. The development process is broken down into smaller, more manageable pieces, each of which is developed and tested separately. The output of one iteration serves as the input for the next, and the process continues until the desired outcome is achieved.

The initial development work is carried out based on well-stated basic requirements, and successive enhancements are added to this base piece of software through iterations until the final system is built. Notice the concept. It is a building block approach. Break the design into pieces that function and keep adding new functionality until the complete application is ready.

SDLC Iterative Model

The SDLC iterative model makes it possible for migrating different versions of an application to production status. The model promotes iterative development where a team gradually builds up the features and functions of the application.  But they don’t wait until each of these is complete before releasing a version into production.

This model is normally chosen when requirements are well defined and well understood. It is ideal when the software application is large and when there is a requirement that insists changes are in the future.

Spiral Model

The SDLC spiral model is a more flexible and adaptable approach to software development. It involves a series of cycles, each of which includes planning, risk analysis, engineering, and testing. The spiral model is iterative in nature, and each cycle builds on the previous one.

The model is used for risk management that combines the iterative development process model with elements of the Waterfall model. The spiral model is used by software engineers and is favored for large, expensive, and complicated development projects. I can see it of value on technical applications instead of business application development.

The spiral model has four phases: Planning, Design, Construct and Evaluation. A software project repeatedly passes through these phases in iterations called Spirals.

SDLC Spiral Model

Agile Model

The SDLC agile model is an approach to software development that is highly flexible and adaptable. It involves breaking down the development process into smaller, more manageable pieces, each of which is developed and tested separately. The agile model places a strong emphasis on collaboration and communication among team members, and it involves continuous testing and feedback throughout the development process.

Closing Remark

Closing Remark

This is not the end of this module training. There is another section – Section 2. All the videos are shown here in Section 1. But the videos will not be available on Section 2 web page. Click here to navigate to the second part of this training narrative.