Copyright 1986 2004 Hamilton Technologies Inc Hamilton 1

  • Slides: 44
Download presentation
Copyright © 1986 - 2004 Hamilton Technologies, Inc. Hamilton 1 1 S 216/MAPLD 2004

Copyright © 1986 - 2004 Hamilton Technologies, Inc. Hamilton 1 1 S 216/MAPLD 2004

What if You Could Design Systems and Build Software with: • Seamless integration, including

What if You Could Design Systems and Build Software with: • Seamless integration, including systems to software • • Defects reduced by a factor of 10 • Unambiguous requirements, specifications, designs…removing complexity, chaos and confusion • Guarantee of function integrity after implementation • • Complete traceability and evolvability (application, architecture, technology) • Automatic generation of complete software systems from system specifications (full life cycle automation including 100% production ready code for any kind or size of system) • • Correctness by built-in language properties Significant increase in inherent reuse Automation of much of design/resource allocation; no longer a need to understand details of programming languages and operating systems Elimination of the need for high percentage of testing • An integrated set of life cycle tools, all defined and automatically generated by itself • Significantly higher reliability, higher productivity and lower risk Hamilton 2 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 2 S 216/MAPLD 2004

Perceptions and Perspective • Most people would say “impossible—software by its very nature is

Perceptions and Perspective • Most people would say “impossible—software by its very nature is destined to have the major problems of traditional environments” • Some would say “impossible in the foreseeable future” • Not only is it not impossible; it is possible to accomplish most of these goals today with at least one technology (a technology in large part derived/evolved from Apollo’s on-board flight software effort) • Some might ask how a technology with Apollo roots could address problems "more modern" technologies have not solved • Its evolution differentiates foundations from the "latest" and the "greatest" (e. g. , OS, programming language, life cycle process)—"don’t throw out the baby with the bath water" • Roots also from concepts older and newer than Apollo; keeping in mind the relevance of a technology is independent of its age • New to the marketplace at large, it would be natural to make assumptions about what is possible and impossible based on its superficial resemblance to other technologies—like traditional object technologies • It helps to suspend any and all preconceived notions when first introduced to this technology because it is a world unto itself—a complete new way to think about systems and software Hamilton 3 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 3 S 216/MAPLD 2004

Background: Some Beginnings—Not to Reminisce. . . But to Understand the Culture • Flip

Background: Some Beginnings—Not to Reminisce. . . But to Understand the Culture • Flip of a coin: on-board flight software for Apollo missions • Software engineering/computer science not yet a field (no school to attend) • Learning was by “doing” and “being” • Problems had to be solved no one else had solved. At times we just had to make it up • Stuff we did had to work—the first time • Most were fearless twenty-something (technical managers and engineers) • Dedication and commitment a given • Mutual respect; managers gave software people freedom/trust; software a mystery • Luckiest people in the world; no choice but to be pioneers Hamilton 4 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 4 S 216/MAPLD 2004

No Time to be a Beginner • Some unmanned experiences —Aukekugel [scientists’ method] —Lunar

No Time to be a Beginner • Some unmanned experiences —Aukekugel [scientists’ method] —Lunar Landmark tables —Forgetit • Manned missions came next • These experiences were exciting enough in their own right Hamilton 5 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 5 S 216/MAPLD 2004

Fascination with Errors • Even more exciting: how they contributed to what was to

Fascination with Errors • Even more exciting: how they contributed to what was to happen later, especially that having to do with errors—finding them, detecting and recovering from them, handling them, preventing them, fixing them, learning from them, learning about systems from them…even defining what an error is • Errors had always been fascinating, even before Apollo (SAGE): —Every error a major event (flashing lights, sirens. . . ) —Polaroid pictures taken of the crash site (person responsible) —One day turnaround encouraged careful thought and multiple cases, in parallel test —Seashore tracking program: finding the errors Hamilton 6 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 6 S 216/MAPLD 2004

It Quickly Became Clear No One and Nothing is Perfect • Software gurus, hardware

It Quickly Became Clear No One and Nothing is Perfect • Software gurus, hardware gurus, astronauts included • Expect the "unexpected" [lightning struck spacecraft at least twice]: always have backups, "what ifs" • Always searching for new and different ways to prepare for the unexpected —P 01 (3 year old), explicit real time "debug“, program notes —Erroneous hardware signals on Apollo 14 (faked out software with manual intervention in real time). Simulation —Asynchronous operating system (systematic reconfiguration in real time) —Priority display (off nominal, emergencies): 1201, 1202 alarms (Apollo 11) • Houston meeting said it all Hamilton 7 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 7 S 216/MAPLD 2004

Other Apollo Experiences Gave Insight to Understanding Software (and its Development) as a System

Other Apollo Experiences Gave Insight to Understanding Software (and its Development) as a System with a System Engineering Viewpoint • "What goes around comes around“; everything somehow related to everything else; one seemingly small event can change everything, for better or worse (ACS) • The very way one communicates can cause or prevent crashes, little ones and big ones (man/tech): ACS daily memos and off line versions • Programmers and designers necessarily became interchangeable; as did life cycle phases • Relationship of real time and development (async) • “System wide recompute restart” far superior to “point repair with fallback results” restart • Everything a moving target. The only constant is change • Build on foundations that allow for freedom of choice without compromising integrity (open architecture, async) • Never say never: more than one way to solve a problem (how affected, not what caused it) • Once understood as a true system, possible to use power of reuse to the hilt and to the highest form (wisdom) Hamilton 8 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 8 S 216/MAPLD 2004

Experiences Like These Compelled Us to Learn from Them So Future Systems Could Benefit:

Experiences Like These Compelled Us to Learn from Them So Future Systems Could Benefit: Top Priority—Reliability • • • Apollo: opportunity to make just about every kind of error humanly possible (no software errors during flight) "What were we doing wrong so we could stop doing it and what were we doing right so we could keep doing it? " Analyzed every aspect possible of on board flight software and its relationships • Error study. . . majority interface (data, timing, priority conflicts to the finest grain): ambiguous relationships, mismatches and conflicts in the system, communication, integration and coordination problems. Military studies later had similar findings • What is an "error"? * (medical): FLTs…catastrophic • Led to a new mathematics/paradigm for designing systems and building software that would, among other things, eliminate all interface errors • Repeat the process over and over again. . . never assume anything or anyone is perfect *Hamilton, M. , Hackler, W. R. , What is an Error? , System Oriented Objects: Development Before the Fact, In Press. Hamilton 9 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 9 S 216/MAPLD 2004

Note 1: no software errors known to occur during flight Note 2: majority of

Note 1: no software errors known to occur during flight Note 2: majority of 44% found by "Nortonizing" 001™ is a trademark of Hamilton Technologies, Inc. Hamilton 10 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 10 S 216/MAPLD 2004

Root problem: traditional system engineering and software development environments support users in "fixing wrong

Root problem: traditional system engineering and software development environments support users in "fixing wrong things up" rather than in "doing things in the right way in the first place". Hamilton 11 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 11 S 216/MAPLD 2004

Solution: Development Before the Fact A new paradigm: define each system with inherent properties

Solution: Development Before the Fact A new paradigm: define each system with inherent properties ("come along for the ride") that support its own development. • Each definition not only models its application but it also models properties of control into its own life cycle. • Every object is a System Oriented Object (SOO), itself developed in terms of other SOOs. A SOO integrates all parts of a system including those that are function, object and timing oriented. Every system is an object. Every object is a system. • Instead of Object Oriented Systems, System Oriented Objects. Instead of model driven systems, system driven models • What is different about DBTF is it is preventative instead of curative. Instead of looking for more ways to test for errors, look for more ways not to let them in, in the first place Development Before the Fact™, DBTF™ System Oriented Object™ and SOO™ are trademarks of Hamilton Technologies, Inc. Hamilton 12 12 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

With Development Before the Fact a System is Defined from the Very Beginning to

With Development Before the Fact a System is Defined from the Very Beginning to Inherently: • Integrate and make understandable its own real world definitions • Maximize its own —Reliability and predictability —Flexibility to change and the unpredictable • Capitalize on its own parallelism • Maximize the potential for its own —Reuse —Automation —Evolution RESULT: a formal based system with built-in quality, and built-in productivity for its own development Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 13 13 S 216/MAPLD 2004

The Universal Systems Language (001 AXES) is the Key: Defines Each System with Development

The Universal Systems Language (001 AXES) is the Key: Defines Each System with Development Before the Fact Properties • Same language used to define and integrate —All aspects and viewpoints* (of and about the system and its evolutions); relationships; levels and layers of requirements, analysis and design (seamless lifecycles) —Functional, resource and allocation architectures including hardware, software and peopleware —Sketching of ideas to complete systems —GUI with documentation…with application —Maps: hierarchical network control systems of interrelated objects • Syntax, implementation, and architecture independent • Unlike formal languages that are not friendly and friendly languages that are not formal this language is both formal and friendly *Adheres to the principle that everything is relative. One person’s design is another person’s implementation. Universal Systems Language™ (USL™), 001 AXES™ and Development Before the Fact™ are trademarks of Hamilton Technologies, Inc. Hamilton 14 14 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

Process of Building a Before the Fact System • Define/Evolve any model in any

Process of Building a Before the Fact System • Define/Evolve any model in any phase (problem analysis, specifications, operational scenarios, constraints, design…) with the before the fact systems language • Analyze automatically the model to ensure it was defined properly • Generate automatically a complete, integrated, fully production ready software implementation/simulation/ documentation for the architecture of choice consistent with the model – Process is iterative/recursive – Can be parallel, asynchronous or incremental – Can be used for rapid prototyping or for production ready, full scale development • Execute the model • Deliver the real system Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Hamilton 15 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 15 S 216/MAPLD 2004

001 is used to make System Oriented Objects, each of which is based upon

001 is used to make System Oriented Objects, each of which is based upon a unique concept of control ™ § Every system defined with 001, including 001 itself, is defined in terms of System Oriented Objects § 001 was used to completely define–and completely and automatically (re)generate–itself 001™ and System Oriented Objects™ are trademarks of Hamilton Technologies, Inc. Hamilton 16 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 16 S 216/MAPLD 2004

DBTF Philosophy: Reliable Systems are Defined in Terms of Reliable Systems • Use only

DBTF Philosophy: Reliable Systems are Defined in Terms of Reliable Systems • Use only reliable systems • Integrate these systems with reliable systems PRIMITIVE SYSTEMS • The result is a system(s) which is reliable ABSTRACT SYSTEMS • Use resulting reliable system(s) along with more primitive ones to build new and larger reliable systems MORE ABSTRACT SYSTEMS A recursively reliable and reusable process Development Before the Fact™ (DBTF™) is a trademark of Hamilton Technologies, Inc. Hamilton 17 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 17 S 216/MAPLD 2004

SOO ™, 001 AXES™, Function Map™ (FMap™) and Type Map™ (TMap™) are trademarks of

SOO ™, 001 AXES™, Function Map™ (FMap™) and Type Map™ (TMap™) are trademarks of Hamilton Technologies, Inc. Hamilton 18 18 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Hamilton 19 Copyright ©

Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Hamilton 19 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 19 S 216/MAPLD 2004

001 AXES™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton Copyright ©

001 AXES™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 20 20 S 216/MAPLD 2004

Systems Defined in Terms of the Primitive Control Structures Result in Properties for Real

Systems Defined in Terms of the Primitive Control Structures Result in Properties for Real Time Distributed Environments Every parent has a higher priority and Behaves as a master scheduler for its children A system is defined from the very beginning to inherently maximize its own flexibility to change and the unpredictable and to capitalize on its own parallelism Every object has a unique parent and is under control Every system is event-driven Concurrent patterns can be automatically detected Every object has a unique priority Each object and changes to it are traceable Each object can be safely reconfigured ("pluggable" and "unpluggable") Primitive Control Structures™ is a trademark of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 21 21 S 216/MAPLD 2004

Hamilton 22 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 22 S 216/MAPLD 2004

Hamilton 22 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 22 S 216/MAPLD 2004

Hamilton 23 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 23 S 216/MAPLD 2004

Hamilton 23 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 23 S 216/MAPLD 2004

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 24 Copyright © 1986

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 24 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 24 S 216/MAPLD 2004

001 AXES™, TMaps™, EMaps™, FMaps™ and Executor ™ are all trademarks of Hamilton Technologies,

001 AXES™, TMaps™, EMaps™, FMaps™ and Executor ™ are all trademarks of Hamilton Technologies, Inc. Hamilton 25 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 25 S 216/MAPLD 2004

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 26 Copyright © 1986

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 26 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 26 S 216/MAPLD 2004

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 27 Copyright © 1986

FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 27 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 27 S 216/MAPLD 2004

Primitive Control Structure™ and FMap™ are trademarks of Hamilton Technologies, Inc. Hamilton Copyright ©

Primitive Control Structure™ and FMap™ are trademarks of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 28 28 S 216/MAPLD 2004

TMap™ is a trademark of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004

TMap™ is a trademark of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 29 29 S 216/MAPLD 2004

Architecture Independent Operating System™ (AIOS™), RAT™, DXecutor™, FMap™ and TMap™ are trademarks of Hamilton

Architecture Independent Operating System™ (AIOS™), RAT™, DXecutor™, FMap™ and TMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 30 30 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

 Hamilton 31 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 31 S 216/MAPLD

Hamilton 31 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 31 S 216/MAPLD 2004

TMap™ and FMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 32 Copyright © 1986

TMap™ and FMap™ are trademarks of Hamilton Technologies, Inc. Hamilton 32 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 32 S 216/MAPLD 2004

Object Map™ (OMap™), Type Map™ (TMap™), Execution Map™ (EMap™) and Function Map (FMap™) are

Object Map™ (OMap™), Type Map™ (TMap™), Execution Map™ (EMap™) and Function Map (FMap™) are all trademarks of Hamilton Technologies, Inc. Hamilton 33 33 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

OMap™, TMap™, EMap™ and FMap™ are all trademarks of Hamilton Technologies, Inc. Hamilton 34

OMap™, TMap™, EMap™ and FMap™ are all trademarks of Hamilton Technologies, Inc. Hamilton 34 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 34 S 216/MAPLD 2004

RMaps™, OMaps™, TMaps™, EMaps™ and FMaps™, RAT™ are all trademarks of Hamilton Technologies, Inc.

RMaps™, OMaps™, TMaps™, EMaps™ and FMaps™, RAT™ are all trademarks of Hamilton Technologies, Inc. Hamilton 35 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 35 S 216/MAPLD 2004

RT(x)™, FMaps™, TMaps™, Xecutor™, RT(x)™, 001 AXES™, Analyzer™, and RAT™ are all trademarks of

RT(x)™, FMaps™, TMaps™, Xecutor™, RT(x)™, 001 AXES™, Analyzer™, and RAT™ are all trademarks of Hamilton Technologies, Inc. Hamilton 36 36 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

RMaps™, Omap Editor™, TMaps™, RAT™, EMaps™ and FMaps™ are all trademarks of Hamilton Technologies,

RMaps™, Omap Editor™, TMaps™, RAT™, EMaps™ and FMaps™ are all trademarks of Hamilton Technologies, Inc. (8 -30 -04) Hamilton 37 37 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

Xecutor™, 001 AXES™, RAT™ and AIOS™ are all trademarks of Hamilton Technologies, Inc. Hamilton

Xecutor™, 001 AXES™, RAT™ and AIOS™ are all trademarks of Hamilton Technologies, Inc. Hamilton 38 Copyright © 1986 - 2003 Hamilton Technologies, Inc. 38 S 216/MAPLD 2004

Before the Fact Testing: an Integral Part of Every Phase (Instead of Testing Something

Before the Fact Testing: an Integral Part of Every Phase (Instead of Testing Something Over and Over Again After the Fact) • Correct use of 001 AXES eliminates majority of errors The need for most kinds of testing used in a traditional environment is removed. Most errors are prevented because of that which is inherent or automated (i. e. , reused) • Analyzer hunts down all interface errors • RAT always generates 1) embedded test cases into code for finding during execution incorrect object use; 2) test harnesses for testing each object and its relationships • Inherent reuse and automation remove need for most other testing: e. g. , built in aspects, inherent integration, 100% of code automatically generated • Inherent testing support facilities include demotion and configurable RAT • Testing components include Xecutor, RT(x) and Coverage Analysis Tool • Remaining test cases can be defined and developed as 001 applications including those having to do with defining constraints Since RT(x) automates the process of going from requirements to design to tests to use cases to other requirements and back again the need to ensure the implementation satisfies the design and the design satisfies the requirements is minimized • Maintenance shares same benefits as development -developer doesn't ever need to change the code -application changes made to the specification-not the code -architecture changes made to the configuration-not the code -only the changed part of the system is regenerated and integrated with the rest of the application (again, all automatically). The system is automatically analyzed, generated, compiled, linked and executed without manual intervention. Xecutor™, RT(x)™, 001 AXES™, Analyzer™ and RAT™ are all trademarks of Hamilton Technologies, Inc. Hamilton 39 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 39 S 216/MAPLD 2004

Alternative Approaches: Began with Opposite Focus • Traditional —Software centric —Syntax first: software language(s)

Alternative Approaches: Began with Opposite Focus • Traditional —Software centric —Syntax first: software language(s) for defining software with (or without) object orientation —In some cases many languages "merged" into one language —Additional language mechanisms (sometimes additional languages), rules and tools added, ad hoc and "after the fact", as more is learned about a class of software systems • Development Before the fact —Systems centric —Semantics first: empirical study of real world systems from which core foundations were derived for a generic system semantics that led to a universal systems language —Universal systems language used for defining (and developing) system oriented objects for software and systems in general —Additional language mechanisms derived from core set of systems language primitive mechanisms • Much of what seems counterintuitive with traditional techniques becomes intuitive with DBTF Development Before the Fact™ (DBTF™) and Universal Systems Language™ (USL™) are trademarks of Hamilton Technologies, Inc. Hamilton 40 40 Copyright © 1986 - 2004 Hamilton Technologies, Inc. S 216/MAPLD 2004

Part 1 of 2 parts Some Differences Traditional (After the Fact) Before the Fact

Part 1 of 2 parts Some Differences Traditional (After the Fact) Before the Fact Integration ad hoc, if at all ~Mismatched methods, objects, phases, products, architectures, applications and environment ~System not integrated with software ~Function oriented or object oriented ~GUI not integrated with application ~Simulation not integrated with software code Integration ~Seamless life cycle: methods, objects, phases, products, architectures, applications and environment ~System integrated with software ~System oriented objects: integration of function, timing, and object oriented ~GUI integrated with application ~Simulation integrated with software code Behavior uncertain until after delivery Correctness by built-in language properties Interface errors abound and infiltrate the system (over 75% of all errors) ~Most of those found are found after implementation ~Some found manually ~Some found by dynamic runs analysis ~Some never found No interface errors Ambiguous requirements, specifications, designs … introduce chaos, confusion and complexity ~Informal or semi-formal language ~Different phases, languages and tools ~Different language for other systems than for software Unambiguous requirements, specifications, designs … remove chaos, confusion and complexity ~Formal, but friendly language ~All phases, same language and tools ~Same language for software, hardware and any other system No guarantee of function integrity after implementation Guarantee of function integrity after implementation ~All found before implementation ~All found by automatic and static analysis ~Always found System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc. Hamilton Copyright © 1986 - 2004 Hamilton Technologies, Inc. 41 41 S 216/MAPLD 2004

Some Differences (Cont. ) Traditional (After the Fact) Part 2 of 2 parts Before

Some Differences (Cont. ) Traditional (After the Fact) Part 2 of 2 parts Before the Fact Inflexible: Systems not traceable or evolvable ~Locked in bugs, requirements products, architectures, etc. ~Painful transition from legacy ~Maintenance performed at code level Flexible: Systems traceable and evolvable ~Open architecture ~No longer a need to understand details of programming languages or operating systems ~Smooth transition from legacy ~Maintenance performed at spec level Reuse not inherent ~Reuse is adhoc ~Customization and reuse are mutually exclusive Inherent Reuse ~Every object a candidate for reuse ~Customization increases the reuse pool Automation supports manual process instead of doing real work ~Mostly manual: documentation, programming, test generation, traceability, integration ~Limited, incomplete, fragmented, disparate and inefficient Automation does real work Trapped in "test to death" philosophy Less testing becomes necessary with each new before the fact capability Product x not defined and developed with itself 001 defined with and generated by itself Dollars wasted, error prone systems Ultra-reliable systems with unprecedented productivity in their development ~Low risk ~Maximum dollars saved/dollars made ~Minimum time to complete ~No more, no less of what you need ~Automatic programming, documentation, test generation, traceability, integration ~100% production ready code automatically generated for all and any kind or size of software ~High risk ~Not cost effective ~Difficult to meet schedules ~Less of what you need and more of what you don’t need System Oriented Objects™ and 001™ are trademarks of Hamilton Technologies, Inc. Hamilton 42 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 42 S 216/MAPLD 2004

Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Hamilton 43 Copyright

Development Before the Fact™ is a trademark of Hamilton Technologies, Inc. Hamilton 43 Copyright © 1986 - 2004 Hamilton Technologies, Inc. 43 S 216/MAPLD 2004

The Heart and Soul of Apollo: Doing it Right the First Time MAPLD International

The Heart and Soul of Apollo: Doing it Right the First Time MAPLD International Conference September 9, 2004 Margaret H. Hamilton Technologies, Inc. Much of the material contained in this presentation is based on work sponsored by the Deeply Integrated-Guidance Navigation Unit (DI-GNU) program, U. S. Army ARDEC, Picatinny Arsenal, NJ Images on Slide 1 and this Slide are from The Apollo Prophecies Copyright © Nicholas Kahn & Richard Selesnick Hamilton 44 Copyright © 1986 - 2004 Hamilton Technologies, Inc. (8 -24 -04) 44 S 216/MAPLD 2004