|
|
|
|
|
|
|
|
|
|
|
SOFTWARE DEVELOPMENT
|
|
Computer Programming allows the creation of Programs, but very
little coverage on how difficult or how long it takes to create
a particular Program is presented in the official HERO System
rules. And for the most part, from the perspective of dramatic
relevance, Computer Programming can (like so many other things)
reasonably occur at the speed of plot, which is to say it takes
whatever amount of time makes for the best story. Still, it
is occasionally useful for a GM to have some kind of gauge of
how long it should take to do something, for consistency if
nothing else. The below chart provides some "rule of thumb"
measurements to assit a GM in this task, and detailed exposition
follows.
|
|
DEVELOPMENT SCOPE |
TIME |
|
Major Software Release |
6 Months to 2 Years |
|
Major Version Release |
3 to 6 Months |
|
Minor Version Release |
1 to 3 Months |
|
Virus |
1 Day to 3 Months |
|
Utility / Applet |
1 Hour to 1 Month |
|
Script |
5 Minutes to 1 Day |
|
RESOURCE FACTORS |
EFFECT * |
|
Excellent General Design |
Decrease Time and
Increase Quality |
|
Real Experts On Team |
Decrease Time and
Increase Quality |
|
Good People Pool |
Decrease Time or
Increase Quality |
|
Time To Do It Right |
Increase Quality |
|
Well Managed |
Decrease Time or
Increase Quality |
|
Poorly Managed |
Increase Time or
Decrease Quality |
|
Insufficient Time |
Decrease Quality |
|
Insufficient People |
Increase Time or
Decrease Quality |
|
Insufficient Skillsets |
Increase Time and
Decrease Quality |
|
Poor General Design |
Increase Time and
Decrease Quality |
|
* All Effects are cumulative |
|
|
|
|
|
In the real world Software design is a complicated, expensive
process with many different scales and scopes of work and few
people outside of the sortware industry have any real idea of
what it takes to deliver a quality piece of software in a given
timeframe. There are literally dozens or more factors to take
into consideration, people to manage, skill sets to utilize,
contingent deliverables, and deadlines to make.
|
|
However, while it is very difficult to accurately predict how
long it will really take to develop something new or how good
it will be in the end, there are two basic factors that have
a very significant impact and that can be taken into account
as a useful rule of thumb: the scope of work and available resources.
|
|
SCOPE OF WORK
|
|
In software development, the scope of work describes the work
to be done in detail and specifies the hardware and software
involved and the exact nature of the work to be done. In short,
it is the definition of what has to be done and is what timelines,
budgets, and deliverables are founded upon. Work is typically
described as "in-scope" and "out-of-scope", meaning that the
work either is accounted for and required, or is being done
in addition to the agreed upon work, usually at extra expense
and chance of throwing off the timeline.
|
|
SCOPE CREEP
|
|
Scope creep is the term used to describe the phenomena of the
nature of the agreed upon work changing (and typically growing)
as the project progresses. This results in many bad things,
most typically a "moving target" for deliverables, but also
confusion, slipped deadlines, and unintended side effects due
to late changes being incompatible or inefficient with design
decisions made in the beginning from the original scope of work.
There are many causes of scope creep, but in the end it is a
sign of weak or bad management of the software development effort.
To represent the effects of this, use the "Poorly Managed" line
item in the chart above.
|
|
AVAILABLE RESOURCES
|
|
In software development, available resources include tangible
things like physical hardware, infrastructure, and people, as
well as intangibles such as time, relevant skills sets, talent,
and competencies. Some resource lacks can be overcome by taking
more time to do something, or don't prevent completion of work
but are reflected in inferior quality, but some lackings are
critical and can cause a software development process to fail
outright. As a rule of thumb if there are three or more detriments
to the project when using the chart above, it is safe to assume
that the project fails at some or all levels as a whole regardless
of whether discrete parts of the intended system are functional.
|
|
TIME AND QUALITY ADVISOR
|
|
The following table first defines some relative software development
scope of work complexities and attributes timeframes to them.
Thereafter a list of complicating and facilitating factors is
listed that indicate the overall affect on the project that
is likely to be caused by those factors. By determining the
scope and identifying some of the factors, it is very easy to
arrive at a reasonably accurate estimate of how long it would
take and what the resulting quality of the product is likely
to be.
|
|
For instance, to write a Utility might take dedicated effort
of anywhere from a day to a month (or more) depending on its
complexity. If the GM were to determine that it will take three
days of development based upon the nature of the software under
development, and the programmer's skill set is lacking in regards
to what they are trying to write, the GM can reasonably determine
that it's going to take the developer longer to muddle through
it and the product is likely to be of lesser quality. Similarly,
if its really a job for three people being done by one then
the GM could reasonably determine that the resulting software
might take even longer to write, or be even worse than it otherwise
would have been.
|
|
It is important to note that this chart makes no mention of
actual skill rolls. It is not intended to replace the general
usage of Computer Programming in other sectoins; rather it is
merely a rule of thumb for GM's to help them make well informed
and consistent decisions about how long it takes to create software.
|
|
Also, this chart is from the perspective of a development team
in a corporate environment, and some of the line items are not
relevant to lone-wolf or "cowboy" coders that are hacking out
software on their own to suit whatever purpose they have in
their own minds. Most player characters are of this later type,
but the chart can still be used with the application of judgment
on the part of the GM. Generally speaking there is a trade off
between all the overhead and management involved in corporate
development that represent drag that doesn't affect a person
coding on their own or with a small group of friends in a non-corporate
environment, but on the other hand all the little touches and
"extras" necessary to turn out a professional looking and robust
piece of software generally are outside the realms of non-corporate
development.
|
|
|
|
|
|