1aro pi meeting may 2002i am not jeannette m. wing the question how can we integrate our methods and...

1ARO PI Meeting May 2002 I am not Jeannette M. Wing

The Question

• How can we integrate our methods and tools into software development processes seamlessly?– we have to have a good understanding of what

industrial people (those building safety & mission critical software) want and need


Our group

• Carl Gunter• Jaime Lee• Kang Shin• James Widmaier• Bruce Krogh• Matt Dwyer


Vision For The (near) Future

• Industry/govt perspective– Build on existing methods (cleanroom, specware)

1. Requirement Document + Operational Profiles2. Formalize Requirements (identify state variables)3. State transition diagrams4. Automate code generation5. Testing driven from operational profiles

– Missing tool support for several transitions (1->2, 2->3)

• Observations– “process metrics” lead to confidence in product (mismatch from “product-based” methods we’ve

discussed)– “reliability” in terms of numbers of 9s (Is reliability sensible? Should it be a question of

existence of stimuli in the profile that lead to failure?)


Standard and Certification

• Standardization of development processes– want a standard way of building HCES software– From requirements to code (and back)– Can we build on existing standards

• General standards ISO 12207 • Layers of domains specific standards

– Security common criteria, …

• Certification– regulatory standards (e.g., FAA)– procurement standards (e.g., NSA, FDA)

• specify metrics about process & product metrics• need technologies to provide those metrics


Technology Assessment

• Lots of popular processes– XP (in embedded systems?)– RUP, UML-based methods– These are not focused on high-confidence as the goal

• They have some useful ideas– Higher-level descriptions (but weak semantics – UML)– Early feedback (co-develop tests/code – XP)

• Some methods seem effective– Cleanroom, specware– Designed for production of reliable software– Anecdotal evidence that they can support

development of high-confidence system


Required Technologies (for embedded systems?)• Requirements are the key

– Need support for eliciting requirements• Did I account for all the corner cases?• Closing the “detail gaps” in requirements• Automated guidance in the form of a “wizard” (domain specific)

– Need support for formalizing requirements• Identification of state variables• (semi) automated methods for developing state diagrams

• Test generation tools– From formal specifications

• Code generation from models– Some support exists– Is it sufficiently general?– Correctness of code is more important than speed

• As long as you can meet your deadlines, extra performance is irrelevant

• Proof generating translators (to verify translation)• Scalability and usability of existing formal tools is in question?

– Can they be applied to realistic systems?– Can they be used by practitioners?


Integrating Technologies (within HCES teams)

• Common conceptual framework/process– To plug ideas/technologies into– To get see a path through technologies from reqts to

code• Map those paths onto the “vision”

• Technological integration– Standardization of languages/APIs– Make tools available to other team members– Targeted interactions

• e.g., HERMES -> Bandera for mixed design/code checking

• e.g., pub/sub research from CMU and K-state


Technology Transfer

• Initiated by the academia– Students as carriers of technologies internships/employees– Requires that students are trained in appropriate methods and

technologies– Publication

• Initiated by industry– Driven by needs of emerging projects

• Small demonstration projects– From industry/govt. research organization to development groups– Prototype a real system, if succesful move to have it required on

upcoming contracts• Robustness of tool support

– Tools need to be scalable, documented, …– Insufficient resources in academia, not the focus– Many organizations want a company “on the hook”

• Challenge problems from industry– Can be lots of work to document reqts for external people– Need to get in at the beginning of a project

• Long time scale for effective transfer– 15-20 year time scale from idea formation to fielded technology

• Can we view follow on applied research be viewed as tech transfer?


Ways to Sell To Program

• Current research is helping current DOD projects (e.g., F18, CARA, secure kernel, …)– Having impact on specific artifacts, stages of development– [more specifics here]

• Prospects for greater impact by better coverage of– Development artifacts– Steps in development process

• Because we don’t have a complete solution– Missing important tools that will enable more dependable

solutions (e.g., requirements -> state var/diagrams)• Spin-off technology to private sector

– Create COTS technology that can be taken up by DOD more cheaply

• University Research Initiatives – Research to lay the foundation for the future applied

research and applications– Training of researchers (“human resources development”)


Misc

• What is ARO’s vision for embedded software?– Application domains– Commonality among programs/projects

1aro pi meeting may 2002i am not jeannette m. wing the question how can we integrate our methods and...

Documents