Resource requirements for Ada development

Resource requirements for Ada development

[Gabor Rozman]

Hello Networld,

This is my first posting, so I apologize for the errors. I am avid reader of
the discussions on planning projects, but I have not seen a discussion on
how do you estimate the hardware requirements for a medium to large software
development.
Most of the work is aimed to establish the size of the software, the manning
and scheduling of the projects. That is fine for the bidding phase, but once
you won the contract, you have to set up a software development environment.
How do you go about it? Are there any "rules", accepted ratios (CPU power,
disk storage etc...)?
I am particularly interested wether anyone has tried to monitor resource
utilization during a medium to large size project ( 300+ K Ada statement :
terminating semicolons) on a SUN 4 network ?  What would be a good estimate
for MIPS/seat Mbyte_disk/seat ?  What are the most influential factors for
reasonable turn-around time (over and including the usual Unix NFS issues) ?
Where is (if there is one) the point of diminishing return, i.e. adding more
"iron" won't make any difference ?

The specific I am facing, a SUN-4 network, about 80 software developers, VADS
for self-hosted and cross-compilers, and a project of the above mentioned size.

I am curious, anyone has any idea what would give us a responsive system, with
a not too long (I know it is relative) waiting time, and build (link) time of
less then a couple of days ?

Language constructs to be avoided, work practices to be followed, and a method
to estimate how to extend the network, or any suggestion are welcomed (general
or specific).

I am following the ada-info and the software-eng thread, so either postings or
direct e-mail is fine.  If I get enough information, I will summarize and post
it on both (splitting the answers according to the relevance).

Thanks.   Gabor Rozman

-- 
+--------------------+-------------------------------------------------------+
| Gabor Rozman       | ACSnet, Ean, CSnet: gaabor@runxtsa.runx.oz.au         |
| 29/7-9 Gilbert St  | Arpa: gaabor%runxtsa.runx.oz.au@UUNET.UU.NET          |
| DOVER HEIGHTS      | Janet: gaabor%runxtsa.runx.oz.au@UK.AC.UKC            |

Re: Resource requirements for Ada development

[Scott McGregor]

In article <1991Mar29.025338.8221@runx.oz.au>, gaabor@runx.oz.au (Gabor
Rozman) writes:

> Most of the work is aimed to establish the size of the software, the manning
> and scheduling of the projects. That is fine for the bidding phase, but once
> you won the contract, you have to set up a software development environment.
> How do you go about it? Are there any "rules", accepted ratios (CPU power,
> disk storage etc...)?

The "rules" vary GREATLY from company to company and often even between
departments in large companies. Largely this is driven by "commonly
accepted practices" local to your company, department or manager.  What
has been done in the past is a good guide to what can be done in the future
without the imposition of significant force. There is a large cultural
reason for this sort of way of determining the correct balances, but there
are actually some economic reasons as well.  For instance, the cost of
capital purchases varies greatly.  At a large hardware producing company,
their own hardware may be perceived as inexpensive, and you can get lots of
it. At a small start-up, equipment can be dear because it is hard to get
loans when you have few assets and are still losing money. Even within
big companies, individual managers may be good or poor at negotiating 
budgets and may be making points or losing points based upon how tightly
they control their budgets.

In general, it is extremely hard to hit a point of resource utilization
where more computers won't be used.  The availability of increased
computing resources typically changes the nature of the problems attempted. 
I did a study for a major computer manufacturer who had R&D on new
chip technologies.  When their researchers only had a minicomputer, they
did a few analytical studies, when they had a mainframe they started some
simulations, with a supercomputer they contemplated full Monte Carlo
simulations.  So you see, it changes the nature of the problem.    On the
other hand, you may reach the knee of the perceived value of the curve.
Someone might say, 'Gee, we'll just hire the *smartest* physicists, they can
use just a minicomputer and their innate "good guesses" and still do
just as well as the *moron* physicists they hire at XYZ who have a Cray
and just use
"brute force" techniques.'  You'll find this sort of instinctual valueing
usually overrides any other aspects of deciding the right solution BECAUSE
no one has really hit the drop off point for extra power.  Similar effects
occur with disk space, memory, etc.

The companies financing of computers also affects the equation.  If a
company charges a flat rate to a group whether they use it or not, it
tends to drive them to use it to capacity (and often to increase their
capacity) on the other  hand, if the large fixed costs are allocated based
on usage, marginal use will fall, which raises the average cost to the
remaining users, causing other usage to become perceived as marginal, and
so on until the computing power is very expensive for a few remaining
heavy duty users.  Since Mainframes and supercomputers are often internally
charged in this latter way, and workstations are largely charged in the
flat rate way there is a tilted playing field towards workstations and PCs.

I mention this because many people remain mystified as to why these kinds
of changes happen when technology is not the only reason.  Management
is a form of chaotic dynamics: the future  is sensitively dependent in
unforseen ways to small changes in initial conditions even when the same
forces are consistantly in play.

Scott McGregor
Atherton Technology