These
samples are representative of the writing I have done over the
past 10 years, including an article
for a home design magazine in 2005. (When these are PDF files, they will open in your browser if it is configured for the PDF plug-in, for Internet Explorer or Firefox).
The
following samples are from a period when I did ClearCase software
configuration management work (and document management as
part of
it): ClearCase release
management and ClearCase
administration
work, team leadership
for a combined SCM and Unix systems administration group, a DocuShare
proposal and implementation, and SCM
lead for a CMM (Software Engineering InstituteCapability
Maturity Model) software engineering
process project.
Some of my older, longer systems engineering and
requirements documents are not currently available in PDF format.
The last
sample is a 1988 conference paper I did in the area of document management.
User
Documentation (ClearCase
& Release Management)
This document
(20 p.) was a User
Guide and FAQ for Unix and Windows application developers
using the
ClearCase system to do
configuration management work for their code.
This is structured, tutorial information for knowledgeable
users.
This document
(2 p.) was a Quick
Reference sheet for the same set of developers, to keep by
their workstation as they used the ClearCase system.
It’s an example of packing a lot of useful
technical
information into a small space, and was modified frequently to answer
the most frequent questions developers—my
customers—had as they used
the system.
Project
Planning & Team Leadership
This document
(6 p.) contains a plan for a 3-month
effort to upgrade the hardware, operating system, ClearCase
software, and databases on a
set of ClearCase servers.
This document
(20 p.) was a planning/priorities/status document I
used to manage work priorities for the Unix system administrators
supporting a ClearCase server complex I was responsible for.
The document was designed to meet several goals: to manage
the work and priorities of the group, to allow group members to update
the status of their own tasks, to provide an ongoing record of tasks
accomplished, and to provide transparent information to management on
the work of our
team. This design, and the use of active hyperlinks to other
working documents, reduced e-mail and other communication overhead
among this set of people.
This document
(4 p.) explained to management how a technical issue caused by poor
makefile coding pactices affected our HP-UX our build process in a
way that was going to cause a need for a $500K hardware purchase.
DocuShare
This document
(2 p.) was a memo to management proposing consideration of DocuShare
for solving common problems in a corporate technology department.
This document
(10 p.) gives a summary of work my lab thought was needed to improve
our implementation of
the DocuShare document management system being rolled out for the
entire 1000-person
division.
This article I
wrote recently to describe an idea about combining the power of
permanent URL's like those in DocuShare with the intra-document target
capability of Acrobat PDF files.
ClearCase
& Systems Administration
This document
(2 p.)
was a template I wrote as a ClearCase systems administrator, as a tool
to help me be more efficient. I used and refined it over
several years to allow me to more quickly perform weekly system
upgrades on as many as 25 servers at a time. The
refinements, over time, allowed me to reduce downtimes from 5 or 6
hours to 3 hours or less, with more machines handled simultaneously.
This document
(22 p.)
was a procedure document I used to guide the setup of a new server to
host a ClearCase database. As our ring of servers got larger, we
were setting up new servers more routinely and needed them to be setup
more consistently and quickly. This document helped achieve this.
Capability Maturity Model (SEI CMM process improvement) Project
This document (17 p.) contains my plan for my local lab to implement the SCM KPA of the SEI CMM for our 130 staff.
This document (7
p.) contains requirements created by a subgroup of a division
team to govern how the DocuShare content management system would be
used to meet the requirements set forth by the SCM KPA (software
configuration management key
process area) of the SEI CMM (Software
Engineering Institute Capability Maturity Model). Section
3.1 gives a good example of how precise I can be with terminology
when the situation demands it.
This document
(1 p.)
captures the essence of an argument I made about a terminological issue
for the
word “procedure”
during a working conference call for an SEI CMM
(Capability Maturity Model) project. It shows my
focus on
precision and clarity in technical communication.
CMMI Infrastructure Project
This document (13 p.) contains the customer requirements document for a project to create an online CMMI Handbook for a very large software development organization.
This document (8 p.) contains the product requirements document for that same project.
Conference
Papers
This conference
paper (6 p.) was given at a 1988 IEEE conference and is
available in the
IEEE digital library.
It is based on work done in the mid-80's
in a
400-person software development lab, enhancing work I started in
graduate school. It shows
my long-time interest in document
management and how the lack of it can affect the
productivity of organizations.
I
wrote a 1979 conference paper for an SPSS Users Conference, on a data
validation system I designed at the World Health Organization to check
the logical validity of clinical trial research data from worldwide
studies in the area of human reproduction (contraception, family
planning, etc), prior to statistical analysis. I have not yet
been able to find a copy of that paper.
Other
Samples
The
next samples are from writing and editing done outside of a job
context.
This article I
wrote recently to describe an idea about combining the power of
permanent URL's like those in DocuShare with the intra-document target
capability of Acrobat PDF files.
In 2003 I
wanted to get a custom desk for my office and worked via e-mail with a
Vermont
manufacturer to get it designed. This document
(14 p.) is a composite of a few different parts of that
process—my original requirements, comments on
feedback and
questions from the craftsman/CAD designer, and the resulting CAD
drawings. Although this composite is a little rough (I've
misplaced the originals and the document only had 3 readers), it does
show how
my interests in functionality, design, and aesthetics can get expressed.
In 2002, a
former colleague wrote a
book on home theater, and I gave him extensive comments and
edits on
several drafts before publication. Although I cannot claim or
point out any specific pages where my changes were used, he does give
me credit in the Acknowledgments on
p. 2 of the book
for my extensive help. This is an example of my editing
skills
and my urge to make technical communications clear and understandable
for
the target audience—what I think I helped Marc Rochkind
achieve
in this book.