Jump to content

Talk:Software development process

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Srfleckenstein (talk | contribs) at 14:59, 29 May 2009 (Undid revision 293105647 by SineBot (talk)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

Object oriented systems development?

I would like to see more on this topic and UML --Dan|(talk) 19:07, 19 June 2008 (UTC)[reply]

Iterative processes needs restructuring

I added the restructuring tag to the mentioned section. One could add "Advantages/Criticism" sections instead of them mentioned in a single lump of text. Honestly, I think the advantages mentioned are applicable to Software development processes as a whole and not merely on iterative processes but that's another story.--147.197.215.16 (talk) 17:27, 27 June 2008 (UTC)[reply]

I concur with the need for restructuring this section. I believe this article is a summary of software development processes and that there are individual articles on each of the different "schools" of development as found in the titles for each of the "paragraphs." The justifications, statistics, etc., for each of these processes should be moved to those individual articles and the summary nature of this article retained.
Softtest123 (talk) 15:15, 7 August 2008 (UTC)[reply]

.net

what is .net frame work

.net is network enabeld technology

.NET is a Microsoft branded software development platform/framework/API... Need to discuss it's advantages and disadvantages relative to alternatives.

Wikification

I started wikifying this article using the computer science template as an example. -- Marcel Douwe Dekker (talk) 23:52, 9 October 2008 (UTC)[reply]

Some text removed

I skipped the following text from the article:

While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.
Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer. The approach can also be very expensive if iterations are not small enough to mitigate risk; akin to... "If you don't know what kind of house you want, let me build you one and see if you like it. If you don't, we'll tear it all down and start over." By analogy the critic argues that up-front design is as necessary for software development as it is for architecture. The problem with this criticism is that the whole point of iterative programming is that you don't have to build the whole house before you get feedback from the recipient. Indeed, in a sense conventional programming places more of this burden on the recipient, as the requirements and planning phases take place entirely before the development begins, and testing only occurs after development is officially over.
In fact, a relatively quiet turn around in the Agile community has occurred on the notion of "evolving" the software without the requirements locked down. In the old world this was called requirements creep and never made commercial sense. The Agile community has similarly been "burnt" because, in the end, when the customer asks for something that breaks the architecture, and won't pay for the re-work, the project terminates in an Agile manner.
These approaches have been developed along with web based technologies. As such, they are actually more akin to maintenance life cycles given that most of the architecture and capability of the solutions is embodied within the technology selected as the back bone of the application.
Refactoring is claimed, by the Agile community, as their alternative to cogitating and documenting a design. No equivalent claim is made of re-engineering - which is an artifact of the wrong technology being chosen, therefore the wrong architecture. Both are relatively costly. Claims that 10%-15% must be added to an iteration to account for refactoring of old code exist. However, there is no detail as to whether this value accounts for the re-testing or regression testing that must happen where old code is touched. Of course, throwing away the architecture is more costly again. In fact, a survey of the "designless" approach paints a picture of the cost incurred where this class of approach is used (Software Development at Microsoft Observed). Note the heavy emphasis here on constant reverse engineering by programming staff rather
TDD proponents tend to dispute the above analysis. Classic TDD suggests that any serious approach to TDD uses heavy refactoring, and that the primary value of TDD is to enable the kind of refactoring and light-up-front-design that critics might suggest to be problematic.than managing a central design.

Further comments

I skipped these text from the article because I think this article is giving an overview of the software development process, and these texts are much to detailed. Maybe they can be readded in the specific articles them selves, where they should have been written in the first place. -- Marcel Douwe Dekker (talk) 23:52, 9 October 2008 (UTC)[reply]

Recreating this Software development process article

At the moment this Software development process is a redirect to the Software development article. I will try to create a new article there, using the German Wikipedia artikel as an example.

Before I start I want to explain a a few strange things, I noticed are here:

  • Merging this article into the Software development article, I think, made that article complete. So the question is where this article should be focussed on?
  • The correspronding articles in other Wikipedia's all have different names and intentions. There doesn't seem to be one general concept here...!?
    • The German article here is titled "Vorgehensmodell zur Softwareentwicklung" which translate to "Process model of sofware development."
    • The Dutch article is titled "Softwareontwikkelmethode", which is translated "software development method"
    • The French article is named "Cycle de développement", which translates to "development cycle"
    • The Italina article is named "Ciclo di vita del software", which is "software life cycle"
  • There are a lot of articles redirecting here related to software development method, development cycle, software life cycle...etc.

Now I think a renewed article should more focuss on the perception of the "Software development process" (in different concepts, models and methods), instead of the description of the "Software development process", which was present in the past article and now moved to the Software development article. -- Marcel Douwe Dekker (talk) 18:35, 22 October 2008 (UTC)[reply]

Articles redirecting here

Now the main articles (still) redirecting here are:

I think a new article here should and could focuss on these concepts.

On the other there are still some articles present:

-- Marcel Douwe Dekker (talk) 18:20, 24 October 2008 (UTC)[reply]

Now a new Software development methodology is constructed, and some of the articles have been redirected there:
This is a first step. Some other articles listed above should be redirected else where.
-- Marcel Douwe Dekker (talk) 15:49, 27 October 2008 (UTC)[reply]

Description of CMMI

Capability Maturity Model Integration is a framework for process improvement. Essentially the CMMI is composed of several process areas with a list of things that a mature software process will be managing. The CMMI does not prescribe a process, it is best described as a means of evaluating the process you have. The CMMI organizes the areas that a mature software process has into five levels. The first level being virtually no process whatsoever, the fifth level being a self managed and evaluated process. The I for integration comes in because the processes are meant to be institutionalized within a company. The company integrates the projects at a process level--not that they have to follow the same process, but that the tools for customizing the processes in place are made available. Among the disciplines that CMMI promotes is using metrics to evaluate the process. For example: if you discover that it takes the average peer review 8 man-hours and only 3-5 cosmetic bugs are found, but using automated unit tests costs 6 man-hours per and catches up to 20 programmatic bugs you have proven that the automated unit tests are providing more value than the peer review. The metrics allow you to make intelligent decisions on how you implement the different process areas, and you have empirical proof that mid to upper management understands.

As described, it sounds as if CMMI were a model for a process. It is a model for process improvement, and does not prescribe any process at all. In fact, you can stretch agile to fit CMMI level 3 [1]. Bloritsch (talk) 02:46, 20 April 2009 (UTC)[reply]

There is a Wikipedia Capability Maturity Model Integration article. Now I don't exactly understand the point your are trying to make. If you have a problem with the current description, maybe better just propose an alternative. -- Marcel Douwe Dekker (talk) 07:59, 20 April 2009 (UTC)[reply]

Proposal to merge Software development methodology here

Today User:Beland has proposed to merge the Software development methodology here into the Software development process article.

  • Oppose -- both subjects are notable enough to justify two seperate articles, and I think there is a notable difference between the two subjects: There is one process with different stages, and there are a series of methodologies to control this process. This article focusses on that one process, and the other article focusses on those different methodologies. -- Marcel Douwe Dekker (talk) 18:34, 13 May 2009 (UTC)[reply]
  • Support -- While I agree with Mdd on the denotation of the two terms, the connotation in practice is that they are the same. Therefore they should be merged. Lwoodyiii (talk) 03:49, 28 May 2009 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Software_development_process&oldid=293106210"