NASA/JSC/MOD/Brian O’Hagan 2008 Software Assurance Symposium (SAS) Sept 10, 2008

1. Technology Infusion of the Software Developer’s Assistant (SDA) into the MOD Software Development Process NASA/JSC/MOD/Brian O’Hagan 2008 Software Assurance Symposium (SAS) Sept 10, 2008

2. Executive Briefing • Problem/Approach • Relevance to NASA • Current capability of the research (and project(s) you are working with) • Planned capability of research (and the type of project or phase in lifecycle your work can benefit) • Technical challenges (which should include any obstacles to overcome or any drawbacks/limitations to your approach)

3. Problem Statement • JSC Mission Operations Directorate (MOD) software must be developed following the new MOD software development process which complies with the NASA software standards. • This process includes the following plans: • Software Project Management Plan • Software Assurance Plan (includes safety and security) • Software Development Plan • Verification & Validation Plan • Maintenance Plan • Configuration Management Plan • The impact is: • All projects must use the new processes & procedures. This implies increased time and cost as compared to the previous process. • Additional training is required for inexperienced personnel such as new hires and those without relevant software process experience. • Strict adherence to process and NASA requirements requires: • Increased administrative and clerical requirements • Increased metrics collection requirements • Increased interaction between different software team roles • The bottom-line is more process means less time for development or an overall increase in the project cost, time, etc.

4. Approach • The Software Developer’s Assistant (SDA) was developed by the JSC/Engineering directorate to track their software development process. It is a workflow tool which captures the required steps, project progress, and assigns the steps/tasks automatically when the previous steps are completed. • MOD has experience with the use of workflow tools for procedures, flight rules, etc. So with a few modifications, SDA could be used to track the MOD process. This required a few tool modifications for: • Use of the MOD process steps • Use of the MOD allowed software life cycles • Additional steps to capture coordination between MOD and external stakeholders • The goal of the Infusion was to determine the usefulness of SDA for software development and to determine if additional changes would be needed in SDA prior to roll-out for general usage.

5. Relevance to NASA • This is relevant to NASA for the following reasons: • All software we develop must comply with the NASA software standards. SDA helps track completion of the process steps to ensure compliance with the standards. • We must track progress and status. SDA captures this info as part of the nominal usage rather than requiring special or manual steps. • SDA improves the development process by: • Providing a standard workflow for users when developing software • Automatically capturing the progress and results of the software process life-cycle steps • Automatically collecting process metrics on activities performed by the software team • Automatically capturing the direct and indirect artifacts created throughout the lifecycle such as documents, assessments, etc. • Reducing the time needed for process training and overhead • When steps need to be re-performed, SDA can capture the new results without losing the original artifacts

6. Current Capability • The SDA tool was modified to provide a MOD compliant process for a class A safety critical software project and a class D non-safety critical software project. • The steps were tailored to the specific projects in order to expedite starting the evaluation. • The primary objectives were to: • Provide a comparison between a workflow process and the old manual process in order to determine the time and effort savings a workflow could provide • Find tool improvements prior to roll-out to the general MOD software development community • The secondary objectives were to: • Find areas for improvement in the MOD software development processes • Improve coordination between MOD and other organizations involved in software development such as the program office and safety • All objectives were achieved.

7. Planned Capability • The process and tool improvements found during the Infusion, will be flowed back into the next release. This includes: • Workflow tailoring based on: • Variations in project size • Sequencing of steps based on the software development life-cycle • Define required steps based on the NPR 7150.2 Software classifications • Apply additional steps depending on the software assurance level • Apply additional steps for safety critical software • Process improvements • Coordination steps between MOD and other organizations • Updates to the MOD software development plans • Fill in process holes • Improvements to better define tasks • Re-sequence tasks for better efficiency • Future tool releases will need to allow the user to create new steps as needed in order to capture external or unforeseen steps. • Additional software development life cycles will also be added to better fit MOD needs.

8. Technical Challenges • There were no insurmountable technical challenges. • We did find challenges in the following areas: • Delays in start-up due to the budget process. We chose to start the processes before this issue was worked out in order to complete the work by the end of the FY. • Use of the tool to capture inputs from external organizations will require further work for tool access and usage agreements. • The need for tailoring was emphasized in order to handle the many variations of MOD software. This will be included in the next tool release.