gorilla systems engineering versus guerilla systems engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Gorilla Systems Engineering versus Guerilla Systems Engineering PowerPoint Presentation
Download Presentation
Gorilla Systems Engineering versus Guerilla Systems Engineering

Loading in 2 Seconds...

play fullscreen
1 / 12

Gorilla Systems Engineering versus Guerilla Systems Engineering - PowerPoint PPT Presentation


  • 147 Views
  • Uploaded on

Gorilla Systems Engineering versus Guerilla Systems Engineering . Keith A. Taggart, PhD James Willis Steve Dam, PhD Presented to the INCOSE SE DC Meeting, May 14 2012. Definitions and Characteristics.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Gorilla Systems Engineering versus Guerilla Systems Engineering' - cassia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
gorilla systems engineering versus guerilla systems engineering

Gorilla Systems Engineering versus Guerilla Systems Engineering

Keith A. Taggart, PhD

James Willis

Steve Dam, PhD

Presented to the INCOSE SE DC Meeting, May 14 2012

definitions and characteristics
Definitions and Characteristics
  • In the rather artificial world of systems engineering there are a couple of interesting types of inhabitants:

Gorillas and Guerillas

implications
Implications
  • We do NOT intend to imply that Guerilla Systems Engineering is “Better” than Gorilla Systems Engineering
  • We only mean to point out some interesting characteristics of the two and speculate on the implications these may have for the future
  • The analogies are not exact but are rather meant to be thought provoking
gorillas systems engineers
Gorillas Systems Engineers
  • Gorillas are the BIG guys: the US Government and the “uber” integrators, the primes
  • These are the organizations and their members who produce or cause to be produced large complex and / or complicated systems
  • They use the standard system engineering approach described by the “V” (or equivalent)
    • a standard set of artifacts (requirements, architectures, interface control documents, and so on)
    • and a limited set of relatively expensive tools to create and configuration manage these artifacts
how gorillas seem to work
How Gorillas Seem to Work
  • On a typical program hundreds (if not thousands) of people work on Systems Engineering.
  • Tools include:
    • Requirements management
    • Architecture development and management
    • Custom data bases
    • Computer modeling
    • Computer aided design
    • To mention the basics
  • The processes used are invariably proprietary
    • Always certified, as in CMMI Level n (Usually 3 or higher)
    • Always involve large number of approval boards
    • Always involve large scale program reviews
  • In the Department of Defense there are specified artifacts, reviews and milestones that must be adhered to
    • DoD 5000 and so on
observations about gorilla systems engineering 1 of 2
Observations About Gorilla Systems Engineering (1 of 2)
  • We offer some observations based on large programs on which we have worked that used Gorilla Systems Engineering:
    • Failure was not an option (though often a result) nor wasbringing problems up the management chain
    • Program management seemed to believe that Systems Engineeringmust not last into production, should not last into testing, and preferably not too far into development. This was probably due to high costs associated with large Systems Engineering efforts.
    • Changes to requirements caused considerable disruption during the entire course of these large programs
    • Linking architecture and requirements is difficult if they are built and managed with separate tools (usually the case)
observations about gorilla systems engineering 2 of 2
Observations About Gorilla Systems Engineering (2 of 2)
  • We offer more observations based on large programs on which we have worked that used Gorilla Systems Engineering:
    • Geographical and organizational diversity made integration really, really hard
    • There were at least two sides to every interface and they never seemed to agree on the documentation
    • No one seemed to know how to define what constitutes a design
    • Nobody seemed to understand how software and hardware designs were to be integrated
    • Process often overshadowed results
    • More time wasspent arguing about process and tools than about results
    • Too many review boards spoiled the product(s)
guerilla systems engineering
Guerilla Systems Engineering
  • Guerilla Systems Engineering tries to deal with the reality of the jungle full of Gorillas and accomplish something helpful
  • It focuses on some aspect of the process that is failing and tries to move outside of the process using small, well integrated teams of experts to make progress
observations about guerilla systems engineering 1 of 2
Observations about Guerilla Systems Engineering (1 of 2)
  • Some of the authors have participated in Guerilla Systems Engineering and offer some observations:
    • Guerillas are born of desperation
    • Guerillas will only be tolerated for a limited time with a very limited focus
    • Roadblocks will be thrown up at every opportunity
    • Stealth is essential but impossible
    • Too much visibility will cause the Guerillas’ early demise
    • Operating outside of the process will cause their early demise
observations about guerilla systems engineering 2 of 2
Observations about Guerilla Systems Engineering (2 of 2)
  • Some of the authors have participated in Guerilla Systems Engineering and offer more observations:
    • Guerillas have a very limited lifetime so they concentrate on analyzing specific critical capabilities and showing sufficiency of end-to-end performance for a relevant set of threads.
    • Guerillas have very limited resources so they have to use inexpensive and widely available integrated and automated tools
    • Guerillas always “lose” in the long run but one case with limited success in the area of design is known
slide11
BUT…
  • Guerilla Systems Engineering characteristics may be more appropriate in the budget constrained future of systems engineering:
    • Sponsors will not want to pay for large SE efforts
    • New approaches to program development such as “Agile”, “IT Box”, and wider integration into an existing “SoS” will probably require both more focus and more flexibility.
    • Capability analysis and “sufficiency” over many capabilities is becoming more important than optimization of a few “critical” capabilities
    • Systems Engineering teams must become smaller and more agile to respond to these trends
    • Systems Engineering tools must become more inexpensive, accessible, flexible, and automated to support these teams.
conclusions
Conclusions
  • Future system engineering efforts, if tolerated at all, will have to operate more like Guerillas than Gorillas
  • A major impediment to Guerillas has been the lack of an inexpensive widely available integrated tool set to allow small groups of organizationally and geographically dispersed experts to match and exceed the work of an army of Gorillas
  • The SPEC Innovations Lifecycle Modeling Language (LML) and tool is designed to empower future Guerillas to succeed. See the following SEDC talks:
    • “Lifecycle Modeling – A Quick Overview of a New Methodology for Simple, Rapid Development, Operations and Support”
    • “Lifecycle Modeling - Application to Software Development“