:Talk:Systems engineering

{{Talk header}}

{{WikiProject banner shell|class=B|vital=yes|1=

{{WikiProject Engineering|importance=high}}

{{WikiProject Computing|importance=high}}

{{WikiProject Technology}}

{{WikiProject Systems|importance=top |field=Systems engineering }}

}}

{{archive box|

1: 2001 - 2006
2: 2007
3: 2008
}}

Wiki Education Foundation-supported course assignment

40px This article was the subject of a Wiki Education Foundation-supported course assignment, between 14 January 2019 and 2 April 2019. Further details are available on the course page. Student editor(s): Ccedric2.0.

{{small|Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 10:37, 17 January 2022 (UTC)}}

A new Systems Engineering template II

I created a new Systems Engineering template to outline the field of systems engineering.

{{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)

Draftversions

I removed the four new added source from www.everyspec.com, which all seem to be draftversions.

  • Pennell, L.W., et al. [http://www.everyspec.com/USAF/TORs/TOR-2005(8583)-3_(REV-A)_3776/ TOR-2005(8583)-3, Rev. A, Systems Engineering Requirements and Products.] The Aerospace Corporation, 2001
  • [http://www.everyspec.com/NASA/NASA+-+SP+PUBS/NASA-SP-2007-6105-Rev-1-Final-31Dec2007_11124/ NASA/SP-2007-6105 (Rev. 1), NASA Systems Engineering Handbook] NASA, 2007
  • [http://www.everyspec.com/ESA/ECSS-E-10A_14021/ ECSS-E-10A, Space Engineering, System Engineering.] ESA Publications Division, 1996
  • [http://www.everyspec.com/NASA/NASA+-+GSFC/GSFC-GPR/GPR_7120_5A_Systems_Engineering_194/ GPR-7120.5A, System Engineering.] NASA GSFC, 2005

I have listed those links here for everybody to check. -- Marcel Douwe Dekker (talk) 00:27, 19 May 2009 (UTC)

: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.

-- Marcel Douwe Dekker (talk) 19:25, 12 October 2009 (UTC)

Hi just wanted to make a suggestion. Inside:

"Software engineering

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.

125.238.93.10 (talk) 01:44, 30 May 2010 (UTC)

History: MIL Std. 499

The comprehensive description of systems engineering by

MIL STD 499 of 7. January 1970 should be added.-- Hjpospie (talk) 12:44, 14 October 2010 (UTC)

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)

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. 63.239.65.11 (talk) 19:17, 9 January 2015 (UTC)

Elegance

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).

Additional quibbles:

  • 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)