Software Development Life Cycle

[Authorgirl]

Hi, this isn't about RoboHELP so hope it's OK here but my company is about to redesign their SDLC and I want to make sure that Documentation gets a proper look in. Are there any protocols anywhere or examples of good processes and systems for communication between developers and help authors?
Thanks

[RoboColum_n_]

How about threatening torture Seriously though, we have a ISO 9001 system here that seems to work better than other places as the development procedure has several points at which development must communicate with the Techncial Authors. Likewise, the documentation process relies on development for input, review and signoff of changes. That said, there is no substitute for regular meetings and as much informal contact as can be productive. The more they think of you, the better the documentation process will be.

[MergeThis]

As Colum says, the sooner you can be involved in the process, the better. The greatest angst experienced in the developer/writer experience is when the writer points out glaring UI issues to the developers, who then come back and say: well, it's too late in the process and it would be too expensive to change that now!

Then, you're the bad guy...


Good luck,
Leon

[RoboColum_n_]

I'd like to be able to attend the development design meetings so I can point out the type of thing Leon highlights. By the time you see the coded UI it may be too late. Things are <GROAN> ever so slowly </GROAN> changing here but I'd like to be able to attend most development meetings and review technical specs. It is a culture change but one that is a win-win.

[---Dirk_Bock]

On the other hand, some companies tend to develop to the very last minute. It sometimes makes sense, not to get involved too early so as not to write texts to be dumepd due to changes.

IMHO it's okay to get involved early to get a grip on the intended workflow for the application and develop a plan for your documentation. Postpone the actual writing until you're rather sure that at least the GUI is fixed.

---Dirk Bock

[Chet Zeshonski]

Dirk's point is a good one. I'd look to get into the testing flow, if your company adequately tests its products as part of the development process. While testers are doing their thing, you can go through the software yourself. Add your comments and suggestions to those of the testers, and bingo: you're in the loop, and your requests become part of the normal test-and-improve cycle.

[Guest]

Not to mention that the customer changes his mind about the way something is worded or how the functionality works...

The fun part is when you have to ship the product in multiple languages at the same time, so you have to write documentation well in advance so it can be translated and worked back in by the code freeze. So in some instances, writing early can't be avoided.

[johnmccallum]

We are a very small company but all of our help authors are also product testers, who are involved early on. We are also all research scientists who are using the product daily. I believe this is a very good model (it is, however, dependent on the genius of our company president). We do with five people, what our leading competitor company does with 500.

I would very strongly support the comments made by ChetZeshonski. As it is not possible to design software that is "intuitive" for every user there will be design issues that cannot be "corrected." If your SDLC links you to the product testing cycle, you will be much better able to write instructional material to get all end users up to speed.

Email me if you would like me to send you a .chm file of our SDC.

John

[HKabaker]

I try to get into it as soon as I hear they are developing front end screens. I won't reveal the timing in our SDLC when they get started on screens.

Once I feel confident the basic flow of the app won't change radically, and the overall screen design is solid, I want to get going on it for the reasons Colum and Leon mention.

I'm willing to do whatever revising is necessary as development progresses.

A bonus: They might change their minds and go back to something you've already written. It happens. I back up a project now and then as insurance against a wipeout, and in case I do something serious that I come to regret. So the old material is there until the project is done.

Harvey

[Authorgirl]

Thanks everyone, that is SO useful.
Much appreciated.

Helen