Talk:Systems development life cycle

System Development Life Cycle

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)

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)

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)

Merge?

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.

• 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 203.147.91.118 (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 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)

Phasist orientation?

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"?

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

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 (talk•contribs) 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 (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)

system maintenance

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

Decommission

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)

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. --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)

Regional Variations

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)

Aged text

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)

Comparison of Methodologies

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)

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)

Copied and pasted from various Wikipedia articles

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

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)

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)

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)

Images

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)

Evolution?

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?

108.210.238.69 (talk) 20:13, 27 March 2013 (UTC)

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)

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)

"Lifecycle" vs "Life-cycle"

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-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)

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

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.

http://en.wiki.x.io/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)

Business, Stakeholder and Solution Requirements

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:

1. Enterprise Analysis (for identifying and documenting business requirements)
2. Business Analysis Planning and Monitoring (for listing the stakeholders, their roles and responsibilities)
3. Elicitation (for identifying and documenting stakeholder requirements)
4. Requirements Analysis (for prioritising, organising, specifying, modelling, verifying and validating stakeholder requirements)
5. 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.

1. Define the needs of the business: The aim of this activity is to identify and define why organisational systems or capabilities need to change.
2. 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.
3. 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.
4. Define the scope of the solution: The aim of this activity is to define the new capabilities that the project or iteration will deliver.
5. 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

1. 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.
2. Conduct the elicitation activity: The aim of this activity is to meet with stakeholder(s) to elicit information regarding their needs.
3. Document the elicitation results: The aim of this activity is to document the results of the elicitation meetings with stakeholder(s).
4. 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

1. 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.
2. 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.
3. Maintain the requirements for re-use: The aim of this activity is to manage the knowledge of the requirements following their implementation.
4. 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.
5. 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)Richard Gale.

References

Why vs Strengths & Weaknesses

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)

Do you have a reference for this as well? Walter Görlitz (talk) 20:33, 28 November 2018 (UTC)

outdated and controversial

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)

"System Analysis and Design" is not a model of SDLC. But, SSADM is.

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)