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 Project Management Plan Software Assurance Plan (includes safety and security) Software Assurance Plan (includes safety and security) Software Development Plan Software Development Plan Verification & Validation Plan Verification & Validation Plan Maintenance Plan Maintenance Plan Configuration Management 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 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.