UNICOM Keynote Speech--Abstract and Bibliography
utzoo!decvax!harpo!floyd!cmcl2!philabs!sdcsvax!sdchema!jmcg
utzoo!decvax!harpo!floyd!cmcl2!philabs!sdcsvax!sdchema!jmcg
Thu Jan 13 20:34:41 AEST 1983
Software Army on the March -
Project Strategies and Tactics
John R Mashey
Bell Laboratories
Whippany, NJ 07981
This talk describes the work of an army building roads ("software projects")
through a part of the countryside that:
* seldom has current maps.
* is plagued by earthquakes ("major environment changes"), flash floods
("temporary problems"), and fog ("inability to predict the future").
* contains villages of natives ("users") who may greet roadbuilders with
anything from great interest to outright hostility, but whose coopera-
tion is essential.
* may be overrun by enemy forces ("competitors") trying to build their own
roads to the same locations.
An effective campaign has two aspects:
* Doing the right thing, i.e., fighting the right war in the right place,
and choosing good routes to reach the goals.
* Doing it right, i.e., building maintainable roads with adequate capa-
city, at a reasonable cost, without losing too many casualties, and
without offending the natives.
Most software methodologies emphasize the second part; this talk emphasizes
the first by examining decision processes and methods of analyzing routes.
Two different veiwpoints are used. The first is the formal game theory
viewpoint--making decisions in a nondeterministic, multi-stage, N-person,
non-zero-sum game played with incomplete information. The second is the
"army" model described above. From this viewpoint will be discussed such
issues as:
* The need for scouts on motorcycles ("fast prototypers").
* How campaigns differ, and thus affect choice of troops, ranging from
commando raids through the march of the hordes.
* Special precautions for earthquake territory.
* Getting natives to buy and drive your trucks, instead of shooting your
tires out as you drive through their villages.
There exist many similarities in the decision processes of formal games
analysis, military planning, and project management. This talk uses the
first and second to help shed light on the third. Provided with the talk is
an annotated bibliography, which includes a famous treatise on "project
management" written in 500 B.C.
Bibliography
BLA78A Blake, S. P., _M_a_n_a_g_i_n_g _f_o_r _R_e_s_p_o_n_s_i_v_e _R_e_s_e_a_r_c_h _a_n_d _D_e_v_e_l_o_p_m_e_n_t, W.
H. Freeman, San Francisco, 1978.
Chapter 4 (Strategies, risk analysis) especially good: alpha stra-
tegy (careful frontend analysis) vs beta (prototyping, adaptation
to state-of-the-art changes). Example of Sidewinder development
(simple, reliable, cost-effective U.S. air-to-air missle) good
example of beta strategy.
BUS65A Busacker, R. G., Saaty, T. L., _F_i_n_i_t_e _G_r_a_p_h_s _a_n_d _N_e_t_w_o_r_k_s: _A_n
_I_n_t_r_o_d_u_c_t_i_o_n _W_i_t_h _A_p_p_l_i_c_a_t_i_o_n_s, McGraw-Hill, New York, 1965.
See applications to games and puzzles in sections 6-8 to 6-13.
CLA51A Clarke, A. C., Superiority. In _A_c_r_o_s_s _t_h_e _S_e_a _o_f _S_t_a_r_s, Harcourt,
Brace, New York, 1959.
A humorous science-fiction story of war lost by the side with
better technology, because they kept changing it.
DUF80A Duffy, N. D., Assad, M. G., _I_n_f_o_r_m_a_t_i_o_n _M_a_n_a_g_e_m_e_n_t -- _A_n _E_x_e_c_u_t_i_v_e
_A_p_p_r_o_a_c_h, Oxford University Press, Cape Town, South Africa, 1980.
Chapter 2 (Informations Systems Development Life Cycles) character-
izes strategies as Linear, Loopy Linear, Plug-in, and Prototype,
then offers attributes that may guide choice of strategy for a
given project.
DUN80A Dunnigan, J. F. _T_h_e _C_o_m_p_l_e_t_e _W_a_r_g_a_m_e_s _H_a_n_d_b_o_o_k. Morrow, New York,
1980.
Survey of serious games, which often resembles real life in aspects
of strategic planning, allocation of scarce resources, and risk
analysis.
FAL81A Fallows, J. _N_a_t_i_o_n_a_l _D_e_f_e_n_s_e, Random House, New York, 1981.
Superb analysis of U.S. military weapons procurement and realities.
Chapters: Realities, Managers, Magicians, Two Weapons, Employees,
Theologians, Changes. "Two Weapons" chapter: F-16 fighter, brilli-
antly designed with good analysis and prototyping; then made less
capable by adding things in opposite direction of original design
philosophy.
GOM82A Gomaa, H. The Impace of Rapid Prototyping on Specifying User
Requirements, in _P_r_o_c_e_e_d_i_n_g_s _A_C_M _S_I_G_S_O_F_T _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _S_y_m_-
_p_o_s_i_u_m: _R_a_p_i_d _P_r_o_t_o_t_y_p_i_n_g, Columbia, Md, April 19-21, 1982, paper
#14.
Case study of project done at GE.
JON80A Jones, A. J. _G_a_m_e _T_h_e_o_r_y: _M_a_t_h_e_m_a_t_i_c_a_l _M_o_d_e_l_s _o_f _C_o_n_f_l_i_c_t, Wiley,
New York, 1980.
Chapter 1 is reasonable introduction to fundamental concepts and
analysis techniques (decision trees, minimax, etc).
KEE81A Keen, P. G. W. Information Systems and Organizationsal Change.
_C_o_m_m. _A_C_M 24, 1 (Jan 1981), 24-33.
Discusses long-term change in organizations related to information
systems. Reviews causes of social inertia, resistance, and
counter-implementation. Good reading for any software designer who
hopes to sell ideas. Includes good bibliography.
LEH80A Lehman, M. M. Programs, Life Cycles, and Laws of Software Evolu-
tion. _P_r_o_c. _I_E_E_E 68, 9 (Sep 1980), 1060-1076.
S-, P-, and E-programs; use of methods to predict release effects.
LUC57A Luce, R. D., Raiffa, H. _G_a_m_e_s _a_n_d _D_e_c_i_s_i_o_n_s -- _I_n_t_r_o_d_u_c_t_i_o_n _a_n_d
_C_r_i_t_i_c_a_l _S_u_r_v_e_y, Wiley, New York, 1957.
Chapters 1, 3, 4, 7, 8 form a reasonable introduction to the topic.
MAC68A Macksey, M. C. _P_a_n_z_e_r _D_i_v_i_s_i_o_n -- _T_h_e _M_a_i_l_e_d _F_i_s_t. Ballantine
Books, New York, 1968.
History of German tanks in WW II.
Moral: when you're even or ahead, don't stop, somebody is gaining
on you. When you're behind, be careful how you try to catch up.
MAR82A Martin, J. _A_p_p_l_i_c_a_t_i_o_n_s _D_e_v_e_l_o_p_m_e_n_t _W_i_t_h_o_u_t _P_r_o_g_r_a_m_m_e_r_s. Pretice
Hall, Englewood Cliffs, NJ, 1982.
Illustrates existing methods and tools for 10- to 100-fold produc-
tivity improvements over conventional methods, for some problem
domains. In some cases, normal high-level language coding appears
to be pathetically absolete.
PYS82A Pyster, A., Boehm, B. W. The Impact of Rapid Prototyping on
Software Development Standards. In _P_r_o_c. _A_C_M _S_I_G_S_O_F_T _S_o_f_t_w_a_r_e
_E_n_g_i_n_e_e_r_i_n_g _S_y_m_p_o_s_i_u_m: _R_a_p_i_d _P_r_o_t_o_y_p_i_n_g, Columbia, MD, April 19-21,
1982, paper #28.
TRW builds Software Productivity System on UNIX with fast prototyp-
ing.
TAY82A Taylor, T., Standish, T. A. Initial Thoughts on Rapid Prototyping
Techniques. In _P_r_o_c. _A_C_M _S_I_G_S_O_F_T _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _S_y_m_p_o_s_i_u_m:
_R_a_p_i_d _P_r_o_t_o_y_p_i_n_g, Columbia, MD, April 19-21, 1982, paper #40.
Some parts are a bit academic, but has some good overall thoughts
on prototyping, especially the section "Limits of Prototyping" on
page 13.
TZUXXA Tzu, Sun. _T_h_e _A_r_t _o_f _W_a_r. 500 B.C. Military Service Publishing
Company, Harrisburg, PA, 1944. [thanks to L. Bernstein]
Contains numerous pithy discussions of project management, although
not expressed in the standard terminology.
"When you engage in actual fighting, if victory is long in coming,
then men's weapons will grow dull and their ardour will be dam-
pened.... Thus, though we have heard of stupid haste in war, clev-
erness has never been associated with long delays."
"[Frederick the Great, in his _I_n_s_t_r_u_c_t_i_o_n_s _t_o _h_i_s _G_e_n_e_r_a_l_s, says
`Those generals who have had but little experience attempt to pro-
tect every point; while those who are better acquainted with their
profession, guard against decisive blows at decisive points, and
acquiesce in smaller misfortunes to avoid greater.' In other
words, keep away from sideshows.]"
WEI82A Weiser, M. Scale Models and Rapid Prototyping. In _P_r_o_c. _A_C_M _S_I_G_-
_S_O_F_T _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _S_y_m_p_o_s_i_u_m: _R_a_p_i_d _P_r_o_t_o_y_p_i_n_g, Columbia,
MD, April 19-21, 1982, paper #42.
Offers clear characterization of 3 different kinds of prototypes:
user interface, functionality, and performance.
More information about the Comp.org.usenix
mailing list