Talk:Systems development life cycle

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Software (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
WikiProject Systems (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is within the field of Software engineering.

System Development Life Cycle[edit]

The following section has beem added here by the anom user use: 16:37, 24 June 2004.

System Development Life Cycle, or SDLC, is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps:

  • The hardware concept - identifies and defines a need for the new system
  • A requirements analysis - analyzes the information needs of the end users
  • The architectural design - creates a blueprint for the design with the necessary specifications for the hardware, software, people and data resources
  • Coding and debugging - creates and programs the final system
  • System testing - evaluates the system's actual functionality in relation to expected or intended functionality.

Here are the six official phases:

1. Preliminary Investigation 2. Systems Analysis 3. Systems Design 4. Systems Developement 5. Systems Implementation 6. Systems Maintenance

Systems Planning is the function of the life cycle that seeks to identify and prioritize those technologies and applications that will return the most value to the organization. Systems’ planning involves three basic phases:

  • Study the organization's mission
  • Define an information architecture
  • Data architecture
  • Network architecture
  • Activities or applications architecture
  • People architecture (i.e., Information Systems organization structure)
  • Technology architecture
  • Evaluate organization area or specialty

Business Area Analysis is the study of the current business and information system, and the definition of user requirements and priorities for a new information system. Business Area Analysis involves three basic phases:

  • Feasibility assessment (Project Survey Phase)
    • Interviews
    • Project scope
    • Problem statement and classification
    • Proposed project plan
  • Organization problem statement (Project Study Phase)
    • Project roles
    • Learn current system (use repository)
    • Model the current system
    • Analysis of problems and opportunities
    • New system's objectives
    • New project scope and plan
  • Organization requirements statement (Definition Phase)
    • Identify requirements
    • Model system requirements
    • Discovery prototype
    • Prioritization
    • Review requirements

Business System Design Systems Design is the evaluation of alternative solutions and the specification of a detailed computer-based solution. It is also called Physical Design. Systems Design is composed of three phases:

  • Select a design target from candidate solutions (Selection Phase)
  • Acquire necessary hardware and software (Acquisition Phase)
  • Design and integrate the new system (Design and Integration Phase)
    • General design
    • Detailed design

Systems Implementation Systems Implementation is the construction of the new system and delivery of that system into "production" (meaning "day-to-day" operation). Systems Implementation involves three phases:

  • Build and test networks and databases (if necessary)
  • Build and test the program
  • Install and test the new system
  • Deliver the new system into operation

Systems Support the ongoing maintenance of a system after it has been placed into operation. This includes program maintenance and system improvements. Systems Support is composed of four activities, in no particular order, but rather as problems arise:

  • Correct errors
  • Software bugs
  • Documentation errors or omissions
  • Recover the system
  • Assist the users
  • Adapt the system to new requirements

The Systems Planning function of the life cycle seeks to identify and prioritize those technologies and applications that will return the most value to the organization. Systems Planning involves three basic phases:

  • Study the organization's mission
  • Define an information architecture
    • Data architecture
    • Network architecture
    • Activities or applications architecture
    • People architecture (i.e., Information Systems organization structure)
    • Technology architecture
  • Evaluate organization area or specialty

While termed "SLDC", the fact that it is a life cycle should extend itself beyond just development. I propose that that term be re-defined as Systems Engineering Life Cycle.-- (talk) 00:06, 18 July 2011 (UTC)


This article should be merged or replaced by the atricle Software_development_process. This article mistakenly identifies SDLC as a specific development process, and not as an umbrella term for development processes. It seems to base this view off of the Maryland's Department of Information SDLC page, from where is copies text and graphics. (talk) 20:35, 4 May 2009 (UTC)

This article should probably be merged with Systems development life cycle. // Liftarn Also see discussion. There are at least four articles it seems that should be merged into one. -- 07:05, 24 July 2005 (UTC)

Software development. is fun. its EASY. lawl. bwahahhaha. :P In my experience, the software development life cycle is distinct from the larger SDLC in many ways. I would not recommend a merge of the two.

  • Vote 1 for keeping systems and software sections separate Ansell 08:55, 25 February 2006 (UTC)
  • I vote for keeping them separate VectorThorn (talk) 18:06, 23 May 2010 (UTC)
  • I vote to Merge them (A normal user) — Preceding unsigned comment added by (talk) 13:24, 5 October 2012 (UTC)

See Talk:Software development process. -- Zondor 03:38, 22 October 2005 (UTC)

SDLC as a point of view on the book which is titled by "Systems Analysis and Design with UML Version 2.0: An Object-Oriented Approach" (authors are Alan Dennis, Barbara Haley Wixom, David Tegarden ) has four parts which are listed below: 1) Planning 2) Analysis 3) Design 4) Implementation

I personally feel that these topics should be merged as it is confusing for the users when they search for the results. The two different pages are trying to define the same thing more or less. Also this will ensure exact complete information is available for the people under one definite page.

P.S: We need an expert who can complete this task. Any mods or senior editor please do have a look into this regard. — Preceding unsigned comment added by (talk) 13:23, 5 October 2012 (UTC)

I vote for merging this article with Software_development_process. As in an above comment, SDLC is an umbrella term for development processes, NOT a specific development process as it is presented in this article. This article begins saying "SLDC [...] is A process of creating or altering information systems", but the usage of the indefinite article suggests there are processes alternative to SLDC, while in this article none is quoted. One could be the "waterfall model" quoted below, because the metaphore of a waterfall contrasts the concept of cycle intrinsic in SLDC, but the sentence "Few people in the modern computing world would use a strict waterfall model for their systems development life cycle" implies that waterfall model, according to the author, is included in SLDC, which is right, because even in waterfall model sooner or later one will have to do some changes, starting a cycle. But this strengthens the fact that SDLC is an umbrella term, whose meaning coincides with that of "Software development process". P.S.: contributors who disagree about keeping this this article and the current "Software_development_process" should give explanation of their position. Vittorioolivati (talk) 09:23, 10 August 2013 (UTC)

Phasist orientation?[edit]

Extreme Programming is listed as an example of an SDLC. The phase-structured breakdown in the article sounds very waterfall-oriented, and is more or less antithetical to to the Extreme Programming approach. Would it be better to remove the non-phasist methods from the list, or should the description be rewritten to be more inclusive? --William Pietri 21:12, 1 Jun 2005 (UTC)

What is "official"?[edit]

I have added an external link for the U.S. House of Representatives version of the Systems Development Life-Cycle. It differes from the DOJ version. Why is the DOJ version "official"? Which version would be more appropriate for complinace with Sarbanes-Oxley? The House of Representatives version has seven phases and I think they are better in that they begin with the two phases of Project Definition and User Requirements Definition. The corresponding DOJ version is one phase called Preliminary Investigation, which is an uncommon term, especially in this context. It sure sounds like something a DOJ person would do!

I think that neither should be called "official". An official standard is one that has gone through the rigorous and thorough life cycle of a standards agency such as ANSI or ECMA.

* Agreed... what do either DoJ or House of Representatives have to do with "official" SDLC? Any objections to remove? There should more appropriatedly (assuming they exist) be links/references to some standards body such as IEEE or ISO. DEddy 12:03, 6 September 2006 (UTC)
There is also a DoD SDLC. Is there an INCOSE one as well? Luis F.
* Agreed... None should be called official, maybe some should be removed. I know that they are currently teaching the last option (5. ADDIE) as the standard course in the VCE IT subjects.

The FADPIM Mnemonic[edit]

I think that the FADPIM Mnemonic is not good because "Feasability study" does not emphasize the importance of defining requirements. A thorough definition of requirements can save a lot of time in later phases yet programmers and/or managers often skip it.

* I tend to agree, and think FADPIM is too specific to one person's teaching methodology. It should therefore be removed from the SDLC topic. --Mwfnwa 16:59, 6 October 2006 (UTC)
* Concur. —- Xsmith (talkcontribs) 03:15, 31 October 2006 (UTC)

Moved the following from the main page:

FADPIM is often taught to students by Malcolm Bishop at the University of Ottawa who are studying database design and/or systems analysis for the first time. It stands for: Feasibility study, Analysis, Design, Programming and testing, Implementation, Maintenance.

—- Xsmith (talkcontribs) 20:11, 2 November 2006 (UTC)

Nice ad for the University of Ottawa. Can we do better than that?-- (talk) 01:17, 29 March 2011 (UTC)

system maintenance[edit]

factors lead to high maintenance cost..what is it?


Is there a specific term to end this SLCP once a system is obsolete or withdraw? 22

Also Why was the Section titled Strength and weaknesses removed? It was a relevant section. --User: 23:52, 18 October 2009 (UTC)
The article was just vandalized and I restored the sections removed. -- Mdd (talk) 00:47, 19 October 2009 (UTC)

Where is true "end-of-life" (e.g. disposal) discussed? Not everything is software. Also, which phase is Research applicable? This needs a bit of work. -- (talk) 02:43, 8 February 2011 (UTC)

Regional Variations[edit]

FWIW the bald statement The SDLC is referred to as the Systems Life Cycle (SLC) in the United Kingdom is misleading. There's just as much variation of terminology and practice here in the UK as there is in any other English-speaking country. 14:04, 23 July 2007 (UTC)

Aged text[edit]

The overall text appears to be a bit aged (if not archaic) and is possibly in need of an update. Most solutions architects tend to equate SDLC with the ITIL processes of infrastructure and applications development and deployment, something more on the line of these entries from Wikipedia: ITIL#ICT_Infrastructure_Management and ITIL#Application_Management. Other references might be drawn in formal methodologies such as C&L Summit-D, Microsoft_Solutions_Framework, agile methodologies and other deployment methods such as SOA (Zapthink) and those presented by software quality bodies but the overwhelming focus seems to be in the direction of using an ITIL focus to describe the SDLC. (background available on application, email nefariouswheel @gmail . com). (talk) 03:06, 11 December 2007 (UTC)

Comparison of Methodologies[edit]

This chart is hardly accurate. Either it is extremely dependent on the terminology as defined by the authors in whatever textbook it was slapped into, or it's plain wrong.

  • Objects are only used with "Windows" interfaces?
  • Open Source has "Few" users? See: MediaWiki
  • Open Source only has "Internal" documentation?

Come on, grad students.

We need a "Systems Development Methodologies" page. —Preceding unsigned comment added by (talk) 02:32, 30 September 2008 (UTC)

Worse yet, Object Oriented development, Open Source projects, and End User development are not "complementary" to SDLC, but orthogonal to it. There's nothing that says I can't use SDLC on an object oriented project, or an open source project... —Preceding unsigned comment added by (talk) 14:31, 24 October 2008 (UTC)

Copied and pasted from various Wikipedia articles[edit]

This article or section appears to have been copied and pasted from various Wikipedia articles, possibly in violation of a copyright. This has occurred last year Oct 2008 when I expanded this article.

I apologize for all inconvenience I have caused here, see also here. If you would like to assist in improving this article, please let me know. I can use all the help I can get. Thank you.

-- Marcel Douwe Dekker (talk) 00:16, 14 October 2009 (UTC)

Problems solved here, so I removed the template. -- Mdd (talk) 12:56, 30 October 2009 (UTC)

Weaknesses of the SLDC description[edit]

Where is true "end-of-life" (e.g. disposal) discussed? Not everything is software (nor exclusively hardware). Also, which phase is Research applicable? This needs a bit of work. Life-cycle definition does not match SLDC. -- (talk) 02:43, 8 February 2011 (UTC)

what is the difference between errors and bugs? — Preceding unsigned comment added by (talk) 06:53, 2 July 2012 (UTC)

I believe there are also weaknesses in the description of this article because the SDLC has "vague" phases in it like "Implementation" (we Implement in every environment as we move through the SDLC). We were taught that a good SDLC has very clear phases with specific "delivery purpose" and with clearly aligned environments, like this SDLC that treats each phase as a step in delivery, just like in Assembly Line Theory, where things have clear steps as they move along an assembly line. The value in something like this is that users can see exactly where work to deliver, deploy to, and support environments must be done. I can't see these things, clearly, in the article as it's currently written. In classes, the instructor used this article as an example of a bad SDLC. Can we fix it? — Preceding unsigned comment added by ElonPhoenix (talkcontribs) 21:07, 27 September 2013 (UTC)


A lot of .jpg images should be replaced by, at least, .png or .svg (the best variant). --Brateevsky (talk to me) 12:18, 20 February 2013 (UTC)


The diagram presented

Model of the Systems Development Life Cycle

shows an evolution phase but the word 'Evolution' does not show up in the text. Why the mismatch? (talk) 20:13, 27 March 2013 (UTC) has also comented that the Development section is called implementation in the diagram - moving this comment from the article to here. Oddbodz (talk) 21:33, 27 March 2013 (UTC)
This diagram is wrong according to the text?!?!?!?!?!? Implementation is after test as I have seen in every other diagram, and shown further down the page?!??!?!?!?! — Preceding unsigned comment added by (talk) 08:19, 20 May 2013 (UTC)

"Lifecycle" vs "Life-cycle"[edit]

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved. -- BrownHairedGirl (talk) • (contribs) 18:20, 9 April 2014 (UTC)

Systems development life-cycleSystems development life cycle – The term life-cycle is not commonly used and is likely ungrammatical. Walter Görlitz (talk) 18:21, 2 April 2014 (UTC)

The title of this page is "Systems_development_life-cycle", with the last word hyphenated. This is a highly irregular use of the word. A Google Ngram search of ["lifecycle" vs "life cycle" vs "life-cycle"] shows no occurrences of the hyphenated version at all. Searching on "development life-cycle" and its variations is the same. No hyphenated. Just searching Google returns over 6 times as many results for the non-hyphenated version of the word. WordNet supports this: [1]. Wikipedia itself uses the terms inconsistently (seemingly randomly).

I suggest changing the title of this page (not just its redirects) to either "Systems development lifecycle" or "Systems development life cycle".

Lousyd (talk) 15:53, 2 April 2014 (UTC)

It was moved 2011-11-02T12:40:54‎ by user Tony1 (moved Systems Development Life Cycle to Systems development life-cycle). No reason for the move was given. There is no discussion here as to why the article was moved either.
I have no problems moving it to Systems development life cycle, but perhaps we should put a move notice on the article itself to see what others say. Walter Görlitz (talk) 18:12, 2 April 2014 (UTC)
Apparently we tag it here. Walter Görlitz (talk) 18:21, 2 April 2014 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

What We Actually Do[edit]

Although this is software-centered, it should be applicable generally to some extent. From the link below: "This is called 'The Received Methodology' because nothing has really been invented here beyond tidying up the process and describing it. It is, in bits and pieces, what working programmers pass on to one another. It already exists in the wild on its own. It is 'what we do'."

The notes below are what I present from time to time when working with other programmers and clients. The diagram is necessarily rigid in that arbitrary lines need be drawn and boxes named. The fact is, real software that ends up being delivered and actually doing a job is arrived at in sloppy iterations as the problem domain itself and the project's ongoing rationale unfold. Monolithic projects that actually deliver may be following a rigid protocol, but in practice the thing that results in a working system conforms more to an iterative protocol and depends highly upon human judgment as to which things to largely ignore and which things to attend to.

Note: obviously putting the material below in the article would violate WP:NOR and can't go into the article itself. I wrote this a number of years ago because I was peeved about people with marginal development experience attempting to divert development resources to wastefully conform with the methodology of the month. I have not bothered to write this up for publication because as someone noted elsewhere, it's not news.

The majority of projects do not even reach fruition. Of those that do, it is a minority that succeed in any meaningful way. A process such as the one pictured below can get to answers more quickly because it asks and answers pertinent questions as soon as (and no sooner than) they become relevant to the process. In many/most cases, the answer will be to retire or cancel the project before it is even done. Whatever the case, more time is spent dealing with issues as soon as they become apparent and returning to re-analyze and correct mistakes.

One of the main takeaways from documenting the process like this is that failure, especially 'localized failure' (of one part of the process) is not pathological, it is the norm. Good managers report as they have been directed, but they don't confuse successful reporting with project success.

Trantor Development Methodology

DeepNorth (talk) 17:59, 6 June 2016 (UTC)