Talk:Software engineering

From Wikipedia, the free encyclopedia

Contents 1 Previous comments 2 Collaboration of the week?? 3 Article improvement drive 3.1 First step: copy to a rework page 3.2 Second step: some section-reordering in Rework 3.3 Third step: coordinate Rework with previous discussion topics 3.4 Fourth step: find sections that can be moved to articles of its own 3.5 Fifth step: improve contents 3.6 Before-last step: coordinate Rework with newer changes in Original 3.7 Last step: replace Original by Rework 4 *whistles innocently* 5 July 26, 2005 Search Engine Results 6 Information Quality Management 7 Source for economic impact paragraph? 8 Process and methodology 9 What is a software engineer? 10 Relationship to (Dependency On?) Definition of Computer Software 11 Software engineering vs software architecture vs software design? 11.1 Answers to questions of life, the universe, and software engineering 12 State of the ART 13 Education 14 Reference, please? 15 Unsourced material about economic impact 16 #1 on Google 17 Applications or Systems? 18 Pervasiveness in missions requiring 'absolute' reliability 19 add'l comments 20 Advocacy definition 21 Questions from the jury 22 images

[edit] Previous comments

• Talk:Software engineering/Archive 1
• Talk:Software engineering/Archive 2
• Talk:Software engineering/Archive 3

To prepare the article improvement, I have moved the previous talk page to Archive 3. Nevertheless, the whole talk archive (1-3) should be reviewed along with the improvement. --Hans-AC ✉ 15:32, 26 May 2005 (UTC)

 

[edit] Collaboration of the week??

On May 20, 2005, I proposed Software engineering for the collaboration of the week. I was wrong doing so, because I did not obeye the rule, only nominate articles which don't currently exist or are stubs. Sorry.

Nevertheless, have a look at the comments by ZeWrestler, WB, and Dpbsmith. --Hans-AC ✉ 15:32, 26 May 2005 (UTC)

 

[edit] Article improvement drive

Reason 

There is a long discussion on the article with a lot of topics not cleared up to now. In my opinion, the article is not state of the art. It could be structured better and some sections could be moved to articles of its own. It should be a start page for all articles concerning with tthe topic and an introductory article for the WikiReader Software Engineering. Simultaneously, I propose a German collaboration (Qualitätsoffensive).

[edit] First step: copy to a rework page

I have just copied the whole original article to Software engineering/Rework.

Please feel free

1. to do your proposed changes at first in the Rework instead of the original,
2. to insert any inline comment and include those comments in /* */

/* like this */

Please contribute to the next steps! --Hans-AC ✉ 16:32, 26 May 2005 (UTC)

 

Don't you want to move all this stuff below to the Talk:Software engineering/Rework page? Or has the whole thing just fallen into disarray? Brent 01:47, 18 October 2005 (UTC)

[edit] Second step: some section-reordering in Rework

[edit] Third step: coordinate Rework with previous discussion topics

... in Archive 1, Archive 2, Archive 3

[edit] Fourth step: find sections that can be moved to articles of its own

[edit] Fifth step: improve contents

This page could definitely be improved in the front-matter right at the top. Software Engineering, as opposed to the formal discipline of Computer Science, puts much more emphasis on the full-lifecycle of development and (potentially long-term) maintenance of a software product. Whereas most Computer Science-trained folks (those with undergraduate degrees in CS) tend to focus on the programming task -- and Computer Science as a discipline focusses on all the theoretical underpinnings of that task such as algorithm development, language specification, compiler construction, etc.,-- the formal discipline of Software Engineering sees programming as only one aspect of the effective development of a software product. SE looks at Requirements Engineering, Software Design (high-level and low-level), appropriate design notations, test planning, formal Software Validation and Verification, Test Planning, Test execution, and quite importantly, the (oftentimes much longer and for some pieces of software, more costly) Maintenance phase.

Software Engineering thinks about developing and shiping the product that will meet the customer needs, in the required timeframe, and within the specified budget.

The fact that 60% - %80 of software projects (citation: the Chaos Study from the Standish Group) fail to meet one or more of these criteria points up the need for considerable growth and advancement in the discipline of SE.

Aside: the figure of 50 programs granting undergrad degrees sounds way high to me. In 1997 when I formally researched it, there were only four universities granting such degrees (one was Rochester Institute of Technology; I don't recall the others). There are many more graduate programs, but I have no idea the number.

I am sorry I don't have time to edit the article page at present, but I'll try to get back to it in the next few months. The above info is a very quick stab at some needed perspective. --N2e 16:03, 10 April 2006 (UTC)

[edit] Before-last step: coordinate Rework with newer changes in Original

[edit] Last step: replace Original by Rework

[edit] *whistles innocently*

Project2501a 20:36, 24 July 2005 (UTC)

• Cute. This is funny, no doubt, but can someone please explain to me why we have this nonsense in an encyclopædia entry? It is childish at worst and uninformative to the novice at best. Perhaps there could be a section for criticism of the industry as it stands today containing a subsection for humor, but certainly not at the top of the page. It is the first thing that catches the attention of the reader, who is then left wondering what this silly comic has to do with software development. Nevermind that requirements gathering, billing, project scheduling (all of which the cartoon pokes fun at) and so forth are not “software engineering” per se, but are separate practices altogether which support many types of engineering. I apologize for my tone, but I think it is warranted. This is unbecoming of Wikipedia. --MichaelAhlers 15:29, 8 August 2006 (UTC)

[edit] July 26, 2005 Search Engine Results

I just looked up "software engineering" on a variety of search engines.

Google #9 Altavista #6 MSN #5 Yahoo #7

This Wikipedia page must be pretty good, because many major search engines are choosing it for their top 10, which was not true 1 year ago. -- Phantom Avenger for SE

[edit] Information Quality Management

User:Adrius42 added the following sentence fragment at the end of the first paragraph: A part of an emerging discipline of Information Quality Management. I removed it because it isn't a compelte sentence and the article it points to needs work. Is this term sufficiently common that it should be inserted and if so then where does it go? RJFJR 19:30, August 2, 2005 (UTC)

What is the point of this? It seems to be just like spam.

[edit] Source for economic impact paragraph?

Economic 

In the U.S., software drove about 1/4 of all increase in GDP during the 1990s (about $90 billion per year), and 1/6 of all productivity growth (efficiency within GDP) during the late 1990s (about $33 billion per year). Software engineering drove $1 trillion of economic and productivity growth over the last decade.

How about a source for this? I thought this was an area of intense debate among economists. The decade mentioned--the 1990s--leads one to ask, in any case, how much was real economic growth and how much was just the Internet bubble. Dpbsmith (talk) 17:19, 5 August 2005 (UTC)

There were articles a few years ago, in both IEEE Computer and ACM Software Engineering Notes, that explained the size of software engineering. Both stated that software engineering accounted for $200 billion to $250 billion in the U.S. of ecomomic activity each year. However it was the federal reserve which stated that "computing" accounted for 1/2 of all economic growth over the late 1990s. Software has 10 times as many people as computer hardware. Software now costs more than hardware. So assuming that software has 1/2 of the impact of computing should be conservative. Just do the math. -- The Phantom Avenger for SE

[edit] Process and methodology

Why is it that we have a section called "Process and methodology" and an article called Software development process? Are we not refering to the same thing? --Kim Nevelsteen 20:41, 23 August 2005 (UTC)

The much of the software development process article was originally a section of this (SE) article. It was moved when this SE article got way too long. Then the process and methodology section started growing and changing into what it is today. They cover similar material. I doubt that any effort has been made for them to relate to each other. -- Phantom Avenger for SE

I would propose that maybe a commom article with the exact software development/engineering procedure should be made and that both articles link to it.--Kim Nevelsteen 15:28, 24 August 2005 (UTC)

Sounds good.

[edit] What is a software engineer?

I have noticed that a lot of the other articles link to this one under the term a "software engineer". I can understand that software development is now sometimes called software engineering, but what is a software engineer exactly and what makes him different than a programmer, software developer/analyst, Lead programmer, systems architect, project manager? I have personally met people in each of these positions, but I have not met a person that is a software engineer that can state what he does differently than any of the ones I have just stated. At my university there is not a degree for a software engineer, yes one for an industrial engineer and also one for a software developer/analyst, but not a software engineer. To my knowledge it seems to be a title created for those that just feel a little bit better than software developers. Can someone please clarify?--Kim Nevelsteen 15:40, 24 August 2005 (UTC)

The last sentence in the intro section says, "There is extensive debate about what SE is, who qualifies as an SE, who sets the standards, etc." Nobody can give you the definitive answer today, though many people have strong opinions. This is a big problem for this page, because people who advocate one answer sometimes try to impose their favorite answer on this page. -- The Phantom Avenger for SE

It's all quasi-political, quasi-religious.

Some of it is probably related to academic infighting. There were fights when people wanted to establish "computer science" departments at universities—traditionally the stuff had either fallen under "mathematics" or "electrical engineering." How could there be a "science" of computers when computers do not exist in the natural world? Once "computer science" was established, there was then the problem that computer scientists are more interested in studying finite automata or proving theorems about programs than in the nitty-gritty of making million-line payroll programs work, so "software engineering" needed to be invented.

Some of it is an advocacy term. The implication is that there is a set of disciplines and "best practices" which, if followed, will allow armies of average programmers to crank out huge software products that are reliable and can be delivered on-schedule and under budget.

You will notice that the general "tone" of this article is quite different from that of other engineering articles. Dpbsmith (talk) 19:58, 24 August 2005 (UTC)

A software engineer is anyone who says they are one, or alternately, that some authoritative body identifies as one. I don't want a definition of "software engineer" so much as I want a description of what a typical software engineer does. Words have definitions, true, but phrases that refer to some kind of activity (or role) resist abstract definition—just describe the activity! That would provide some idea of what software engineering was. Moreover, one could then write down what a programmer does, and also what a software developer does, and compare them and see if anything comes of it (like, they're all the same, or that some go to more meetings, or something). There is definitely a lot of commonality in the effort of creating software, regardless the nomenclature, since a lot of software gets created, and mostly in similar ways. Brent 02:06, 18 October 2005 (UTC)

Although I happen agree that "a lot of software gets created, and mostly in similar ways," I believe those who use "software engineering" as an advocacy term would strongly disagree. They would assert (incorrectly) that there is a difference in kind between the sort of creative art/craft small-team-of-bright-individual programming that produced e.g. the original Mac OS and what SEI CMM 5 organizations do. Dpbsmith (talk) 09:36, 18 October 2005 (UTC)

In which case, documenting the controversy about software engineering is more important to the Wikipedia than trying to resolve it. But I challenge any software engineer to deny that you'd have engineered software without programmers writing code and compilers compiling it. I personally don't think that software engineering is different in kind, only in degree, but maybe even that's moot.

So, how about an article with this gist: "Software engineers make software. What makes them different from other people who make software is subject to vociferous debate. Some people think software engineering is a loaded term. Some think it is an oxy-moron (or just nonsense). Others (X number of self-described software engineers amongst them) think it's an important and valid distinction. Many have said that software errors are bad, and that something needs to be done to avoid them. It seems to be taken for granted that making software gets harder the more complex it is (exponentially so?), so highly managed techniques are an attractive way to attempt to control the complexity. Pro-software engineering camps favour systematic approaches in line with other engineering disciplines, as well as similar accreditation and the like. See other articles for different opinions about how to increase software quality/reliability." 216.234.42.2 20:41, 18 October 2005 (UTC)

Well, I like it. I trust you can dig up source citations to show that there are camps holding each of those opinions... I just noticed that SEI now disowns the entire CMM model and has a New Improved model. I'll bet the organizations that spent good money getting to CMM Level 5 are really pleased to know that their certifications are garbage and it's time to hire a consulting to help them qualify for CMMI certification... :-) Dpbsmith (talk) 22:31, 18 October 2005 (UTC)

For Wikipedia internal consistency, if this article is to remain entitled "Software Engineer" it could read like and perhaps even reference the Wikipedia "Engineer" article. The "Engineer" article currently states, "An engineer is... a person who uses scientific knowledge to solve practical problems using technology." If it is postulated here that "Software Engineer" is a specific example of the general category "Engineer" in the same manner that "Automotive Engineer" is a specific example of "Engineer" then the difference between "engineer" and "builder" becomes somewhat clearer.

According to this definition, what distinguishes a "software engineer" from a "software developer" is the application of "scientific knowledge". Scientific knowledge is that type of knowledge that is measureable, repeatable, public (published), peer reviewed, and accepted as fact, or at least factually backed theory. I can personally build a car (or dune buggy, or at least a go-cart) by going into a scrapyard and sort of copying what I see. I can probably build it faster and cheaper than a regular car. Furthermore, there is certainly nothing wrong with building a go-cart for private use, and there should never be any legal restrictions on doing so. It may be a fine vehicle, even a thing of beauty - but it likely wouldn't be generally accepted as being "engineered" and legally roadworthy. In contrast, I could read a large body of knowledge on car design, and perhaps even get certified in that BOK, which may be time consuming and annoying and indicate some commitment to a long-term career in that field. I also then have to commit to following generally accepted scientific principles regarding effective automobile construction that meets specifications including socially accepted codes for safety, comfort, limits on permissable uses of toxic materials, acceptable stopping distances etc etc. Complete overkill for a go-cart. Not entirely necessary for the dune buggy that me and my buddies are going to run in off-road settings. Completely legitimate if human safety, large volume sales, and/or a business is at stake.

The gist for me then is not whether there is a role called "software engineering" - but rather "is software engineering a common practice, or more of an exception"? I don't know the answer to this, but I know I want to fly in planes where the engine control software was "engineered". I want to do my banking with software that was "engineered". I don't care if thousands of people write tons of cool programs for tons of cool purposes and even distribute them for free. That's probably even a good thing. Especially if it's a cool game. But if that cool free game bungs up my home computer, then I'll be mad anyway, even if its free.

I hope my little diatribe sheds some light on the above comments and implied questions as well, particularly the initial para by K. Nevelsteen. ThreePD

Slightly related, I am curious to know which software engineering methods have been used with the Linux development model [section Software engineering today]. Traditional software engineering methods have emphasized the importance of specifications/requirements documents, but the Linux project has been able to deliver a solid piece of software without the use of these. If the software engineering methods used by Linux is documented somewhere, it would be helpful for future projects, especially open source ones.

I am a software engineer, The difference is simple, i have a degree on my wall that says software engineer. Those who have an engineering degree are engineers. you can't be an engineer without an engineering degree from a university. let me give some examples. a construction worker is not a civil engineer. a construction worker with 10 years of experience may know more than a new grad civil engineer. but the construction worker is still NOT a civil engineer. if you have an engineering degree your an engineer, otherwise your are not. an electritian is not an electrical engineer. an electrician with experience can know more than an electrical engineer. but the electrician is NOT an electrical engineer. a factory supervisor can know more than an industrial engineer, but he is still NOT an industrial engineer. there are many more examples from every engineering discipline. and more. hope that helps. the difference in the job they do doesn't matter, anyone can do anyone's job with enough practice. if you see a Surgeon do an operation 50 times, you will be able to do it yourself. does that make you a doctor? clearly NOT you have to go through med school first.

Okay... and what about a Software Quality Engineer?? This new term that has come up in the IT industry -- is a Quality Engineer also a Software Engineer? --221.134.24.63 19:36, 21 May 2006 (UTC)

[edit] Relationship to (Dependency On?) Definition of Computer Software

Hi. I'm a trifle concerned (and amazed) that so much energy is expended on arguments about "Software Engineer" when one of the operative terms—Software—has an article on Wikipedia which is so wanting. It seems obvious—if only to me—that it's very difficult to define a term like "Software Engineer" without first getting an explicit consensus on the nature of software. I guess it's just too obvious to everyone else. Even if I'm off base, that page needs attention, and maybe it would be a good day off for some of the participants around here. And if the nature of software is so obvious, it's a shame that the page is so poor, since it would be a low-hanging fruit.

The weird irony is that instead of paying sufficient attention to a discussion of software, a lot of energy has seemed to go into creating a long list of kinds of software. Are software engineers feeling so slighted that they feel a desperate need to advertise? I've never found lists of examples of a type did much to explain the deeper nature of the type. And with something like software, where the end product is only the tip of a very large iceberg (hence the energy expenditure to understand and describe the act of its creation), the futility of such a list is even more pointed. A proper definition deserves better attention in the Wikipedia.

A while back I added a bunch of stuff to the Talk:Computer software page, hoping it would attract some more attention. I have ideas about what to do, but I'm new at this and can only drop in periodically, so I could use some help.Brent 01:11, 18 October 2005 (UTC)

Please avoid the mistake of confusing a concept with the words and letters that describe the concept. For example "engineering" is not "enginee" + "ring" which might be the interpreted as "engines that make rings" or something else silly. There are not a lot of rings in most engineering. Likewise, "software engineering" is not "software" + "engineering". SE almost never uses differential equations, or phyics or chemistry. And SE is not just a fancy version of software. Software engineering is its own field, with its own history, ideals, tools, conventions, etc. That is why this article struggles so hard to define itself. -- Phantom Avenger for SE

Computer hardware engineering doesn't necessarily make heavy use of differential equations, physics, or chemistry either (unless you're talking about low-level semiconductor device design). They're more likely to use boolean algebra and other discrete formalisms. By the same token, there are many aspects of signal processing (nominally an electrical engineering discipline) that make minimal use of differential equations or chemistry. Engineering is not defined by differential equations (even if many engineering math textbooks might lead you to believe otherwise), or continuous mathematics in general. Nor is it defined by a tie to physics or chemistry. Engineering is a pragmatic approach to solving design problems.

The reason that SE seems different from other engineering disciplines is that other engineers (pragmatically) use appropriate mathematics and scientific results to understand what their designs will do before integration and test time, while many self-professed "software engineers" are loathe to use any form of mathematics and restrict their use of science to experimentation with different implementations to find something that will work. Which is not to say that there aren't developers that actually "engineer" their software (e.g. by using CSP to evaluate a design for deadlock prior to committing to implementation, or performing some prototyping so that they can make throughput measurements that can be extrapolated to a finished system, or using relational database theory to help them develop a good design). They're apparently just somewhat rare. --Allan McInnes (talk) 22:19, 2 March 2006 (UTC)

If software engineering was so close to traditional engineering, like you say, then companies would gladly hire civil engineers or mechanical engineers to do their programming and software project management. But, companies don't, because software has almost nothing to do with engineering. Rather, companies hire computer science and IT and all sorts of other professions to do programming and project management, because that is what software engineering really is.

The reason software engineering don't use a lot of math, is because the logic and deduction that they use every day is not considered real math by engineering snobs. And software engineers don't use calculus or physics, like engineering snobs. -- The Phantom Avenger for SE

By your logic, electrical engineering apparently isn't engineering either, since few companies are likely to hire a civil engineer to do analog circuit design and microprocessor design project management. Yet EE is engineering, jsut as SE is engineering. What makes all of these things engineering are shared underlying principles related to how to solve problems and how to design things. What separates them is domain knowledge.

There are a number of reasons that companies hire people other than software engineers to do their programming. Among those reasons are: CS grads have the requisite domain knowledge, and nominally learn some engineering design principles; engineering encompasses more than just programming and all the company needs is programming; some companies don't need (or don't realize that they need) software to be engineered – any random hack that works will be acceptable.

Any "engineering snob" that thinks that the math behind software engineering isn't "real math" has apparently never encountered category theory, type theory, process calculus, or algebraic specification. And I say that as a trained engineer (EE and Aerospace Eng. degrees). --Allan McInnes (talk) 21:23, 5 March 2006 (UTC)

I have spent almost my entire life in software and software engineering, and I am still amazed at how often EE and aerospace engineers try to tell me what my job is. Usually, it is related to a statement about "engineers do this, so software engineers should do it to." For example, the CACM published an article recently about how when software engineers finally get "real engineering practices" there will be no more cost overruns in software projects. Also, the Tau Beta Pi passed a constitional ammendment stating clearly that CS is not adequate to join their engineering honor society. This says as a loud as possible that I am not an engineer, even though I am an SE. The Tau Beta Pi is full of engineering snobs. —The preceding unsigned comment was added by 204.134.9.4 (talk • contribs) .

Well, I'm sorry if you've had bad experiences with engineers from other disciplines who do not understand sofwtare engineering. All I can tell you is that, having been educated as an engineer, and worked in both software engineering and other engineering fields, I see a lot of similarities in approach but an obvious need for differences in analysis tools. IMHO software engineering is as much engineering as any other engineering discipline (whether or not every "software engineer" uses good engineering practices is a separate question). I'm not alone in this: software engineering luminaries such as David Parnas and Steve McConnell also hold this view. The fact that the IEEE publishes a Transactions on Software Engineering would seem to indicate that the IEEE feels the same way.

I've recently been working my way through The Pragmatic Programmer again, and am constantly struck by how much of the content is great advice for practicing engineers in any discipline (I wish someone would write The Pragmatic Electrical Engineer in the same style and with similar content). But then I guess that shouldn't be surprising, since engineering is fundamentally just "pragmatic design of useful products". --Allan McInnes (talk) 21:33, 9 March 2006 (UTC)

The question is not whether there are similarities, of course there are. There are also many differences. There are also similarities to creative writing.

The more interesting thing is that there are almost as many software engineers as there are traditional engineers combined. Software engineering is a big, important, long-lived pofession, that does not need to be defined in terms of traditional engineering. The people who seem to claim SE as engineering mostly seem to be wannabes, who disrespect the legacy of software engineering. There are over 10 times as many software engineers as computer engineers. We don't need CEs or EEs telling us what SE is all about. We don't need your condescension. - Phantom Avenger for SE

Sure. But there are also differences between other engineering disciplines. It's the similarities that make them all "engineering". And yes, there are undoubtedly, at a more abstract level, similarities between every kind of creative endeavour. That doesn't change the fact that "engineering" (regardless of the discipline) has certain common concerns that are not shared with other creative endeavours.

I wouldn't call David Parnas a "wannabe" who "disrespects the legacy of software engineering" — he helped create a lot of the legacy to which you are referring. So I'm not quite sure what you're trying to get at there.

I'm also not sure why you are trying to create some kind of artificial dichotomy between "software engineering" and "traditional engineering". For starters, there isn't really any such thing as "traditional engineering". There are some traditional disciplinary divisions, but even those are hazy (many control engineers come from an ME background, many others come from an EE background), and the field is constantly evolving (disciplines like aerospace engineering and computer engineering are not all that much older than software engineering, and disciplines like biomedical engineering and nanoengineering certainly post-date SE). As I've said several times now, it is the commonalities between all of these disciplines that makes them all "engineering", and suggests that there may be knowledge and principles that can be usefully shared between them. That was certainly the rationale for the naming of the 1968 NATO Software Engineering conference that helped popularize the term "software engineering". If you don't believe that SE has anything in common with other engineering disciplines then I have to wonder why you insist on calling it software engineering (as opposed to software development or some other term that doesn't connote a relationship with engineering).

Having said all of that: the debate about what SE actually is has been going on for decades (as this article makes quite clear), and the odds of us resolving the argument here seem pretty minimal. Not to mention taht it's not really what talk pages are meant to be used for. So, thank you for discussing this issue with me, and please don't be offended if I don't participate any further in the discussion. --Allan McInnes (talk) 01:27, 10 March 2006 (UTC)

There are similarities and differences. However, I did not choose the word engineering, nor did I choose the things I actually do on the job. These things emerged on their own. But, software engineering is still completely from engineering, as the Tau Beta Pi, the National Academy of Engineering, and other traditional engineering organization prove everyday, by deliberately slandering computer science and software engineering. I did not start this. Traditional engineers did.

I note that you end up by saying "If you don't believe that SE has anything in common with other engineering disciplines then I have to wonder why you insist on calling it software engineering" which is analyzing a field by the words, and not by the reality. This is typical for engineering, but poor analysis. -- The Phantom Avenger for SE

I noticed that the article argues that Dijkstra considered software engineering to be a branch of mathematics. I disagree. In 1989 Dijkstra called SE "The Doomed Discipline", and he wrote that SE has accepted as its charter, "how to program if you cannot" (Dijkstra, Edsger W. (1989) On the Cruelty of Really Teaching Computer Science. Communications of the ACM 32(12): pp.1398-1404). Dijkstra considered computing science to be a branch of mathematics --Matti 10:02, 10 July 2006 (UTC)

[edit] Software engineering vs software architecture vs software design?

I hate to sound like a pedant, but can anyone shed light on the relationship (if any) between the following disciplines (or are they practices?):

• Software engineering
• Software architecture
• Software design

--Richard@lbrc.org 17:07, 3 January 2006 (UTC)

[edit] Answers to questions of life, the universe, and software engineering

Sure, at the risk of near certain critique, I'll give it a whirl - but from a bottom up perspective, and including the more foundational term you avoided in this recurring list.

• "Software programming" indicates an activity of forming a software program which means producing at least some piece of a special syntax language (code) that can provide instructions to a computer. Several different languages and techniques are available.
• "Software design", in contrast, indicates an activity of designing, which means forming an arrangement of software components that fulfils some specific purposes. It implies that the software program has achieved a degree of complexity that warrants decomposition into smaller "blocks" or "modules" that require arrangement. This deliberate arrangement attempts to achieve some of its own purposes that are commonly known as design criteria or non-functional requirements, such as safety, performance, maintainability, or simply aesthetics. Preferably there is a documented artefact that describes the "arrangement" and how well it meets its design criteria.
• "Software architecture" is often misunderstood as high level software design, but it actually represents the overall approach taken to the design activity (for example following a multi-threaded distributed task architecture with priority pre-emptive scheduling). These top-level architectural decisions inform the design at every layer of abstraction and must be consistently applied within the intended scope in order to achieve the desired end-results. For example "Baroque" is quite a different building architecture than "Multi-unit efficiency", although each has its own merits and schools of designers. Designs are specific manifestations of those architectures. I can speak about a software architecture without pointing to a particular design.
• "Software engineering" is an engineering discipline that seeks to study the sciences and technologies involved with the practical development of software in order to better apply those sciences and technologies towards greater success. Software engineering includes the practice of defining important terms and relationships between terms (forming relevent ontologies), as well as discussing the merits of the various architectures, designs, and programming languages and techniques that are available. The idea is to form a publically available Body of Knowledge (BOK) about the discipline. There are of course various schools of thought within this BOK. Correct application of software engineering generally depends on possessing detailed knowledge about both the available techniques and the domain area under consideration. The debate about the nature of the SWE BOK (software engineering body of knowledge) is part of the BOK itself. This is also the case for any discipline including philosophy and history.

ThreePD 21:24, 4 February 2006 (UTC)

My over-simplified perspective:

• Software programming - Writing code. Flow-charting would not be considered programming, but programmers may develop and use flow-charts.
• Software design - Developing specs, planning and problem-solving for artistic form and user-interface experience (both predictable and subjective). Designs may or may not include engineering.
• Software architecture - Planning and problem-solving (including flowcharts) for the broader computing structure of code-driven functions based on design specs.
• Software engineering - Planning and problem-solving (including flowcharts and code) for all computing structure, code-driven functions and scientifically predictable user-interface experience based on design specs.

That's just my take. But since I'm none of the above, I may be wrong. I'm only posting this because anyone concerned needs to know how it may appear from the outside looking in. It is just one perspective. Oicumayberight 22:23, 26 October 2006 (UTC)

[edit] State of the ART

I would like to give a presentation on a new topic in SE , any suggestions ? Thanks

[edit] Education

Someone keeps modifying the description of Software degrees in the education section to say that

About half of all practitioners today have computer science degrees with detailed knowledge of hardware.

AFAIK, the majority of CS programs do not teach "detailed knowledge of hardware" - hence the term "software degree". Can whoever keeps making this modification provide some kind of evidence that

1. There are a significant number of CS degrees that teach "detailed knowledge of hardware".
2. That about half of all SE practitioners have received such degrees.

--Allan McInnes (talk) 14:49, 12 April 2006 (UTC)

[edit] Reference, please?

I would really appreciate a citation for the statistic stating that the Boeing 777 has X many processors and 5 million lines of code. I happened to find the statistic "2.5 million lines of code" in a CMU article (http://www.sei.cmu.edu/str/descriptions/ada83_body.html), but that author was citing someone else, using URLs that (when I checked) were dead. Anyway, it would be nice to have a source for this quote, because I'd like to believe it and I'd like to use it in some presentations. -- LandruBek 11:09, 20 April 2006 (UTC)

I don't know where the previous material came from. Unfortunately I mistook the reason for your query. In the context of the article, believing that facts should be sourced, I replaced the unsourced statement with a different one--properly sourced--to the effect that an airliner has several million parts, and the space shuttle has ten million. The two point here is that software is roughly comparable in complexity to the most complex physical objects.

The unsourced sentence I removed was:

(The Boeing 777-200 has about 132,500 engineered and unique parts. Including rivets, bolts and other fasteners, the airplane has more than 3 million parts. Included are approximately 1400 data processing units and 5 million lines of code.)

Dpbsmith (talk) 15:22, 20 April 2006 (UTC)

I too have no idea where the previous data came from. However, I've added a sourced SLOC count of 4 million lines of code for the Boeing 777. This comes from a CrossTalk article written by Boeing's Manager of Embedded SE for the Commercial Airplane Group. The actual breakout is (from the article) ~2.5 MSLOC of new code, and ~4 MSLOC inclduing COTS and optional software. I have no idea how many processors the 777 has though. --Allan McInnes (talk) 17:11, 20 April 2006 (UTC)

[edit] Unsourced material about economic impact

The material below has been unsourced for a long time. It shouldn't be in the article unless there is a source. (And, saying "reliable statistics are hard to find" is not a substitute for finding them!) Dpbsmith (talk) 16:27, 16 May 2006 (UTC)

Material removed:

Economic: In the U.S., software drove about one quarter of all increase in GDP during the 1990s (about $90 billion per year), and one sixth of all productivity growth (efficiency within GDP) during the late 1990s (about $33 billion per year). Software engineering drove $1 trillion of economic and productivity growth over the last decade. Around the world, software drives economic growth in similar ways, though reliable statistics are hard to find.

An anonymous user reinserted the above text, and added a "source" for the statistics. However, after looking at the source in question (Raccoon, L. B. 2001. Definitions and demographics. SIGSOFT Softw. Eng. Notes 26, 1 (Jan. 2001), 82-91. DOI= http://doi.acm.org/10.1145/505894.505914), I have again removed the text in question. The article by Raccoon does not support the text in any way, and in fact does not appear to contain any mention of GDP or economic growth.

I have also again removed the "peacock statement" on social impact that was reinserted after Dpbsmith removed it. Dpbsmith is right: this is a vacuous "peacock statement". Nor has any source been provided for this statement. --Allan McInnes (talk) 19:13, 17 May 2006 (UTC)

[edit] #1 on Google

Wikipedia is now (finally) the standard authority for information on software engineering. I just searched on Google for "Software engineering" and this page for the first time (that I have ever noticed) came up in the #1 slot. Note that most other search engines did this long ago. —The preceding unsigned comment was added by 216.184.31.126 (talk • contribs) .

[edit] Applications or Systems?

The first sentence says that SEs write "systems" when it used to say "applications". I find that system is a blah word that refers to complex things of unspecified nature. Application is far more concrete. SEs write word processors, but are word processors systems? Is a video game a system? Is a flight control application a system? The answer is partly yes, but seems so unsatisfactory. I think it should be reverted. -- Phantom Avenger for SE

Are you suggesting that SEs don't write, for example, operating systems? Or is it your contention that an OS is an application? --Allan McInnes (talk) 17:21, 14 July 2006 (UTC)

For my money, dump the word system and leave it as "... create and maintain software by applying ...". A software engineer can engineer software components without ever producing something that would be called a system. For example, a library developer, etc. -- Munchtipq

Works for me. --Allan McInnes (talk) 14:36, 7 August 2006 (UTC)

[edit] Pervasiveness in missions requiring 'absolute' reliability

Re that statement, I meant not that software is often found -- as an essential component-- in missions requiring high reliability (my claw hammer has no software), but rather that software often finds itself in such situations. That idea is so pervasive that I would think a citation is not needed. Providing one would be low priority for me (unless I come across one by good chance). Anyone feel free to revise, revert or provide cite. Vincehk 03:09, 27 August 2006 (UTC)

If the idea is so pervasive, then it should be easily verifiable :-) --Allan McInnes (talk) 14:57, 27 August 2006 (UTC)

[edit] add'l comments

It might be useful to reference the SWEBOK effort, including Notkin, Gorlick, and Shaw's dissent:

 http://www.acm.org/serving/se_policy/bok_assessment.pdf#search=%22swebok%20shaw%22

gotta mention CMU SEI's CMM.

[edit] Advocacy definition

It looks to me as if the "advocacy" definition of software engineering was there before the IEEE definition was added. I thing the IEEE definition should have replaced the advocacy definition, since it is exactly what was being advocated; i.e. "software engineering" did not refer to the advocacy itself but rather to what was being advocated. I would therefore suggest deleting the advocacy definition, but I didn't want to do that without checking, after someone had gone to the effort of finding a citation. --Boson 17:51, 19 October 2006 (UTC)

[edit] Questions from the jury

Is there any part of the software development process that is neither administrative or engineering? Oicumayberight 22:39, 24 October 2006 (UTC)

The easy answer is that programming is neither "administrative" nor "engineering". (The whole point of "software engineering" is to make programs.) According to people like Dijkstra, writing programs is more like mathematics than anything else. The hard answer is that there is a huge debate over what "engineering" means and how it applies to "software". This page details some of the debates. Then, of course things like "requirements analysis" and "testing" apply to many fields beyond SE and engineering, so depending on point of view, they may not be either. -- Phantom Avenger for SE

Next question: Should everything that attempts to accomplish anything be called engineering? Would it be accurate to call parenting or spousehood, "family engineering?" Oicumayberight 21:24, 26 October 2006 (UTC)

I would say that the term "engineering", in its literal sense, can only be applied when the main product of the process is the result of significant intelligent design by persons, even though the process may also involve activities involving humans rather than artificial objects. This would apply to machines, computer hardware and software, probably even bridges, roads and buildings, though all involve application of theories and methods, project management, definition of processes, getting things to work, etc. It would apply particularly if the product functions or operates in a way that has been specified in detail by humans (like a nuclear reactor or the software used to control it). In an extended sense, the term "engineering" could also be applied to biological systems if they are deliberately manipulated on the basis of defined methods and theories (e.g. "genetic engineering"). --Boson 23:16, 26 October 2006 (UTC)

Would this mean that work to achieve indefinite (open-ended) goals and expectations would fall under the category of "art" not engineering? Oicumayberight 00:12, 27 October 2006 (UTC)

I don't see that the goal (rather than the immediate function) is particularly relevant, but I may have misunderstood. I suppose one might draw a distinction between civil engineering and architecture based on the relative importance of operation or functionaity, rather than aesthetics, if that is what you mean.

Your question is a good one, which is very, very hard to answer. There are lots of debates over *how* to define "engineering". It might be a tradition, a guild, an ideal, etc. This page details some of the complexities, as far as software is concerned. But, I don't know of any way to give a definative answer. -- Phantom Avenger for SE —The preceding unsigned comment was added by 216.184.13.211 (talk • contribs) 00:15, 31 October 2006 (UTC)

[edit] images

Image:Software spanner.png is a nice picture, but it is not informational and adds no information to the article. It only adds some aesthetic value. Can we find a picture that adds both aethetics and useful information? NerdyNSK 21:05, 28 October 2006 (UTC)