 |
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-16The End of the Historical Record?ACM News Service: The Fading Memory of the State. NARA, the National Archives and Records Administration has a painful job for preserving documents in the 16,000 software formats used by the federal government. This is aggrevated by the problem of “bit rot” which occurs much more rapidly with paper documents. NARA has contracted for a permanent Electronic Records Archive (ERA) that will handle present and future formats in an authentic, available and secure form. It is not clear how close we are to accomplishing digital preservation so handily. Meanwhile there is mention of an open-source XENA (XML Electronic Normalizing of Archives) being used in Australia. I want to know about that regardless of any reservations I have about the prospects for an ERA. David Talbott’s July 2005 Technology Review article is a great read, offering this daunting comparison: “The most famous documents in NARA's possession—the Declaration of Independence, the Constitution, and the Bill of Rights—were written on durable calfskin parchment and can safely recline for decades behind glass in a bath of argon gas. It will take a technological miracle to make digital data last that long.” The challenge is simply illustrated by the 2000 census data: 40 terabytes of TIFF images. And NARA has a miniscule proportion of the digitally-born documents that it must preserve, and it has no way to take receipt of them. (The Library of Congress is not part of NARA and is making its own provisions for digital preservation and availability.) The MIT DSpace project, another open-source effort, is an early example created to preserve scientific research data and papers. The ability to scale to the level of demand that NARA faces is completely untested, however. Software Inspection's Lonely AdherentsACM News Service: Software Under Scrutiny. I was amazed to see a blurb that features software inspections as something that has not penetrated practice very much. Sue Bushell’s 2005-07-07 CIO Australia article confirms that to be the case, with great explanation for how inspections can be tied to demonstrable reduction of software-development costs. The article clarifies the resistance to inspections and also describes the importance of inspection, the common methodology in almost every software process improvement methodology. There are some useful principles as well as an assertion by Karl Wiegers that one of the greatest payoff is in inspection of requirements, about as up-front in the software-development stages as you can get. An intriguing factor with regard to inspections is that the payoff approaches 1:1 (break-even) as the development processes become more successful at not having defects in the first place. This may lead management to want to abandon them. It becomes important to have clear understanding of what the phenomenon is.
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.
from:
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |