|Comment Page||Associated Page||Comment Title||Comment||Author||Last Editor||Created||Last Edited|
|CommentStreams:8c71816efcb28d0fe3827cb783e7b602||Download SEBoK PDF||The link is still incorrect||anonymous||Feb 28 at 5:01 am|
|CommentStreams:7d7528730de1a31811033732cd90192f||Introduction to Systems Engineering||Focus of a Systems Engineer||I am somewhat distressed that the emphasis, intentional or otherwise, on a System Engineer seems to focus primarily on process. In the workplace, this is often translating into pigeonholing the SE into a "process" only job where they are merely the shepherds of the lifecycle process pieces. Even our SE language "the System Engineering supports the lifecycle process" when we mean "the SE aids the successful creation of the desired product" places the SE in a functionally supporting process role only. To quote "A systems engineer helps ensure the elements of the system fit together to accomplish the objectives of the whole..." This, although generally mentioned after process discussions, seems to me to be the true purpose of the SE. A good SE, in my experience, works with and across the other disciplines to ensure the aggregate whole is optimized during the entire life of the product. This includes real analytical engineering work and people-oriented negotiation. Yes, there are supporting techniques and processes the SE uses to accomplish those tasks but those supporting functions seem to dominate the conversation on the definition of the SE. To read much of the discussion about an SE, I don't really need an SE, I need process people to write down requirements, handle documents or models, and support real engineers. I would much prefer if we moved the quote I mentioned earlier to the forefront and then indicate that there are processes that aid the SE function. This would place the processes in the position of supporting the SE and not the SE supporting the processes. R Porter||anonymous||Feb 24 at 3:49 pm|
|CommentStreams:1aa4dd4f893e5387597f3896cc6d723e||Cycles and the Cyclic Nature of Systems||All diagrams are too complex to read||Fig1: No ! too much information + unreadable
Fig2: too much information + dark background not easy for impaired eyes
Fig3: too cluttered
|anonymous||Feb 12 at 4:41 pm|
|CommentStreams:02cf39b95bc6d581d8a8e8aaebd90bbb||Systems Engineering Overview||Figures out of order||Figure 3 is before figure 2 in this article.
We're Systems Engineers, not savages.
We're Systems Engineers, not savages.
I tried to make an account to fix it, but according to your FAQ I can't.
|anonymous||Feb 8 at 11:06 am|
|CommentStreams:157eefa7d0fc955f742ed7a7ffbc7012||Download SEBoK PDF||The link still incorrect...||anonymous||Feb 2 at 6:41 pm|
|CommentStreams:4a6667f0680eb581a34ccfc761cae175||System Definition||carl||helpful||anonymous||Jan 16 at 1:20 pm|
|CommentStreams:367b2728a2185dc9c2cce7bf4b847c4f||What is Systems Thinking?||Systems thinking helps in complicated systems situations as well||I continually worry that a lot of SE literature focuses (obseses?) on it applying to complex systems. Clearly it does. But SE applies equally in complicated situations - and Systems Thinking ("applying the properties seen in systems to your situation to gain insight and understanding", and acting as a "framework for curiosity " - works just as well in complicated systems. My company makes complicated systems, and has Systems Thinking as an essential competency underpinning the engineering activites||anonymous||Jan 13 at 5:40 pm|
|CommentStreams:3f9121fbff41b9604e2e3f8a48f0a781||Introduction to Systems Engineering||stakeholder (plural) not Customer (single)||The text correctly says there are customers and stakeholders - but
a) you say the needs of those that acquire and use the system need to be satisfied. but there are other stakeholders - regulators (who do not acquire and use) and the business producing the system have needs that impact the solution
b) figure 1 shows a single customer - and whilst that is the only one the system is "provided to" there are significantly more stakeholders who provide needs and who need to be considered. Not including them devalues a very important, useful and informative figure.
|anonymous||Jan 12 at 11:24 am|
|CommentStreams:F2c0659a25d38b40379eee5cb6dff1e0||Emergence||emergence is a property of complicated systems as well||this article continues the mistake that emergence is limited to complex systems. This is not true. Complex systems merely more likely to have unexpected emergence and so cwhen working a complex system a greater lookout needed||anonymous||Jan 12 at 8:55 am|
|CommentStreams:D79d91f294665d77191d5d9045dcd546||Download SEBoK PDF||me too - SEBoK 2.3 full pdf link is not correct||anonymous||Jan 12 at 8:47 am|
|CommentStreams:8b3a0bf5b5da800f069054803416b53b||Risk Management Guide for DoD Acquisition||Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, January 2017||This is the latest version of this guide, which is listed on https://ac.cto.mil/erpo/
This is the new website contains many of the DASD(SE) guidance post-reorganization..
Listed under Independent Technical Risk Assessments.
|anonymous||Jan 8 at 12:28 am|
|CommentStreams:58548a3b71c756232968893803897bfc||Systems Engineering Core Concepts||systems engineers perform processes using competency||in the figure I agree that Systems Engineers are one of organisations roles that have competency to define / qualify them in the role. But they also carry out processes (typically the organisation will have a quality system defining them), and a role will have a varying degree of involvement (Accountability, Responsibility etc.) for a sub-set of these processes. SEs need specific competencies to allow them to provide their contribution to the processes - see Annex C of the INCOSE Systems Engineering Competency Framework (on Defining roles using the Framework).
Usually I am fighting for competencies to be recognised as well as processes - not adding the process
|anonymous||Jan 7 at 1:23 pm|
|CommentStreams:1c318da450421d2d04b7807e75cc7fb7||Download SEBoK PDF||I'm facing the same issue here.||anonymous||Dec 23 at 5:34 pm|
|CommentStreams:7a726fd61e300428393f09bb8e82b71a||Enabling Systems Engineering||Here's another example: When looking at the definition of "systems approach", I see the text "A set of principles for applying systems thinking to engineered system contexts."
Should it be: a) " ... engineered (system contexts)"; or b) " ... (engineered system) contexts"?
I'm guessing the latter, in which case it'd be more readable if the definition e.g. said: "A set of principles for applying systems thinking to the context of an engineered system.". Alternatively, if the aspects of multiple systems is important: A set of principles for applying systems thinking to the contexts of engineered systems."
Considering that in SE we should be advocates for writing unambiguous requirements, I find the ambiguity here a little ironic ;-)
|anonymous||Dec 8 at 12:32 pm|
|CommentStreams:92bc296cf415e6209bbe07dc6385c2e9||Enabling Systems Engineering||Question on how to read the title||Just a comment as a "new reader" to this wiki.
When reading this page's title, "Enabling systems engineering", it's difficult for me to know if it means "Enabling (systems engineering)" or "(Enabling systems) engineering".
If it's the latter, readability would improve if the title instead was e.g. 'Engineering of enabling systems". If it's the former, perhaps use a synonym to 'enabling'.
Note: I've now seen this kind of combination/stacking of words at multiple places in this wiki. And even though I'm used to technical documents, here I find that it relatively often makes it more difficult for me to correctly parse the language. It certainly slows me down, and I suspect it also causes me to unintentionally group the nouns incorrectly at times when skimming text.
|anonymous||Dec 8 at 12:25 pm|
|CommentStreams:441ecc2b35f02b4e8a60dd7cf12bb23a||emergent property||Please clarify discussion section||Reading the discussion, I though there should be a link to a glossary entry for "emergence". (Or if no such entry exists at this point, a link to non-existing destination, waiting for someone to define it...)
Alternatively, if the definition is delegate to a section in the Emergence article, it should say so more clearly (and perhaps link to the relevant section) in the Emergence article.
Finally, the Emergence article says the following:
Emergent properties can be defined as follows: “A property of a complex system is said to be ‘emergent’ [in the case when], although it arises out of the properties and relations characterizing its simpler constituents, it is neither predictable from, nor reducible to, these lower-level characteristics” (Honderich 1995, 224).
I'm not sure why this is not shown on this page, rather than being (perhaps) indirectly referenced via the Emergence article. To me this latter definition is not quite the same as the one by Checkland.
|anonymous||Dec 8 at 10:45 am|
|CommentStreams:D6163013f9b6ca409e662b6c423dffdb||Emergence||Surprised by "What is a system" redirection to other page||When reading the introductory part of this page, where it says "... It will discuss how these ideas relate to the general definitions of systems given in What is a System?; ..." I followed the latter link and was surprised when I ended up on the page "Introduction to System Fundamentals". Turns out the page "What is a system" redirects. This was unexpected, and I wasn't sure I had really ended up on the right page, nor was it immediately clear which section on this introduction page that was relevant.
Perhaps the text in the introduction on this page should be modified to e.g. " ... It will discuss how these ideas relate to the general definitions of systems given in Introduction_to_System_Fundamentals; ...".
I suspect it'd be even better if the link actually referred to a section within that page, perhaps the section "A general view of systems". Or perhaps a section actually called "What is a system".
As an aside, I'd say this is an example of a weakness in the traceability/maintainability of this wiki system. E.g. if the introduction page expands further, or if it were to be split up in the future. FYI, I think that in other wikis it's possible to link to a section. IIRC, I also think it's possible for the referenced section to have a visual indicator (anchor) in the referenced section indicating it's being referenced, and that it allows you to list the pages that reference the section. I don't know if this wiki engine supports this, but it might be very useful for this particular wiki.
|anonymous||Dec 8 at 10:22 am|
|CommentStreams:4ce180988d379e4538762cf4634a5145||architecture||Definitions 1 and 3 identical - should they be.||Definitions 1 and 3 look identical to me, at least I couldn't see how they differ. Perhaps this should be mentioned in the discussion section (assuming they're supposed to be verbatim identical).
Note: I don't know how to create an account (I'm likely not allowed), so it's perhaps not so likely I'll see any responses to this. If it is allowed to create an account, please note it's not clear how that would be done.
|anonymous||Dec 7 at 3:06 pm|
|CommentStreams:2e243ccf124e48e3e0a06b07b1d21259||Systems Approach Applied to Engineered Systems||Readability of page with browser in "night mode"||A minor comment. The readability of e.g. this page isn't great when switching the browser (Firefox) to "night mode" (here using the addon Dark Night Mode). For instance, links become a blue colour on black background (i.e. the contrast could be better). More annoying is e.g. figure 1 above, where the background turns black, thus making the lines impossible to read.
Just thought I should share this aspect.
|anonymous||Dec 7 at 2:57 pm|
|CommentStreams:051937994f6cd5fe71e9ee33fdeb8bb0||system of systems (sos)||Typo or similar in discussion section.||The discussion section looks odd, I see an "e" starting the sentence as well as an extra "e" at the end.||anonymous||Dec 7 at 11:15 am|