Talk:Systems development life cycle

message: :The following section has beem added here by the anom user use:209.69.11.18 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.--96.244.247.130 (talk) 00:06, 18 July 2011 (UTC)
replies: text: Why is Systems Engineering Life Cycle exclusive to just software?    This is a MAJOR flaw in this article.   Consider a nuclear power plant (a system) and the electrical grid (a system-of-systems).   Maintenance and disposal phases are relevant. DeRavenSay (talk) 00:53, 24 June 2022 (UTC)
thread_title:  System Development Life Cycle 

message: 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 http://doit.maryland.gov/policies/Pages/sdlc.aspx, from where is copies text and graphics.
12.44.117.104 (talk) 20:35, 4 May 2009 (UTC)
thread_title:  Merge? 

message: 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)
thread_title:  Phasist orientation? 

message: 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)
replies: text: * Concur. —- Xsmith (talk•contribs) 03:15, 31 October 2006 (UTC)
thread_title:  The FADPIM Mnemonic 

message: 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:115.129.9.104 23:52, 18 October 2009 (UTC)
replies: text: The article was just vandalized and I restored the sections removed. -- Mdd (talk) 00:47, 19 October 2009 (UTC)
thread_title:  Decommission 

message: 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. 80.192.119.21 14:04, 23 July 2007 (UTC)
thread_title:  Regional Variations 

message: 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).
202.53.35.32 (talk) 03:06, 11 December 2007 (UTC)
thread_title:  Aged text 

message: 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 72.196.18.82 (talk) 02:32, 30 September 2008 (UTC)
thread_title:  Comparison of Methodologies 

message: 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)
replies: text: Problems solved here, so I removed the template. -- Mdd (talk) 12:56, 30 October 2009 (UTC)
thread_title:  Copied and pasted from various Wikipedia articles 

message: 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. --71.245.164.83 (talk) 02:43, 8 February 2011 (UTC)
replies: text: 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 (talk • contribs) 21:07, 27 September 2013 (UTC)
thread_title:  Weaknesses of the SLDC description 

message: 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)
thread_title:  Images 

message: The diagram presented  shows an evolution phase but the word 'Evolution' does not show up in the text. Why the mismatch?
108.210.238.69 (talk) 20:13, 27 March 2013 (UTC)
replies: text: 108.210.238.69 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)

text: 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 85.92.208.147 (talk) 08:19, 20 May 2013 (UTC)
thread_title:  Evolution? 

message: 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. 
https://en.wikipedia.org/wiki/User:DeepNorth/ReceivedDevelopmentMethodology
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. 
DeepNorth (talk) 17:59, 6 June 2016 (UTC)
thread_title:  What We Actually Do 

message: In a conteporarily-organised organisation, the role of capturing and documenting business, stakeholder and solution requirements (amongst other activities) is the responsibility of a Business Analyst. To become a Certified Business Analyst, the certification body, the International Institute of Business Analysis (IIBA), requires a certain level of knowledge in the subject. The knowledge source that the IIBA requires aspiring Business Analysts to be knowledgeable in is the Business Analysis Book of Knowledge (BABOK). The BABOK breaks-down the process of capturing and documenting business, stakeholder and solution requirements into 5 phases:
:# Enterprise Analysis (for identifying and documenting business requirements)
:# Business Analysis Planning and Monitoring (for listing the stakeholders, their roles and responsibilities)
:# Elicitation (for identifying and documenting stakeholder requirements)
:# Requirements Analysis (for prioritising, organising, specifying, modelling, verifying and validating stakeholder requirements)
:# Requirements Management and Communication (for identifying and documenting functional and non-functional solution requirements)
The BABOK identifies the objectives of each of these phases and the purpose of the each of the constituent activities as follows:
Enterprise analysis
The objectives of this phase are to define the needs of the business, assess the gaps in capability, determine the approach to the solution and define  both the scope of the solution and the business case"Enterprise Analysis", "BABOK Page", January 2015..
:# Define the needs of the business: The aim of this activity is to identify and define why organisational systems or capabilities need to change.
:# Assess the gaps in capability: The aim of this activity is to identify what new capabilities are required by the enterprise to meet the needs of the business.
:# Determine the approach to the solution: The aim of this activity is to determine which approach to the solution is the most viable one to meet the need of the business. This approach needs to be sufficiently detailed to be able to be used as input for definition of the solution scope and the preparation of the business case.
:# Define the scope of the solution: The aim of this activity is to define the new capabilities that the project or iteration will deliver.
:# Define the business case: The aim of the activity is to determine whether or not an organisation is able to justify the investment required to commission a project or iteration to deliver a proposed solution.
Business Analysis Planning and Monitoring
The objectives of this phase are to plan the approach to business analysis, conduct an analysis of the stakeholders, plan the business analysis activities, communications and requirements management process and manage the performance of business analyst activities"Business Analysis Planning and Monitoring", "BABOK Page", January 2015..
:# Plan the approach to business analysis: The aim of this activity is to select the best approach to performing business analysis, identifying which stakeholders need to be involved in the decision and who will be consulted and informed of the approach.
:# Conduct an analysis of the stakeholders: The aim of this activity is to identify those stakeholders who maybe affected by a proposed initiative, those who share a common need ot the business need, those who are able to influence a stakeholder and those members of internal or external authority bodies who approve project deliverables.
:# Plan the business analysis activities: The aim of this activity is to identify the deliverables that must be produced, define the activities that are needed to produce these deliverables, sequence these activities, estimate activity resources, estimate activity durations and identify the management tools that are required to measure the progress of those activities and deliverables.
:# Plan the business analysis communications: The aim of this activity is to describe the communication structure and schedule and organise and record the activities for setting the expectations of business analysts activities, meetings and others.
:# Plan the requirements management process: The aim of this activity is to approve the implementation requirements and define how changes to the scope of either the requirements or solution will be managed.
Elicitation
The objectives of this phase are to prepare for elicitation activity, conduct the eliciation activity and document and confirm the elicitation results"Elicitation", "BABOK Page", January 2015..
:# Prepare for elicitation activity: The aim of this activity is to ensure that all the resources required for conducting the elicitation activities are organised and scheduled.
:# Conduct the elicitation activity: The aim of this activity is to meet with stakeholder(s) to elicit information regarding their needs.
:# Document the elicitation results: The aim of this activity is to document the results of the elicitation meetings with stakeholder(s).
:# Confirm the elicitation results: The aim of this activity is to validate that the stated stakeholder requirements are aligned to the stated needs of the business.
Requirements Analysis
The objectives of this phase are to prioritise, organise, specify and model the requirements, define the assumptions and constraints and verify the quality and validity of the requirements"Requirements  Analysis", "BABOK Page", January 2015..
:# Prioritise the requirements: The aim of this activity is to grade each stakeholder requirement so that analysis and implementation effort may be guided to satisfying each requirement in a descending list of importance to the business.
:# Organise the requirements: The aim of this activity is to organise the stakeholder requirements in such a way that the listing is complete and may be understood by all stakeholders.
:# Specify and model the requirements: The aim of this activity is to analyse each stakeholder requirement within the context of how the organisation currently operates using a combination of statements, matrices, diagrams and models.
:# Define the assumptions and constraints: The aim of this activity is to identify any assumptions made by stakeholders in their stating of their requirements and to identify any constraints which had a bearing on their identifying of their requirements.
:# Verify the quality of requirements: The aim this activity is to ensure that the stakeholder requirement specification and models meet the mandated standard of quality and allows them to be used effectively as a guide in future activity.
:# Validate the requirements: The aim of this activity is to ensure that each requirement in the listing of stakeholder requirements represents a stakeholder requirement and that there is a logical relationship between each requirement in the listing and the stated  goals and objectives of the business.
Requirements Management and Communication
The objectives of this phase are to manage the solution scope and requirements, manage the traceability of requirements, maintain the requirements for re-use and prepare and commmunicate the requirements package"Requirements Management and Communication", "BABOK Page", January 2015..
:# Manage the traceability of requirements: The aim of this activity is to ensure an ongoing linkage between the needs of the business, the requirements of the stakeholders and the solution requirements.
:# Manage the solution scope and requirements: The aim of this activity is to ensure that stakeholders are kept abreast of any changes to either the needs of the business or the scope of the solution to maintain their confidence that their requirements will be fulfilled.
:# Maintain the requirements for re-use: The aim of this activity is to manage the knowledge of the requirements following their implementation.
:# Prepare the requirements package: The aim of this activity is to ensure that the solution requirements are structured and documented is such a way that the stakeholders are able to easily relate solution requirements to their own requirements.
:# Communicate the requirements: The aim of this activity is to ensure that all stakeholders have a common understanding of the solution requirements.
Richard Gale (talk) 09:16, 19 November 2017 (UTC)
thread_title:  Business, Stakeholder and Solution Requirements 

message: The "why" this exists is not clearly shown by showing of strengths & weaknesses, as those show both areas where it should be applied and those where it should not without explaining it in terms of benefit or situational usage.  Should perhaps it be showing what the software life cycle model provides:
* Breaks the process into discrete well-understood steps
* Provides visible outputs
* Provides points for review and audits
* Provides management decision points
* Allows risk to be managed
Should there be something to address the "why" ? — Preceding unsigned comment added by Markbassett (talk • contribs) 18:18, 28 November 2018 (UTC)
replies: text: Do you have a reference for this as well? Walter Görlitz (talk) 20:33, 28 November 2018 (UTC)
thread_title:  Why vs Strengths & Weaknesses 

message: So much of this is outdated and controversial, that it screams out for discussion.  Surely this "talk page" is the correct venue? — Preceding unsigned comment added by 99.243.121.9 (talk) 06:25, 20 June 2021 (UTC)
thread_title:  outdated and controversial 

message: Why is "System Analysis and Design" a form/model of SDLC? It is too narrow to be consider even a meta-model as it says in that section? They are just two steps in SDLC which are already considered in the preceding model (Waterfall model).
There is one model with a similar name: "Structured Systems Analysis and Design Method" (SSADM). That is a truly model which might be considered a form of SDLC.
 George Rodney Maruri Game (talk) 01:00, 10 September 2023 (UTC)
thread_title:  "System Analysis and Design" is not a model of SDLC. But, SSADM is.