Talk:Software development process

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Software development process article.
Article policies

Contents

[edit] System/Software Design/Development Process/Life/Cycle Merger Discussion

Systems development may refer to something as vague as a person handing out tickets at the entry gate - which may not be related in any way to software development. PLEASE review the articles in this light and do not merge the topics !!! Here is the single point of discussion for the merger of the following articles with Google results:

  1. "Software development process" - 912,000 results
  2. "Project lifecycle" - 383,000 results
  3. "Software development life cycle" - 300,000 results
  4. "Software development cycle" - 160,000 results
  5. "System Development Life Cycle" - 112,000 results
  6. "Systems development life cycle" - 105,000 results
  7. "System Design Life Cycle" - 925 results

How shall we deal with them? -- Zondor 03:37, 22 October 2005 (UTC) -- Zondor 03:48, 22 October 2005 (UTC)

  • I think that is a great idea. Limbo socrates 15:24, 24 October 2005 (UTC)
  • What about simply rolling the above list up from the bottom? Redirect the last to the previous, appending anything useful; lather rinse repeat.... Limbo socrates 18:31, 7 November 2005 (UTC)
  • It's an excellent idea! Why not? What wouldn't be good about it? Jake 16:48, 11 November 2005 (UTC)
  • Consider also Project management. It got 65M hits on Google and is quite tightly related to the Project lifecycle (or ought to be). Development process and lifecycle are closely related to each other on the system level (ISO 15288 "System life cycle processes") as well as on the software level (ISO 12207 "Software life cycle processes"). My humble proposal would hence be to aim for the three main articles covering systems, software and projects respectively. Daniel.wengelin 07:55, 4 January 2006 (UTC)
  • Projects are not always IT based. Although Wiki is very IT-centric, a Project Lifecycle is not always software or hardware based. Project Lifecycle is a sub component of Project Management. These items need to be distinguished. Paul Jones January 4, 2006.
  • Don't merge. Systems and software are like fruits and seeds. SDLC goes beyond software with consideration for hardware and other platform implementation needs, for example. SDLC is not limited to just software. ISO 15288 is only limited to information systems, but it sounded good. — Dzonatas 12:21, 17 January 2006 (UTC)
  • Software development life cycle is mostly management; I'd say merge it. Project life cycle is short and almost entirely software-specific; merge it, perhaps leaving a stub if others really want a separate generic project life cycle article. Don't merge System stuff with software stuff -- but perhaps edit system later. Software development life cycle is basically waterfall, so should merge with the Waterfall model article. I haven't considered the others listed at the start of this section, but it seems reasonable to start with the list I mentioned. If there is consensus I'd be willing to start on these changes fairly soon. --David.alex.lamb 05:03, 19 February 2006 (UTC)
    • The Process steps section of this article is also pretty much waterfall and needs to be generalized a bit to fit more models. --David.alex.lamb 00:42, 23 February 2006 (UTC)
  • Systems do not have to be made using software. I think its a good idea to put down the theory of how solutions are devised for problems in a System Development Process page. The fact that Project lifecycle and the system development process are almost synonomous with each other if you omit the fact that most (or all) systems are developed with IT solutions these days shouldn't mean that a generic entry shouldn't be maintained to detail the academic side of how and why systems are devised for problems. Definitely need a description of the different IT methodologies, maybe this is where articles like the Waterfall model article could be linked against. However, other software development methodologies should be included... the first ones that occur to me are RAD and the Extreme Programming methodology but there are other "Iterative" methodologies that should also be represented. Merging is good and is needed, but focusing on which pages have more results or more content doesn't mean they are more deserving of a page on their own. --Ansell 10:52, 21 February 2006 (UTC)
    • I agree there should be articles (or at least stubs) for all the "major" methodologies. To your list I'd add Spiral model. I'm not so sure about keeping the Project Lifecycle page, though I'd support reducing it to a stub for someone else to fill in later. --David.alex.lamb 02:18, 22 February 2006 (UTC)
      • There are existing articles for all the major ones. This article needs to be generalised a bit to fit arbitrary models, such as the open source model for instance, which may be able to be included in the current models but which should be stated on its own as well.
  • First of all, process and lifecycle are two separate things. Process is a series of actions taken to achieve a result. Lifecycle is the changes that happen in the life of things. Usually, lifecycle consists of stages or phases that reflect the major changes in the life of things. System is the thing we built and software development is the process to build a system. Like many other things, system could undergo stages initiation, build, maintain and eventually death. So, it has nothing to do with the software development process.

    Since software development usually managed as project, a project does have a lifecycle. This is where the software development lifecycle (SDLC) comes into the picture. To manage software development projects effectively, it would be better to adapt the project lifecycle with the software development process. Software development process largely depends on the development methodologies adopted for the project. The classical waterfall model would mean stages including initiation, analysis, design, development (construction), testing, implementation (deployment) and review.

    "System", "Software Development", "Process" and "Lifecycle" are different, but correlated, topics. They should be organized in a clearly defined hierarchy of topics.
    --Francis Law (talk) 00:53, 20 December 2007 (UTC)

[edit] The Software design article should be merged here

I can see that a lot of work has been done here, but we still have an article called software design which today contains only another enumeration of software development activities. Thus is appears to be both incorrect (in that it introduces many development activities that extend far beyond what most people would consider to be design) and redundant (in that this article already exists to introduce all the activities of software development). Therefore I have suggested it be merged here. I would consider doing the work myself, but I am already working on a rewrite of Web development and Web design articles. Chris Loosley 18:00, 27 December 2006 (UTC)

Oppose Merge: I agree that the page introduces many development activities that extend far beyond what most people would consider to be design. Design is only part of the development process, unless you are designing the process. The term was originally directed at software engineering, which is just a more rigorous form of design with more emphasis on the processing engine and efficient code than creativity or content. I originally redirected that term to user experience, because that is the only part of the software that a user need be concerned with aside from the price. But instead SteveMerrick made a separate page, listing "design" as a subset of the "design", contrary to set theory.
This article is too broad to say enough about user experience considerations. The main focus of the software design should be what the user gets out of it. Everything else is either business admin, production engineering, routine production, testing, or delivery. All of the above, including design, falls under the category of development. The software design page is now just a lesser version of this page. There's nothing there that isn't covered in this page. I suggest it be deleted altogether and the "software design" term be redirected to "user experience" or user experience design. Unless someone want's to rename this page "software design process", we shouldn't let such an important topic as user experience get buried in all the other development concerns. That would be as bad as merging the software development process article into a product development article. Oicumayberight 22:38, 27 December 2006 (UTC)
I don't really follow your arguments related to user experience, since the only reference to user experience on the software design page is in the sentence Software is generally written ... to provide users with an entertaining experience ... in the introduction. You also say: The term was originally directed at software engineering. Which term -- Software design? Chris Loosley 23:29, 27 December 2006 (UTC)
Yes. The term "Software design" was directed to "software engineering". Oicumayberight 00:38, 28 December 2006 (UTC)
You say that: The software design page is now just a lesser version of this page. There's nothing there that isn't covered in this page. I agree completely -- that was why I suggested merging it. You also say I suggest it be deleted altogether and the "software design" term be redirected to "user experience" or user experience design. Doesn't that amount to merging the contents of software design here? If so, why are you opposing the merge? Chris Loosley 23:29, 27 December 2006 (UTC)
It's not technically a merge if the page is deleted. It is technically a merge if the term redirects here. I'm opposed to redirecting "software design" to here. Oicumayberight 00:38, 28 December 2006 (UTC)
Software design is a subset of software development, not (as you pointed out) a subset of "design". So we should not have a software design page that describes the entire development process. If you want to see a software design page that has some special focus on UX aspects, I encourage you to write something about that. But that does not lessen the need to remove existing content that is NOT about software design. Chris Loosley 23:29, 27 December 2006 (UTC)
I think we are in agreement here. Content that is NOT about software design should not be part of a software design article. There should be a separate article for software design with emphasis on UX. I'm not enough of an expert to write the article. I only redirected it to user experience as a temporary solution with the hope that someone more knowledgeable would go into more specifics with a designated article. I just don't like the idea of "software design" redirecting here since there isn't much said about UX design in this article (not that there should be). If the term doesn't direct to the UX or UX design page, then it should be directed to a disambiguation page at least. Oicumayberight 00:38, 28 December 2006 (UTC)
OK. We agree. Someone should delete most of what's in the software design article today because it's not about software design. But we shouldn't delete the topic itself, and eventually, this article should include a link to software design. But first, someone should write a real article about software design, which includes coverage of the UX aspects. It seems that that editor just won't be us, at least not now. But I won't delete the "merge" templates yet, because at least they highlight the problem and point people here. So if anyone reading this discussion feels qualified, please work on this cleanup. Chris Loosley 06:12, 28 December 2006 (UTC)

[edit] Managing the merge/cleanup

We're going to have to eliminate a lot of weasel words, especially opinions stated as facts. --David.alex.lamb 00:52, 23 February 2006 (UTC)

I suggest using this topic for recording things people have done that require future action. for example

  • I just deleted the material on programming paradigms, which is now in the Software development process/Archive for later merge with the programming paradigm article. cross out this segment when you've taken care of this particular task. --David.alex.lamb 00:33, 23 February 2006 (UTC)
  • There is a big chunk of material towards the end of the archive (several sections) that might be appropriate for the Waterfall process article, or it might be ignorable. Added this a day or two ago, forgot to comment about it. --David.alex.lamb 21:32, 23 February 2006 (UTC)
  • The archive now has a block on EUD which needs to go somewhere, perhaps in this article? --David.alex.lamb 21:32, 23 February 2006 (UTC)

I created a new Template:Software development process that I'd like to put on all the appropriate pages.

It puts a Category:Software development process on every page that includes it. Should this be the existing Category:Software development instead? I haven't looked through the old category thorougly, but I wonder if some of the topics there don't belong under 'process'? --David.alex.lamb 03:06, 23 February 2006 (UTC)

The merge of the specific articles previously listed via mergefrom links is complete, aside from the archived material. There remain the additional comments in the overall discussion, particularly Zondor's initial list of articles. --David.alex.lamb 03:11, 24 February 2006 (UTC)

Did we decide yet whether or not we are going to merge the software specific articles with the systems specific articles, I vote that we focus on software where it is stated and systems where they are stated, with links in between describing the similarities in common language and usage of the terms. Ansell 08:53, 25 February 2006 (UTC)

All the 'systems' articles mentioned above, including those listed by Zondor, turned out to be about this one process, SDLC, from the US Dept of Justice. So they stayed separate. --David.alex.lamb 00:25, 26 February 2006 (UTC)

[edit] Software Development Activities

There are numerous activities and tasks could be carried out in software development. However, they can be grouped into analysis, design, development, testing, implementation and management. Other activities or tasks could be listed or described under these main activities. For example, system and architectural design should go under the design activity.
--Francis Law (talk) 01:05, 20 December 2007 (UTC)

[edit] Design and architecture

Since Design and architecture was a red link, I'm changing the link to Software architecture, per the listing in Template:Software development process. The text in that section formerly read as follows:

Design and Architecture
Design and architecture refer to determining how software is to function in a general way without being involved in details. Usually this phase is divided into two sub-phases.

The article Software architecture, however, talks about design and architecture as pretty much being the same thing, or being intertwined. I'm sure that every methodology comes up with different names for similar processes, so I'm not sure if there's one single "right" answer, but I'm just going to be bold and make this edit. --Elkman - (talk) 05:42, 18 March 2006 (UTC)

[edit] Six Sigma

The "Six Sigma" paragraph under "Processes and meta-processes" states specifically that it doesn't have anything to do with software development. I believe we should remove it. --Stephen e nelson 03:57, 21 September 2006 (UTC)

[edit] Processes and meta-processes

This is an important topic, but does it necessarily belong in this article? The meta-processes (at least CMM) are for rating an organization's overall process management, not directly about a specific software development process. Certainly putting this section at the top is confusing and conflates two different topics. --Stephen e nelson 04:05, 21 September 2006 (UTC)

[edit] Process Models is driven by Software Crisis

in section Process Models it is writen "With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management is proving difficult." is this a fact ? look at The Standish Report: Does It Really Describe a Software Crisis? DoronAbram 16:22, 17 October 2006 (UTC)


[edit] Formal Methods

Hm, why is Formal Methods included on this page? It is a wonderful topic, but it is a development technique, rather than a development process. I propose that it can be omitted here user: Michel


[edit] Relationship

Hm, what is the relationship bewteen software development process and project lifecycle? Much duplication between these pages, needs to be clarified. - Guppie

Also, what is relationship between methodology and software development process?

It all comes down to definition. Project lifecycle is to with project, not necessarily software. And software is often only one component of a system (requirements definition, analysis, design, hardware, network infrastructure, disaster recovery, operations manuals, user manuals, marketing, training, etc etc). And a methodology can apply to any one or any subset of all these. Or to the project. You could even have a project to develop a methodology. We have different words for different things! Luckily. Paul Beardsell 16:45, 20 Feb 2004 (UTC)


A life-cycle organises the various processes, methods and sub-components and is mainly focused on the order and priority with which they should be completed e.g. when to design, when to develop, when to test (kind of like an animals life-cycle: birth, growth, adulthood, old-age, death). A methodology on the other hand defines exactly how the project and its sub-components should be carried out (how often the whole team should meet, who's in charge of each bit, who keeps tabs, how new feature requests should be handled etc). Specific methodologies are often used with specific life-cycles (i.e. evolutionary and iterative life-cycles use more agile methodologies whereas waterfall life-cycles use more traditional and structured ones. Canderra 00:09, 7 December 2005 (UTC)


Please don't be overzealous and merge methodology into this article - methodologies are different to processes. A process may be something like waterfall or spiral, a methodology may be something like an object oriented design methodology or an executable uml methodology. Methodologies are not the same thing as processes, therefore, please don't merge these articles. GeorgeBills 17:39, 25 April 2006 (UTC)

[edit] Test effort

A link was made to test effort, since the development process also influences testing a lot. BTW: why should testing and development be seperated? :-) --Erkan Yilmaz 15:46, 28 October 2006 (UTC)

[edit] Should this whole article be merged with "methodology"?

Is there a difference between a software development's process and a Methodology (software engineering)? XP, for instance, is defined as a methodology but categorized as a process. What about a "software design approach" such as Model-driven architecture?

I'm also confused by the overlap between different methodologies. For instance, is Agile a model/process/design approach or is it a family of models/processes/approaches that include Extreme Programming? Is Extreme Modeling part of Extreme Programming, or is it seperate? What about Model Driven Architecture? I'd really appreciate it if someone could clear this up for me. --Logomachist 03:33, 5 January 2007 (UTC)

[edit] TDD material

The final two paragraphs in Iterative processes probably belong on this page, as a discussion. I don't see any sources cited; these are philosophical arguments, and probably violate WP:NOR. Partisan wrangling about the merits of one approach over another don't belong in a Wikipedia article. Please try to provide some well-sourced explanations of the approaches and concepts, or remove the posturing before an exclusionist looks at this. Trevor Hanson 05:12, 24 May 2007 (UTC)

[edit] Functional Specification effort estimation

How do we estimate the effort for preparing the functional specifications document based on the requirements ? —The preceding unsigned comment was added by 192.193.164.8 (talk) 06:41, August 23, 2007 (UTC) --192.193.160.8 10:25, 24 August 2007 (UTC)

This probably isn't the right place to discuss this, but there is no correct answer. Depending of the project structure and the type of software product you are making, the importance of an FS will vary. A telecom network solution, for example, may have several sub-projects that need to coordinate, in which case an FS (or several such specs) can be used as a tool to synchronize effort. A small in-house project using a light-weight process might dispense with explicit FS documents altogether.
Before you can estimate how much time to spend writing an FS (or any other spec. for that matter), you should think about what it will be used for (synchronizing teams, negotiating scope, input to user documentation, clarification for outsourcing etc.) Once you know that, you should have a better idea of how long it will take, and when you will need it. The other matter is how much time you can afford to spend on the FS. Remember that implementation and test are the most risky and time consuming parts of any project. If you spend two weeks on an FS and only prevent a week of wasted implementation effort, you've scheduled too much time. That tradeoff is difficult to calculate in advance, but it is worth thinking about nevertheless. --ChrisSteinbach 12:07, 24 August 2007 (UTC)

[edit] Proposed refactoring with Methodology (software engineering)

I see above in the "System/Software Design/Development Process/Life/Cycle Merger Discussion" section that some tremendous work has gone into refactoring several similar Wikipedia articles with this one. Well done! I'd like to propose an additional refactoring (though not a merge): this article and Methodology (software engineering).

Despite possible semantic disagreements about "process" vs. "methodology," the presentation here on Wikipedia is pretty clear: "process" is the set of steps that go into designing a software system, while "methodology" is a formal description of what should be performed during each of those steps. There is already an article about methodology: Methodology (software engineering).

As such, the discussion of formal methodologies at the top of the "Processes and meta-processes" section in this article feels premature. Also, the "Process models" section at the bottom is better served by being in the Methodology (software engineering) article.

I propose the following. (I'd be happy to implement this as well. I wasn't sure how far WP:BOLD should be taken, so I thought I'd solicit feedback and work towards consensus if there's disagreement...) New structure of this article:

  1. Introduction
  2. The current list of steps ("Domain Analysis", "Software Elements Analysis", et al.) minus the discussion of formal methodologies
  3. Introduction to formal methodologies, with a link to Methodology (software engineering)
  4. Possibly a brief mention of popular methodologies (e.g. waterfall and iterative,) with links to their respective articles

The discussion of formal methodologies in the current "Processes and meta-processes" section would be moved into Methodology (software engineering). Any text removed from the brief mention of popular methodologies would be moved into their dedicated pages.

Thoughts? Thanks! WalterGR 16:43, 4 November 2007 (UTC)

(Also, it'd be nice if the "Models" text in the sidebar linked to Methodology (software engineering), but I can't figure out where the markup for that sidebar lives...) WalterGR 16:45, 4 November 2007 (UTC)

[edit] Paragraphs on TDD

Having gone through several methods including TDD, it doesn't appear that the author of the those paragraphs understand how TDD works. I also don't see much in the way of qualified references, which leads me to believe that I'm reading opinion.

Maybe a quick comparison of the process relative to others and the outcome of using it would be enough for the article.

Regardless, it needs some revision.

brill (talk) 20:12, 20 May 2008 (UTC)