P. 1
Hacker's Guide to Project Management

Hacker's Guide to Project Management

|Views: 997|Likes:
Published by Nauroz Khan
Methods that how to manage a project at any level.....
Methods that how to manage a project at any level.....

More info:

Categories:Topics, Art & Design
Published by: Nauroz Khan on Mar 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/19/2013

pdf

text

original

Whether or not you are going to run the long-term support and maintenance for your

system, you need to think carefully about how they will be managed, and make sure

that the deliverables from the previous stages will meet their requirements.

Consider the internal and external events to which the operators of the system must

respond. If they are a separate organisation, ask them - they will have experienced

problems which you may not have thought of (or even thought possible!). You need to

write procedures to handle each of these events, and you should ideally test them in

simulated live running, with suitable simulated problems.

If the eventual operators are separate from your group, they should help write and

“own” the procedures, and you must make sure they can maintain them.

The maintainers of the system will use the documentation in two ways: to assess

whether a user’s request is an error to fix, or a change; and to work out how to fix or

change the system. Once the system is updated, they will need to re-test the system,

re-deliver it, and make sure the documentation is up-to-date.

Clearly, the easier it is to re-test the system and re-deliver it, the more likely these

tasks will be done properly for each batch of changes or fixes. A comprehensive Test

Strategy and library of test scripts is a very useful tool to the maintainers. It may be

impractical to completely re-test the system at each delivery. Instead, the Test Strategy

must indicate which are the most critical aspects of the system (which must be re-

tested in all cases). A library of test scripts will allow tests to be targeted at certain

functions or parts of the system structure, making the testing at redelivery much more

focused.

Proper configuration control, supported by things like build scripts and delivery

instructions, will make the process of redelivery quicker and less error-prone.

You shouldn’t assume that the maintainers will automatically pick up these tech-

niques and use them without problems. If you have used specific tools for debugging,

testing or configuration control, make sure they are available to the maintainers. Make

sure that the maintainers have been trained to use the tools, but don’t be afraid to

provide some documentation or training on the specifics of how they are used on your

project.

Equally, don’t assume that the maintainers will be as familiar as you with the

functions and structure of the system or will have the time to read the documentation

to gain that familiarity. In a typical maintenance environment, time will be at a

A Hacker’s Guide to Project Management

191

premium. Think about whether you can usefully provide top-level documentation

“maps” or checklists, and make sure that in any case you walk through the

documentation with the prospective maintainers.

Think about who will maintain the documentation you produce, and how. The user

documentation may be the responsibility of the Implementation Manager or someone

in the user organisation. The technical documentation may be maintained by the

maintainers, or maybe by some remnant of your project team. Production-related

documentation may be maintained by the operators. You will need to make sure that

these people have access to the right tools, have been trained to use them, and that the

change control process includes updating relevant documentation. It is also a very

good idea to plan regular updates of the documentation in the early life of a system.

You can be reasonably sure it will change, and if your plan allocates time to doing the

document maintenance, you are much more likely to do it at a sensible time.

Ask yourself “How maintainable is the code?”. Code will often be maintained by the

most junior programmers (because the more experienced ones get the more

interesting and challenging jobs of new developments or major changes). The code

should therefore be as simple and clear as possible. You have to ensure that your

programmers avoid questionable or unclear constructs in their code, just as in the

documentation. Inspect the code, and check for any potential maintenance problems.

What Are the Potential Problems?

If the maintenance process is not well managed, then a stream of minor amendments

will be merged with genuine error corrections to provide rolling changes to the

system. If this happens, the documentation may become out of date, and the quality of

design and code will be compromised. If a large number of small changes are

redelivered separately, then the overhead costs of making the deliveries may add

significantly to the costs of maintenance.

You can help to control this by imposing a batched change control process. Make sure

that there is a clear procedure for handling error reports and changes, re-testing and

redelivering the system, and updating the documentation. If you present this as a fait

accompli it will be used. If, on the other hand, the maintainers have to create their own

procedure, there is no guarantee that all these things will be done.

In the same way, it pays to think of other ways in which your system and procedures

can be abused. You can then think of possible preventative measures and build them

into the procedures and training you give to the maintainers.

A Hacker’s Guide to Project Management

192

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->