 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-07-11Trustworthy Deployment: What's That?My work on the TROST dissertation is moving along sluggishly, with 17 days remaining to the deadline. I seem to have overcome some sort of block and I’m now dealing with an uncorked urge to speak about every aspect of open-systems trustworthiness all at once. I must channel that into an useful stream of results. My first offering is a fragment on the confirmable construction and deployment of software components. Wanting to Demonstrate Trustworthiness. While wrestling with the project part of my M.Sc dissertation, I learned that demonstration of trustworthiness (what I call TROSTing the software) has to be incorporated from the very beginning. Furthermore, achieving trustworthiness requires anticipation of users having their hands on the product for the duration of the activities that are important to them; the delivered software is merely an instrument in the adopter’s pursuits and that must be recognized and supported. Respecting the User’s World. This leads to taking the software-development life cycle out beyond the usual level of attention into what is called the system-life cycle view in the adopter’s world. In particular, it involves anticipating that the software-product life cycle intersects a consumer’s distinct application life cycle that is nowhere coterminous with that of the software. (By the way, I am shopping for terms other than producer-consumer, especially the -consumer part, as labels for the participants in this kind of engagement/commerce. I notice that I have been using adopter and maybe that will stick.) Starting from Nothing. The upshot of this perspective is that, in preparing to build up to a stable release where there is no delivery process already in place, I needed to bootstrap the construction and deployment of deliverable packages first. That provides the necessary foundation for periodic software builds, confirmation of the builds (a software quality assurance and stabilization activity), and delivery of preliminary material to potential reviewers and interested developers in a way that exercises and confirms the deployment methodology, building trustworthiness along the way. What They Get Is What They See? So what do we put in the hands of those lucky recipients? There’s certainly some (early) version of the software itself, but what else must be in place to have there be what I’m calling, for now, a trustworthy deployment? Exhibit A: The scoping checklist. The checklist is a general one that came to mind for delivering software of this kind. Because I’ll be bootstrapping my way into the deployment process ahead of and then concurrent with building the software itself, versions of the checklist will have a good number of “not addressed for this version”) entries at first. That’s all right: Accounting for the checklist elements makes explicit what the desired state is (the envisioned scope), and what the current state is (an interim, achieved scope). Feedback Invitation. The draft scoping checklist is available for review and comment. Comments are welcome here and on the TROST-discuss and ActiveODMA-discuss lists. I’ve already received some feedback. My notes on what I’ve learned are in the Diary & Job Jar page that accompanies the scoping document. Trustworthiness in Artifacts? Laying out the trial scoping and discussing it today have given me a powerful insight into how trustworthiness is reflected in artifacts: the artifact is an expression of the producer’s care for the adopters/users. I invite your consideration for how developer attention to such elements is an opportunity to express care for the recipient of the artifact and thereby build trustworthiness. The scoping document is oriented to the reference-implementation of a document-management system driver for the Open Document Management API, ODMA. The ODMA Connection Manager is a piece of on-Windows middleware that is akin to the Open Data Base Connectivity (ODBC) driver manager, but for integrating desktop applications with document-management services in a smooth, plug-and-play fashion. Such a driver is a binary component, a Microsoft Windows Dynamic Load Library (.dll file), that is installed on a Windows PC and then advertised for use by making ODMA-related additions to the Windows registry. I mention all of this because the delivery process is different, and mostly simpler, than what it takes to install a full-up Windows production-quality application. It’s also not something so easily knocked off as a little desktop utility. Professor, this is good stuff here. I might amend your statement "the artifact is an expression of the producer’s care for the adopters/users" just slightly. A software artifact has many facets and the expression of care for users is one of them. Now I think it's a BIG one, but I'm biased towards this view. And one phrase that's a bit confusing to me is "software quality assurance and stabilization activity". What does "stabilization" refer to? Good point. That's not all the artifact is an expression of. "stabilization" is Microsoft-ese for getting the bugs to go down and stay down and the function to be leveled and stay leveled (in my words).
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |