Talk:Software engineering

From Citizendium
Jump to navigation Jump to search
This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
Catalogs [?]
 
To learn how to update the categories for this article, see here. To update categories, edit the metadata template.
 Definition The process by which requirements are translated to software design and testing specifications, and reliable and timely computer code is produced, so as to fit the needs of potential users and to be maintainable for future demands [d] [e]
Checklist and Archives
 Workgroup categories Computers and Engineering [Editors asked to check categories]
 Talk Archive none  English language variant British English


Rewrite 21st October 2007

I rewrote the article to focus more specifically on software engineering and moved some of the previous content into stubs for other articles. I hope some of you like it. Please discuss how the article can be improved.

I'd love to see this article get approved status soon as it is a major subject within the Computers workgroup category. Is it ready now? Let's get things moving in that direction. --Mark Jones 19:50, 21 October 2007 (CDT)

SE is a complex field, I'm not sure if this article does it justice.

I'm a software engineering student, and it's a huge field. I've glanced through the article between classes and I plan to read it soon, and it seems solid. To be honest, I think it might be hard to write one entry that will please everyone, so I think there is a need to have a lot of related pages discussing the topics that can only be summarized in this article.—The preceding unsigned comment was added by Thomas Owens (talkcontribs) 07:58, 22 October 2007 (UTC)

lacking parts

It seems early important steps in SW engineering are lacking methods like Structured Programming, Predicate Logics, System Development Management are not even named while they have played an important role in the development of methods to increase efficiency and maintenance of software development.—The preceding unsigned comment was added by Robert Tito (talkcontribs) 08:12, 22 October 2007 (UTC)

I, too, think this article is lacking in parts. Like any form of engineering, software engineering is based, in part, on scientific principles; those should be discussed, at least briefly, in this article. There also seems to be apparently contradictory (and poorly cited) bits on the origin of the term "software engineering". There should also be discussion of several different arena for software engineering, such as shrink-wrapped commercial software, enterprise software, embedded software, and (forgetting the correct name) the high-reliability software required for avionics and medical devices. Anthony Argyriou 11:47, 22 October 2007 (CDT)
Most of the topics mentioned above would be more suited to subtopics and linked from the main article in some way. Also, Anthony, can you be more specific about which parts are contradictory and poorly cited so that I, or someone else, can fix it? Many thanks. --Mark Jones 14:34, 22 October 2007 (CDT)
  1. The term was coined at a conference whose title included the term.
  2. Transistor revolution? How about integrated circuit revolution?
  3. in an effort to formulate useful theories, methods and techniques to address the problem of the inherent complexity of software You discuss some results and techniques, but almost nowhere address the theories of software engineering.
  4. many early practices and principles were imported directly from other engineering disciplines such as construction engineering. Which ones?
The scientific, economic, or managerial principles behind software engineering do need to be covered, if only briefly, in this article. The geotechnical engineering article would be incomplete without a discussion of soil mechanics, similarly, this article is incomplete without discussion of the theory behind software engineering. Also useful would be a discussion of how much software is developed with formal software engineering guidance, and how much isn't. Anthony Argyriou 22:26, 22 October 2007 (CDT)
Transistor revolution? How about integrated circuit revolution? Oops, sorry that was my careless mistake. I will correct the article. Thanks. The other stuff you mentioned I will put some thought later today into what key stages of the evolution of software engineering should be included and add them in. I wanted to at least make a start and get people thinking and working on the article (which I am glad the current article is doing!). I'm sure a lot more could be said—probably by others. I would like people to give some thought to how much should be mentioned here and how much to link to in subarticles as they write it though. It was mentioned in some early discussions on Citizendium that our approach should not follow that of many Wikipedia articles of cramming all the information into the top level articles but that we would make proper use of subpages linked to (briefly mentioning salient points is good) from the main article. I also think articles about a topic should not develop into a "history of..." article, which sections often tend to dominate the article but which answer a somewhat different, if closely related, epistemological question; these are better suited (in my opinion) as a separate, linked-to article. I tried to make this article answer the question "What is Software Engineering" in terms of essence, and the milieu and rationales that caused it to come into being rather than telling the whole story from start to finish. I am sure we will get the right balance in the end, though, if need be through trial and error. Thanks again for the clarification. Please add anything to the article you feel is missing that should be there. --Mark Jones 06:25, 23 October 2007 (CDT)

Requires the major models that comprise Software Engineering

This is a good start. The above comments might be helped with including the major models and frameworks commonly used. These may lay the foundation for a better understanding of the field. It might also help to have some of its leading minds listed. —The preceding unsigned comment was added by Andrew M. Colarik (talkcontribs) 19:37, 22 October 2007 (UTC)

Thanks. I think things like models and frameworks are best mentioned (and linked to as subtopics) to the not-yet-created article Software development process which I have linked to in the main Software engineering article.

Articles not meant to be exhaustive

Thanks for the feedback. In answer to some of the above comments, remember, the article is meant to provide an introductory overview of the subject to a layperson not exhaustive coverage (which would require an entire book!). The idea is to provide links to subtopics so people can drill down to the finer details if they so wish. It was decided fairly early on that this was going to be the best approach for writing articles for Citizendium, not try to cram all the details into one article (as is the case in many Wikipedia articles). Many of the lacks cited above can be solved by writing sub-articles and adding links to this article. Remember, some topics will be subtopics of subtopics so they don't all need to go in the software engineering article. --Mark Jones 14:25, 22 October 2007 (CDT)

For example, this article already links to Software development process which is a subtopic of the article. This subtopic article should describe an overview of process models and link to specific models as subtopics. These models should be described fully on their own pages. This way the lay-reader who has only a fleeting interest in Software Engineering is not overwhelmed by too much detail (that they possibly won't understand or care about) in main article but can drill down to specific topics he or she is interested in. --Mark Jones 15:03, 22 October 2007 (CDT)

I completely agree with the intention not to overdo and be exhaustive BUT since this is the history of the topic it needs placing things in historic perspective. It makes no sense to give attention to outdated methodologies like SDM but they need being mentioned as well as why they were intensively used. The more modern methodologies (be it UML or OO methodologies) do need their own subpages but the old things, I don't think so. Maybe for the interested but not for the lay man taking a peek to see how and what this engineering is all about. Robert Tito |  Talk 
I don't think this article is finished but I did wonder about how much to include in the history section — although, it is a relatively young discipline, an incredible amount of activity has gone into the development of software engineering disproportionate to its age and there is potentially a lot of information that could be included; it could get very long for just an overview. I wondered whether, perhaps, the history of software engineering deserves to have its own article (as History of computing)? We can discuss and decide what else could be included here. I welcome other people's input. --Mark Jones 16:45, 22 October 2007 (CDT)

There already is a history of computing article but that is about generic computing, this article is about the art to make software end the used technologies and methodologies. I see no reason not to include it in this article since you started this article from the past - it seems justified to include all of the past and nut just bits and pieces. Only some items would do damage to the value of this article where it better is to have a somewhat longer article that has link to in depth articles explaining topics but not mentioning main street methods and technology in a historic way would hurt the article more. Besides the reader will get the idea how and why things developed as they did. Forgetting things because we want a short article would do the topic harm. Robert Tito |  Talk 

I am aware the history of computing article already exists, I just used that as an example of how the history of a topic can be covered more extensively in its own separate article. Before reading your comment, I just changed the title of this section to "Emergence of software engineering" to reflect its current more limited scope. If this section does develop into a history we can change it back. I do suspect, though, that a full (or even partial) history of Software Engineering might be too much too include in an overview article and a link to a separate "history of..." article might be a better way to approach it. --Mark Jones 17:16, 22 October 2007 (CDT)


Text here was removed by the Constabulary on grounds of civility. (The author may replace this template with an edited version of the original remarks.)

You mention the start an early step in 1987 where the first real need for this systemetic approach was defined during the development of for instance FORTRAN, quite some years before that. You can't place software engineering on the map without its context and for that reason its history. It came from somewhere and it evolved to something due to intermediate changes - these are an integral part not something irrelevant. Robert Tito |  Talk 


A comment here was deleted by The Constabulary on grounds of making complaints about fellow Citizens. If you have a complaint about the behavior of another Citizen, e-mail constables@citizendium.org. It is contrary to Citizendium policy to air your complaints on the wiki. See also CZ:Professionalism.

I do, however, disagree with your assessment of both my reasoning and what I am saying—you may need to read my comments again. If I have said anywhere in the talk pages that something mentioned is irrelevant to software engineering, please point it out to me and I will probably recant it. What I have said, is that the design of wiki pages—and Citizendium in particular—is to provide introductory overview articles at the top levels and details in linked sub-pages. How much of the history, and substance, of software engineering is included here (or alluded to) and how much is linked to in subpages is what is being discussed here. This isn't leaving things out entirely or calling it irrelevant—it is just simply structuring information (wiki-style).
At the moment, the title was changed to reflect the current content. If you feel a history of software engineering is appropriate for the article, please write it in (or provide a draft here), change the title of the section back to "history of..." (as I previously suggested), and let us do the critique. Eventually, the article will be what it is meant to be with everyone's participation. --Mark Jones 19:10, 22 October 2007 (CDT)
Robert, you mentioned the 1987 date but this date is provided as the date a seminal paper was written by Brooks, not when the need for a software engineering breakthrough was identified. The paper reflects on past software engineering problems and breakthroughs (past and potential future) and considers which, if any, might solve the inherent problem in software development. It is also not in the history section so I am not sure what point you were making here as it is very pertinent for the section it is in. Can you clarify your point for me please? Many thanks. --Mark Jones 19:59, 22 October 2007 (CDT)

suggestion for resolving above issues (for now)

First: 1) I've got 24 years experience developing software in a variety of industries, half of which was spent developing telecom software in Bell Laboratories. I was a guinea pig for SE theories many times, and some of them, well, smell a bit. 2) I taught a grad-level SE course for 5 semesters recently at Upenn, so I've done a lot of reading in the field. 3) A search just now in the INSPEC database yielded up 89382 articles with "software engineering" in title or abstract. To me, that suggests that this field is just too big for one article. It requires many related subarticles.

The field of SE is as likely as any to test our ability to collaborate civilly here in Citizendium, for I have never encountered any more contentious field (even with all the politeness endemic to our profession). Here's a proposal for a way to go forward, at least temporarily. As with programming languages, how about: A LIST!

Let's have this article state something to the effect that "SE is a huge, complex field with many specializations. See the 'List of subfields in software engineering' for more information. Then each author, who feels that such-and-so is missing from this article, can go to the list and add A BRIEF DESCRIPTION (2 sentences or so) describing the missing thing, and then point off to an article saying much more about that thing.

In the meantime, we can work on polishing this article as a fair-minded introduction to a very complex set of topics, all of which sometimes are included in software engineering as well as other fields.

I'm going to go begin the list now, and link the article to it. Hope this helps.Pat Palmer 23:01, 23 October 2007 (CDT)

Thanks, Pat. I had foreseen the 'See also' section becoming something like this but 'List of topics in software engineering' is a much better title and likely to prompt a more exhaustive list.

good early draft

Compliments to the authors and editors who've contributed time and effort so far to this excellent early draft. I think there are quite a few things we can do to "seek balance" on potentially controversial elements (which are many in this field) and respond to some of the concerns mentioned in previous comments, without adding radically to the length of the article.

Fred Brooks

Fred Brooks later folded the "No Silver Bullets" into the updated edition of his seminal book, "The Mythical Man Month", a book so influential that it is considered by many to have jump-started software engineering as a field of study. The book debunks the usefulness of adding programmers to an already late project, and the "no silver bullet" opinion has to be taken seriously since, after 35 years of so-called "scientific study" of software engineering, projects still fail for many complex reasons (that scholars cannot even agree on). It seems to me that, though Brooks is "old news", no introduction to SE should fail to mention him.Pat Palmer 00:13, 24 October 2007 (CDT)

Intro to article

Though I do like the definition given in the article's intro, the introduction of the article might benefit from some kind of more explicit acknowledgement of a common source of confusion in software engineering. What makes software "good"? How many projects "fail"? (We'd need to give some evidence or references for that, too). What does it mean for a project to "fail"? Etc. "Goodness" and "failure" are inherently subjective kinds of things, and unfortunately parts of SE are subjective and thus subject to great debate. The top-level article could, in my opinion, contain questions and not exactly answer them (see Language for an example of this kind of approach). It might be a way to deal with issues that, otherwise, people will debate to death, and beyond.Pat Palmer 01:32, 24 October 2007 (CDT)

Some important topics for SE

  • The NATO conferences
  • Education
    • Graduate
    • Undergraduate
  • Key Concepts
    • Requirements Analysis
    • Modelling
    • Design Patterns
    • User-Centric Designs
    • Architecture
    • Process
  • The Debate
    • Is SE Engineering?

There is more, but that's a good start of the most important topics when talking generally about SE. Thomas Owens 11:09, 24 October 2007 (CDT)

The above list is from Thomas Owens. Funny, I would make a completely different list--and I imagine many of us authors would make completely different lists. It just delineates the difficulty of the field, and so I especially like the last suggestion ("Is SE Engineering?"). These are useful suggestions--I'm softening the intent just a bit by altering the section title.Pat Palmer 10:51, 24 October 2007 (CDT)
Well, to generate this list, I turned to my first-year SE textbook and notes and looked at what the common topics were. I think that these topics would be of interest to most people wanting to get the basics of SE. Thomas Owens 11:09, 24 October 2007 (CDT)
Nothing wrong with this list. And, if you look in another textbook, you will likely get a completely different list--see the Bibliography page for some other texts to check out. A really good place to put this list, for now, would be the List of topics in software engineering which I started last night. I hope it will be a place where we can capture everyone's suggestions, initially just listing them without evaluating them, and then we can do some journal searches and research and see which ones deserve to go into the main article.Pat Palmer 11:23, 24 October 2007 (CDT)

Correct location of NATO conference

As a resident of Garmisch-Partenkirchen, Germany, I feel I should point out that Garmisch ceased to exist as a separate entity in 1935. Although the city name is commonly abbreviated to Garmisch, including by NATO, e.g. USAG Garmisch, the correct name of the location of the software conference is Garmisch-Partenkirchen. Jay Proctor 17:09, 24 October 2007 (CDT)

Thanks, Jay. I corrected it. Please feel free to correct the articles directly. :) --Mark Jones 14:59, 25 October 2007 (CDT)

Modern-day software engineering section

I feel that this section currently says too much about the software engineering process which could/should be moved into its own article (which does not exist yet); a briefer overview of a single paragraph might be more in order. Additionally, I would like to give equal weight given to the other developments in the following subsection also in the form of a brief overview paragraph covering each. I would like to get some feedback from the community before going ahead doing this. If there are no objections I will make a change in 2 or 3 days time. --Mark Jones 10:00, 27 October 2007 (CDT)