Your SlideShare is downloading. ×
Essence syseng omg_20jun13_v4.1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Essence syseng omg_20jun13_v4.1

11,972
views

Published on

Published in: Technology, News & Politics

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
11,972
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
23
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Essence for Systems Engineering(Systems Engineering Essence)Berlin20 June 2013INCOSERussianChapter
  • 2. ContextRoadmap (http://semat.org/?p=863):• 1st of August 2013 – define model and architecture ontological status inthe Essence• 1st of September 2013 – publish first draft of the Essence kernelextension for Systems Engineering• 1st of December 2013 – map Essence Systems Engineering kernelelements to ISO 15926• End of December 2013 – publish first version of the “Essence systemsengineering kernel elements (mapped to the ISO 15926)”Achievements:• Proposal discussed at the INCOSE Russian Chapter on 22nd of May 2013(http://incose-ru.livejournal.com/42524.html).• Proposal disussed at MESI conference on 6-7th of June 2013(http://www.mesi.ru/our/events/detail/121699/) with Ivar Jacobsonand wider audience.2
  • 3. Language, kernel, practice3...LanguageKernel(abstract)Practices(specific for situation)...RequirementsStakeholdersConOpBudgetExplorepossibilities Perform interviewBrainstorm
  • 4. Alpha: states = checklists : checkpoints4ALPHA -- Abstract-Level Progress Health Attribute.
  • 5. Engineering project alphas: as is5Essence Tutorial May 25, 2013. San Francisco CA USA 5CustomerSolutionscopes andconstrains< plans and performs< fulfils^ producesWork TeamSystem ofInterestRequirementsWay ofWorking^< provideStakeholdersOpportunityfocuses>useandconsume>supports>Setuptoaddress>EndeavorOpportunity OpportunityStakeholders
  • 6. Systems engineering• Intuition: V-model• Focus on system definition (more resources todefine the system, i.e. more work with bitsrather than atoms)• Agile in the work with bits, cascade in thework with atoms.• Architecture and design are of the sameimportance as requirements (constraints todesign solutions, focusing in Essence terms).6
  • 7. 72D representation of Life Cycle:practices executed in timedefine needs acceptancearchitecturingdesign parts manufacturingintegrationvalidationverificationverificationSystemdefinitionSystemrealization[Systemoperation]
  • 8. Requirements, Architecture, Design andSystem: state redistribution is needed8*Requirements definedSystemimplementation(atoms)Systemdefinition(bit)*design
  • 9. Essence and Architecture• Not present in current standard as alpha:«architecture wasn’t addressed explicitly in manysoftware projects»• Required by systems engineering methodology(design should be architectural)• Current Essence kernel choices for architecturemodeling:– Architecture is an independent alpha– Architecture is a sub-alpha of alpha “System”– Architecture is a pattern9
  • 10. Trade-off options• System definition (result of system definition activitiesin V-diagram) alpha with requirements, architectureand design as sub-alphas (with system descriptions aswork products): with redistribution of states fromSystem realization alpha• Architecture and design as first class kernel alphas• Architecture and design as sub-alpha of system• Architecture as Patterns (according to Ian Dietz – linkbetween requirements and system like GORE patternsis link between Opportunities/Goals andRequirements)10
  • 11. Proposal: kernel modification1111Essence Tutorial May 25, 2013. San Francisco CA USA 11CustomerSolutionscopes andconstrains< plans and performs< fulfils^ producesWork TeamSystemRealizationSystemDefinitionWay ofWorking^< provideStakeholdersOpportunityfocuses>useandconsume>supports>Setuptoaddress>EndeavorOpportunity OpportunityStakeholders
  • 12. System Definitionvs System Realization• System Definition = Requirements, Architecture,Design• Composed from models that grouped by views –generalized from ISO 42010• System definition frameworks are sub-alphas ofway-of-working (generalized from ISO 42010architectural framework)• System definition languages are sub-alphas ofway-of-working too («language» is a practice in amethod aka «resource» - «language» in ISO24744)12
  • 13. ISO 4201013Solution area ofconcern alphasWay-of-workingsub-alphasWork products (i.e. in practices)Map to Essence
  • 14. System definition and realization(ISO 42010 generalization)Way-of-workingsub-alphas(specified bystandards)
  • 15. Solution area of concern alphas & V-modelSystemDefinitionSub-alphasverificationverification
  • 16. Solution Area of Concern Alpha States16Conceived1/6SystemDefinitionIt is clear how the system will bedefined. It is clear what success is forthe new system. Viewpoints are agreed upon. The approach to concorddescriptions among thestakeholders has been agreed. The description changemanagement mechanisms havebeen agreed.Consistent2/6Consistent System definition has beencreated. Descriptions are documentedand available for the team andstakeholders. The origin of the description isclear. Descriptions are examined. Contradictory descriptions havebeen identified and are dealtwith. The team understandsdescriptions and agrees toimplement them. The system implementing thedescriptions is accepted be thestakeholders as worth realizing.Used for Production3/6System definition is used for systemproduction. Enough of the descriptions areready for starting systemrealization. Realization technologies havebeen defined. Part of the team responsible forsystem realizationacknowledges availabledescriptions sufficient to realizethe system. Issues occurring during systemrealization lead to the re-workand actualization of the systemdefinition.Used for Verification4/6System definition is used for testing. There are no missed parts ofthe system definition that maketesting impossible. Tests, success criteria and testmethods have been defined. Stakeholders agree with testscope.Used for Operation5/6System definitions is used bystakeholders for operation. System definition is used forgathering information aboutstate of the operational systemrealization. System definition withininformation about the state ofthe operational system is usedfor making decisions aboutmaintenance, repair, andmodernization.Used for Disposal6/6System definition is used for systemdisposal. System definition is used formaking decision about systemdisposal or operation extension. System definition showsabsence of undesirableconsequences (e.g. environmentpollution) through systemdisposal. System definition is used forplanning and performingdisposal or recycling of thesystem realization.Raw materials1/6Raw materials for system realizationare available and ready partsmanufacturing. Raw materials for systemrealization are available andallow manufacturing of theparts with required properties. Facilities for manufacturingparts from the raw materials areavailable. Parts production and logisticschedule has been agreed. Parts manufacturing works areready to start.Parts2/6Parts have been produced and are readyfor integration. Parts of the system have beenproduced and/or purchased andchecked. Integration schedule has beenagreed. Integration works are ready tostart.Demonstrable3/6The system has been assembled fromthe parts and is ready for testing. Some functions of the system canbe exercised and keycharacteristics can be measured. Key system characteristics havebe demonstrated. Critical interfaces have beendemonstrated. The integration with other existingsystems has been demonstrated. The relevant stakeholders agreethat system has to be tested.Ready4/6The systemема (as a whole) has beenaccepted for deployment in a liveenvironment. The functionality of the system hasbeen tested. Level of defects is acceptable for thestakeholders. Setup and other user documentationis available. The stakeholder representativesaccept the system as fit-for-purpose. Configuration of the system to behanded over to the stakeholders isknown. The stakeholder representatives wantto make the system operational. The system is fully supported to theagreed service levels.Operational5/6The system is in use in a liveenvironment. The system has been madeavailable to the stakeholdersintended to use it. At least one example of thesystem is fully operational. The system is fully supported tothe agreed service levels.Retired6/6The realized system is no longersupported and disposed and/or recycled. The system realization has beenreplaced or discontinued. The system is no longersupported. There are no “official”stakeholders who still use thesystem. Updates/ modifications to thesystem will no longer be produced. All material components of thesystem are re-used or have beenproperly disposed.SystemDefinitionSystemDefinitionSystemDefinitionSystemDefinitionSystemDefinitionSystemRealizationSystemRealizationSystemRealizationSystemRealizationSystemRealizationSystemRealization
  • 17. 17Thank you!Anatoly Levenchuk (Lead scientist)http://ailev.ruailev@asmp.msk.su(President of INCOSE Russian Chapter)Victor Agroskin (ISO 15926 liaison)vic5784@gmail.comAndrey Bayda (SEMAT liaison)andrey.a.bayda@gmail.com