Technology for Evolutionary Software Development

1
Technology for Evolutionary Software Development

• Dr. W. Morven Gentleman
• Global Information Networking Institute
• Chair, IST-026/RTG-008
• www.cs.dal.ca/ESD

2
Why 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

3
Why 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

4
What 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.

5
Evolutionary 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

6
Some 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)

7
Choice 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?

8
Choice 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?

9
Incremental 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?

10
Concurrent 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?

11
Coping 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?

12
Data Structure and Format evolution

• Changes to
• Input?
• Output?
• Database?
• Control directives?
• Can conversion tools apply changes systematically?

13
Interoperability

• 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

14
Configuration Management

• Contrast with configuration control
• Nontextual entities?
• Third-party software?
• E.g. prime contractor and subcontractors
• Configuration management at customer site?
• Tailoring
• Rationale

15
If CM foresight fails?

• Reverse Engineering technologies
• Design recovery
• Program understanding
• Reconstruction of rationale
• Reuse technologies

16
Testing 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?

17
Automated Field Support

• Plug-and-Play installation configuration
• Automated upgrading
• Registry concept and uninstall?
• Compatible data exchange with earlier and later
  releases

18
Aids 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?

19
Implications 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?

20
Conclusions

• Paradigm shift from traditional approach
• Widely applicable
• Principal challenge is to gain acceptance
• Plenty of opportunities for research