Evolution and Evolvability George Percivall Evolution and Evolvability Definitions Evolutionary Development Process Definition: development methodology that adapts throughout lifecycle using iteration, user feedback, and Òin-lineÓ prototyping Goal: Develop a system which best meets users needs System Evolvability Definition: the ability of a system to accommodate changes to the requirements, design or implementation in a timely and cost effective manner Goal: Enable the system to be changed economically ¥ Isolate changes to ÒAffordableÓ component replacements or modifications. ¥ Separate fast changing items from slowly changing items Evolution Categories 1. Refinement Through Iteration: convergence of requirements and design (e.g. review of interface mockup) 2. Planned Improvements: improving and adding functionality, technology insertion, system growth (e.g. upgrade of ECS using DAAC development) 3. Paradigm Changes: major changes in user paradigmÿ change in system architecture (e.g. change to OO op. system) Evolutionary Development Process Key Elements of Evolutionary Development Process ¥ User Involvement ¥ Prototypes ¥ Competition ¥ Technology Assessment ¥ Multi-Track Development ¥ Risk Management Each Key Element Alignedÿ with Evolutionary Development Evolutionary Development Process User Involvement Continuous, active user involvement in system decisions Evolution Category 1: ¥ Reviews, RRDB, focus teams ¥ ECS Tirekickers ala V0 Tirekickers ¥ Collaborative Prototypes Evolution Category 2: ¥ ECS upgrades based on user preferences at DAACs, SCFs ¥ User involvement in allocating functionality to releases Evolution Category 3: ¥ ECS University Academic Outreach ¥ NASA Research Announcements ¥ Alternate Architecture Study Evolutionary Development Process Prototypes Prototype to support decisions about future steps in development process Technology Analysis Prototypes ¥ Supports a particular release (Evolution Category 1) ¥ Last step in the technology assessment process ¥ Examples: Evaluation of Archive Robotics Unit Engineering Prototypes ¥ Iteration of requirements and design (Evolution Category 1) ¥ Release planning based on prototypeÿ results (Evolution Category 2) ¥ Example: Building an Expert Advisor/Decision Support for FOS Advanced Prototypes ¥ Visionary investigations: new requirements, paradigms, or architectures for ECS ¥ ECS related, non-release specific (Evolution Category 3) ¥ Example: Alternate Architecture Study Evolutionary Development Process Competition Benefits of competitive approaches to evolve system Evolution Category 1: Parallel prototypes ¥ Identify functions and competitors, define requirements ¥ Method for selecting winner or merging of designs Evolution Category 2: Merging community solutions into baseline ¥ ECS infrastructure to enable, foster competition: e.g. APIs, providing source code ¥ ECS keep abreast of Ònon-ECS developedÓ solutions ¥ Merge some solutions into ECS baseline at later releases Evolution Category 3: Parallel system definitions ¥ Visionaryÿ system conceptsÿ through advanced prototypes ¥ Study other systems implementing similar requirements ¥ Consideration of system architecture changes Evolutionary Development Process Technology Assessment Forward looking assessment and planning for evolution Evolution Category 1: Current Technology ¥ Current Performance FDDI, PCÕs, X-Terms, Small Workstations, etc. Reduced Future Price Evolution Category 2: Technology Insertion ¥ Future Performance Supercomputers, Compute Servers, Workstations, etc. ¥ Future Technology Presently Planned for Use in ECS 3480 Optical Tape Drives and Media, DME, etc. Evolution Category 3: Technology Evolution ¥ Future Technology Under Study MPP Proliferation, High Performance Fortran, Extended Relational and OO Databases, etc. ¥ Standards Open Systems Environment: Portable Systems Software, Portable Applications, Portable Users, Portable Data, Open Communications, etc. Evolutionary Development Process Multi-Track Development Use development methodology appropriate to System/Segment priorities Formal Release Development Track Priorities: Requirements well understood, Support of launch or data storage Process: Waterfall, Formal Reviews, Documentation Examples: Data Ingest, Data Storage, Network Management, Flight Operations Incremental Development Track Priorities: Requirements change with design evaluation Process: Iteration, Monthly Demonstrations, Informal Documentation, Merge with formal track for I&T Examples: Data Access and Management, Toolkits Evaluation Packages Combination of prototypes and increments Delivery Mechanism for User Feedback Evolutionary Development Process Multi-Track Integration Evolutionary Development Process Risk Management Design for Evolvability -- Implement to Requirements and Budget Evolutionaryÿ Risks considered in Risk Management process Evolution Category 1: Requirements Creep, System Reliability ¥ Requirements creep -- Mitigation: Continuing system architecture activity. ¥ Lower reliability of iterated code -- Mitigation: Reliable integration of development tracks Evolution Category 2: Maintainability, Adaptive Flexibility. ¥ Maintainability of iterated code -- mitigation: Reliable integration of development tracks, Software development practices, Adherence to standards and architecture constraints ¥ Adaptive flexibility to changes -- mitigation: System Evolvability Evolution Category 3: Unanticipated Large Changes. ¥ Large late changes of ECS -- mitigation: Evolutionary Development Process, System Evolvability System Evolvability - Agenda Active process of projecting present system into the future and evaluating resulting changes Predicting Evolution ¥ User/Data Model ¥ Evolvability Design Criteria ¥ Evolvability Requirements ¥ Evolvability Tests System Architecture ¥ Elements of a System Architecture ¥ Architecture for Evolvability ¥ Architecture Change Analysis Evolvability Design Criteria Evolvability Requirements Definition of Evolvability Requirements ¥ Requirements for changes that are likely ¥ Contained in specifications, Validated by analysis at PDR/IDR ¥ Present specification contains growth requirements Existing Level 3 Evolvability Requirements - Paraphrased ¥ Accommodate growth in all functions and addition of new functions (EOSD0545) ¥ Support additional spacecraft (FOS-0050) ¥ DAAC growth without changes to architecture or design (DAAC0290) ¥ ESN capacity, performance extensions to meet ECS functions (ESN-1207) Evolvability Requirements (Continued) Potential Level 3 Evolvability Requirements ¥ Provide APIs and infrastructureÿ for science user extensions and direct access to data ¥ Evolve to be an apparent federated unit within GCDIS, e.g. GCDIS data centers should not have to negotiate different interfaces with each DAAC ¥ Facilitate sharing of ECS-developed software with other GCDIS agencies and science users ¥ Extended provider support, e.g. client can access data/services at SCF and DAAC interoperably ¥ Enable addition of significantly different data types with minimal changes ¥ Enable addition of ICCs, ISTs ¥ Enable adding a DAAC, service providers ¥ Enable expansion to GByte Network Evolvability Tests Definition of Evolvability Tests ¥ User paradigm shifts or technology evolution which ECS would need to accommodateÿ ¥ Future requirements, Not in specificationsÿ ¥ Basis for Architecture Change Analysis Examples ¥ Multi-media collaborative environments, videoconferencing. ¥ Heterogeneous (e.g. non-Posix compliant)ÿ operating system environment ¥ Dynamically adding or dropping a DAAC, ADC or ODC ¥ Advances in extended relational and OO Databases ¥ High Performance Computing (MPP proliferation and workstation farms) ¥ Networked in situ sensors: deployed sensor arrays with realtime data acquisitions Elements of a System Architecture Architecture: Modules, Interfaces, Design Constraints Provides structure, reduces complexity to allow engineering analysis for system design Developing and adhering to architecture is key to evolvability Modules ¥ System partitioned into modules: e.g. subsystems, components ¥ Defined by allocation of services: e.g. advertising service Interfaces ¥ Greatest leverage in architecting is at interfaces ¥ Data flow, control flows ¥ Standard interfaces for plug and play in ÒEarth Science WebÓ Design Constraints ¥ Reference Model and Applicable Standards ¥ System interconnection structure System Architecture For Evolvability Traits of a System for Optimal Evolution Based on studies of multiple types of complex systems ¥ System complexity increases with time ¥ Small reusable components Change at the component level ¥ Mixture of Substructureÿ Dynamics Stable intermediate forms Changing components for evolvability ¥ Boundary layer of volatility Analogy to phase transition Architecture Change Analysis Process for looking Ònear-termÓ and Òfar-termÓ simultaneously and iteratively Analyze changes in architecture to address an Evolvability Test Architecture Change Analysis part of each cycle, evolvability considered at each review: ¥ Start with present architecture ¥ Identify applicable Evolvability Tests ¥ Analyze change in architecture to accommodateÿ test ¥ Modify architecture to minimize cost of transitionÿ Present examples ¥ GCDIS/UserDIS Study ¥ Parallel and Distributed Testbed ECS Evolutionary Development Summary To be successful, ECS must evolve Evolutionary Development Process ¥ Develop the System interactively with users ¥ Embed evolution in all processes: Prototyping, Technology Assessmentÿ, Competition, Multi-Track Development, Risk Management ¥ Prepare for all sizes of changes: iteration, upgrades, paradigm shift System Evolvability ¥ Deliver a System which can change cost-effectively ¥ Predict System Changes: User/Data Model, Evolvability Criteria, Evolvability Requirements, Evolvability Tests ¥ System architecture to prepare for evolution