1 / 35

State of the SARP

State of the SARP. NASA OSMA Software Assurance Research Program Overview 9 August 2005 Kenneth McGill. Overview. Why SARP? Goals and Objectives Recent Evolution and Status Metrics Where we are going. Why SARP?. Because software is different Because software will bite you Safety

vincentp
Download Presentation

State of the SARP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. State of the SARP NASA OSMA Software Assurance Research Program Overview 9 August 2005 Kenneth McGill

  2. Overview • Why SARP? • Goals and Objectives • Recent Evolution and Status • Metrics • Where we are going

  3. Why SARP? • Because software is different • Because software will bite you • Safety • Mission risk • Cost and Schedule risk

  4. Software is Different

  5. Software is Different • Component failure follows bathtub curve • Will function the same over a range of operational scenarios • Can be completely tested • No hidden functionality

  6. Software is Different

  7. Software is Different • Failure is event driven (Doesn’t follow a bathtub curve) • Can have hidden functions • Near infinite state space • Can never fully test all scenarios

  8. Software is Different • Fully IV&Ved system • BTW, don’t think you are going to solve your software problems by reuse. His code was designed for reuse.

  9. Software is Different • Software failures are not a function of time but input • Can’t determine reliability with finite testing • FMEA and FTA don’t apply straight out of the box • Can never test all possible scenarios • After years of use you can still have unexplored paths • Safety and mission risks are harder to quantify • Can’t simply make it more reliable by adding redundancy

  10. Software is Different • Software cost and schedule requirements are often under estimated • Software requirements often get refined (creep) • Obviously results in development risk • Also results in • Shortcuts to make up time • Truncated testing • More safety and mission type risk

  11. Software is Different • We have both the best and the worst in software development sitting side by side • Things we knew 20 years ago still aren’t consistently applied • Too many exceptions to the rules • Too many scientists and too few engineers

  12. Software is Different • We must: • Define the envelope where we can depend on our software • Integrate software into systems engineering • Address both mission and development risk • Apply what we know

  13. Software is Different • In NASA, SARP is the only surviving program focused on software assurance • There are programs which focus on a particular technology but when all have is a hammer…..

  14. Goals and Objectives • Provide software assurance practices, methods, and tools needed to produce safe and reliable software for NASA • Current and future needs • Emphasis on transferring technology to NASA missions

  15. Goals and Objectives • We use the Oceans, Fish, Fishermen, Hooks paradigm for selection research • There was a time when we tried to make sure every center got something.

  16. Oceans • Oceans are the topic areas • Must be relevant and promising • Must be software assurance • We don’t do project development • Must be externally valid • Some oceans are fished out

  17. Fish • Fish are data from real NASA projects • We don’t like toy projects • We like to fund research that is closely tied to a project • Someone at a NASA Center has an advantage

  18. Fishermen • The researchers • Don’t have to be a big name • Need to convince us that they are the right people for the job

  19. Hooks • Must have the right tools for the job • Mathematical techniques • Formal approaches • Exiting technologies which could be expanded

  20. Recent Evolution and Status • Currently 34 SARP initiatives • 25 Center Initiatives (CIs) - $150K average • Centers: ARC, GSC, GSFC, IV&V, JPL, JSC • Others: UMD, PSU, UVA, Triakis • 9 University initiatives at WVU - $50K average

  21. Recent Evolution and Status • Consecutive 14% cuts in FY05 and FY06 resulted in a total loss of $1.6 million • 3 initiatives cancelled in FY05 • FY06 selection cancelled (No new starts.) • This doesn’t mean no research infusion

  22. Recent Evolution and Status • Seven initiatives from FY03 will end this year • One FY03 initiative will be extended through FY07 • Seven FY04 initiatives should end in FY06 • This will make room for new initiatives in FY07

  23. Recent Evolution and Status • New FY07 initiatives • Call for proposal in February 2006 • Proposals due EOM April 2006 • Selection at SAS06 • Start January 2007 • Note that funding comes through the SMA office at each center. • Center SMA Directors and IV&V Facility Director should sign off on these in late April • Will be a NASA only competition

  24. Recent Evolution and Status • So what if you are a contractor? • Most of our research is actually done by industry and universities in association with a NASA Center • Is it in scope of an existing contract? • What if you don’t have a contract?

  25. Recent Evolution and Status • Make sure you make it very obvious that • Your proposal is software assurance • Not development • You have targeted a NASA software development project to work with • You have a clear path to technology transition • Your results will be externally valid • Local SMA director has to approved your submission • Proposal typically for 3 years • 50K to 300K per year

  26. Recent Evolution and Status • WVU is hiring a new NASA Liaison • IV&V Facility funded at 75% • $40% Research, 35% NASA interface, 25% Teaching

  27. Recent Evolution and Status • Plan to hold mini-SASs at Centers • I want to know which research results you could use at your center • We plan to award a “Most Wanted” award at the end of SAS

  28. Metrics • SARP Results Web Page • Performance Reviews • Penetration Factor • Letter Grades

  29. SARP Results Web Site http://sarpresults.ivv.nasa.gov/

  30. SARP Results Web Site

  31. SARP Results Web Site When PRA = ?, researchers need to decide if it should be published When PRA = Required, Researchers need to complete a NF 1676

  32. Performance Reviews

  33. Penetration Factor 9 results actually used by project 8 data passed back to project 7 data used by researcher 6 data passed 5 project agrees to passing data 4 positive response to contact 3 project contacted 2 project targeted 1 no project targeted

  34. Letter Grades • SARP plus IV&V Facility Research • “B”s 10 • “B+”s 19 • “A-”s 5 • “A”s 6 • All “C”s and many “B”s fell to budget cuts

  35. Were are we going • More interaction with NASA projects • More involvement from SMA organizations • Ability to identify software risks like we do with hardware • PRA • Cost and schedule risks • Software engineering vs code development

More Related