Title: Technology for Evolutionary Software Development
1Technology for Evolutionary Software Development
- Dr. W. Morven Gentleman
- Global Information Networking Institute
- Chair, IST-026/RTG-008
- www.cs.dal.ca/ESD
2Why Evolutionary Software Development?
- Successful software must evolve
- To address new requirements
- To take advantage of new technology
- To meet new expectations
- Conventionally, each update is treated as an
isolated project with fixed specifications
3Why Evolutionary Software Development
- Since there will be multiple releases anyway,
instead of single Big Bang, deployment can be
spread across releases to reduce
time-to-market/time-to-field - Provides developer a revenue stream earlier
- Provides customer limited capability earlier
- User feedback can improve product success but
creates new expectations/requirements
4What is Evolutionary Software Development?
- Evolutionary Software Development recognizes that
planning for the whole lifetime, with all its
changes, including those unforeseen, can reduce
lifecycle costs and accelerate delivery of new
functionality.
5Evolutionary Software Development differs from
- Traditional waterfall
- Releases not constrained to meet requirements
- Traceability not sacrosanct
- Boehms spiral development model
- Releases are fully deployed
- Incremental development
- Functionality may be retracted, not just added
6Some NATO DCI predicated on evolving software
- Capacity to integrate non-NATO nations with their
own standards - Need of automated and deployable NATO C3 Systems
- Reprogrammability of existing EW systems
- Improvements in data processing in the fields of
STAR (Surveillance, Target Acquisition and
Reconnaissance), C2, communications, EW, avionics
and vetronics (land operations)
7Choice of Software Architecture(components and
relationships)
- What architecture meets runtime needs?
- What architecture facilitates development?
- What architecture facilitates anticipated
possible changes? - What COTS components help and what architectural
implications are imposed? - What architecture encapsulates changes in COTS
and other third-party components?
8Choice of Software Process
- What processes facilitate development?
- What processes facilitate maintenance?
- What processes avoid redundancy across releases?
- What processes facilitate early delivery of
partial functionality? - What can be automated?
- Will process and tools be mandated?
9Incremental Delivery
- Is the time scale nightly build?
- Is the time scale product release?
- What defines a release?
- Ship date
- Budget
- Partial functionality completion
- How to decide what to defer?
- What is the basis for acceptance?
10Concurrent Development of successive releases
- Can unrelated changes be developed concurrently
by multiple teams or subcontractors? - How to identify, evaluate, select, and manage
such? - If multiple releases are in the field, how to
efficiently maintain all simultaneously? - When to initiate development of a new release?
- How to represent initial ideas for future
releases?
11Coping with Platform Evolution
- Changes in both software and hardware?
- Can use portable software, e.g. Java?
- Can converter tools apply source code
transformations systematically? - What if third-party components dont upgrade?
12Data Structure and Format evolution
- Changes to
- Input?
- Output?
- Database?
- Control directives?
- Can conversion tools apply changes systematically?
13Interoperability
- Software used in conjunction with this software
evolves too? - Unrelated, complementary, and alternative
- Require interoperability at all levels?
- Co-existence with other software
- Backward and forward compatibility
- Integration
14Configuration Management
- Contrast with configuration control
- Nontextual entities?
- Third-party software?
- E.g. prime contractor and subcontractors
- Configuration management at customer site?
- Tailoring
- Rationale
15If CM foresight fails?
- Reverse Engineering technologies
- Design recovery
- Program understanding
- Reconstruction of rationale
- Reuse technologies
16Testing and QA
- What regression testing is appropriate?
- Changes induce need for integrity testing?
- Need inter-release consistency testing?
- Automate integration testing?
- Automate installation and upgrade testing?
- How to beta-test successive releases?
- Incremental QA?
17Automated Field Support
- Plug-and-Play installation configuration
- Automated upgrading
- Registry concept and uninstall?
- Compatible data exchange with earlier and later
releases
18Aids for retraining users
- Semi-automated design and production of training
manuals? - Semi-automated design and production of training
exercises? - Semi-automated design and production of
integrated wizards?
19Implications for procurement
- Balancing long-term relationships
- Cost of maintaining team
- Challenge of maintaining interest
- Commitment to continued activity
- Opportunities for reassessment
- Support for Prime/Sub relationship
- Alternatives for progress payments?
- How to change the culture?
20Conclusions
- Paradigm shift from traditional approach
- Widely applicable
- Principal challenge is to gain acceptance
- Plenty of opportunities for research