|Comment Page||Associated Page||Comment Title||Comment||Author||Last Editor||Created||Last Edited|
|CommentStreams:839cc360d97dd0b63a4142605274b600||Hubble Space Telescope||Background section "STOPPED HERE "||There seems to be some self-notice text left online.||anonymous||May 10 at 9:02 pm|
|CommentStreams:E2a6710f284a1ad4ea804383b724ff0c||Applying a Model-Based Approach to Support Requirements Analysis on the Thirty-Meter Telescope||cross reference matrix of examples||this case study isn't included in the matrix of implementation examples page||anonymous||May 10 at 10:28 am|
|CommentStreams:125b6b41ca499d210d8226c27cb3018e||Hubble Space Telescope||The link to Mattice cited work doesn't work||please check these links, as case studies really rely on them!||anonymous||May 10 at 10:21 am|
|CommentStreams:3784a4ed9d4a59c5762accf432a2dbf3||Global Positioning System||broken link||the link to the Friedman and Sage article in the works cited does not work||anonymous||May 10 at 9:14 am|
|CommentStreams:9efe930271c1a14b00297525422ff8b3||System Design||good job||anonymous||Apr 29 at 11:45 pm|
|CommentStreams:2334b03a8b8625ca8eba6156d4379d8c||Information Management||Excellent Reference||Thank you for sharing this detailed information about information management.
I also wrote an article cover information management on my blog
|anonymous||Apr 26 at 4:04 pm|
|CommentStreams:F6b7a4ead7081bd7efe1a9cb01970878||Systems Biology||more references||look at the work INCOSE member Gary Smith has done applying ST to medicine - he did some very good work looking at Sepsis as a system||anonymous||Apr 26 at 6:53 am|
|CommentStreams:2254fef7341b42c378499e635fbf47b9||Systems Engineering in Healthcare Delivery||missing key reference on health care delivery||it is good there is an article on healthcare delivery (rather than purely the product.
A key reference which looked at (UK) healthcare delivery (which is interesting variation due to the "not for profit" / NHS stakeholder values, and hence expectations of the consumers of healthcare) is the Royal Academy of Engineering report "Engineering Better care". Particularly important consideration of how Systems, Design, People and Risk thinking need to be applied, and on making the "systems process" accessible.
|anonymous||Apr 26 at 6:48 am|
|CommentStreams:051f5f4b7b38f37daf26f9a54f8d97bb||Healthcare Systems Engineering||contract versus market driven||this is a critical difference, and i think INCOSE / Systems Engineering would be far better served if it made this far more clear. The contract driven is one extreme of the spectrum of situation, and pure market driven (there are domain more so that health care products) the other. I think the majority of systems are market driven, and those placing the large procurement / development contracts (customers) would do well to learn the "barriers" their contracting style creates, so there should be more emphasis on how to be a good stakeholder) emphasis in the literature. Instead too often there is an implicit assumption that it is "big procurement" and things like requirements are written too much from the point of viw of interpreting customer (contact) specifications - and not recognising the needs of the business providing solution, or the idea of the supplier looking for / completing / validating ALL stakeholder requirements||anonymous||Apr 26 at 6:36 am|
|CommentStreams:56de4896a51286a7b5da9a4c2121b90d||Socio-Technical Features of Systems of Systems||make clear the difference between SoS and system||the points you make about the pain points are true for the constituent elements of a system - an optimised systems is made of sub-optimised parts, and (conversely) if the parts of a system are optimised the whole will not be. True for a system and so true for system of systems
The point is because the parts of a System of Systems are designed as independent systems then a) there is no single controlling architect (and procurement control doesn't do it) b) the System of Systems may be transient, and so "modifications" to the parts may not be feasible or economic c) many of the systems may already exist.....
please - it is important we get the fundamental properties clear!!!
|anonymous||Apr 25 at 7:58 pm|
|CommentStreams:C7ef26aba6032c0eddb869ebbeb468be||Systems of Systems (SoS)||the defintion at the top||I know it is an ISO definition ("ISO/IEC/IEEE 21839 (ISO, 2019) provides a definition of SoS : ystem of Systems (SoS) — Set of systems or system elements that interact to provide a unique capability that none of the constituent systems can accomplish on its own. Note: Systems elements can be necessary to facilitate the interaction of the constituent systems in the system of systems"
But I am afraid this isn't good or clear enough, as this can be held to be true for a system (or anything that is considered as a system). So you have to make this article be clear that a system of systems is both a system (and a true system, with all the properties seen in a system that are used in Systems Thinking) with the following additional properties
a) the constituent elements in a systems of systems are in themselves "true" systems
b) typically there is no single owner for all the systems in a system of systems (making top down control hard!)
c) a system of systems may be a permanent or temporary connection of the consituent parts
Using David Snowden's Cynefin framework, this makes a System of Systems a "complex system", whereas a single system may be complex or complicated. Typically (if the consistuent system is a product) is a "complicated" system. This distinction is really important as there is a different approach needed for each (sense - analyse - respond for complicated, probe - sense - respond for complex)
Far too often I hear complex and complicated used interchangeably, and things that are just systems (say an aircraft) described as a system of systems (when it really isn't, its just its sub-systems are described as systems, and can be thought of as one to applying systems thinking / Systems Engineering). Just like with Systems Thinking, there is nothing wrong with applying Systems of Systems thinking to a system that isn't really one, but it isn't often very useful.
|anonymous||Apr 25 at 7:46 pm|
|CommentStreams:C742c0899011109bad07b7bac93ec43b||supplier||Comment||To my knowledge: The supplier cannot be individuals. Individuals benefit from protective consumer laws. Suppliers can be only organisations.||anonymous||Apr 22 at 8:07 pm|
|CommentStreams:8f8b38abc4050c35ed72888175c4d574||enterprise system||What is an enterprise?||What is an enterprise?||anonymous||Apr 4 at 8:07 pm|
|CommentStreams:996dff85e3b32999b04c9040f65e7dc4||Relationships between Systems Engineering and Project Management||There is much more||you can add detail to the "intersection" Venn diagram - the INCOSE UK chapter produced a Z guide with APM on the overlap which is good. (also would help make clear there is more than one professional PM society)||anonymous||Mar 29 at 1:00 pm|
|CommentStreams:2c23967147740234e33a14392bec38e0||Download SEBoK PDF||Download link for v2.3 in this page now links to a new page where you can actually download the right v2.3 document - thanks Rob||anonymous||Mar 28 at 6:17 pm|
|CommentStreams:Ce18c71225063ff0ecdfee8ac0c76531||Systems Thinking||Naive||Not to mention Ashby's cybernetics, Forrester's system dynamics or Meadows primer in ST is astonishing.
See chapters 4a and 4b "Ideas from systems thinking history" here https://bit.ly/2yXGImr
Chapter 4b points to where Ackoff confused social entities with activity systems, and Meadows confused goals without outcomes.
|anonymous||Mar 27 at 9:41 am|
|CommentStreams:E5074fd52236dcb1a6139f88d482fc04||Developing Systems Engineering Capabilities within Businesses and Enterprises||more on TRL||in the discussion of TRL is is worth mentioning that the interaction with technology and the other aspects of organisation capability need to be considered. For example a new technology may make the existing tools and methods obsolete, and so the engineering will not be able to design solutions using the new technology. Aspect of needing to see the capability to engineer systems as a system in its own right. See Beasley / Pickard paper from IS 2020 (in the not presented due to reduced size of conference section) which is a development of ideas started when I (richard Beasley) first wrote this article back in 2011/2012||anonymous||Mar 24 at 9:38 am|
|CommentStreams:2aeb7d2c76404f01d2f7a69b017233a6||architecture||Completely agree. An update is needed. I see only two definitions.||anonymous||Mar 19 at 1:47 am|
|CommentStreams:1869758ffe487c88729095dea7831a80||Relevant Standards||other standards||Do you think this list is complete - I often here discussion of the Asset Management standard ( ISO55000) especially in conjunction with maintaining / supporting Capability and Enterprise Systems ?||anonymous||Mar 16 at 9:19 am|
|CommentStreams:0120bb3887e0bebf02dcbc1feed7a322||Systems Engineering Management||Other work on overlap of SE and Project management||there is work various parts of INCOSE have done with PMI and APM (in UK - including a Z guide) looking at the integration of Figure 1 which would be good to at least reference here, if not actually build up to figure 1. I think Systems implementation and Project management could be seen as an overlap of three projects - the first to develop the solution (definition of system solution, verified and validated), second a project to "produce the system" (build each instance, recognising in many systems this will be a "one-off") and thirdly support the operation of the system (which may be combined with the second (especially if it is a system where many instances produced - e.g aircraft). Ideally of course the second and third projects are clear, because the pre-work lifecycle thinking in SE means these system phases have been "Designed for" in the system development||anonymous||Mar 7 at 1:23 pm|