Archive | Systems Development Lifecycle (SDLC) in IS RSS feed for this section

The End of an “Eternal Sunshine”

10 Mar

Now that this seemingly “Eternal Sunshine of an IS Mind” is finishing up tonight I would like my final blog to briefly summarise the Systems Development Lifecycle (SDLC) in IS.


  • Basically Software Development Life Cycle (SDLC) is a process that organisations use to develop information systems.
  • It was introduced to address the problems faced during the software development process.
  • SDLC is a disciplined and systematic approach that divides the software development process into various phases, such as requirement, design, and coding.
  • The phase-wise development process helps to track schedule, cost, and quality of the software projects life cycle.A

Overview of SDLC Phases:

  1. Planning:
    Establishes a high-level view of the intended project and determines its goals.
  2. Analysis:
    Analyses end-user information needs in terms of what the IS should do.

  3. Design:
    Describes desired features and operations in detail – how the parts of an information system should be implemented.
  4. Implementation:
    Convert final physical system specifications into working and reliable software.
  5. Maintenance:
    Software Changes are made here.

There are various SDLC methodologies which have developed over the past and guide us through the software development life cycles. The major SDLC methodologies are :

  1. Waterfall Method
  2. Rapid Application development (RAD)
  3. Prototyping Model
  4. Spiral model

The following brief video explains SDLC in simple terms:

Thanks for reading my blogs! I hope they helped you to understand SDLC and its phases more clearly. Thanks for all the comments and best of luck with your projects 馃檪

Please read the rest of my groups blogs on this topic:

  • SAD111456462
  • SAD111456588
  • SAD111461372



SDLC Phase 5: Maintenance

10 Mar


The Maintenance Phase occurs once the system is operational. It includes implementation of changes that software might undergo over a period of time, or implementation of new requirements after the software is deployed at the customer location. The maintenance phase also includes handling the residual errors that may exist in the software even after the testing phase. This phase also monitors system performance, rectifies bugs and requested changes are made.


Maintenance, often turned support, is a crucial activity for linking the experiences of users/customers with the product delivery organization. We consider perspectives on high tech maintenance from bug fixing through to design focused activities.

Key Deliverables:

  • Keep system live
  • Maintain code
  • Update software when required

The following video briefly summarises the Maintenance Phase of SDLC:



Basically Maintenance is what happens during the rest of the software’s life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

Thanks for reading 馃檪


SDLC Phase 4: Implementation

10 Mar


In this stage physical system specifications are converted into a working and reliable solution. This is where the system is developed. It is followed by testing and then implementation.


Implementation Phases:

  1. Coding:
    Includes implementation of the design specified in the design document into executable programming language code. The output of the coding phase is the source code for the software that acts as input to the testing and maintenance phase.
  2. Integration and Testing:Includes detection of errors in the software. The testing process starts with a test plan that recognizes test-related activities, such as test case generation, testing criteria, and resource allocation for testing. The code is tested and mapped against the design document created in the design phase. The output of the testing phase is a test report containing errors that occurred while testing the application.
  3. Installation:
    In this stage the new system is installed and rolled out.a

Key Deliverables:

  • Fully Installed system
  • Fully trained users
  • User and Operational Documentation



The following video summarises the Implementation Phase of SDLC:


Thanks for reading 馃檪 My next blog will detail the final phase of SDLC: Maintenance!


SDLC in Information Systems!:)

10 Mar

Hey guys…seeing as this is the official end date for this blogging business I decided that I would provide some final information on the stages of the SDLC!:):) So here it comes….









System Development Life Cycle – A process by which systems analysts, software engineers, programmers, and end users build information systems.

The core of the SDLC (analysis-design-implementation) is based on the standard approach to problem solving. First, you need to figure out or define what the problem is (analysis), then you need to figure out a good approach for solving it (design), and finally you need to go ahead and do it (implementation). The number of actual steps will vary depending on which texts and sources you consult. The steps listed above are one example that addresses most of the concerns of the SDLC.

The SDLC comes in two basic flavors. The waterfall or linear approach implies that you do each step in sequence. This is the way most older systems were developed. The major problem is that it assumes you can do all the analysis and get everything right without doing any design or implementation. On complex systems this just isn鈥檛 possible. The fountain or iterative approach implies that you do some analysis, then some design, and then some implementation. Based on what you learn, you cycle back (loop) through and do more analysis, etc. This supports human learning a lot better. It is the approach we recommend for most projects today.


Request by client/user
Corporate/organizational requirement

Key Activities:
Conduct preliminary investigation/feasibility study
Determine scope of problem/project
Identify constraints to systems development
Identify resources required
Set timelines, schedules, checkpoints, etc.
Set project deliverable goals
Develop high level specifications
Key Outputs:
Decision to proceed
Project plan
Preliminary needs analysis report


A brief look at the following factors:
路 Technical (is hardware and software available to do what is needed?)
路 Economic return (can the expense be justified by potential financial returns?)
路 Non-economic return (can expense be justified in ways that cannot be measured financially?)
路 Legal and ethical (will the system operate within boundaries?)
路 Operational (will the system receive support from the people who operate it and make it work?)
路 Schedule (is it possible to satisfy development time constraints?)
As specified in McLeod, 1998, p. 192

Key Activities:
Gather business requirements
Build trust and rapport with users
Document the existing system
Develop preliminary data and process models
Verify requirements and current system/procedures with users

Key Outputs:
Systems Requirements Documents
Detailed Project Scope and Deliverables Reports
Data and Process Models


What information?
路 Overview of business area mission and goals
路 Tasks done
路 Activities done in completion of tasks
路 Flow of information through application area
路 Uses of reports (Who generates them? How are they used?)
路 Current system documentation
路 Existing company procedure manuals
路 User wish list
路 Work samples
路 ETC.

Who do I get information from? (Subject Area Experts)
路 Key workers in the job
路 Knowledgeable supervisors
路 Existing systems maintenance and analysis staff
路 ETC.
路 Direct observation
路 Interviews (individual and groups, structured and unstructured)
路 Questionares/surveys
路 Activity logs/work diaries
路 ETC.


Key Activities:
Determine technical systems configuration
Determine data structure
Determine make or buy decision
Set systems conversion plan

Key Outputs:
Systems architecture report
Systems conversion chart and plan
Data structure diagrams


Key Activities (if create in-house):
Create the physical system
Test the system
Obtain hardware
Create documentation and training materials

Key Outputs:
Tested programs
Completed system
Training materials


Testing of individual units or modules

Testing the entire system as one

Correcting systems problems

Two basic types of documentation
Systems Documentation
Information needed for the on-going maintenance and operation of the computer system
Structured for the technical systems professional
Examples: technical diagrams, flowcharts, database management structures, etc.

User documentation
Easy to read (step by step) instructions for using the application system
Structured for non-systems professional

Systems Documentation
路 Maintenance staff must learn system
o The original systems developers are usually not the systems maintenance staff (they move to other new development projects)
路 To ensure continuity of systems development after original developers leave the company
路 To facilitate the incorporation of new aspects into the system (e.g., adding to the original models) by systems development staff

User Documentation
路 To reduce the number of problem telephone calls that the developer receives from customers
路 To minimize the amount of the new system training needed


Key Activities:
Conduct cutover
Train users/customers
Manage change
Obtain user sign off

Key Outputs:
Satisfied users/customers
Modification requests


Changing from old to new system

路 Smaller trial system
路 Subset of the entire system
路 If successful, rest of system is typically cutover

路 Convert everything on one day
路 Works best for small systems

路 New system is incorporated one section at a time

路 Old system is maintained concurrently with new system
路 Time consuming and expensive
路 Greatest security against failure
-based on McLeod (1999)

路 Schedule as close to new systems introduction (implementation) as possible
路 Train people about what they need to know (don鈥檛 bore them with unnecessary information)
o May differ for each job
路 Which type of training?
o Classroom vs. on the job vs. individual vs. computer aided, etc.

User acceptance/sign-off
路 Resistance to change
路 Increase in stress reactions
路 Avoidance of the new system

路 Invoice users in the development process early (to increase feelings of personal involvement and commitment)
路 Provide ample time for training
路 For introductory period, ask management to disband productivity performance measures associated with computing (the new system)
路 Provide support to resistant users
路 Provide well written, easy to understand documentation
路 Be honest with the users as to what the system can and cannot do
路 ETC.


Key Activities:
Conduct on-going systems maintenance

Key Outputs:
Change requests
New systems proposals/requests


Waterfall Vs Agile Model

10 Mar

Differences between the Waterfall Model and Agile Model:

  1. The main advantage is the backward scalability in Agile. Under waterfall approach we cannot change the decisions and implementations that we had made under the previous stages. If we want to make changes under waterfall we will have to build the entire project from the scratch once again.
  2. The flexibility to error check under any part of the development stage makes Agile more bug free and less聽mistaken as compared to Waterfall which can only test bugs at the end of the development module.
  3. Since Agile provides聽flexibility聽to make changes as per customer requirements it is more inclined towards better client satisfaction. This is a real set back for the Waterfall model which聽doesn’t聽allow any modifications once the module has been completed.
  4. Under Agile development modular partitioning of the software can be effectively carried out as compared to its聽counterpart. Though both of them allows option for segregation the later lacks the modifications in the implementation stage. The rules are set down before the commencement of the project hence it hinders further break down of the logical module. Whereas Agile can be of great help under such situations and can allow simultaneous development of different modules at the same time as per time bound requirement. If we want the project to be more segregated Agile comes as a pain relief for developers.



All good things must come to an end…

10 Mar


Well they say all good things must come to an end! Over the last 2 months we’ve all blogged with such enthusiasm, learning more than we ever thought on our particular topics. But this is my final blog on System development life-cycles. I’ve covered all the individual stages, along with the pro’s and con’s of SDLC. In this final blog I will conclude my thoughts with the addition of some nifty diagrams for your studying aid.

A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.
The oldest of these, and the best known, is the waterfall, the one most discussed in my groups blogs.

It is clear from looking at the blogs that SDLC is definitely something to be aware of, as the computer design world is swiftly adapting all the time.


So good luck to everyone in the final exam, I know ye’ll all do great 馃榾


SDLC models – The Final Chapter

10 Mar

Why read about about SDLC models when you can see SDLC models? And by “see” I mean see a diagram that involves some light reading.

The ultimate revision diagram. Even has stuff we’ve never done. Enjoy!

%d bloggers like this: