Hello all,
I included (for now) a list of (one) techniques for software maintenance. In the future if some good souls were to add to the list, perhaps the list
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology
This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems
The content of IEEE 1219 was merged into Software maintenance on 10 August 2017. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. For the discussion at that location, see its talk page.
A fact from Software maintenance appeared on Wikipedia's Main Page in the Did you know column on 28 July 2024 (check views). The text of the entry was as follows:
Did you know... that some estimate that maintenance of existing software costs up to nine times as much as creating it in the first place?
Latest comment: 18 years ago1 comment1 person in discussion
Hello all,
I included (for now) a list of (one) techniques for software maintenance. In the future if some good souls were to add to the list, perhaps the list of techniques could be broken off into its own page, since the current page treats this subject (as it should) on more of a top-level. A couple more can likely be gleaned from the latest edition of Page-Jones, and maybe a few more from the Best Practices section of the book Rapid Development by Steve McConnell, and maybe from his other book Code Complete. I urge caution, since these practices could more properly fall into the program coding stage, or earlier stages. Vonkje 18:38, 10 Jun 2005 (UTC)
Latest comment: 3 months ago4 comments3 people in discussion
Please replace the content of the article with User:Buidhe paid/Software maintenace. Reason: rewrite based on better sources, add sections about the development -> maintenance -> obsolescence cycle, change cycles, workforce, etc. The current article is mostly unsourced. Buidhe paid (talk) 01:52, 7 May 2024 (UTC)Reply
The software maintenance categories are out of date compared to the new ISO/IEC 14764:2022 standard, which also includes additive as a maintenance category. — Preceding unsigned comment added by ~2026-30341-82 (talk) 16:26, 20 May 2026 (UTC)Reply
Wiki99 summary
Latest comment: 2 years ago3 comments2 people in discussion
Summary of changes as a result of the Wiki99 project (before, after, diff):
Complete rewrite of the article based on scholarly sources
Added sections about:
The process of how software goes from release to different cycles of maintenance and obsolescence
How software is changed during maintenance
Workforce
Research
Added information about maintenance of free and open source software
For other editors to consider doing in the future:
Help me get the article to GA status
Potentially expand with more content, if more sources can be found
Consider a merge with software evolution, since the difference is inconsistently defined, blurry, and many sources are about "software maintenance and evolution"
Oh no. You did it again. This is the second article I've found that you have hacked up. How many have you done? Please stop. You are doing the opposite of improving. You seem to have the best intentions, but your resulting work is not good.
I take issue with almost every sentence of the intro. I won't go beyond that with examples of your work since my blood pressure is already too high.
Software maintenance is often considered lower skilled and less rewarding than new development That's BS ... and depressing. Who considers id lower skilled? And many people complain that they hate their job regardless of what they do.
As such, it is a common target for outsourcing or offshoring Foolishness, everything is a target for offshoring.
Usually, the team developing the software is different from those who will be maintaining it nope.
The developers lack an incentive to write the code to be easily maintained crazy talk.
Software is often delivered incomplete and almost always contains some bugs that the maintenance team must fix commonly held thought that is basically BS ... and depressing ... how about we stick to facts
Software maintenence often initially includes the development of new functionality, but as the product nears the end of its lifespan maintenence is reduced to the bare minimum and then cut off entirely before the product is withdrawn. more non-factual, depressing, popular thinking BS
Each maintenence cycle begins with a change request typically originating from a customer. That request is evaluated and if it is decided to implement it, the programmer studies the existing code to understand how it works before implementing the change. Testing to make sure the existing functionality is retained and the desired new functionality is added often comprises the majority of the maintenance cost. in the dreams of process geeks; not reality
software maintenance is not as well studied as other phases of the software life cycle, despite comprising the majority of costs. Understanding has not changed significantly since the 1980s. really? we have studies showing we didn't study that? studies showing we know as much about maintenance today as we did in the 80s? more BS
Software maintenance can be categorized into several types depending on whether it is preventative or reactive and whether it is seeking to add functionality or preserve existing functionality. less than interesting or useful.
Stevebroshar, regardless of who is writing the article it needs to follow what reliable sources say about the subject. Most of the points above are supported by multiple sources and therefore should be included in the article regardless of what Wikipedia contributors think about them, although if you are aware of similarly authoritative sources contradicting those in the article, I would welcome that information. Buidhe paid (talk) 13:43, 24 June 2024 (UTC)Reply
Open source software workforce
Latest comment: 2 years ago6 comments3 people in discussion
I am also part of the Wiki99 project developing this article. Buidhe above did a major rewrite, and I think it looks great. The overall Wiki99 project has a theme of open source software. Buidhe did not readily identify this theme in the wiki literature review to develop this article, so I asked some academic colleagues to suggest a paper. Here is one that I like.
I would like to include content about maintaining open source software. These researchers interviewed people who maintain this kind of content.
Geiger, R. Stuart; Howard, Dorothy; Irani, Lilly (13 April 2021). "The Labor of Maintaining and Scaling Free and Open-Source Software Projects". Proceedings of the ACM on Human-Computer Interaction. 5 (CSCW1): 1–28. doi:10.1145/3449249.
Here is my own summary of the paper:
The team interviewed 37 developers for an average of an hour each
They attempted to recruit diversity in the interviewee pool, both in terms of demographics of the developer and the class of F/OSS project they maintained
Many of the interviewees reported that the project they maintained depended on volunteer labor
Differences between maintaining open versus closed software include the culture of workers getting paid by paying customers versus volunteer developers in a socio-technical system for non-paying users
Developing F/OSS requires significant socializing, trust, giving thanks, and community membership, including in volunteer contexts
Recognition can lead to F/OSS projects getting more support; lack of recognition even for popular projects can mean less support
Project coordination is a challenge when there are no staff for key elements of an ecosystem
Although this is an interesting study, I'm not sure about WP:DUE. I've tried to avoid citing primary sources, in part because of concerns about replication and generalizability. Additionally, I did add a couple sentences about FOSS projects that are already in the article. Buidhe paid (talk) 22:17, 10 May 2024 (UTC)Reply
Related to this issue is the wording of the Intro section, which is very commercially oriented; e.g., "software product after delivery", and "originating from a customer". BMJ-pdx (talk) 00:07, 29 July 2024 (UTC)Reply
Its fair to say that the sources are focused on commercial software. But open-source projects deliver software to users and take feedback from them. Buidhe paid (talk) 00:14, 29 July 2024 (UTC)Reply
I see that Buidhe changed the wording from "customer" to "end user" which is more aligned with the meaning of the cited sources. @BMJ-pdx: How do you feel about the term "software product"? To me it seems natural to use the word "product" to describe free services from nonprofit organizations, such as when a charity provides food and social support to people with little means. I collaborate with my local Code for America chapter and almost everything we do is free tech development for nonprofits which provide free services, and we call our software and the services offered "products". Do you have an alternative term suggestion? Thanks. Bluerasberry (talk)18:54, 29 July 2024 (UTC)Reply
Thanks for your consideration. I think "product" most often has a commercial connotation; e.g. from WordNet(r) 3.1: "commodities offered for sale". How about just "software" in place of "a software product"? BMJ-pdx (talk) 19:31, 5 August 2024 (UTC)Reply
GA Review
Latest comment: 2 years ago11 comments2 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Noting that I had forgotten about this, I'll try to get to it this week. (Feel free to ping me liberally if I don't) Sohom (talk) 03:09, 28 May 2024 (UTC)Reply
On reading through the article, one thing in particular jumps out to me. It feels like article sort of assumes that the waterfall model is the default (and only) model used in software development. The article very briefly mentions the fact that software is often delivered in a incomplete state nowadays but doesn't address the elephant in the room i.e. the fact that a lot of the software development that happens today happens in a iterative manner utilizing frameworks like the agile software development and often the maintainence phase is done alongside the rest of the phases.
My understanding is that waterfall versus agile methodology is more relevant to the pre-delivery software development, rather than the scope of this artile that is about post-delivery changes driven by change requests rather than requirements. Given that the definition for software maintenance is "the modification of a software product after delivery", agile or FOSS products that are delivered early and undergo refinement after delivery could also count as maintenance. However, it does not tend to be called maintenance in sources, making it harder to cover. Also, "the agile software development lifecycle lacks a dedicated maintenance plan" 2024.
I think that fact itself should be mentioned (that newer SDLCs do not actually have a maintainance phase at all)
The article should probably give some context on where/how the offshoring/outsourcing happens. Currently, the article has a slight bit of a globalization issue, as it mentions offshoring and outsourcing the maintainance of software to other countries without any context of which countries do it when I'm pretty sure it tends to be mostly the anglosphere.
I think you're correct that offshoring tends to be from countries with higher cost of living to those with a lower cost of living, but I'm having a really hard time finding sources that say this explicitly for software maintenance.
Added
that maintenance is not be practical or economical
Done
The section Alternatives to maintenance should probably be prosified with context on when those list options are chosen.
The source does not cover this information; I will look elsewhere. I do think that bullet points are appropriate because each of these does not have enough content to be a separate paragraph.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Did you know nomination
Latest comment: 2 years ago5 comments3 people in discussion
The following is an archived discussion of the DYK nomination of the article below. Please do not modify this page. Subsequent comments should be made on the appropriate discussion page (such as this nomination's talk page, the article's talk page or Wikipedia talk:Did you know), unless there is consensus to re-open the discussion at this page. No further edits should be made to this page.
@buidhe and Vacant0: book doesn't verify claim. It says that three of the four things to spend on are maintenance compared to one for development, and seems to imply that the levels of spending on each should be equal, but doesn't say at all that that's what happens in practice. We could go with the 90% estimate? theleekycauldron (talk • she/her) 04:53, 19 July 2024 (UTC)Reply
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.