Downloaded 43 times
More Related Content
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Kahn.theodore
- 1. IMPROVING PROJECT MANAGEMENT USING FORMALMODELS AND ARCHITECTURES Theodore Kahn theodore.e.kahn@nasa.gov Ian Sturken ian.sturken@nasa.gov Project Management Challenge February 9-10, 2011 Making Modeling Work
- 2. Problem Statement 2 Project information is stored in various documents, spreadsheets and systems with little consistency and/or formal structure A lack of common understanding of a project’s organizations, roles, objectives, behaviors and constraints .
- 3. Agenda 3 Theory of: Enterprise and Business Architecture Formal modeling Applying EA and Modeling to Project Management Case studies: MODEAR Flight Readiness System Ares development Ames process modeling Making Modeling Work for You Today Future Trends and Closing Remarks Q&A
- 4. Four Modeling Perspectives 4 Model Based Systems Engineering (MBSE)
- 5.
- 6. 6 Enterprise Architecture
- 7. What is theScope of an Enterprise 7 Architecture? Most Restrictive Several ideas are in common use: • An accounting of an organization’s IT artifacts and their application to lines of business. (Lists of IT things.) • The relationships and behaviors of an organization’s IT artifacts and their application to lines of business. (Lists and Life-cycle of IT things.) • An accounting of an organization’s meaningful artifacts and their application to lines of business. (Lists of “all” things.) • The relationships and behaviors of an organization’s meaningful artifacts and their application to lines of business. (Lists and Life-cycle of “all” things.) Most Expansive
- 8. FEA and DoDAFEA Definition 8 A strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to changing mission needs. EA includes a baseline architecture, a target architecture, and a sequencing plan.
- 9. How did weuse an Enterprise Architecture? 9 To organize the information about our processes, products, people and systems To relate these entities to one another To provide different diagrams and reports of the information suitable to each of the stakeholders in the project To export information to other tools for analysis and simulations
- 10. Benefits of EnterpriseArchitecture 10
- 11. Zachman Framework What How Who (Data) (Function or (People) Process) Scope •List of things •Function List of important to Hierarchy Organizations Technology business •Functions to Org Matrix Agnostic Technology Business •Conceptual •Process Model •Org to Function Agnostic - Model Data Model mapping (roles) Understand ConOps The Business System •Logical Data •Use Case •Process to Role Model Model Matrix Requirements •Activity Diagram System Requirements Technology Technology •Physical Data •Activity Diagram •Roles/Access Design Model Model •Sequence Matrix Specific – Specifications Diagram Specify and Design the Systems to Support Detailed •Technology •Technology •Technology Design Specific Specific Specific The Business 11
- 12.
- 13. Which EAF doI Use? 13 Zachman Easier to grasp and get started with. Can start with lists of “things” and start relating these to other parts of the business Hierarchical in nature, provides good mechanism for abstracting levels of detail from executive to engineer More IT centric DoDAF More prescriptive in nature – specific products to fill different purposes Separate different viewpoints – business processes from systems that support them Supported by many tools Has a modeling language specifically designed for it: UPDM General purpose Create your own If you don’t use a standard framework – you will create your own mechanisms for organizing and relating information in your models!
- 14. Use Standard Architecture 14 Framework, Model or Both? Architecture Frameworks: Can range from simple (lists) to complex Useful for providing an outline of what information to gather and how to organize that information Can customize this outline to fit your needs Can be used to compare different systems from different vendors Can be used to study “as-is” states to “to-be” states Can leverage modeling languages such as UML, SysML, and Archimate Modeling Standards Can range from simple to complex Quick to build a few diagrams For larger projects will need to organize model Formal language/annotations used Both Provides guidance on what modeling artifacts you will need and how to organize them according to a standard framework
- 15. 15 Modeling Models, Formal Models and SysML
- 16. What is aModel? 16 An Abstraction of the Physical World Around Us • An electrical schematic of a radio • An economic model • A mathematical model • A model student • A non working model airplane • A written description of a pencil • A diagram • A spreadsheet • Music • Art • Natural languages
- 17. Sample of ModelingLanguages 17 Language Purpose IDEFx Business UML Software BPN Software AADL Hardware, software, realtime (avionics, aerospace, automotive, and robotics). Simulink Simulation and analysis of multidomain dynamic systems Archimate Business SysML Systems of systems
- 18. Modeling Language Attributes 18 Formality More formality = less ambiguity, more accuracy Less abstraction = more detail, Abstraction more precision
- 19. Abstraction Levels 19 La Joconde Femme au Chapeau Orné
- 20. What is aFormal Model? 20 The degree to which the model adheres to: • Well defined semantics: model components have precise interpretations. • Well defined grammar: model components can only be related using precise structural rules.
- 21.
- 22.
- 23. SysML Diagram Taxonomy 23 Source: OMG Specification
- 24. 24 Applying EA & Modeling to PM
- 25. Modeling and PM 25 Projects are now modeled using spreadsheets, diagrams and documents to represent different parts (components) of the project. A formal model does not change this. Instead, your project components must now be represented using formal grammar and semantics. And, if you are using a standardized framework, your project follows a well known architecture.
- 26. System Engineering andProject 26 Management From NASA System Engineering Handbook - NASA/SP-2007-6105
- 27. Review Entrance Criteria (NASA Systems Engineering Handbook) 27 Milestone Artifacts System Concept Review System Goals And Objectives Concept of Operations System Requirements Review System Requirements System Functionality Description Concept of Operations Preliminary System Requirements Preliminary Design Review Preliminary subsystem design Specs Operational Concept Interface Control Documents Requirements Traceability Matrix These can all be described in one model!
- 28. Building ConOps fromModel 28 Conops Section DoDAF product SYSML Model Scenarios OV-5 Activity Diagram Use Case Diagram, Activity Diagram Conceptual Overview OV-1 High Level Concept Block Definition Diagram Event sequence OV-6c Sequence Diagram Connectivity OV-2 Node Connectivity Block Definition Diagram Architecture Diagram, OV-3 Information Exchanges, SV-1 System Interface, SV-2 System Communication Glossary AV-2 Integrated Dictionary Block Definition Diagram
- 29. Technical Decision Analysis (Trade Analyses) 29 Instance Structural Functional
- 30. Formal Modeling andSix Sigma (Complementary Technologies.) 30 Six Sigma Formal Models Both Together Methodology Yes No Yes Formal Data No Yes Yes Semantics & Grammar Data Persistence No Yes Yes
- 31. 31 Case Studies
- 32. MOD Flight ProductionProcess Re- 32 engineering Goal: MOD needs to transform into an agile organization to be able to quickly meet needs and opportunities that arise in the next decade. Challenge: Currently, most information about how we conduct business is housed in different documents, spreadsheets, systems and other repositories. It is difficult to gain a comprehensive, integrated, common view of the way we conduct business and what the impact of changes are on our people, processes and systems. Approach: An enterprise architecture provides a framework that will allow us to organize information about our people, processes and systems in an organized, structured and integrated manner. Benefits: An organization that can quickly assess the impact of external events saving $$$$ and reducing risk.
- 33.
- 34. Use Architecture Informationfor 34 Several Purposes System DoDAF Architect Diagrams Performers Mission EA Repository Discrete Operations Event timeline, critical Simulator path determination Tabular reports
- 35. DoDAF Connectivity Diagram(OV-2) 35
- 36. Flight Readiness System 36 Goal: Develop a new system to support certification of flight readiness for Cx Challenge: How do we specify the components of our system with varying levels of detail while maintaining consistency throughout Approach: Use DoDAF/UPDM to describe the ‘as-is’ process and systems for shuttle. Then design a new set of processes and supporting systems for Constellation as a ‘to-be’. Benefits: Information is organized and represented consistently with various levels of detail appropriate to different stakeholders
- 37. As-Is and To-BeTemplates 37 As-Is To-Be
- 38. Flight Readiness “As-Is”OV-5 38
- 39. Flight Readiness “To-Be”OV-5 39
- 40. Flight Readiness SystemModel 40 Connectivity Activity Diagram Diagram Sending node activity Activity Information Element Exchange Data Report Model Information Element
- 41. Modeling Ares Development 41 Problem Definition: 1. Large amount of data… 2. maintained in three separate artifacts: document, spreadsheet and diagram… 3. to meet different stakeholder needs. Lead to the following concerns: 1. Time consuming and error prone to modify data as Ares program changes. 2. Not easy to meet new stakeholder needs.
- 42. Ares Model Architecture (UPDM) 42
- 43.
- 44.
- 45. UPDM OV7 Diagram (Structure) 45
- 46. UPDM OV2 Diagram (Behavior) 46
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. 55 Making Modeling Work for You Today Practical Information for achieving quick ROI
- 56. Modeling is anEngineering Task 56 Approach it systematically Know what resources you will need Define milestones, a roadmap Be pragmatic
- 57. What Makes aGood Formal Model? 57 Model those aspects of the project required to answer stakeholder questions, and no more. Model the degree of precision required to answer stakeholder questions, and no more. Models must always be accurate.
- 58. Why is modelinghard? (It Requires Five Knowledge Domains) 58 Need to know Need to know Architectural modeling tool Framework Need to Impediments Need to know understand to Modeling project/system modeling domain semantics
- 59. Four Modeling Steps (Do only one at a time.) 59 Questions & Project knowledge translate to Architectural Framework Knowledge apply to Modeling Language knowledge apply Tool knowledge
- 60. Modeling Tools EncompassTwo Areas (Do only one at a time.) 60 Database program Drawing program
- 61. Think Small, ThinkFocused (Get ROI in Weeks!) 61 What questions should your model answer? Select a modeling language. Determine the architecture. Select a tool.
- 62. You’re in Frontof your Computer (Now what do you do?) 62 Your tool is running You created a new project (in this case, SysML) And… You create packages to organize your project
- 63. A “Template” SysMLModel 63
- 64. Extending SysML 64 Use English to document each entity. Use diagram notes to highlight explain diagram elements. Use SysML Profiles to extend SysML semantics to meet your own domain specific needs.
- 65. Modeling Tips 65 What if you don’t know something? Make your best guess, its easy to change. What should go on a diagram? Itshould tell a story, answer a question, address a specific stakeholder need. Look to see how a set of diagrams might meet a stakeholder’s need in some specific area. Model only those elements for which you know there is a value.
- 66. Culture Issues (Modeling is about sharing information.) 66 Some people do not necessarily want to share their information Job security They don’t know the information, and perhaps reluctant to say so. Its time-consuming to get the information, what’s in it for them? Some people like to work independently
- 67. Modeling Summary 67 Think small, know what questions your model should answer. Keep the architecture simple. Learn your modeling language semantics. Pro actively manage the modeling task: Engineering effort Cultural issues
- 68. 68 Future Trends and Closing Remarks
- 69. Future Trends 69 Fully defined semantics Prescriptive methodologies Improved tooling Analytical integration EA Frameworks are adding behavior and project management representations
- 70. Closing Remarks 70 Approach modeling as an engineering task Determine the architecture (structure) Determine the modeling language Think small and focused Make sure you understand stakeholder needs Be aware of cultural issues
- 71.
- 72. DODAF 2.0 72 Capability Viewpoint Project Viewpoint Vision Taxonomy Phasing Dependencies Portfolio Organizational Mapping Timelines Activities Mapping Capabilities Mapping Services Mapping
- 73. Project Management Information: Gantt Chart, Event Chain Diagram, ISO 10006, Six Sigma …producing strategic …leading to better estimates for PM artifacts... schedule, scope and resources.. 73 Schedule Resources Scope …and also used for aligning project …maintaining a consistent, feasible schedule, scope and resources… project and a refined model… Formal Model Formal semantic relationships + consistent representations improved common understandings & decisions. …providing consistent operational …used for creating SysML model… information used by all stakeholders… …which encompasses project data… Text Docs Spreadsheets Diagrams Represented by… Projects are defined and change mostly due to external events: Continuously.
Editor's Notes
- #3 Among other effects not having a common understanding makes it very difficult to recognize how a change in one aspect of a project might affect other aspects.
- #4 Objectives:Some theoretical understanding of enterprise architecture, business architecture and formal modelingThe application of formal modeling to Project ManagementActual projects using formal modeling and enterprise architecturesSpecific do’s and don’ts for making formal modeling work for you today: short term ROI
- #5 Modeling means very different things to people, largely dependent on their roles in the organization. This diagram depicts one approach at decomposing modeling concepts into four distinct perspectives.Forth (bottom) row: Formal modeling (models having formal semantics and grammar) had their start in various engineering disciplines in the 1960's and 70's along with the development of computer technology. These models are largely based on mathematical and stochastic techniques.Third row: Modeling larger engineering efforts crossing several or many engineering domains proved more difficult. It was not until the 2006 adoption of SysML (Systems Modeling Language) that a generally accepted open specification for describing engineering systems was available. The application of more formal models to systems-of-systems is often referred to as Model Based Systems Engineering (MBSE).Top row: Meanwhile, during the 1970's and 80s organizations were having their own problems keeping track of the myriad of IT resources upon which they were increasingly dependent. This then was the impetus for Enterprise Architectures in the early 1990's. Unlike the engineering system's dynamic models, EAs have historically been more interested in the relationships among entities: this machine runs that software supporting these departments. Examples include Zachman and FEAF. The defense and aerospace industries developing very large systems had needs for depicting full system life-cycles and so developed their own EA variants, mainly DoDAF and MoDAF.Second row: The actual work-product of an organization, its lines of business have been largely ignored from a modeling perspective. The concept of enterprise business architecture, at least at a conceptual level, tries to address this, but as yet there is no generally accepted modeling language. Two proxies are the Business Process Notation (BMN) and SysML. BPN, however, is designed to model software and to the extent that a business process is not software centric, it becomes difficult to model. In addition, BPN does not support structural relationships or requirements. SysML does address many of these problems but does not intrinsically include business concepts. This is addressed by a relatively new modeling language ArchiMate.
- #6 We build representations of our organizations all the time. Representations always include notions how different parts of our systems are organized and how we represent those structures.The advantages of using pre-described (standards-based) representations is that:We do not have to think about them which leaves more time and energy for describing our systems, andWe do not have to explain what we mean by what we do to our readers which again saves us time and increases the likelihood that our architecture will be understood correctly.This slide shows various system engineering standards. We can see from this chart that there are numerous standards, frameworks and methodologies. This presentation focuses on the two areas that are most pertinent to getting the job done – architecture frameworks, specifically DoDAF and Modeling standards, specifically Sysml. A framework prescibes certain artifacts (e.g. diagrams, reports etc.) that describe a system, business or enterprise to satisfy the needs of your project stakeholders. The modeling standards provide a language with which to build the artifacts to be used in the framework. So for example, the framework might say that to satsify the needs of a database developer you will need to provide a logical data model. The modeling standard tells you what language to use in describing the logical data model. Note that you can implement an architecture without following any modeling standard. And vice versa, modeling standards do not require the use of an architecture framework.
- #8 These four definitions differ in two areas.Domain of artifacts: IT or all an organization’s artifactsThe first two limit an EA’s concern to only IT things whereas the last two definitions suggest that an EA is concerned with keeping track of all artifacts that would be useful for stakeholders to know about.Representations of artifacts: Lists or Lists and LifecycleThe first and third definitions limit the relationships artifacts have to each to simple ordering and associations, lists. Whereas the second and fourth, add the notion that EA’s should also describe artifact behaviors.
- #9 It is interesting that both the Federal Enterprise Architecture (FEA) and the Department of Defense Architectural Framework have the same definition.The key to understanding the domain of a particular EA is how the mission is defined. For example, does include all the supporting activities that mission requires for successful execution, or is just those activities directly supporting the objectives?
- #10 We wanted to provide a relatively simple definition, and provide insight in how we actually used an EA. plain language of what an enterprise architecture is- sort of an elevator pitch - and this is what we came up with. An enterprise architecture describes…. EntitiesAnd it can be used to describe an existing enterprise, business or mission or a planned one. It can provide all manner of products to support your business including conops, icds, requirements, business models,
- #11 What we are showing in this diagram is the gradual benefits you realize from an EA model. Starting with a road to discovery – promoting a common understanding of what the enterprise does. Once you have an understanding you can start discovering gaps – whether they be systems needs, overlapping processes, etc. You can determine what constrains your enterprise has an simulate the business processes to determine length of time to market. Eventually the overall goal is to optimize your business, reduce risk. Resource bottleneck example: you can discover if a resource is utilized by too many processes – and you need to either increase the resource or reduce the dependencies on the resource Information Resource Needs will indicate what processes map to what systems and specify requirements for those systemsDetermine Critical processes – e.g. the sub-process path that makes up the length of the overall processSimulate and execute processes – EA can feed business process simulations. E.g. the data gathered for EA can also be used for simulations. MOD is currently doing this.
- #13 This is the DoDAF 2.0 framework. In our projects we used the 1.5 framework. In the 2.0
- #14 There are many architecture frameworks to use. We have been using the two that are listed here. One key thing to remember is you don’t need to use all features of a framework. You can customize to suite your own needs. We will see an example of this later on in the presentation. The first, Zachman has been around for some time and is quickly modify and adopt. DoDAF is still evolving and is somewhat more complex. But DoDAF has more definition in what information should be collected and how that should be represented. Particularly if you use UPDM which is a modeling language specifically built to be used in the DoDAF framework.
- #15 So we have seen some of the frameworks available. But you should know that you can use a standard AF, a modeling standard, both or neither. But our recommendation is that adopting a modeling language will provide a lot of bang for the buck – it can be simple® to use to produce a few diagrams and will provide the consistency which is often the first problem to be solved in depicting systems of systems
- #17 As human beings, we model all the time. Its what we do.Models are around us all the time in many forms.
- #19 Increased formality can result in models more difficult to understand and more time consuming to produce.
- #20 We deal with notions of abstraction levels all the time, maps, arts are good examples. However, rarely is it discussed or even thought of formally in the context of technical information. SysML brings formal semantics for expressing abstraction levels to technical communications.Abstractions are of course used in project management. Perhaps most notable when we hear the phrase “Let me give you the big picture.”However, there are no formal notations or syntax supporting the expression of abstractions. And perhaps because few people are comfortable communicating abstractions, their seems to be a tendency to move from the very abstract to the very detailed without proper consideration of their relationships: does the detailed truly represent the abstraction and do we really want to “lock” ourselves to this implementation?More abstraction levels and traceability across abstraction levels helps assure that the community of interest achieves a more complete common understanding of the problem being described and the rationale for the decisions made.Note: Why the French title for the Mona Lisa? The only title I found for the Picasso painting was French. I could have translated it into English (Woman with ornate hat) but my French is not that good and orné can also mean decorated, so I was not really sure what the best translation would be. Also, the painting is known by its French name. Alternatively, I could have used the English name, Mona Lisa, but then two languages are used, adding complication. Since the Mona Lisa is owned by the French government and resides in France, I used its official name. Both paintings are now referred to using their official titles in the same language. Thus, there is precision and consistency regarding the names, at the expense of confusion for non French speaking audiences. This was a modeling choice having no theoretical best solution.These types of considerations occur frequently in modeling and trade-offs need to be considered from multiple perspectives. And yes, sometimes one spends more time than warranted discussing minutia, but that’s another issue.
- #22 SysML is a graphical language. This means that the main way, but certainly not the only way, to communicate is visual.We will go over all the elements on this diagram, but do not worry if you don’t understand everything, some are abstract concepts and take being exposed to them several times before their interpretation can be fully understood. All these concepts will be talked about later in more detail.Important point: All diagram elements and their relationships are stored at a granular level in a database. This information could just as easily also be rendered in any number of report formats. For example, you could create a report where columns of each row represent use cases, stakeholders, and requirements. The critical idea to understand is that the diagram is not the model: one model, many diagrams.This is an example of SysML a Use Case Diagram. Its primary purpose is to relate the functionality of your project to stakeholder benefits. In short, it highlights who is to derive what benefits from your project. This particular diagram has the following elements:Four structural elements, from left to right:The stakeholders, stick figures on the left. They can be people, computers or any external (to your project or what you are building) device.Your system (what you are building), blue rectangle.Different functions (use cases) of your system, yellow ovals.The requirements of your system, pink rectangles on the right.Three relationship behavioral elements, from left to right:An inheritance or type-of relationships, solid lines with hollow arrow-heads. The element at the tail has all the characteristics and behaviors of the element at the arrow-head plus its own unique characteristics and behaviors.An association relationships, solid lines. (Associations can also have arrow-heads, but they will be open.) Other association types communicate whole-part relationships.A dependency relationships, dashed lines with hollow arrow-heads. The element at the tail has some form of dependency on the element at the arrow-head.Three stereotypes, which are enclosed by guillemets. Stereotype annotations add semantic information that is either not represented by its own SysML notation, or extends SysML semantics to meet your own domain specific requirements. The there stereotypes are:«extend», optionally may include«refine», relates two levels of abstraction of the same idea.«functionalRequirement», role of elementThe abstract use case Administration is denoted by the title being in italics. Abstraction denotes that the structural element cannot actually be constructed or used; hence, it is normally seen in the context of inheritance relationships.Projects have objectives. In part, meeting these objectives requires activities, here expressed as use cases. Writing requirements that distinctly and completely express the objectives of these activities is often a good first step in assuring the activities will be implemented.Every functional requirement should have a relationship to one or more use cases. If this is not the case, then some part of your project objective is not being met; andEvery use case should have a relationship to one or more functional requirements. If this is not the case, then you may be doing work that is not required.Likewise, every project activity should relate (directly or indirectly) to a stakeholder benefit. Specifically:Every use case should be associated with one or more stakeholders. If a stakeholder cannot be found who would benefit from a use case, then perhaps the use case is not needed leading to the requirement being changed or even eliminated.Every stakeholder should be associated to one or more use cases. If this is not the case, then perhaps some stakeholder needs are not being met and the requirements should be revisited.Summary:Every visual element has a formal semantic meaning and so readers have to make very few assumptions as to what the diagram is communicating.This means that discussions around diagrams can be concerned about how the model should be constructed: what should its structure and behavior be and not about what the diagram actually is trying to say.Example: As shown, the administrator can perform all the user use cases. That is, administrators can query and update the database. If, however, the inheritance relationship between user and administrator were to be eliminated, then administrators would not be able to user activities. There is of course no intrinsic right or wrong. The point being that diagram discussions can be focused on what the desired behavior should be, and not what the diagram means.
- #23 Dashed lines communicates dependency relationships between two entities.The tail end entity is dependent on the arrow end entity.The stereotype, text inside the angle brackets, denotes the nature of the dependency.Examples:If a requirement changes, then the use case may also need to change.Likewise, if the use case changes, then the activity representing the use case may also need to change.The <<refine>> stereotype communicates the same concept at different levels of abstraction.
- #24 The BIG picture.Note that the taxonomy is divided into two parts:StructureBehaviorThe concept of structure and behavior reoccurs several times in SysML and is worth thinking about when modeling.There are two important semantic constructs shown in this diagram addressing the idea of abstraction:Italicized names indicates abstract elements. Abstract elements are elements not having enough definition to actually be created. They provide a formal semantic for showing the starting point of a taxonomy.Closed white arrow-heads conveys the notion of generalization/specialization (aka, inheritance or type-of). Thus, we now understand that a Parametric Diagram is a type-of Internal Block Diagram and that an Internal Block Diagram is a type-of Structure Diagram. And, by inference, we also know that a Parametric Diagram is a type-of Structure Diagram.Finally, there are several types of arrow-heads in SysML that convey very different information. Regardless of the type, they are always read from the tail to the arrow-head.We will be looking at five diagrams:PackageBlockActivityRequirementUse caseImportant: SysML modeling and semantics are presented through diagrams because they provide an organized visual approach. It should be noted, however, that all modeling can be performed directly against the database or programmatically, depending on the tools capabilities.
- #26 The first bullet simply says that you are now modeling your project, only its an informal model and the various parts (components) of your project do not necessarily follow a specified grammar or semantics. Thus, different stakeholders might interpret parts differently.The second bullet says that employing a formal model does not change the modality of what your doing, you will still be doing modeling, but now you must adhere to a formal semantics and grammar.Adhering to a formal model requires time and effort. The point of this presentation is to provide the information to make an informed decision as to whether having more precise and accurate information is worth it: Is there an ROI?
- #27 This is from the system engineering handbook and it reminds us that there is a great deal of overlap between project management and systems engineering. In fact, in smaller projects, the roles often are carried out by the same individuals. The idea with models is that we can keep both sides of the project house informed so that changes on either side of the circles are visible to all project stakeholders.
- #28 The system engineering handbook describes sets of artifacts that your project has to produce that are listed here. Often times, these documents are created with informal diagrams and information that is inconsistent. By using a modeling approach, the information for building these artifacts can come from one consistent source. And if anything changes in the model,
- #29 In this table we show an example of how you might use modeling artifacts in a Concept of Operations document. The first column shows the components that might go into a conops document. Traditionally, these sections are built with unstructured text and informal diagrams. The second column shows the DoDAF products that can be used in the Conops, The third column shows the equivalent SYSML model. Note that once these diagrams are persisted they can be resued other artifacts as welll as connected to requirements.
- #30 This diagram shows how parametric analyzes can be preformed using SysML.This model shows two numbers being added.SysML does not intrinsically support analyses.In this case, a proprietary extension to the SysML tool is used.This requires following the extension's protocols in terms of model representation.The structural components are created.There functional relationships modeled.An instance of the structure is created. There can be any number of instances.Values are defined for A and b in the instance. In this case, 10 and -500.An execution command is issued.The parametric extension sends the instance data to an execution engine (in this case Mathematica).The execution engine returns the results. In this case, -490.The parametric extension inserts the results into the model. In this case, the model element C is set to -490.The SysML tool itself has no knowledge that -490 came from an execution engine.
- #31 Six Sigma, and process improvement methodologies in general have no formal grammars for data representations and persistence.Significant efforts may be expended in determining how data are to be rendered. This can be particularly troublesome when data are not strictly quantitative.By contrast, modeling languages in of themselves have no concept of methodology. Thus, organizations are free to consider using a modeling language that best fits their needs and data structures and then applying those models their process improvement methodology of choice.
- #33 The MOD folks had an objective to reduce their costs for operating missions. So the first step was to start cataloging the processes, organizations, systems etc. Then determine how long each of the processes took, to determine critical path. Define, develop, validate and execute our missions with a common understanding of how our people, processes and systems will interact with one anotherRun models and simulations of our business to validate our processes and systems and find areas where efficiencies can be achievedDetermine our net-readiness and interoperability capabilitiesFind gaps and overlaps between our operations needs and system capabilities
- #35 The information in MODEAR is currently exported to several tools. One generates DoDAF diagrams (as shown in the next slide) to aid in visualization of the mission ops processes. Data is also exported to a discrete event simulator to determine how long it will take to run flight operation and what tasks are on the critical path. Finally you can generate tabular reports that describe exchanges between organizations, what organizations own what products and processes, etc. More information on this will be in the talk tomorrow AM.
- #36 Here we can see an OV-2 where organizations for example, DD, are responsible for certain functions such as 3.3.4.1. and what systems MORS are suporting this activity. Note that Do is doing work, but we don’t know what the systems that support that work are. We can also see we are formally recording the exchange of resources between the two organizations and you should be able to drill-down to the lower levels to determine what is in the mission requirements.
- #38 This shows the organization of information using DODAF. In the initial stages of the project an “as-is” was created to study current operating practices. Then a “to-be” was proposed, as to how to change the processes and build a system for Cx.
- #39 Our first step in the flight readiness project was the development of a concept of operations document. This involved looking at the as-is state of how shuttle did flight readiness and the to-be for Cx. Using activity diagrams such as shown above allowed us to maintain consistency in what products were developed for looking at how we did things and how we were going to improve. So looking at this slide we see our performers of activities like a data aggregator who is utlizing a powerpoit slide to update product status and on the to be slide…
- #40 We can see the data aggregator would use a system to to input status and the system then would take over much of what previously was done by other performers. So you can see it is easy to see where we were and where we want to go to.
- #41 This is the project information for the CoFR or Flight Readiness system project. You can see different diagrams such as an activity diagram that shows steps that need to be performed with a connectivity diagram that shows that data needs to go between different organizations. The red text squares show the different diagrams or reports. The green boxes show the actual elements such as an information element that goes between the diagrams. Then an exchange report that provides a tabular report of the information that is in all the other diagrams.
- #42 Many Aresprocesses and process outputs are described in documents. Therefore, understanding the contents of these documents and their temporal relationships provides a good approximation to the actual Ares activities.Each document represents a process. Ares then creates a corresponding Data Requirements Description (DRD) document recording key information about the document it represents. This information can be considered in two groups:Document attributes. Examples include name, document number, office of primary responsibility, contents and description, to name a few.The document’s relationships to other documents. Three such relationships were identified:Parent/child. The notion being that the parent had information and/or instructions for creating its children.Guidance. One document has information required of another document. This information might be in the form of how something is to be produced or presented.Inputs/outputs. This information communicates that the information in one or more documents is required for producing one or more other documents.Once a DRD was received, it was entered into a spreadsheet, one row per DRD. The columns corresponding to the various attributes and relationships.Most of this information was entered in bulk at one time and a diagram created showing the relationships.However, over time, as the project evolved, the individual DRDs and diagram were not maintained as it was time consuming and error prone. Therefore, the spreadsheet became the primary source for this information.The data in the model was obtained from the spreadsheet.
- #54 Constraints are elements in their own right.The same constraint can be applied to any number of actions.
- #59 Understanding your stakeholder questions is the key—gatekeeper—to producing effective models in short times.The more focused and limited those questions are, the better able you will be to gather the data required that answers their questions.It minimizes the amount of the architectural framework, modeling semantics and even the project/system domain you need to know.One reason modeling efforts fail is that modelers are not clear as to what the model needs to say, so they often have correct models of little value.
- #60 This extends the ideas in the previous slide providing guidance regarding the chronological order of activities.Be sure and understand the questions and carefully consider the project data that needs to be modeled in order to answer the questions.Determine where in the architectural framework that data belongs.Determine the modeling semantics/grammar that needs to be applied to the data in order to correctly represent it.Determine the formats and other constraints your tool may require to actually perform the modeling.
- #61 These modeling tools are complex, in part, because they are performing two very complex tasks:They are a complete database program allowing you to create, modify and delete entities, their characteristics and relationships.They are also a complete drawing program proving many choices on how to present your model.
- #62 Formal modeling is most useful for large projects and systems. That said, it is best to acquire modeling skills on smaller projects, or small parts of a larger project.Make a list of stakeholders and questions they need answered. Try to be focused and specific. You are likely a stakeholder, so consider starting with yourself.If you are trying to understand technical systems or projects, consider SysML.Do you want to use a formal architectural framework? Maybe you only need part of a framework. Or, you might just look at frameworks for guidance.Avoid tool wars and comparisons. Probably any tool that supports your modeling language will be at least be adequate. Negotiate with commercial vendors for trial copies. Often they will provide you with one for at least several months, especially if you say you are just trying to understand the tool and modeling.Note that not all tools support all languages and frameworks and so for pragmatic reasons, you may need to compromise.
- #63 Here the example gets a bit more specific in that SysML is being shown rather than the generic concept of a model. This is because we needed to have something concrete in which to highlight the concepts of architecture.All models include an architecture, which is nothing more than the models organization. The question then is do you use a standard framework, or make up your own?Or, you could consider using just some aspects of a framework, at least to get started.To keep things simple, we are not using an AF here at all. And because SysML has no concept of a framework, we need to make one up.The seven packages shown provides a good starting point for many models.
- #66 What if you don’t know something? This happens more often then you might think. Its not always clear what we don’t know until we are called upon to explain it in detail. It is also a very good side benefit of modeling. It forces you and your colleagues to think precisely how your project is put together.What should go on a diagram?It may help to think of a diagram as a section in a large document. Several diagrams (sections) addresses a stakeholder or
- #67 These are legitimate and compelling reasons for people not share their information. Mitigating these problems requires pro-active management.More specifically, there needs to be an alignment of interests for the project as a whole and the individuals comprising the project.
- #70 Modeling semantics are still changing, this is especially true as it pertains to the integration of architectural frameworks and modeling languages.Protocols need to be developed providing guidance regarding data collection, organizing modeling efforts and determining model objectives. Communities of Practice that are inclusive of all stakeholders need to be developed.Tools will have to start including protocols and methodologies as an integral part of their offerings. For example, if a use case is created, it should prompt for associated stakeholders. More generally, tools should proactively manage all traceability throughout the model.The intergration of dynamic analytics provides powerful ways for understanding the models actual operations.
- #73 With DoDAF 2.0 two new viewpoints were added to map capabilities of a project to timelines, portfolios, activities etc. This appears to be a trend to start bringing portfolio and project management into the architecture framework. Of course, this adds additional complexity to the architecture framework.