NASA Research Opportunity
by Lisa Montgomery

The NASA Office of Safety and Mission Assurance (OSMA) Software Assurance Research Program (SARP) call for proposals for fiscal year 2006 will be released in February 2005. This year will not be an open competition. SARP will accept research proposals from government civil servants and JPL Cal Tec employees only. However, industrial firms and universities may collaborate with civil servants and Cal Tec employees. If you have any ideas which are in line with the goals and objectives of the program, contact Lisa Montgomery . She may be able to direct you to a NASA organization which may be interested in collaboration.

The primary goal of this research program is to provide NASA with the software assurance practices, methods, and tools needed to produce safe and reliable software. This program is designed to address fundamental software assurance problems in the field of software engineering primarily as it relates to software safety, quality, independent verification and validation (IV&V), testability, and reliability. It is intended to develop and transfer to NASA projects, software assurance practices, methods and tools to improve the quality of the software produced by and for NASA, and to assist NASA in becoming a leader in the development of safe and reliable, cost effective software.

The objectives of the OSMA Software Assurance Research Program are to: a. Support promising new software assurance research that facilitates NASA missions. b. Identify, develop, adopt, and integrate software assurance "best practices" and research results into NASA programs to reduce software costs, improve delivery time, and increase software safety and quality. You should note from the above that SARP is an applied research program. Hence it is imperative that potential researchers align themselves with on-going NASA work. For more general information click here , or here for a list of topics. Potential researchers may also wish to peruse the SARP Results Web Site , and the conclusions of the annual Software Assurance Symposium to gain a better understanding of the program.

S.P.E.C. Software Protection Evaluation Course

Presented By Arxan Labs

Adversaries present a significant threat in their ability to attack mission critical software systems in order to gather national intelligence and disrupt proprietary systems. This workshop will be presented by Arxan Labs which designs, develops, and markets robust software anti-tamper solutions which deter security breaches and piracy. Participants will learn how to circumvent common software protection mechanisms in order to better understand how to secure software against reverse engineering, tampering, etc.

This workshop will be a one day, intensive seminar taking place on Saturday, April 2, 2005 from 8am - 6pm at Ball State University. It is free for all SERC affiliates and Ball State faculty and students. Enrollment is limited. To register, go to www.serc.net.

Value of the SERC for Motorola
by David Dorenbos

Motorola joined SERC in 1997 and by my count Motorola has had six research threads and 14 projects with SERC. The research threads were and are: Design Metrics,
Process modeling,
the Eclipse Environment,
Global Testing,
Design Recovery, and
Usability. In addition, benchmarking with Ontario Systems, presentations to prospective SERC members and contact with NSF have broadened our thinking, and the thinking of SERC researchers. Each of these threads and contacts is a tale of technology focus, research and technology transfer that I find fascinating. I'll tell you about two of the threads today.

Design metrics

Motorola has applied design metrics to SDL (the Specification and Description Language) that is an International Telecommunication Union standard. We worked with the BSU team to tune the design metrics to SDL. This required looking at SDL designs and relating these designs to internal and field failures. The BSU was given access to these results for a large Motorola product and successfully created the calibration.

Results:

The good - Our research trials showed that this technique worked. We were able to add a pull-down to the commercial modeling tool that provided the design metrics results for a model. Our vision for DMA-SDL is shown in the following picture.

The serendipitous outcomes were many. From this work came an awareness of source line estimation from graphical design models. This knowledge was then applied to Bayesian process analysis work research. What's more, the DMA-SDL work resulted in a SDL seminar taught at BSU in 2002. Motorola hired 14 people from this class!

The bad - We had two problems in rollout. First, the development teams did not think that they had time to run DMA-SDL because the tool had to run on a completed model that had been verified for syntax and basic semantics. In the view of the teams, when they reached that point they were DONE.

Teams did take too well to the idea of reviewing a model again. Second, the customized front-end of the SDL Design metrics was really like a complex compiler and every new release of the modeling tool would cause the design metrics tool to break, a complex maintenance problem.

Future:

We may want to pick up on this work again as we transition to UML. Next time we will focus on the tool vendors to embed the capability. We will try to find a control point in the process flow where design metric review can be introduced painlessly. We're also eagerly waiting on a new release of the DMA-C tool that we could try on legacy code.

The Eclipse Environment

Eclipse environment is a tool that has a good chance of becoming an industry standard. Originally targeted at Java, it is expanding as an environment for rapid development of tools targeting many platforms and across all the life cycle. If Eclipse gets wide acceptance then researchers and developers can concentrate on innovation, not tool infrastructure. My view is that adoption of new tools is slowed because of reluctance to learn yae (yet another environment).

Eclipse has a simple architecture as shown below. Standard Eclipse plug-ins are the Java development tools and the plug-in development environment. With these tools in-hand adopters can add their own plug-ins or adopt university or commercial plug-ins.

In our investigation of Eclipse with BSU we covered plug-ins for six areas. 1. UML Modeling
2. Aspect Oriented Programming
3. Validation and Verification
4. Quality & Performance
5. Plug-in Development
6. Process Tie-in and Enhancement (specific to Motorola) Requirement Management, Configuration Management, Customization and extension with plug-ins

Results:

The Good - We found that Eclipse was indeed easy to use both with available plug-ins and those we could create. We were also able to hire the SERC researcher that worked with us on this project.

The Bad - The immediate opportunities to apply Eclipse within Motorola were small, small teams working on specialized projects. Another negative, the "nattering nabobs" said "So what's research about this?" After all, anybody could do it. Well nobody had taken a broad look at Eclipse and its potential, its use had been extremely tactical.

Futures:

The future wasn't long in coming. Within the last month we have had opportunity to tie a modeling front-end to a scripting language. This was done in a week and may result in solving a major problem for a large Motorola business. I don't know where Eclipse projects will go but they should enable SERC researchers have significantly lower barriers to acceptance of innovations because the environment for the innovation will be well-known to developers.

The overall moral to my two tales is that technology transfer is hard, it has its disappointments but mastery of a technology area will pay off. If you are managing research projects the trick is to make it look like you aren't surprised by the unexpected victories.