Talk:Software development process/Archive 2

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

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)

Object oriented systems development?

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

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)

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)

Wikification

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

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)

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)

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)

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)

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)

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)

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)
  • 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)
  • Oppose -- It seems to me that these two articles should most definitely be seperate. As the first sentence says this is about the development of an information system An IS is more than just software and systems development methodologies as described in this article are concerned with this broader approach. My suggestion would be to rename this article Systems Development Methodology and to clarify the differences between the two terms. Catkins in nz (talk) 02:19, 22 July 2009 (UTC)

Six Sigma

...isn't a model. Plus, does it really belong in an article about "software development process" when its own reference says (sic) "really doesn't apply to software development yet".

Jrbirdman (talk) 17:47, 25 August 2009 (UTC)

Implementation: Software engineers or Programmers?

I strongly believe that this is the job of a Software Engineer, and this can be seen in references in many locations. Using the term "computer programmers" is incorrect because it indicates that there is no focus on the development lifecycle or process during the implementation phase, which is wrong. Programming is just one of many tasks of a software engineer, so it is certainly appropriate to say Software Engineer here. --Mpdelbuono (talk) 19:16, 25 November 2009 (UTC)

"Software engineers" are not certified in some countries or states/provinces. If the term "computer programmer" is too weak, perhaps "software developer" would work better. "Software engineering" does not really exist, it's a term that describes things that are also done by (good) computer programmers and computer scientists (testing, debugging, requirements-gathering, etc.) I consider it redundant, misleading and I find it promotes arguments where there should be none (i.e. software engineers vs. computer scientists vs. programmers vs. software developers).
So my proposal is to compromise and use the title "software developer" and have it perhaps wiki-link to the software "engineer" page. --OMouse (talk) 19:20, 26 November 2009 (UTC)

Lack of verifiable references

The lack of verifiable references in this article is likely due to the lack of accuracy. The definitions sound as though they've been written by folks who favor a particular view. Reference to DO-178B in formal methods even lacks a foundation in truth and accuracy.

Make this article meet Wikipedia guidelines for verifiability or put a disclaimer on the opening page that warns readers about the lack of verifiability.

(k.p) 97.122.82.215 (talk) 11:43, 4 December 2009 (UTC)

Software Package Development Process

What about a discussion of software package development processes? I'm not an expert is software development. Instead, I'm a statistician who is very familiar with the standard process used for package development for R. I've looked for comparable systems with other languages (Matlab, Perl, Python, C, C++) and have not found anything. Key features of this process for me include co-development of documentation and code, with the documentation including rudimentary unit testing. I believe this formal process and the Comprehensive R Archive Network of contributed packages have been largely responsible for the roughly exponential growth in the use of R. The one weakness I know is the lack of any formal computation of code coverage statistics by unit test. This could be added, e.g., to a package like RUnit, but it seems not yet to have been done.

Comments? DavidMCEddy (talk) 06:16, 16 April 2010 (UTC)

Proposal to merge Software development methodology here v2

I propose merging Software development methodology into this article. I note that it has already been discussed here and here. Sadly those discussions didn't reach much of a conclusion so I would like to start the discussion again. Yaris678 (talk) 19:34, 26 January 2011 (UTC)

  • Support merger as proposer. Yaris678 (talk) 19:34, 26 January 2011 (UTC)
I have commented on this, I think, several times that there is a fundamental difference between the process and the methodology. I have argued before that it makes more sense to merge the software development and the software development process articles. -- Mdd (talk) 19:19, 27 January 2011 (UTC)
On the face of it, it seems to make sense to merge in software development too. What is this fundamental difference between the methodology and process articles? Is it to do with the articles as they are or the articles as you think they should be? The articles as they are cover very similar ground. Yaris678 (talk) 20:31, 30 January 2011 (UTC)
There are three articles which talk about three close related subjects from three different angles. For outsiders in the field this can be a advantage, and this will give us three different possibilities to explain. I think it is an illusion that one big article can explain all. You should take a look at all the redirects to these articles. In the field there are dozens more terms in use. -- Mdd (talk) 11:15, 9 February 2011 (UTC)
  • Support merge. These two articles are about the same topic and cover some of the same content. This is an encyclopedia, not a journal or reading list, so it doesn't need multiple articles on the same topic from different angles – they're called content forks. (If the specific terms aren't exact synonyms, just choose the best name according to WP:Article titles.) --Pnm (talk) 18:36, 12 February 2011 (UTC)
What is your opinion about merging the software development and the software development process articles? -- Mdd (talk) 15:49, 14 February 2011 (UTC)
I'd be fine with merging them. However if the Software development article grows substantially, I could see the need to split them back out again at a later time. --Pnm (talk) 01:40, 16 February 2011 (UTC)
  • Oppose this merger, but support merging software development and software development process. Software development methodology is a different thing, and should cover things like the waterfall method, spiral method, etc., which don't belong in the software development or software development process articles. Spock of Vulcan (talk) 18:47, 15 February 2011 (UTC)
    • Hey! I'm fine with that too, so long as that content is removed from the other article (leaving just a summary). --Pnm (talk) 01:40, 16 February 2011 (UTC)
      • For the record. I already merged those two articles once in 2008, see here. This lead to quite some discussion, see here. -- Mdd (talk) 18:31, 28 February 2011 (UTC)

I removed the merge proposal (for now). There is neither any consensus about this nor any activity to discuss this any further. -- Mdd (talk) 11:32, 18 March 2011 (UTC)

Merging Code and fix to this article

Code and fix is not very well-sourced or neutral. However, a quick Google search reveals that it's pretty much what the page says it is—an example of how not to do something, as opposed to an actual software development model. I think we should either merge that page to the Software Development Models section of this page, or simply remove that page. wctaiwan (talk) 06:47, 5 April 2011 (UTC)

  • Support merge. The Code and fix article defines an informal method of software engineering. As such, I propose that a new section is added to Software development process which defines the informal methods used in software engineering. The old article should then redirect to this article. JohnQED (talk) 21:31, 7 April 2011 (UTC)
  • Support merge. Don't see much potential for expansion as-is. --Fang Aili talk 20:50, 15 April 2011 (UTC)
  • Support merge with redirect. Gierszep (talk) 02:35, 21 April 2011 (UTC)

Thanks for your comments. I merged the stub here. -- Mdd (talk) 12:11, 21 April 2011 (UTC)

Processes models or process models?

It says in the intro: "...There are several models for such processes...", but in Scacchi, Walt. Process Models in Software Engineering. 2001 and in "Sommerville, Ian. Software Engineering - 9th ed.. Addison-Wesley, 2011" they call that "process models". — Preceding unsigned comment added by Marcpedian (talk • contribs) 11:53, 21 February 2012 (UTC)

I see no problem here. One process model can model multiple processes. Perhaps you confused by independent noun and verb usages of the same word. Or maybe I misunderstood your question. Jojalozzo 16:05, 21 February 2012 (UTC)

Seriously?

Do we really need a citation to justify the statement that, "software is only effective if it is used correctly"?

I will admit I'm not the most experienced in writing this type of article, but on the surface at least it looks like someone got a little carried away with their criticism. Or perhaps the citation was meant to cover the assertion that support and training makes for more effective use of a given software product. Still, even for that, requiring a citation looks a little excessive to my eye.

Please tell me if I'm wrong about this. Educate me!

Thanks...

-Dw — Preceding unsigned comment added by Dwandelt (talk • contribs) 17:05, 25 May 2012 (UTC)

Copyright problem removed

Prior content in this article duplicated one or more previously published sources. The material was copied from: http://www.nh.gov/doit/internet/standards/documents/AppendixE-SoftwarDevelopmentMethodologyReference021805.pdf. Copied or closely paraphrased material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. Dpmuk (talk) 23:59, 17 December 2012 (UTC)

Code and Fix neutrality

The section on "Code and Fix" sounds like a harsh criticism of unplanned development rather than an informative analysis. It makes it sound like any code written without prior planning is going to be poorly written. We can debate all we want about the merits of proper planning, but at the end of the day, there is no justification for generalizing it like that. The section should be revised. 24.245.8.146 (talk) 18:02, 26 August 2013 (UTC)

Merger proposal

The two pages Software development methodology and Software development process appear to cover almost the same topic. Since the former is (IMHO) the better article, I suggest a merge to that article.

Murray Langton (talk) 09:30, 2 November 2013 (UTC)

Is it software development process or methods of software development

The page heading and the content do not correlate with each other properly. The software development process includes planning, requirement gathering, prototyping, designing, development, testing, documentation, deployment and maintenance. However, the page details about type of software development methods. Author needs to review heading of page. — Preceding unsigned comment added by 182.72.49.82 (talk) 10:04, 17 September 2015 (UTC)

Expert request

I'm making some changes, and going to remove this notice at the same time.

Mixing software development processes (which this article should be about) with programming paradigms and tools, which could be a subsection, but should not be listed as emerging examples in the history of software development processes. Mixing specific methodologies or family of software methodologies or processes (like Agile) and a general characteristic of software methodologies (incremental, iterative, sequential, etc), e.g., Agile family of methods are iterative and incremental. The following sections must be structured better: maybe it could be split indeed in specific software methodologies (or family of methodologies) and characteristics (or approaches, which is also not the best title for this subsection, which should be called 'examples' or 'specific software development processes') common to software methodologies. Is this a software development process, so that it deserves to be even mentioned in this article?.

Power~enwiki (talk) 20:45, 12 July 2017 (UTC)

Structuring code v. structuring teams

Structured programming, for example, is a way of structuring software code. Scrum (software development) is a way of structuring an organization of software developers. I believe this article is about both, but it should explain which are which. Power~enwiki (talk) 03:10, 13 July 2017 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Software_development_process/Archive_2&oldid=1176324621"