Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Kahn.theodore
1. IMPROVING PROJECT
MANAGEMENT USING
FORMAL MODELS 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
7. What is the Scope 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 DoDAF EA 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 we use 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
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
13. Which EAF do I 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
16. What is a Model?
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 Modeling Languages
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
20. What is a Formal 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.
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 and Project
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 from Model
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
30. Formal Modeling and Six 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
32. MOD Flight Production Process 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.
34. Use Architecture Information for
34
Several Purposes
System DoDAF
Architect Diagrams
Performers
Mission EA
Repository
Discrete Operations
Event timeline, critical
Simulator path
determination
Tabular
reports
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
40. Flight Readiness System Model
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.
55. 55
Making Modeling Work for You
Today
Practical Information for achieving quick ROI
56. Modeling is an Engineering Task
56
Approach it systematically
Know what resources you will need
Define milestones, a roadmap
Be pragmatic
57. What Makes a Good 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 modeling hard?
(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 Encompass Two Areas
(Do only one at a time.)
60
Database program
Drawing program
61. Think Small, Think Focused
(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 Front of 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
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
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
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.
Notes de l'éditeur
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.
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
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.
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.
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.
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?
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,
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.
This is the DoDAF 2.0 framework. In our projects we used the 1.5 framework. In the 2.0
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.
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
As human beings, we model all the time. Its what we do.Models are around us all the time in many forms.
Increased formality can result in models more difficult to understand and more time consuming to produce.
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.
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.
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.
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.
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?
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.
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,
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.
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.
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.
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
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.
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.
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.
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…
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.
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.
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.
Constraints are elements in their own right.The same constraint can be applied to any number of actions.
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.
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.
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.
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.
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.
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
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.
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.
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.
