Lessons Learned in Developing an International Planning Software System

1
Lessons Learned in Developing an International
Planning Software System

• Randy Saint
• Consolidated Space Operations Contract / Lockheed
  Martin
• Space Ops 2002
• October 9-12, 2002

2
Outline

• Background
• Planning System
• History
• Lessons Learned 5 Categories
• Design Decisions
• Development Methods
• User Requirements
• External Interfaces
• Platform
• Conclusion/Summary

3
Background

• Consolidated Planning System (CPS)
• Subsystem of Integrated Planning System (IPS)
• Software Application used for planning
  scheduling crew and automated activities on U.S.
  Space Shuttle and International Space Station
• CPS History
• Consolidated several planning tools into one
  all-in-one tool
• Used as the standard method for planning data
  exchange between NASA control centers and
  International Partners
• Development Cycle
• New software releases generally require 6-9
  months development time
• Application details
• Languages C/C, ProC, ProC, SQL
• Size Over 380 K SLOC
• GUI X Windows OSF/Motif for display GUI
• Platform IBM/AIX Power PC workstations

4
Lessons Design Decisions
Design decisions must be considered not only on
how they affect the existing system, but also on
how they will affect the system in the future

• Consider software maintainability before
  incorporating prototyped re-use software
• Prototype software was included in main
  application due to time resource limitations
• Maintainability of the application was hampered
  by the difficulties in working with the prototype
  software
• Using proprietary, unique file formats for data
  exchange limits future flexibility and requires
  frequent updates
• Data formats tied too closely to the application
  data structures forces format changes for any
  data revisions
• Problems exacerbated when other groups develop
  software to read write data exchange files

5
Lessons Design Decisions

• The planning applications need a reliable method
  for merging timeline data
• Timeline Integrate functionality allows users to
  merge data from 2 timelines
• Allows users to filter data to integrate only
  data specific to a planning center
• Distributed planning requires a method to track
  objects across multiple users and multiple
  control centers
• Each object, including copies on other timelines,
  must have a unique identifier within a local
  database
• Each object must have an identifier that is
  common across all planning centers
• Data structure efficiency must be considered from
  the start of development
• Size and quantity of current planning data can
  seriously hamper performance of the system
• Efficiency of the data structures and storage
  must also be considered

6
Lessons Development
Contract restrictions and development methods
play a critical role in the creation, update and
usage of an application.

• Users desire quick turn around on certain
  software updates
• Users often identify a problem while working
  towards an upcoming mission. Often no time to
  produce a fix via software update
• Often, a quick turnaround is not possible unless
  the fix is deemed critical or mandatory
• Manual testing of application inefficient and
  error prone
• Current test procedures are instructions for
  human testers to step through and verify
  application functionality
• Automated procedures may be more efficient and
  reduce errors when the tests are executed
• User evaluation testing of the software is
  critical
• User demonstrations often take the place of users
  evaluating the software hands on
• High demands on the users time have limited
  their availability to perform user evaluation
  testing before the software is released to
  operations

7
Lessons User Requirements
An application tied closely to the user community
must rely on the users to define accurate and
stable requirements.

• Focusing on current operational needs creates
  system requirements that may not be applicable in
  future operations
• Changing Ops Concepts can lead to functionality
  implemented that is now unused
• Loss of time/effort that could have been spent on
  long range or shared requirements
• Multiple User Demographics are sometimes
  difficult to reconcile
• Different user communities utilize the software
  in different ways and have different data needs
• International Space Station (ISS)
• Space Shuttle Program (SSP)
• ISS Payloads (at MSFC)

8
Lessons User Requirements

• Prioritizing work on a yearly basis can provide
  flexibility to reprioritize for changing
  operations concepts, but also inhibits long range
  updates to the planning process and applications
• New functionality added to the periphery of the
  application, rather than the core
• Updates are limited in scope to what can be
  accomplished in a year
• Users require easy access to data for producing
  standard and ad-hoc reports
• The data that is being generated and maintained
  is important, more so than the format
• Storing data in an Oracle database allows for
  some user generated queries and reports, however
  data must be stored in standard, readable formats
• Tools to retrieve data and generate reports are
  necessary for the users
• User support of the development design of the
  application is critical to the overall usability
  of the application
• The benefits of user involvement are tied to the
  amount of participation in the development process

9
Lessons External Interfaces
Distributed planning requires an application that
can interface with other applications.

• A standard file format for data exchange should
  be identified containing a core set of data
  fields with flexibility for future changes
• Using a unique file format requires that all
  applications intending to use the data must write
  custom code to read it
• Using a file format that includes all parameters
  fields forces the format to change with every
  database change
• Utilizing data files for planning data exchange
  works well for distributed planning
• Using files allows flexibility for when how to
  merge other planning centers data
• Files also provide for an informal method to
  backup users data

10
Lessons External Interfaces

• Synchronization of International Planning tools
  requires not only file format planning
  upgrades, but also schedule coordination
• File format changes must be communicated
• Schedules must be coordination between external
  applications so that upgrades do not break the
  interface
• Data integrity rules are critical to maintaining
  accurate plans
• Prevents application errors resulting from from
  incorrect data

11
Lessons - Platform
Every application is dependent on the hardware,
however the dependency can be minimized.

• Building application on one platform can restrict
  flexibility for hardware upgrades
• Using proprietary software libraries can prevent
  changes to new hardware or operating systems if
  they are not supported
• Users require remote access to plans
• The planners have many customers for their
  plans that require a view-only copy of the plans
• Some users customers require the actual data
  in order to perform their own planning and
  scheduling
• Inadequate data sizing can pose problems with
  future performance of the tool
• Size and quantity of current planning data
  seriously hampers performance of the system
• Users expected to increase the amount of data
  that must be manipulated and stored

12
Summary

• Software developers and mission planners must
  work together to create a vision for the future
  of the software tools
• Space mission planning is a complex task that
  requires a complex application or set of
  applications to support the mission planners
• Any application that exchange data with other
  applications must consider the external
  interfaces
• The dynamic environment of ISS planning requires
  flexibility of the tools and flexibility of
  development and design changes
• Decisions made today about the design of the
  applications will affect the way the software is
  used and even the space mission planning process
  in the future

13
Authors Advice

• Get the users involved early and keep them
  involved throughout the development process
• Define and agree upon a stable operations concept
  and minimize changes to it over time
• Generate realistic sizing estimates for the
  amount of data necessary
• Define the data structures and exchange data
  independent from the application
• Use a standard, flexible method for defining the
  data exchange between applications
• Keep in mind how to track data throughout the
  global system and how to merge the data
• Provide methods for non-users to view the data
  generated by the application users
• Carefully consider how each upgrade will affect
  the system and how it will be used long-term
• Make the application portable or platform
  independent
• Use automated testing tools for regression
  testing the application

14
Acronyms

• CPS Consolidated Planning System
• CSOC Consolidated Space Operations Contract
• IP International Partner
• IPS Integrated Planning System
• ISS International Space Station
• JSC Johnson Space Center
• MSFC Marshall Space Flight Center
• NASA National Aeronautics and Space
  Administration
• SSP Space Shuttle Program