|Sources for development of this article may be located at|
|This article is of interest to the following WikiProjects:|
A new Systems Engineering template II
I created a new Systems Engineering template to outline the field of systems engineering.
Now this is just a first design. I could use some more ideas here, thank you. -- 21:45, 22 October 2008 (UTC)
The 1965 and 1967 SE definition of Harold Chestnut
I just twice referted the changes made to the definition from Systems Engineering Methods by Harold Chestnut, 1967. It seems I was right the first time. Chestnut slightly changed the 1965 definition in the 1967 edition:
- The 1965 definition states: The Systems Engineering method recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions...
- And the 1967 definition is: "The Systems Engineering method recognizes each system as an integrated whole even though composed of diverse, specialized structures and subfunctions...
The current defintion in the article here is based his 1965 book "Systems Engineering Tools", which is also cited in James N. Martin's 1997 "Systems Engineering Guidebook", p. 281. So I will change the year and book and hope this will do. -- Marcel Douwe Dekker (talk) 20:36, 12 November 2008 (UTC)
I removed the four new added source from www.everyspec.com, which all seem to be draftversions.
- Pennell, L.W., et al. TOR-2005(8583)-3, Rev. A, Systems Engineering Requirements and Products. The Aerospace Corporation, 2001
- NASA/SP-2007-6105 (Rev. 1), NASA Systems Engineering Handbook NASA, 2007
- ECSS-E-10A, Space Engineering, System Engineering. ESA Publications Division, 1996
- GPR-7120.5A, System Engineering. NASA GSFC, 2005
- I checked some more an readded the Systems Engineering Handbook 2007 directly from the NASA source. -- Marcel Douwe Dekker (talk) 00:32, 19 May 2009 (UTC)
Article section(s) to be removed or improved
Due to possible violation of copyright, see WP:Copyvio, one or more section of this article should be removed or improved. In the past I might have:
- Used text from secundary sources without using the proper quotation marks, and/or the text of those sources needs to be rewrited.
I apologize for all inconvenience I have caused here, see also here. If you would like to assist in improving this article, please let me know. I can use all the help I can get. Thank you.
Hi just wanted to make a suggestion. Inside:
From its beginnings Software engineering has helped shape modern Systems Engineering practice. The techniques used in the handling of complexes of large software-intensive systems has had a major effect on the shaping and reshaping of the tools, methods and processes of SE."
I'm guessing SE is referring to systems engineering. I think this is confusing in 2 ways, first it is only used here once for the first time (maybe use it at the beginning), and secondly, SE is used very commonly in for software engineering.
History: MIL Std. 499
I added a citation in the history section to the MIL-STD-499 (1969) as evidence of the discussion mentioning field's evolution growing by DoD participation. Further description of MIL-STD-499 is as a key milestone of Systems engineering process. I did not mention MIL-STD-499 discontinuation as part of historical DoD generally stopped doing MIL-STDs in the late 1990s since that seems a digression. Markbassett (talk) 13:40, 28 August 2012 (UTC)
System Thinking and SE Functions
Was reviewing SE course materials and delta to the article content here ...
The article thread seems to lose it's initial "systems thinking" (holistic/synergistic) view of what SE does and the "interdisciplinary nature" of SE as covering interactions between disciplines (e.g. project manager, stakeholder, logistics, maintenance, budgetary, user, operations) with SE supposed to not become yet another competing stakeholder. They appear in the Concept section, but are not reflected in the later sections of Education, SE topics, and Related Fields. Systems thinking should focus that the attention is on:
- Tracking - Handling complexity of SE systems by tracking all, ensuring multiple functions and parts are identified and defined and do not get overlooked.
- System focus - On the system that creates a product, rather than focusing on the product itself or on the technology implementing the system.
- Inter-relationships - On the inter-relationships of the SE functions and defined parts, and tradeoffs or interactions. (e.g. the V-diagram where processes proceed down the V in detail and then later intergration and testing proceeds up and links back to the prior leg of the V; e.g. the balance or tradeoff of Cost/Schedule/Delivery/Risk in general or at particular tradeoff such as better operational performance vs. better maintainability / reliability.
The functions of the various SE approaches cover the Engineering (requirements development, logical and physical design, implementation, integration, verification, validation, transition), Management (decision analysis, technical planning, technical assessment, risk management, configuration management, data management, interface management) and Life Cycle (mission definition, Concept of Operations, Project planning, requirements definition, system specification, system architecture, syustem design, system implementation, system testing, and system evolution).
Each SE function is some combination of People, Budget, Process, and Tools.
- People - staff, stakeholder, and governance contribute different skill sets to produce artifacts with varying values and viewpoints.
- Budget - people, space, equipment, and money are all traded off as to amount and organized in time
- Process - stucture imposed on tasks and activities making SE products; there are several competing and choice affects planning and language used
- Tools - the particular hardware and software used for SE; selection may be from corporate mandate, SE process, and capabilities of staff
I'll post a 'see also' link to "Systems Thinking" but the basic article flaw remains that initial SE concept description is not well shown in the artile sections for actual SE ... Markbassett (talk) 21:59, 17 July 2013 (UTC)
I notice that Mdd recently moved the lines that were links to documents from the section "External links" to the section "Fruther reading". Can anyone state a WP guidance or general defacto practice that clarifies the lower sections usage and what goes where ? I am thinking that almost any thing I would list is something readable, sometimes it's a section from a book sometimes it's an article or blog, and I was using Reading as being text citations of written material (text, articles, etcetera) not available by web, and links as being any link to web-accessible items. Markbassett (talk) 13:56, 5 September 2013 (UTC)
The Role of Standards
I think it would be great to see something on the role and importance of national and international standards in this important field. Any suggestions?--Graham Proud (talk) 14:04, 16 February 2014 (UTC)
- Mmm - seems inactive but I'll say there seem multiple ways to read that one and article seems OK without mention. If Graham Proud describes some specific edit might make it easier to say further. 126.96.36.199 (talk) 19:17, 9 January 2015 (UTC)
The systems engineering process must begin by discovering the real problems that need to be resolved, and identify the most probable or highest impact failures that can occur - systems engineering involves finding elegant solutions to these problems.
There are so many problems with this sentence, it's far from obvious how to fix it.
First, the Mutt and Jeff parallelism where "must begin by discovering" is echoed against "identify".
"and must identify" would help slightly (fitting half-pint Jeff with platform shoes).
- Who says "must" anyway?
- After SE finds solutions, does it do anything with them?
- Do "elegant" solutions even exist? By what/whose criteria, and who decides?
- Presumably, the tone here is that SE finds elegant solutions in contrast to solutions too-horrible-to-even-name foisted upon the problem by those (unnamed) other people.
- Finally, it's a bit of leap that every failure mode is actually a problem (e.g. looming heat death of the universe). Problems are a social construct.
— MaxEnt 15:51, 5 August 2015 (UTC)