Re: cobol code assessment

Alistair wrote:
>
> Just in case others have missed it:
>
> Perhaps you could analyse the number of lines, the number of programs
> and the systems which use those programs. Differentiate between batch
> and online code. If you had the time (and you haven't) you could have
> done some kind of function point analysis which would give you a
> measure of size and complexity of any one system.
>
> Others have commented about ease of maintenance but how about asking
> just how much work is there outstanding which the users would like to
> have done. A difficult-to-maintain system might have no work
> outstanding and may be 100% reliable whereas an easy-to-maintain
> system might be bug-ridden with tons of outstanding work. The latter
> might be a good case for re-writing or replacing but the former would
> be a good candidate for leaving alone.
>
> I suspect that your boss wants to know how much Cobol code you have,
> in which systems it resides, how reliable it is and what kind of
> workload is outstanding on it. He probably wants to replace it with a
> language-du-jour or flavour of the month OO system.
>
>
> Finally, unless your boss gives you a proper scope statement (ie
> details his requirements and criteria for success) then you are on a
> losing sticky wicket.

Be sure to include the "skill inventory" of the staff. For example:

Average experience
Senior programmers - 12.
COBOL: 17.2 years
Assembly: 3.3 years
JAVA: 0.4 years
RPG: 0.3 years
FORTRAN: 0.1 years
Other (all): 0.3 years

Junior programmers - 4.
COBOL: 2.6 years
Assembly: 0.2 years
JAVA: 0.6 years

etc.

With a view toward emphasizing the human investment in the existing
methodology.




.