John R. Diamant

Resilient Security Architecture: A Complementary Approach to Reducing Vulnerabilities

The software industry would benefit from more emphasis on avoiding security mistakes in the first place. That means security requirements analysis and architecting and designing security in, an approach thats currently rare but that provides substantial benefits. The most common approaches to the latent (generally called 0-day) vulnerability problem fall into one of two categories: Do nothing. Wait for vulnerabilities to be discovered after release, and then patch them. Test security in. Implement code with vulnerabilities, and invest in finding or removing as many vulnerabilities as practical before release or production.

Human interaction support in HP SynerVision for SoftBench

The paper describes how human/tool and human/human interactions are supported in the SynerVision for SoftBench process enactment tool from Hewlett-Packard. The scope is not limited to enactment time, due to a feature of SynerVision which allows process enactors to simultaneously be process designers. Questions that are touched on briefly include: what is the relationship between humans and the framework? How are humans and tools modeled in the software process? What does the formalism allow one to specify (roles, goals, other)? How should humans be handled or supported in the process? How are interactions modeled in the software process?.

Process Modeling in HP SoftBench

This paper describes the existing support and possible fbture directions for supporting process modeling in the Broadcast Message Server architecture and HP SoftBench.

A preprocessor based implementation of common Lisp

The Hewlett-Packard company developed aCommon Lisp product, based on a preprocessor model to ensure consistent semantics between compiled and interpreted code. This implementation is unique in that it combines aspects of a “compile only” system with those of a traditionally interpreted system. This paper presents a short description of the operation of the preprocessor, and then goes on to present areas where the definition ofCommon Lisp (as presented inCommon Lisp,the Language) is inconsistent or incorrect in light of such an implementation. Finally, we present some suggestions which we hope will be helpful in improving future specifications ofCommon Lisp.