Systems development life cycle

Keywords: sdlc strengths limitations, agile software development, rapid prototyping

1. Introduction

SDLC, The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Hence an array of system development life cycle (SDLC) models has been created: Fountain, Spiral, rapid prototyping, synchronize and stabilize and Incremental. Although in the academic sense, SDLC can be used to refer to various processes followed during the development of software, SDLC is typically used to refer to the oldest of the traditional models a waterfall methodology.

2. Software Engineering Process

The SDLC supports a list of important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained more in detail later in this report. Traditionally the waterfall model was regarded as the original: which adhered to a sequence of stages in which the output of each stage became the input for the next. No definitive models exist, but the steps can be describe and divided as follows:

• Project planning, feasibility study, Initiation:

A feasibility study is a quick examination of the problems, goals and expected cost of the system. Projects are usually evaluated in three areas of feasibility: economical, operational, and technical. In addition, it is also used as a guide to keep the project on track and to evaluate the progress of project (Post & Anderson, 2006). Thus the goal of the feasibility studies is to evaluate alternative systems solutions and to propose the most feasible and desirable business application for development, (Obrien & Marakas, 2006) states that the feasibility of a proposed business system can be evaluated in four major categories

• Organizational Feasibility: An illustration of how a business supports the strategic business priorities of the organization.
• Economic feasibility: Identifies whether expected cost savings, increase revenue, increase profits and reductions in required investments will exceed the cost of developing and operating a proposed system.
• Technical feasibility: can be demonstrated if reliable hardware and software capable of meeting the needs of a proposed systems can be acquired or developed by the business in the required time.
• Operational feasibility: can be measured by the ability and willingness of management, employees, customers, suppliers and others to operate, use, and support a proposed system. for example if Tesco’s was to change its software platform at the tills to something entirely different, employees may begin to make to many errors and find ways around using it or just all together quite, thus it will fail to show operational feasibility.

• Requirements gathering and Systems Analysis:

(Hawrzyszkiewycz 2004) “This step defines the proposed business solutions and any new or changed businesses processes”. The goal at this stage is to find any problems and attempt to fix the system or improve its productivity and efficiency. The technique here is to break the system into smaller pieces as it is easier to be explained to others and can be split up amongst different development team. A draw back of this though is that it takes time and effort to reintegrate all of the pieces (Post & Anderson, 2006).

• Systems design:

Functions and operations are described in detail during the design stage, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will be to describe the new system as a collection of modules or subsystems. (Hawrzyszkiewycx 2004) states that system designs is a two step process,

Broad design: which indentifies’ the main architecture of the proposed system which may include the language use to develop the databases, network configurations, software requirements and whether programs are to be developed using internal programmers or external contractors.

Detailed design: only after the design phase is completed the detailed design phase can be initiated, during this phase the database and program modules are design and detailed user and system interaction procedures and protocols are documented.

• Build:

Software developers may install (or modify and then install) purchased software or they may write new or custom design programs (Senn 1989). Just like the design phase, this phase is broken up into two separate sub phases, development and implementation. During the implementation phase the components built during the development are put into operational use. Usually this means that the new and old systems run parallel until users are trained in system operations and existing processes converted to the new system. (Hawrzyszkiewycz 2004)

• Testing:

During the integration and test stage, the software artefacts’, online help, and test data are migrated from the development environment to a separate test environment. At this point, all test cases are run to verify the correctness and completeness of the software. Successful execution of the test suite confirms a robust and complete migration capability. In addition, reference data is finalized for production use and production users are identified and linked to their appropriate roles. The final reference data (or links to reference data source files) and production user list are compiled into the Production Initiation Plan and the system is used experimentally to ensure that the software does not fail, also the code is tested iteratively at each level (Senn 1989).

• Installation, Implementation and Deployment:

Implementation is a vital step in the deployment of information technology to support employees, customers, and other business stakeholders, the system implementation stage involves hardware and software acquisition, software development, testing of programs and procedures, conversion of data resources and additionally involves the educating and training of end users and specialist who will operate the new system. All together this is the final stage where the project is finally used by the business (Obrien & Marakas, 2006).

• Maintenance:

Once a system is fully implemented and is being used in business operation, the maintenance function begins; this involves the life of the system which may include changes and enhancements before its decommissioning. (Obrien & Marakas, 2006) states that the maintenance activity includes a post implementation review process to ensure that newly implemented systems meet the business objectives establish for them. (Hawrzyszkiewycx (2004) supports the argument that maintenance is required to eliminate errors in the system during its working life and to improve the system in the light of changes by monitoring, evaluating and modifying operational business systems to make desirable or necessary improvements.

3. Evaluation and Reason for Adopting SDLC for a small Pc Application

The adoption of the SDLC for the development of a small application on a pc will not be appropriate because the SDLC is just what is says it is – the Life Cycle of the system software. The SDLC is a process use to manage time and resources on a project, from the identification of a need for the system Initiation) to rolling it out to the user (Implementation) to de-supporting or no longer needing it (Disposition), Each phase of the SDLC requires documentation, reporting, and approval. This assures that a project cannot get out of hand either by changing the direction or becoming a financial black hole and the project sponsors are aware at every step of exactly what is going on as it is documented. Therefore it is reasonable to assume that the development of a small application on a pc does not require the adoption of the SDLC model whereas a large systems which have teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive enterprises today, will without a doubt need to adopt an SDLC solution to manage the resources of such a project.

4. Evaluation Of the Traditional SDLC Strengths & Limitations

The Waterfall Model

The waterfall model is the most classical sequential life cycle; each phase must be completed in its entirety before the next phase can begin. (Post & Anderson, 2006) states that one advantage of the SDLC is the formality aspect which makes it easier to train employees and to evaluate the progress of the development as well as ensuring that steps are not skip, such as user approval, documentation and testing. In addition with eighty percent of MIS resources spent of maintenance, adhering to standards whilst building the system makes it easier to modify and maintain in the future because of the documentation generated and the sustain consistency, however the formality of the SDLC approach can be problematic as it increases the cost of development and lengthens the development time (Post & Anderson, 2006)

The formality of the SDLC method also causes problems with projects that are hard to defined, unlike newer methods like Agile which helps software development teams to respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints (Cohn, Mike 2006). Agile Methods aim at allowing organizations to deliver quickly, change quickly and change often. While, agile techniques vary in practice and emphasis, they share common characteristics, including iterative development and a focus on inter-action and communication. Maintaining regularity allows development teams to adapt rapidly to changing requirements, and working in close proximity, focusing on communication, means teams can make decisions and act on them immediately, rather than wait on correspondence. It is also important to reduce non-value adding intermediate artefacts to allow more resources to be devoted to product development for early completion.

The SDLC however works best if the entire system can be accurately specified in the beginning. That is, users should know what the system should do long before the system is created. (Post & Anderson, 2006) further explains that because of the rigidity of the SDLC, the development of more modern applications are difficult, hence the combination of existing SDLC models and the creation of other alternatives models and methodologies are adopted as outlined later in this paper.

Advantages

• Easier to use.
• Easier to manage because of rigidity
• Phases are completed at specific phase intervals
• Requirements are very well understood.

Disadvantages

• scope adjustment during the life cycle can kill a project
• Working software is not produced until the life cycle is complete.
• Not suited for long and ongoing projects.
• In appropriate where requirements are at a moderate to high risk of changing

• Alternative development mythologies

One management advantage of the traditional SDLC method is the sequential series of tasks; on the other hand using the traditional SDLC has many drawbacks. For example, when adopting a traditional SDLC methodology, the rigid chain of phases may subsequently make it impossible for developers to improved ways to provide functional requirements as the project is being built, which results in the designers redoing their work. Instead programmers should be involved in the planning and design phases, so that they may be able to identify improvements much earlier in the process, thus enhancing the effectiveness of project activities, (FFIEC IT Handbook (2009).

Development solutions such as iterative and Rapid prototyping address many of the shortcomings of a traditional SDLC. And a brief description of two the newer methodologies are outlined below along with some advantages and disadvantages for comparison purposes.

Agile Development Model

Agile software development is a conceptual framework for undertaking software engineering projects. Agile methods attempt to minimize risk and maximize productivity by developing software in short iterations and de-emphasizing work on secondary or interim work artefacts’.

The key differences between agile and traditional methodologies are as follows:

• Development is incremental rather than sequential.
• People and interactions are emphasized.
• Working software is the priority rather than detailed documentation.
• Customer collaboration is used, rather than contract negotiation.
• Responding to change is emphasized, rather than extensive planning.

Rapid Prototyping model

Rapid prototyping is a process for creating a realistic model of a product’s user interface (Najjar, L. J. (1990) ,Using rapid prototyping, you model the look and feel of the user interface without investing the time and labour required to write actual code (Najjar, L. J. (1990).

Advantages

• Saves time and money
• Promotes consistency in user interface design
• Allows early customer involvement
• Reduces time required to create a product functional specification

Disadvantages

• Usually does not produce reusable code
• Lacks an obvious stopping point

5. Conclusion

It can be seen from the above comparison that differing philosophies can produce radically different views of a system. Nevertheless, both the Traditional SDLC and the alternatives produce valid working systems as well as their share in drawbacks

The “one size fits all” approach to applying SDLC methodologies is no longer appropriate. Each SDLC methodology is only effective under specific conditions. (Traditional SDLC methodologies are often regarded as the proper and disciplined approach to the analysis and design of software applications but the drawback is that it takes a considerable amount of time and all of the system details have to be specified upfront.

Methodologies like Rapid Prototyping alternatively are a compromise of rigidity and no rigidity. These new hybrid methods were created to bridge the gap with the evolution of more modern application developments requirements. Newer the less methodologies like Agile are most appropriate when volatility and uncertainty exist in the development requirements, and the SDLC is good when the requirements are already defined.

6. Bibliography

• Najjar, L. J. (1990). Rapid prototyping (TR 52.0020). Atlanta, GA: IBM Corporation.
  http://www.lawrence-najjar.com/papers/Rapid_prototyping.html
• FFIEC IT Handbook (2009). Alternative development methodologies http://www.ffiec.gov/ffiecinfobase/booklets/d_a/02.html
• Senn James A. (1989), Analysis & Design of Information Systems, Introduction to Information Systems, pg27 – 32 Ch1 McGraw-Hill Co- Singapore
• Post. G & Anderson. D (2006), Management Information Systems, Organizing Business Solutions, pg 448 – 459 Ch 4 McGraw-Hill Co- New York
• Igor Hawryszkiewycz. (1998), Introduction to System Analysis & Design, The Development Process, pg120 – 136 Ch 7 Prentice Hall- Australia
• Obrien A. O & Marakas .M. (1989), Management Information Systems, Introduction to Information Systems, pg27 – 32 Ch1 McGraw-Hill Co- Singapore