This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||
|
System lifecycle was nominated for deletion. The discussion was closed on 11 March 2017 with a consensus to merge. Its contents were merged into Systems development life cycle. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here. |
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:
Here are the six official phases:
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:
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:
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:
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:
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:
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:
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)
Disposal is another phase of life cycle not covered here. Every system must ultimately be decommioned. Too easy to ignore the trash heap. 2600:6C48:7006:200:B056:6066:1296:EF0B ( talk) 04:40, 5 March 2019 (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 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)
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. -- 144.138.83.154 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.
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 203.147.91.118 ( 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)
I vote to merge too, but the name software development process should be removed because in most of the textbooks it uses SDLC. So content written in software development process should be posted here and that article should be removed altogether. — Preceding unsigned comment added by 112.134.76.28 ( talk) 09:06, 24 May 2018 (UTC)
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)
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.
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.
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 ( talk• contribs) 20:11, 2 November 2006 (UTC)
Nice ad for the University of Ottawa. Can we do better than that?-- 74.107.74.39 ( talk) 01:17, 29 March 2011 (UTC)
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
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. -- 71.245.164.83 ( talk) 02:43, 8 February 2011 (UTC)
It all ends at the trash pile or recycled. Disposal/Decommissioning phase is just as important as every other phase of SLDC. 2600:6C48:7006:200:B056:6066:1296:EF0B ( talk) 04:42, 5 March 2019 (UTC)
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)
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)
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.
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)
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 67.134.239.205 ( talk) 14:31, 24 October 2008 (UTC)
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)
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)
what is the difference between errors and bugs? — Preceding unsigned comment added by 115.248.224.194 ( talk) 06:53, 2 July 2012 (UTC)
End-of-life, or disposal, is an idiotic concept that deserves to die. Business constantly evolves, and if a solution does not inspire users, supervisors, and managers to imagine further capabilities then the solution has failed. The entire idea is to addict every level of an organization to productivity, and the evolution of that goal. MAINTENANCE is the most important phase of the lifecycle, it adds to productivity, profitability, and evolution of an organization. It is a CYCLE, never ending, the idea of an endpoint is a failure of imagination (and opportunity!) — Preceding unsigned comment added by 2600:8800:5283:DE00:4C8B:2F91:8FF2:EF0C ( talk) 07:15, 24 May 2022 (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
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)
The result of the move request was: moved. -- BrownHairedGirl (talk) • ( contribs) 18:20, 9 April 2014 (UTC)
Systems development life-cycle →
Systems 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)
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.
/info/en/?search=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)
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:
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 [1].
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 [2].
Elicitation
The objectives of this phase are to prepare for elicitation activity, conduct the eliciation activity and document and confirm the elicitation results [3].
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 [4].
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 [5].
Richard Gale ( talk) 09:16, 19 November 2017 (UTC)Richard Gale.
References
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:
Should there be something to address the "why" ? — Preceding unsigned comment added by Markbassett ( talk • contribs) 18:18, 28 November 2018 (UTC)
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)
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)
industry 102.213.69.89 ( talk) 15:46, 1 February 2024 (UTC)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||
|
System lifecycle was nominated for deletion. The discussion was closed on 11 March 2017 with a consensus to merge. Its contents were merged into Systems development life cycle. The original page is now a redirect to this page. For the contribution history and old versions of the redirected article, please see its history; for its talk page, see here. |
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:
Here are the six official phases:
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:
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:
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:
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:
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:
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:
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)
Disposal is another phase of life cycle not covered here. Every system must ultimately be decommioned. Too easy to ignore the trash heap. 2600:6C48:7006:200:B056:6066:1296:EF0B ( talk) 04:40, 5 March 2019 (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 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)
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. -- 144.138.83.154 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.
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 203.147.91.118 ( 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)
I vote to merge too, but the name software development process should be removed because in most of the textbooks it uses SDLC. So content written in software development process should be posted here and that article should be removed altogether. — Preceding unsigned comment added by 112.134.76.28 ( talk) 09:06, 24 May 2018 (UTC)
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)
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.
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.
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 ( talk• contribs) 20:11, 2 November 2006 (UTC)
Nice ad for the University of Ottawa. Can we do better than that?-- 74.107.74.39 ( talk) 01:17, 29 March 2011 (UTC)
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
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. -- 71.245.164.83 ( talk) 02:43, 8 February 2011 (UTC)
It all ends at the trash pile or recycled. Disposal/Decommissioning phase is just as important as every other phase of SLDC. 2600:6C48:7006:200:B056:6066:1296:EF0B ( talk) 04:42, 5 March 2019 (UTC)
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)
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)
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.
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)
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 67.134.239.205 ( talk) 14:31, 24 October 2008 (UTC)
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)
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)
what is the difference between errors and bugs? — Preceding unsigned comment added by 115.248.224.194 ( talk) 06:53, 2 July 2012 (UTC)
End-of-life, or disposal, is an idiotic concept that deserves to die. Business constantly evolves, and if a solution does not inspire users, supervisors, and managers to imagine further capabilities then the solution has failed. The entire idea is to addict every level of an organization to productivity, and the evolution of that goal. MAINTENANCE is the most important phase of the lifecycle, it adds to productivity, profitability, and evolution of an organization. It is a CYCLE, never ending, the idea of an endpoint is a failure of imagination (and opportunity!) — Preceding unsigned comment added by 2600:8800:5283:DE00:4C8B:2F91:8FF2:EF0C ( talk) 07:15, 24 May 2022 (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
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)
The result of the move request was: moved. -- BrownHairedGirl (talk) • ( contribs) 18:20, 9 April 2014 (UTC)
Systems development life-cycle →
Systems 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)
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.
/info/en/?search=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)
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:
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 [1].
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 [2].
Elicitation
The objectives of this phase are to prepare for elicitation activity, conduct the eliciation activity and document and confirm the elicitation results [3].
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 [4].
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 [5].
Richard Gale ( talk) 09:16, 19 November 2017 (UTC)Richard Gale.
References
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:
Should there be something to address the "why" ? — Preceding unsigned comment added by Markbassett ( talk • contribs) 18:18, 28 November 2018 (UTC)
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)
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)
industry 102.213.69.89 ( talk) 15:46, 1 February 2024 (UTC)