web analytics
SDLC vs SLC

SDLC vs SLC (IN DETAIL!)

by

Introduction

The creation of new applications for information technology is a business that is both expensive and fraught with potential danger. It is absolutely necessary to exercise responsible management of the process, the product, and the resources that were invested. The knowledge gained over the course of forty years of working on commercial software projects has led to the development of a conventional approach to the management of application development. This approach is commonly referred to as the “system life cycle,” and it can be found in many different contexts. In this article, we are going to discuss what is SLC, and what is the difference between SDLC vs SLC.

What is the difference between SDLC VS SLC?

In the context of SDLC vs SLC, in the development phases, SLC is interested in the post-development operation and maintenance phases. The development phases are the only ones covered by the conventional SDLC, which ends shortly after implementation. With the addition of the disposal/end of life actions step, the system life cycle is essentially the same as the SDLC. SDLC does not worry about getting rid of the items once their usefulness has expired. The implementation (also referred to as the deployment) stage is where certification and accreditation take place. When all bugs and requirements are fixed, the system is then used for the first time by the customer. After being approved by the client, it moves into the operation and maintenance phase. After learning the difference between SDLC vs SLC, let’s discuss a bit about SLC.

The Concept of the System Life-Cycle

The term SLC is used to convey that:

  • The method considers all aspects of the system, which means that it takes into account not only the hardware, networking, system software, and application software, but also the significant amount of human labor that is required;
  • The product, the procedure, and the utilization of resources are frequently reviewed and compared to the original blueprints; and
  • Each iteration of the product contributes to the context in which the next one is created; thus, the process is iterative.

During the course of the previous two decades, there has been a considerable increase in the total number of application software packages that are currently on the market. Because of this, developing an application “from scratch” is becoming an increasingly uncommon practice today. Instead, the process of developing new applications typically involves the evaluation and acquisition of suitable components, the construction of additional components that are specific to the application, and the integration of the components that have been acquired and constructed into a single whole. The SLC includes several important elements, including checkpoints, tasks, and phases:

  • A phase is a sizable group of connected tasks;
  • A task is a particular activity with a specific goal; and
  • A checkpoint, also known as a milestone or deliverable, is a predetermined result whose fulfilment marks the end of a phase or task.

The Conventional System Life-Cycle

The SLC is typically broken up into the following phases, according to the convention:

  • Project Planning: The project’s purpose, scope, stakeholders, cost/benefit analysis, resource allocation, and project management framework are established as a result. A project plan and agreed-upon terms of reference serve as its checkpoint;
  • Requirements Analysis: This determines “what” the product is supposed to accomplish. It is necessary for participants to take on a mindset that is inquisitive and analytical rather than the “synthetic,” inventive, or constructive approach that is suitable for later phases of the process. Its checkpoint is a System Requirements Statement (SRS) that has been mutually agreed upon;
  • System Design: This determines “how” the product is supposed to carry out the functions that are outlined in the SRS. Its checkpoint is a System Design Specification that has been mutually agreed upon. This phase may be further subdivided into the following:
    • Logical Design: This is to a large extent unrelated to the physical environment in which the product is going to be operated; and
    • Physical Design: During this stage, the Logical Design is mapped onto a physical environment, which is comprised of particular pieces of system software, networks, and workstations;
  • Construction: This entails the assessment and procurement of already-existing software, the creation of new software, the precise specification of manual tasks, the integration of all components into a whole, and the layer-by-layer testing of the programme. Its Checkpoint is an integrated programme that satisfies all the requirements for quality, including being put through various levels of testing and having the necessary supporting documentation;
  • Implementation: This marks the beginning of the process by which the target demographic will begin making use of the service. Its Checkpoint service is one that is recognised and in operation;
  • Operation: This refers to the continuous use of the system and includes provisions for the reporting of incidents and the submission of work requests to address errors, as well as changes in the environment of the system and the requirements of the users.

A review is undertaken at the completion of all phases and of major tasks, as well as on a periodic basis. The purposes of a review are:

  • to evaluate delays and progress;
  • to take resource usage into account;
  • to provide an explanation for significant deviations from resource allocation and time schedules;
  • to determine any necessary corrective action and to aid in the re-estimation of incomplete phases and tasks;
  • to aid in organising upcoming stages and tasks; and
  • (in the event of significant negative variances) to give management data to support a “go/no-go” decision regarding the project’s continuation.

The SLC is frequently portrayed in discussions through the metaphor of a waterfall. This illustrates the phases as a cascade, with control passing from one phase to the next in sequential order. There is not much of a difference between a sequential order of phases and an orderly progression of phases. Having said that, the metaphor can be developed further to make it more useful. The SLC is analogous to a “hydro-electric power scheme,” which involves water being pumped back up the hill and then released back down the cascade. This process generates electricity. This approach allows for the possibility that the review conducted at the conclusion of each phase may lead to a determination that the results do not match the standards, and as a result, the phase currently under development needs to be repeated. The form’s layout makes it possible to go back to any earlier stage. It also illustrates how post-implementation reviews may eventually lead to the launch of a new project with the aim of either entirely replacing or greatly improving the current system. The fact that it occurs is something that reflects this.

Some project management strategies severely undervalue the significance of the requirements analysis phase. These are frequently based on IEEE standards, have a flavour that is strongly influenced by “software engineering,” and substitute a “Functional Design Specification” for the SRS. The “what”-oriented, user-focused requirements analysis phase is replaced with a “how”-oriented, technical/synthetic/constructive conceptual design phase in these techniques because they fail to acknowledge the importance of user requirements. Additionally, the importance of user demands is not acknowledged by these methods. Studies have indisputably shown that mistakes made during the creation of a system are much more expensive the sooner that they are made in the project. A simple programming error is on the order of 100 times less expensive to rectify than a failure to comprehend the demands of the users. As a result, it is dangerous to rush into a more technical or software engineering approach too early in the project and skip over the requirements analysis phase.

Several businesses offer productized project management methods for sale. These methods typically come in the form of binders that contain documents and forms, as well as associated training courses. It is common practice for software development consultancies and contractors to have a project management approach of their choosing, which they favour utilising for development contracts that they carry out. Different interpretations of the SLC have been incorporated into these productised methods. Inappropriately, these kinds of products are frequently referred to as “methodologies.” This term may only be used in the singular; it cannot be used in the plural because it officially refers to the “study of methods,” not to a particular method.

Advanced Considerations

Applications developed in the modern era typically have long lifespans and are subject to significant development and improvement. It is also common for them to be initially made available in a version that, while it does provide enough functionality for users to begin gaining value, it does not provide the full set of capabilities that were intended to be provided by the product. The term “release” is commonly used to refer to these incremental versions of the software. These are typically denoted by release numbers, which enables a greater number of minor releases to be contained within a major release (for instance, Release 1.0 was followed by Release 1.1), as well as a greater number of minor bug fixes and enhancements to be contained within a minor release (e.g., Release 1.1c). In general, steps are performed in the order listed here. In actuality, their being interleaved is caused by a combination of two factors:

  • Haste: The delivery of applications must frequently be sped up due to time constraints. This may occur as a result of real deadlines (such as a legal obligation), arbitrary deadlines (set in order to focus the minds of the project staff), or the pressures brought on by competition. This means starting some nominally later tasks, or even whole phases, before the checkpoints for the tasks and phases that came before them have been satisfied. To accomplish this, one must be willing to take some calculated risks; and
  • Scale and complexity. Due to the characteristics of modern applications, it is customary for them to undergo a progression of development. It is common practice to begin work on later releases before the SLC for earlier releases has been completely completed.

The term “prototyping” can be considered an additional qualification for the SLC. The development of both software and human processes will be done in this manner: in an experimental, iterative fashion. When it comes to functions that are not well understood, such as those that are innovative, prototyping is an appropriate method to use. It is possible that a whole new service will be so poorly understood in extreme cases that it will be impractical to approach it in the methodical manner that is required by the SLC. Because the outcomes of using a prototyping approach and the utilisation of the resources are, for the most part, unable to be planned for, using this method is a very risky approach to take when working on structured projects. This has not prevented it from becoming overly trendy, from being overused, or from attracting names that are considered trendy (e.g. “rapid application development”).

In spite of the fact that the traditional SLC model is an example of oversimplification, the framework that it offers for project management is extremely useful. Importantly, it lays the groundwork for a skilled project manager to conduct risk analysis and develop a risk management strategy, enabling the delivery of new systems within acceptable deadlines and with acceptable risk profiles. This is made possible by the foundation that this establishes. Both technologies and fashions are subject to regular and rapid shifts. The “structured” philosophy, which had been prevalent for a long time, has been supplanted over the course of the past decade by a descendant philosophy that is known as being “object-oriented.” Because of this, there is a greater opportunity for the re-use of existing code, which leads to increased productivity (by preventing the ongoing re-writing of common functions) and increased quality (by applying pre-tested blocks of code). Although the SLC has not been fundamentally altered as a result of the object-oriented approach, it has led to some modifications in the approach itself as well as some changes in the terminology that is used.

References

http://www.rogerclarke.com/SOS/SLC.html

SLC Vs SDLC | Cyber Defense (luizfirmino.blogspot.com)

SLC vs SDLC? from cissp