|
|
|
|
|
|
|
|
|
|
|
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 very vague 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. |
|
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
below.
|
|
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 below, 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.
|
|
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 |
|
|
|
|
|
|
|
|
|