|
|
|
|
|
|
|
|
|
|
|
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 for
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.
|
|
The following chart categorizes software development in general sizing terms
and gives a default base time to produce a releaseable version of features and / or fixes
of that size; for instance a minor release for existing software has a much smaller scope of
work than building the first version of a non-trivial application or platform.
|
|
The following chart assumes a "professional" level of quality of basically working software that
satisfies its primary purpose with no major bugs; but that might be missing a few minor features or
have a few minor bugs (of the quirks or glitch variety). A lower quality release will have
significant bugs, and / or narrower functionality, and / or poor ux or integration options,
and / or basic engineering flaws such as leaked resources, instability, security holes, and so on.
Higher quality software will offer a richer feature set, and / or be entirely bug free, and / or
have excellent ux or "just works" integration options, and / or exhibit optimal engineering qualities
such as efficient resource consumption, hardened security, impressive speed of execution, and so on.
|
|
DEVELOPMENT SCOPE |
TIME |
|
New Software Release |
1 Year |
|
Major Version Release |
3 Months |
|
Minor Version Release |
1 Month |
|
Virus |
3 Months |
|
Utility / Applet |
1 Day |
|
Script |
6 Hours |
|
RESOURCE FACTORS |
EFFECT * |
|
Excellent General Design |
Decrease Time and
Increase Quality |
|
Real Experts On Team |
Decrease Time or
Increase Quality |
|
Time To Do It Right |
Increase Time and
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 |
|
Leveraging Existing Components |
Decrease Time and
Decrease Quality |
|
Derivative / Routine |
Decrease Time or
Increase Quality |
|
Cutting Edge |
Increase Time or
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 software 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, funding issues, and generally unrealistic
deadlines forcing many non-optimal trade offs.
|
|
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 gaps can be overcome by taking
more time to do something, or don't prevent completion of work
but are reflected in inferior quality, but others 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 time and quality chart 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.
|
|
It is important to note that the time and quality factors makes no mention of
actual skill rolls. It is not intended to replace the general
usage of Computer Programming in other sections; rather it is
merely a rule of thumb for GM's to help them make
consistent decisions about how long it takes to create and enhance software.
|
|
Also, the time and quality factors 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 industrial grade and robust
software generally requires some kind of larger organizational infrastructure
(though some exemplary open-source development efforts challenge that assumption).
|
|
|
|
|