TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Mike Collier - SSG <MikeCol -at- SBSERVICES -dot- COM> coherently explained how to
respond to buzzwords, and added:
>Life Cycle (or is it becoming "Lifecycle"):I'm a bit fuzzy on this one but I
>think it involves taking into account how future changes in customer
>requirements, user needs, hardware evolution, etc. can affect the life
>(future versions) of the system and planning for its maintenance, and
>eventual death
Not to present any of the following as a survey, or as Wholly Writ (Holy
Ritt? <sigh>), but I thought I'd give my shift key a little excercise and
try to explain some of the principles behind "Life Cycle" development...
Interval training... no, wait, that's another list..<blush>
The goal of any Life Cycle method is to be able to achieve definite,
planned, reproduceable results from prototype thru production and upgrade.
While every other issue of _Software Development_ will be championing some
new Lifecycle Methodology, they all seem to boil down to a couple of
principles taken straight from Total Quality Management (which is why
companies involved in ISO, SixSigma, SEI, or similar Continuous Process
Improvement initiatives are so keen on them).
The Shewhart, or Kaizen cycle of PLAN - DO - CHECK- ACT. (Usually
illustrated as a four-slice pie with "Customer" in the rich creamy center)
So for example, The first round of one popular Lifecycle methodology
involves the following phases to reach a useable prototype system:
Requirements analysis, Risk analysis, Design analysis, User review,
Implementation, Quality Assurance, Roll-out & Evaluation, and back to
Requirements analysis.
The Requirements thru Design analyses (the PLAN) rely on
* Explicit User Requirements, and modifications to them based on Risk
and Design analysis,
* to produce a Requirements Document
The User Review thru Implementation phases (the DO) need
* A Design Document approved by the customer and mgmt, and
* a completed Implementation and Test Plan
The Quality Assurance phase (the CHECK) attempts to verify and validate the
Implementation of the prototype according to plan.
The Roll-Out and Evaluation phase (the ACT) is actually a mini-lifecycle of
it's own when the group moves from prototype to production.
* Any disconnects uncovered during evaluation of the roll-out become
part of the Explicit User Requirements for the Requirements Analysis of
the next release.
Two caveats when asked about Life Cycles:
1) Don't tell the agency muffin[1] all that I just told you (just say
"yes I've done that"), save the preceding long explaination for the phone
interview with the hiring manager at the company.
2) When you get the job, and sit down with your engineer to begin work
on, say, a design document for the next release of CamelCaps2K, and the
engineer asks you what you know about Life Cycles, etc., and then disagrees
and sez it's about PLAN - DO - STUDY - ACTION, just look diligently at the
previous design docs, and say "Oh, of course, I see what you mean[2]," and
get to work.
>I think a lot of the confusion is created by the engineering tendency to
>string together adjectives and modifiers. This is one of the tendencies
>that gives engineer-speak its endearing (and, unfortunately, enduring)
>qualities.
Should any list members desire it, I'd be happy to detail the methodology
used *before* corporations discovered Life Cycle management (READY - FIRE -
AIM) <smile>
Footnotes: [1] Of course, I would never refer to anyone on the list, nor
anyone who posts jobs to the list
as an agency or HR "muffin." Blame it on my rereading
of _Primary Colors_ if you need to.
[2] Certainly, I would never contenance misleading or
otherwise pulling the wool over your
engineers' eyes: there's just no reason to argue
about that sort of thing when the real
issue is the engineer staying up till 3am recasting
all your punchy, active, bullet-lists
into passive blobs of text. The sooner you argue
with an engineer, you sooner you'll be
exiled from the lab, and the sooner you can start
looking for another gig.
-----------------------------------------------------------
Dan BRINEGAR, CCDB Vr2Link
Performance S u p p o r t Svcs.
Phoenix, Arizona
vr2link -at- vr2link -dot- com http://www.vr2link.com
"Show up, be there, think it up and do it, exceed your job-description,
control your own means of production (that's yer brain)! "
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
