University of Southern California Dissertations and Theses

Analysis of information process for software development productivity

(USC Thesis Other)

Analysis of information process for software development productivity

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content INFORMATION TO USERS
This manuscript has been reproduced from the microfilm master. UMI
films the text directly from the original o r copy submitted. Thus, some
thesis and dissertation copies are in typewriter face, while others may be
from any type o f computer printer.
The quality of this reproduction is dependent upon the quality of the
copy subm itted. Broken or indistinct print, colored or poor quality
illustrations and photographs, print bleedthrough, substandard margins,
and improper alignment can adversely afreet reproduction.
In the unlikely event that the author did not send UMI a complete
manuscript and there are missing pages, these will be noted. Also, if
unauthorized copyright material had to be removed, a note will indicate
the deletion.
Oversize materials (e.g., maps, drawings, charts) are reproduced by
sectioning the original, beginning at the upper left-hand comer and
continuing from left to right in equal sections with small overlaps. Each
original is also photographed in one exposure and is included in reduced
form at the back o f the book.
Photographs included in the original manuscript have been reproduced
xerographicalty in this copy. Higher quality 6” x 9” black and white
photographic prints are available for any photographs or illustrations
appearing in this copy for an additional charge. Contact UMI directly to
order.
UMI
A Bell &. Howell Information Company
300 North Zeeb Road, Ann Arbor M I 48106-1346 USA
313/761-4700 800/521-0600
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ANALYSIS OF INFORMATION PROCESS
FOR
SOFTWARE DEVELOPMENT
PRODUCTIVITY
by
Christine Pao-Fang Chang
A Dissertation Presented to the
FACULTY OF THE SCHOOL OF EDUCATION
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree of
DOCTOR OF EDUCATION
(Educational Psychology and Technology)
August, 1997
Copyright 1997 Christine Pao-Fang Chang
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UMI Number: 9816085
UMI M icroform 9816085
Copyright 1998, by UMI Company. All rights reserved.
This microform edition is protected against unauthorized
copying under Title 17, United States Code.
UMI
300 North Zeeb Road
Ann Arbor, MI 48103
1
i
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UNIVERSITY OF SOUTHERN CALIFORNIA
School o f Education
Los Angeles, California 90089-0031
This dissertation, written by
under the direction o f h£^LD issertation Committee, and
approved by all members o f the Committee, has been
presented to and accepted by the F aculty o f the School
o f Education in partialfulfillm ent o f the requirem entsfor
the degree o f
D o c to r o f E d u c a t io n
Gate
Dissi Committee
Chau
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ACKNOWLEDGEMENTS
I am grateful to the many people who gave their time and effort to help me
through this learning process of transforming an idea into a dissertation.
Deepest thanks to my chair, Professor Edward Kazlauskas, for his guidance
and help. Thanks to Professor Frederick Knirk for his encouragement and for serving
on my committee. I would also like to thank Professor Myron Dembo for serving on
my committee. I appreciated his many challenging questions and great suggestions.
I am also indebted to Mike Jacobson for his friendship, his good sense of
humor, and countless hours of correcting my writing. I would also like to express my
gratitude to Dr. Cindy Vinson who gave me very useful comments on my first
dissertation draft
My sincere thanks also goes to Professor Richard Clark, Professor Harold
Hailer, Dr. Daniel Blair and to all of my doctoral classmates who encouraged and
supported me during the past several years.
Last, I would like to acknowledge those software engineers and managers who
accepted my interview in the midst of their busy work. They enthusiastically shared
their experiences, thoughts, and insights. I thank them for their contribution.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
TABLE OF CONTENTS
ACKNOWLEDGEMENTS............................................................................. ii
LIST OF TABLES AND A FIGURE.............................................................vi
ABSTRACT................................................................................................... vii
CHAPTER
1. THE PROBLEM...........................................................................................1
Introduction................................................................................................. 1
Statement o f the Problem........................................................................... 2
Purpose of the Study................................................................................... 3
Significance of the Study............................................................................ 4
Research Questions..................................................................................... 4
Definitions...................................................................................................5
Limitations..................................................................................................6
Delimitation................................................................................................6
2. REVIEW OF THE LITERATURE.............................................................7
Introduction.................................................................................................7
The Process of Software Product Development..........................................7
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
I
A Shared G oal....................................................................................8
A Networked Communication System...............................................9
An Information Repository...............................................................10
Policies and Protocols...................................................................... 14
Feedback and Control....................................................................... 16
Performance Measurement...............................................................18
Summary....................................................................................................22
3. METHODOLOGY.....................................................................................24
Introduction................................................................................................24
Subjects..................................................................................................... 24
Design....................................................................................................... 26
Measures....................................................................................................26
Procedures................................................................................................. 28
Data Analyses............................................................................................28
Summary................................................................................................... 29
4. RESULTS................................................................................................... 31
Introduction................................................................................................31
iv
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Cross-Case Analysis..................................................................................31
Analysis by Themes...................................................................................57
Summary...................................................................................................73
5. DISCUSSION, SUMMARY AND IMPLICATIONS............................ 75
Introduction............................................................................................... 75
Discussion.................................................................................................75
Implications...............................................................................................82
Recommendations..................................................................................... 83
REFERENCES.............................................................................................. 86
APPENDIX: INTERVIEW GUIDE..............................................................91
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
LIST OF TABLES AND A FIGURE
TABLE
1. Description o f Subjects........................................................................25
2. Summary of Question 1........................................................................33
3. Summary of Question 2........................................................................35
4. Summary of Question 3........................................................................37
5. Summary of Question 4 A....................................................................40
6. Summary of Question 4 B ....................................................................43
7. Summary of Question 5........................................................................45
8. Summary o f Question 6........................................................................46
9. Summary o f Question 7........................................................................48
10. Summary of Question 8 .....................................................................50
11. Summary of Question 9......................................................................56
12. Summary o f Six Essential Information Process................................. 59
FIGURE
1 . Six Essential Information Processes.................................................... 30
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ABSTRACT
This study sought solutions to improve software development productivity.
The investigation interviewed sixteen software engineers and managers who had been
directly involved in software product development. The interviewees were asked a set
of questions referring to their information needs; the way information was retrieved,
structured, stored, and updated; the information-related barriers during the course of
software development; and an open-ended question asking them to describe an ideal
information infrastructure.
The results revealed six essential information processes that contribute to
productivity. These were:
1) A shared goal and defined requirements.
2) A Networked communication system.
3) An information repository for knowledge retaining.
4) Policies and protocols for storing, updating, and sharing information.
5) Feedback and control for managing changes and making the necessary
adaptations to the changes.
6) Performance measurement for testing the product quality and monitoring
the scheduling.
The research findings indicated that information processes were critical for
software development success. Besides the information processes, this research found
that the concept o f teams, the corporate culture, and the Web were emphasized during
the interviews. Further research in the areas of team interactions, Web-based
collaborative tool designs, and knowledge capturing procedures was recommended.
vii
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
C h a p t e r 1
THE PROBLEM
Introduction
Improving productivity in knowledge worker environments is a critical
challenge in the networked information age. The problem is to divide the task so that
individual efforts can proceed simultaneously, while synthesizing their separate
components to form a coherent whole (Smith, 1994). Researchers in the fields of
computer science, human-computer interaction, c o m m unication , cognitive
psychology, social psychology, and economics are concerned about what factors
influence the performance o f research and development (R&D) teams, and in what
information environment collaboration is efficient.
Speed and productivity o f product development are essential elements for
success, survival, and renewal of organizations, particularly for firms in fast-paced
markets (Brown, 1995; Wheelwright, 1993). Isansiti (1997) emphasized that a
company’s process for rapidly and efficiently translating its R&D efforts into
products that excel in satisfying the market’s needs is much more important than just
focusing on the amount a company spends on R&D as an indicator of its competitive
strength.
I
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The software industry encounters the constant challenge o f fast-paced
software development The common difficulty underneath each software
development project is to deliver a quality product on schedule. The uncertainties and
complexities o f producing software are heavily weighted on the side o f collaborative
intellectual activities (Smith, 1994). Kraut stated “While there is no single cause o f
the software crisis, a major contributor is the problem o f coordinating activities while
developing large software systems” (Kraut & Streeter, 1995, p. 72). McCarthy (1995)
stated, “... without a standard or broadly accepted view o f what constitutes normal
experience during software creation efforts, we are doomed to confuse the healthy
and .the pathological drives o f the software team indefinitely, with no hope of
remedy” (p. 10). This raises the questions o f what is an ideal information process
environment that helps the software development teams to deliver quality software
products on time.
Statement of the Problem
The process of software product development is not well understood. From an
information process perspective, this study provided an in-depth analysis o f how
software products were developed among software teams by interviewing system
designers, engineers, product managers, and project managers who have been directly
involved in software product development.
Software product development involves large numbers o f engineers engaged
in the design and construction o f large and complex systems over certain periods of
2
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
time. Each participant in a team has to take responsibility for solving problems,
making design decisions, working with other design components, and coordinating
the interdependencies. Software development management addresses issues such as
information sharing, communication protocols, scheduling, documentation, and
common understanding o f design specifications. The dilemma o f software
development is that it requires precise planning which relies heavily upon the
completeness and precision of specifications; however, it is very difficult to capture
the right information, to keep up with the changes and to manage the huge amount o f
information. Software engineers often suffer from missing information,
inaccessibility to the pertinent information, or too much irrelevant information.
Management o f the information process in distributed knowledge work
environments; including information needs, acquisition, usage, capturing, structuring,
and sharing; greatly contributes to the challenge o f producing satisfactory software in
a timely manner.
Purpose of the Study
The purpose o f this study was to improve software development productivity.
This research explored essential processes in a software development environment,
which included the understanding o f what challenges the software development teams
were facing, how the teams got and used information to complete their tasks, and how
they communicated, structured, and shared information.
3
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Significance of the Study
This study proposed an information environment that facilitated collaborative
design and development o f complex software products. Although this study focused
on the task domain o f software development, the findings could be of benefit to other
intellectual work settings with similar demands o f information sharing,
communication, collaboration and coordination. The tasks o f intellectual construction
of all kinds draw on a common set o f underlying processes and constraints. For
instance, Baker (1978) mentioned that the nature o f a comprehensive instructional
design required careful definition and coordination o f the flow of activity “while the
system’s components and stages of development are differentiated, it is important to
note that they are interdependent” (p. 6).
In addition, this research lead to the design o f computer tools to improve the
environments for software development. It could help solve the difficulties o f team
communication and information capturing, organization, sharing, and retrieval.
Research Questions
This study explored essential processes that made an environment productive
for software product development The research question was:
What are essential information processes that facilitate the software
development environment to deliver a quality product on time every time?
4
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Definitions
The following terms have been used throughout this study. These short
definitions should assist the reader in understanding the study.
Productivity
Productivity refers to delivering quality software products on time every time.
Software Development Process
The software development process can be described using three generic
phases: definition, development, and maintenance. During the definition, the software
developer and the customer attempt to identify what function and performance are
desired, what interfaces are to be established, what design constraints exist, and what
validation criteria are required. During the development, the software developer
defines how software architecture is to be designed, how procedural details are to be
implemented, and how testing will be performed. The maintenance phase focuses on
change that is associated with error correction, adaptations required as the software’s
environment evolves, and changes due to enhancements brought by changing
customer requirements. (Pressman, 1993).
Software Development Environment
Software development environment is a collaborative intellectual
environment. It requires tight coordination and constant communication among the
multifunctional development teams. The functions and responsibilities of each team
are described as follows:
5
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1) A program management team that manages the schedule, external
dependencies, and manufacturing logistics
2) A development team that involves coding, fixing bugs, participating in
design, and assuring quality
3) A project management team that communicates the product to the market
and the customers
4) A technical writing team that prepares the information so that the end-user
can use the product
Limitations
There were many facets o f software product development; but this research
focused on the information aspect. It primarily emphasized the information process
and communication web with less emphasis on the organizational behavior,
motivation, professional skills, and team interactions. It did not cover the financial,
marketing, sales, or business-oriented aspects o f software product development.
Delimitation
The research focused on the information process and information
environment. It addressed the information-related issues o f knowledge workers in a
closely coupled work setting. The study was limited to the analysis o f software
product or knowledge-related product development.
6
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
C h a p t e r 2
REVIEW OF THE LITERATURE
Introduction
This chapter reviews related literature and discusses the nature o f software
product development. The chapter is divided into six sections representing six
essential processes: 1) a shared goal, 2) networked co m m unica tio n , 3) an information
repository, 4) policies and protocols, 5) feedback and control, and 6) performance
measurement.
The Process of Software Product Development
A process is a sequence of steps performed for a given purpose. Schwarz
(1994) emphasized that groups must manage a number of processes in order to be
effective. “A software process can be defined as a set of activities, methods, practices,
and transformations that people employ to develop and maintain software and the
associated products” (SEI, 1995, p.9). The products include project plans, design
documents, source code, test cases, and user manuals. A fully effective software
development process must consider the interrelationships o f all the required tasks, the
tools and methods used, and the skill, training, and motivation o f the people involved
(Humphrey, 1987).
7
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
I
\
The sections below review the related literature on processes involved in
software development.
A Shared Goal
Researchers (O’Connell, 1996; Schwarz, 1994; Sundstrom, 1990) considered
a clearly defined goal as the key to team effectiveness. “A group cannot reach its
goals systematically if the goals are ambiguous or missing. The goals should be clear
enough that the group can measure its progress toward them” (Schwarz, 1994, p. 29).
O’Connell (1996) stated that after identifying the goal, two related processes should
start immediately. One was to tighten the definition o f the goal, and the other was to
start the planning process. Schwarz (1994) stated that the two primary group
processes were problem solving and decision making.
At a very early stage in software development, the different parties (the
customers, marketing managers and software developers) get together to discuss and
reach an understanding of the requirements o f the product. Tasks based on the
requirements, functional specifications are assigned to different groups and
subgroups. Each development group estimates the time and resources required and
develops development plans and milestones, and actually starts developing the source
code for achieving the goals.
A fundamental characteristic of many software systems is that they are very
large and far beyond the ability of any individual to create or even to understand in
8
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
complete detail. The best way to design a complex structure is to first decompose it
into separate parts. Simon (1981) stated:
One powerful technique is to discover viable ways o f decomposing it
into semi-independent components corresponding to its many
functional parts. The design of each component can then be carried out
with a degree o f independence from the design o f others, since each
will affect the others largely through its function and not through the
details o f the mechanisms that accomplish the function (p. 148).
Coordination is the act of managing interdependencies between activities
performed to achieve a goal (Malone, 1993). Researchers in coordination science ask
questions such as how overall goals can be subdivided into actions, how actions can
be assigned to groups or to individual actors, how resources can be allocated among
different actors, and how information can be shared among different actors to help
achieve the overall goals.
A Networked Communication System
Software development needs sufficient c o m m unication networks and various
communication channels. Research conducted at IBM 's Santa Teresa Laboratory
found that 50 percent o f a typical programmer’s time was spent interacting with other
team members, 30 percent working alone, and 20 percent in not directly productive
activities (Rada, 1991). The research indicated that communication played an
important role in developing software.
In large software development projects, communication bottlenecks and
breakdowns are very common (Karut & Streeter, 1995). Because o f the high degree
9
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
of uncertainty typical o f software projects, informal and interpersonal communication
should be a valuable method for achieving the coordination necessary for complex
systems. Because o f the large size of these projects, the inefficiencies of face-to-face
communication may preclude the use o f informal communication as a practical
technique for solving coordination problems. Because of the tight coupling necessary
between software modules, conversation, the primary medium of informal
communication, may be too imprecise to communicate well and too ephemeral to
serve as a record o f the informal exchange (Kraut and Streeter, 1995).
Brooks, Jr. (1995) stated the two reasons why the Tower of Babel was a
failure were communication and organization. “They were unable to talk with each
other; hence they could not coordinate. When coordination failed, work ground to a
halt” (p. 74). He suggested that teams should communicate with one another in as
many ways as possible through phones, meetings, and workbooks. With available
technology, the workbook could be on a direct access file, marked with change bars
and revision dates. He also pointed out that organization was necessary to reduce the
amount o f communication and coordination. “If there are rt workers on a project,
there are (n2 - n)/2 interfaces across which there may be communication, and there
are potentially almost 2n teams within which coordination must occur” (p.78).
An information Repository
A shared information repository stores all the related intellectual artifacts,
including source code, design specifications, design rationale, assumptions, policies,
10
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
!
procedures, e-mail and memos. Team members are responsible for storing their
intellectual artifacts. This information repository serves as a knowledge database,
which not only has the storage function, but also has organizing, updating, and
retrieving capabilities. People put forth effort to build an information repository, but
the structured and unstructured forms o f information still fail to serve the complex
interaction activities o f software development. Often, information is not easily
retrieved, is inappropriate for usage, or is incomplete. Much of the developing time is
spent in trying to locate and collect relevant information.
The following section reviews relevant literature and explains the important
characteristics that are associated with an information repository: accessibility,
collective intelligence, and organizational memory.
Accessibility. Accessibility is the most important criteria in the choice of an
information source. Accessibility is more important than any other property,
including the perceived quality of information carried. There are many aspects of
accessibility. There are practical, measurable aspects such as physical proximity and
response time. There are also psychological aspects, such as the perceived intellectual
level required to access the source, and the personal or corporate style of the
management o f the source (Maguire & Kazlauskas, 1994). Individuals are important
not only because they themselves are a source of information, but also because they
largely determine what information will be acquired and then retrieved from the other
memory stores. Networked computers provide the basis for a “nervous system” that
11
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
could be used to develop the capacity for organizational memory. Information flows
among team members in the forms of e-mail, file transfers though the network,
accessing the database, and other forms of communication.
Collective intelligence. Smith (1994) proposed that the concept o f collective
intelligence be constrained to collaborative groups that used a computer and
communication system as an integral part o f their work. A requirement for collective
intelligence is achieving a critical level of coherence in the work. Smith described:
... the concept of collective intelligence by considering how
collaborative groups ranging in size from 3 to 30 individuals working
together for periods of several weeks to several years can produce an
intellectual product that represents accomplishment of the group’s
main goal so that the product has the characteristics we would expect
had it been produced by a single good mind. (Smith, 1994, p. 3)
Collective intelligence is when a group o f human beings carry out a task as if
the group was a coherent, intelligent organism working with one mind rather than a
collection o f independent agents. That is, “a singular purpose and a seamless
integration o f the parts, as if the conceptual object were produced by a single good
mind” (Smith, 1994, p. 3). The hypothesis o f collective intelligence is that it is related
to individual intelligence, but it involves more than one person at the same time and it
works with higher-level communication systems. Some o f the processes involved in
collective intelligence can occur between people, although at a different level of
complexity.
12
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Organizational Memory. Organizational memory refers to the record o f an
organization that is embodied in a set o f documents and artifacts. It is the knowledge
that enables the organization to remember and to reinterpret effectively. The construct
o f organizational memory includes the structure of a retention facility, the
information contained in the facility, the process o f information acquisition and
retrieval, and the consequential effects o f that information system.
Schatz (1993) proposed three imperatives for considering organizational
memory: the locus of organizational memory (i.e. its retention structure); the
processes by which information can be acquired, stored, and retrieved from this
retention structure; and the precise ways by which the use o f memory is consequential
to organizational outcomes and performance. People in an organization have need to
browse the knowledge, to filter out selections irrelevant to the problem, and to share
annota tio n s o f the relevant selections with other members o f the organization (Schatz,
1993). Yakemovic (1993) designed a tool to capture organizational memory called
Issue-Based Information System (IBIS). IBIS provided a content-based indexing
structure within which the cumulative records of the organizational process was
preserved and organized. It was also easier to determine why a decision was made
without replaying the discussion. When an expert left, much o f the logic behind his
design was retrained. This “why” information turned out to be critical to
implementing the systems. The use o f organizational memory could facilitate
decisional processes. Walsh (1991) stated:
1 3
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Specifically, the retrieval o f both decision stimulus and response
information from the individual retention facility and other sources of
memory can help to frame a particular problem or opportunity in its
historical context. By and large, it is the controlled (i.e., purposeful
and conscious) retrieval o f information from the retention facilities
that can be the most helpful in the decision formulation stages, when a
person is assessing the similarities and differences between the past
and the present. (Walsh, 1991, p. 74)
The information repository represents a collective intelligence. For an
organization to augment its memory, Conklin (1993) emphasized that it must shift
from the currently pervasive document- and artifact-oriented paradigm to one that
embraced the process behind the artifacts. That was, to capture the context that laid
behind the documents when they were created.
Organizations are finding that the artifact-oriented way o f capturing
work to be too impoverished a model to support the complexity of
work in the information age. They are turning to a richer, more
complete view, which embraces the messy (and sometimes chaotic)
nature o f process. No longer ignored are the assumptions, values,
experiences, conversations, and decisions, which lead to and constitute
the context and background o f the artifacts. (Conklin, 1993, p. 562)
Policies and Protocob
Software development must have strong constraints and disciplined
procedures to guide the team to produce a highly cohesive and fully functional
product according to the product specification. A policy is statement o f principle
governing software development activity. A protocol stipulates format, content and
activity conventions for software development. Donaldson and Siegel (1997)
considered policies, guidelines, procedures and standards be important components
14
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
for software development environment. Policies, guidelines, and protocols bring
about consistent product development
Collaboration is a type o f information processing activity. This collaborative
activity must address wide-ranging issues such as how individuals or teams working
together represent knowledge and use conventions to facilitate the sharing and reuse
of knowledge base systems. Greif and Sarin (1987) asserted that a central concern in
computer-supported cooperative work was coordinated access to shared information.
In software product development, the combination o f large size, uncertainty,
and interdependence requires special coordination techniques that may not be
necessary in more routine production environments. Because of interdependence,
different groups involved in software development are tightly coordinated. In addition
to setting a hardware framework, an organization must set the standards, procedures,
policies and make the capturing o f the process information tap into the flow o f
communication that is already happening within an organization.
Software consists o f thousands of modules that must mesh with each other
perfectly for the software system to operate correctly. Kraut and Streeter (1995)
indicated that the large size and uncertainty in software development would be less of
a problem if software did not require precise integration o f its components. Poor
coordination between subgroups producing software modules led to failure in
integrating the modules.
15
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Control o f the integrity of the source code includes defining the procedures
and policies for checking in and checking out source code from a central database.
Access control mechanisms need to be set up to prevent two engineers from working
on the same piece of the code at the same time to avoid overwriting code. Coding
guidelines are developed so that all team developers use the same convention, such as
variable naming conventions, coding styles, and documenting when designing the
software system.
By following communication protocols, rules and policies, team members are
able to store and retrieve information from the repository to perform their tasks. The
information delivered by the computer needs to be conveyed to users in a way they
can comprehend, and likewise, users need convenient ways to convey their reasoning
to the computer.
Feedback and Control
Software design is best understood as an evolutionary design process. It is
uncertain because the design information can never be complete, and the design
practices change with time (Gilb, 1988). A field study showed that people were
initially unable to articulate complete requirements and tended to start from a partial
specification and refine it incrementally based on feedback (Fischer, 1992).
Brown (1995) suggested that innovative routines, which included dynamic
planning, monitoring, and scheduling project overtime as the environment changes,
were needed. Eisenhardt (1995) studied accelerating adaptive processes. The results
16
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
indicated that using an experimental strategy o f multiple design iterations, extensive
testing, frequent project milestones, a powerful project leader, and a multifunctional
team accelerated product development.
Bohner and Arnold (1996) warned that making software changes without
visibility into their effects could lead to poor effort estimates, delays in release
schedules, degraded software design, and unreliable software products. Software
product development often required repositories to organize their software artifacts,
which were becoming increasingly interdependent. They proposed the idea of
software change impact analysis for a detailed examination of the consequences of
changes and the impacts on the relationships among software artifacts — including
requirements, design source code, test cases, and documents.
Document control is a serious problem in the process of development. Recent
studies have confirmed that capturing design rationale was especially important in
large-scale development efforts. Different project teams are involved in different
phases of system development. In the absence of knowledge about design rationale,
key design decisions are often misunderstood and misinterpreted (Ramesh, 1992).
Conklin (1993) stated, “the design rationale o f large, complex systems is thoroughly
and systematically lost” (p. 562). This process knowledge, involving deliberation on
alternative requirements and design decisions, is often lost in the course o f designing
and changing such systems (Ramesh, 1992). New engineers must understand why
previous engineers made design decisions. The reasons often consist of not only why
17
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
a choice was made, but also how specifications and constraints interact with other
design decisions. When making a change to a system, the maintenance engineers
must understand how the change will propagate to other parts of the system. The
software development team needs tools to help capture and access design ideas,
design scenarios, design status, design issues, solution rationale, source code, control
policies and other tasks related to information processing and collaboration.
Paepcke (1996) pointed out that the information shared with insiders was full
o f rich context. The information described processes, changes, and rationale. These
descriptions contained many interwoven threads, rather than isolated facts. However,
the information shared with outsiders was simply to describe interfaces between one
group and another, to convey the current status of a piece of work, and to provide
isolated facts, such as names of the contacts. He continued that process-related
information had three basic components: context, control flow, and exceptions. The
context identified the current place in the process to make the data understandable
and to evoke the proper questions and the structure in the user’s mind. Control flow
information produced the choices of actions at a particular point, such as tests that
might help refine a problem and identify the documentation to consult. Exceptions
conveyed how the current step might fail and how it can be recovered.
Performance Measurement
An important initial step in addressing software development is to treat the
entire task as a process that can be controlled, measured, and improved (Humphrey,
18
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1987). Measurement is fundamental to any engineering discipline. Software
engineering is interested in measuring the following three entities: the design process,
the software product, and resources. The design process is concerned with
constructing specifications, the detailed design, and the testing; the software product
includes design documentation, source code, and test suites; and the resource consists
o f teams and hardware and software resources (Pressman, 1993).
The software project status has to be closely monitored (Humphrey, 1990;
Paulish, 1993). The system checks the integrity of new information objects, notifies
developers about internal and external changes, reviews the progress status,
coordinates interdependencies, alerts for critical paths, and documents why something
happened. When an expected schedule slips, the problem must be diagnosed and
necessary resource allocations or readjustments made that might require rearranging
the team tasks.
Communication network systems should be robustly supported to allow
synchronous and asynchronous, one-to-many, and many-to-many communication.
The network configuration needs to integrate all the components and sub-components
together and ensure a successful assembly build every night. The entire design team
needs to know the network configurations in order to link the necessary components.
In this area, developers need to know the network environment settings, the computer
facilities and tools, the source code, and document policies and protocols.
19
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Based on the specification defined, the quality assurance team designs a test
plan and test cases for each component o f the product, as well as an integration test
for the entire product. “In problem solving, a partial result that represents
recognizable progress toward the goal plays the role of stable subassembly” (Simon,
1981, p. 206). Some methodologies call for carefully developed test suites and
rigorous testing of components before and after integrating these components into a
larger program.
The test plan needs to closely correspond to the developers’ schedule, product
functionality, and any modification of the specification. The overall testing
environment, bug tracking systems, and the documentation of testing procedures
needs to be agreed upon between the development and testing groups. Incremental
and extensible releases, defects tracking, and functionality testing are measurements
of performance.
There are three widely known assessment methods for quality measurement:
the Malcolm Baldrige National Quality Award (MB), the International Organization
for Standardization 9000 (ISO 9000), and the Software Engineering Institute (SEI)
Capability Maturity Model (CMM) for Software (Zubrow, 1994). The fundamental
concepts o f these three methods are for continuously improving the software process.
They are not intended as specific requirements but rather as an underlying philosophy
or guide for a quality management system. The guidelines ISO provides for the
software development are such as development planning, quality planning, testing
20
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
and validation, acceptance, installation, maintenance, configuration management,
document control, measurement, rules, practices and conventions, tools and
techniques, management responsibility, internal quality system audits, corrective
action, and purchase requirements (Jenner, 1995).
Tingey (1997) compared the three assessment methods and summarized the
top three elements in each one:
1) Malcolm Baldrige
a) Process Management (MB devotes 29.4 % in its activities to this category)
b) Customer Focus and Satisfaction (23.6 %)
c) Information and Analysis (13.2 %)
2) ISO
a) Process Management (66.4%)
b) Information and Analysis (9.6%)
c) Customer Focus and Satisfaction (7.5%)
3) SEI
a) Process Management (56.3%)
b) Leadership (16.3%)
c) Information and Analysis (11.4%)
21
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Process Management examines the key aspects o f process management,
including customer focused design, product and service delivery processes, support
services and supply management involving all work units, including research and
development.
The Information and Analysis category examines the management and
effectiveness o f the use o f data and information to support customer-driven
performance excellence and marketplace success.
Leadership examines senior executives’ personal leadership and involvement
in creating and sustaining customer focus, clear values and expectations, and a
leadership system that promotes performance excellence.
Customer Focus and Satisfaction examines the company’s systems for
customer learning and for building and maintaining customer relationships.
Summary
This review of the literature associated with the process of software product
development was discussed. Software development is large scale, complex, and
component-based but interdependent. The design is often iterative and evolutionary.
It is a knowledge-intensive process involving information capturing, retrieving,
understanding, managing, and sharing. It demands close communication,
coordination, and collaboration so that the released product appears as if single good
mind created it (Smith, 1994).
22
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Management of the information process is key to overcome the barriers o f
missing and inaccessible information. The amount and variety o f information
available to the team affects the success o f product development (Brown, 1995).
Based on the literature reviewed, the software development environment requires the
following information components:
1) A shared goal and clearly defined functional specification.
2) A networked communication system to distribute and retrieve the information.
3) An information repository to capture the information and to serve as a knowledge
base.
4) Policies and protocols to acquire, store, update, and share the information.
5) Feedback and control to manage the information changes.
6) Performance measurement.
23
i
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Chap te r 3
METHODOLOGY
Introduction
This chapter describes the research design and procedures used in this study.
The subjects, survey methods, and measurements used to conduct the study are
discussed.
The purpose of this study was to explore essential information processes of a
software development environment that improves software development productivity
through the understanding o f information needs, information acquisition and usage,
information-related issues, and the management o f information changes during the
course o f software product development.
Subjects
This study examined software engineers and managers who have been directly
involved in software product development. Table I presents a summary o f descriptive
characteristics o f the subjects.
24
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 1
Description of Subjects
Subject Company Size Experience Role Gender
1 Company A L 10+years Developer M
2 Company B L 10+years Manager F
3 Company B L 10+years Manager M
4 Company C S 10+years Manager M
5 Company D S 10+years Manager M
6 Company B L 10+years Manager F
7 Company E M 10+years Developer M
8 Company E M 3 years Developer M
9 Company A L 10+years Manager F
10 Company A L 10+years Developer F
1 1 Company F L 2 years Developer F
12 Company F L 2 years Developer M
1 3 Company G L 3 years Developer F
14 Company H L 2 years Developer M
1 5 Company I S 5+years Manager M
1 6 Company F L 10+years Manager F
The study involved interviewing 16 subjects, from nine different companies.
Five o f the companies had greater than 1000 employees, three o f them were small
companies with less than 100 employees, and one was a medium size company with
approximately 250 employees. Eight of subjects were in a management role and eight
25
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
of them were software developers. For confidentiality, all the company names were
coded by Company A, B, etc., and the subjects were coded as subject 1, subject 2,
subject 3 ,... up to subject 16.
Design
This research used the general interview guide approach (Patton, 1990). This
approach involved a set of questions and issues that were explored with each
respondent before interviewing began. The set of questions (See Appendix A) was
first e-mailed to each o f the participants in the study. The questions served as a basic
checklist during the interview to make sure that all relevant topics were covered. The
entire interview was tape recorded and later transcribed by a professional court
reporter. The analysis of the transcribed tapes focused on the following questions as
they related to the research questions posed by this study.
Measures
The study used nine questions, which mapped to the research questions and
the proposed six information processes. Question 1 mapped to Shared Goal, which
was to define the product purpose and requirements. Questions 2 and 4 mapped to
Information Repository, which captured information and became a knowledge base.
Question 3 mapped to Policies and Protocols, which set the standards for information
storing, retrieving, updating and sharing. Questions 5, 6, and 7 mapped to Feedback
and Control, and to Performance Measurement. From these three questions the study
26
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
intends to measure how the development teams managed changes and
interdependencies, and monitored the project status against the goal and schedules.
Question 8 mapped to Networked Communication, which helped to distribute and
retrieve information. The last question directly asked the general research question of
an ideal software development environment that improved the productivity of
software product development. The following was the questionnaire:
1) What kind o f information is most critical to you during the process o f software
development?
2) How do you get and use the information to accomplish your tasks?
3) How easy is it to retrieve the information you need? Is there any information
missing, conflicting, out dated, or overloaded?
4) How is information structured and stored? Do you have any suggestions for
improvement in this area?
5) How is information updated? Do you have any suggestions for improvement in
this area?
6) How is information shared? Do you have any suggestions for improvement in
this area?
7) What are the information-related barriers that prevent you from doing your job
effectively, such as out-of-date materials, awkward access procedures, etc.?
27
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
8) Evaluate and rank the effectiveness o f these communication channels as they
help you get the task done: group discussions, phone conversations, e-mail, face
to face meetings, and printed memos.
9) Describe an ideal information infrastructure that will help a software
development team to be successful.
Procedures
A pretest of the questions was given to three engineers. The questions were
modified based on the feedback o f the pilot study. The questions were made shorter
and open-ended to allow participants to elaborate more in their answers.
The interviews took times ranging from 45 minutes to 2 hours, in a face-to-
face interview with audio tape recording for twelve o f the study participants. The
other four participants used e-mail to answer the questions because of geographic
limitations. All of the recorded interviews were transcribed. The tapes were replayed
to check the correctness of the transcription. Some answers were followed up with e-
mail and telephone calls for clarification.
Data Analyses
The study first used content analysis to do the cross analysis for each question
from the transcriptions. Secondly, the transcriptions were analyzed and organized by
the research questions. In other words, the contents were analyzed by the six essential
information processes (See Figure I). Each process was considered as a theme. A
28
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
theme itself was considered a unit o f analysis (Budd, R. W., Thorp, & R. K.,
Donohoe, 1967). The themes were linked to the problem and the theories on which
the research was based.
The transcriptions were analyzed for recurring themes:
1. A shared goal.
2. A networked communication system.
3. An information repository.
4. Policies and protocols.
5. Feedback and control.
6. Performance measurement.
Summary
The chapter discussed the research procedures: the subjects, survey methods,
measurements, and the data analysis. In the next chapter, the detailed data analysis
will be given.
29
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 1. Six Essential Information
Processes of a Software Development
Environment
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
C ha p t er 4
RESULTS
Introduction
The findings from each question, based on the interviews, were analyzed in
this chapter. There were two sections in this chapter. The first section used cross-case
analysis (Patton, 1990). It grouped together answers from different interviewees for
each question and it analyzed interviewees’ perspectives on each question.
This second section analyzed the answers based on the six essential
information processes derived from the literature review in Chapter 2. Each process
was considered as a theme or a category. A theme itself was considered a unit of
analysis.
Cross-Case Analysis
In this section, a summary table o f each question was presented. It grouped
how the different interviewees responded to each question. Quotes were used to give
more details to support the points identified. Each quote ended with a footnote
reference numbered subJect 2’ 3’ etc., which represented the interviewee.
31
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Question 1: What kind of information is most critical to you?
Table 2 showed that the most critical information during the software
development was to know the customers’ needs and to know their problems, the
requirements, and functional specifications.
The results revealed that developers were concerned with what the product
was supposed to do and with the problem they were solving. “The first step is that
you have to know who it’s for. Otherwise, you end up building a product that maybe
isn’t useful for anyone.”S u b jc ct 4 “Knowing your user and your user’s environment is
very important; knowing what their current problems are, is the key. You want to
make their job much easier than it is today.”S u b jcct 2
The results indicated that the managers paid more attention on the project
goals, plans, schedules, and status.
The kind of information that I was really trying to get on a regular
basis was project logistics information. Were the tasks happening on
time? Were there potential problems coming up that might risk the
schedule in the future? Were there problems between groups where
one group needed something from another group and things weren’t
being communicated smoothly.S u b jcct 9
32
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 2
Summary of Question 1: What kind
of information is most critical to
you?
Subjects Descriptions
1, 2, 4, 7,
13, 14
Customers’ needs and problems; requirements
8,10, 11,
12, 15
Requirements and specification
5,6,15 Project goals, plans and schedules
3 Design rationale, assumptions, and scope
i 1
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Another valuable piece of information that a system architect emphasized was on the
design rationale, which interacted with other decisions and assumptions.
Usually, you focus around functions and information about
functionality. And those things like rationale and the decisions you
made often times end up as the one that bites you. You don’t
necessarily report why you made those decisions. You may have read
for two or three hours and decided something, only to go back and
document the conclusions but not the decision process. The hard part
is that rationale is not easy to get down. They are made up [by the]
factoring of different things. Often times the pieces that you want to
refer to, are hard to go back and reconstruct the reasoning at the time
or figure out how to apply it to a current situation because a whole
bunch of things have changed in the meantime. So, I think capturing
rationale is an important one.Subject3
Questions 2 and 3: How do you get information and how easy is it to retrieve?
Getting the right information from the right people and tracking that
information in a timely way was critical to the success of software development. Most
of the responses indicated that the information came from the product development
manager, project management team, or system-engineering group. These people or
groups were responsible for creating the requirements or specifications by interacting
with the customers and marketing managers. The responses o f how to get the
information were summarized in Table 3.
34
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 3
Summary of Question 2: How do you
get Information?
Subjects Descriptions
13 We got the information from our program managers and
marketing folks.
5,8,15 We have to work closely with the product development
manager and develop our own specification from their
marketing requirement document
9 Getting the project logistics information from the right
people and tracking that information in a timely way.
10 Mostly I talk to the developer to have a verbal transfer of
knowledge about what the design purpose was or what
influenced a design decision.
12,16 We have system engineering groups that generate
requirements.
15 Get the design specification from the system architect
who gets it from customers.
1 4 From specifications and project status through group
Web.
5 Most leading-edge projects need information from
vendors.
7 From project management teams and the marketing
people at the very beginning.
1 2 Design documentation and/or people.
35
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
As for the retrieving information, the answers showed that the development
teams had difficulty in getting information. The responses were summarized in Table
4. The most common problem was missing and inaccessible information. In general,
retrieving information required lots of communication between the marketing teams
and the developing teams. The results also revealed that their communication often
broke; “You have to find one o f those marketing people and ask them what is going
on, and they are hard to get hold o f.,,S u b ject 1
Getting the information isn’t easy. It’s very unlikely that you have a
fully defined specification at the very beginning. It is necessary to
have meetings to go back and forth with marketing, project managers
and engineers. The sooner we leam about changes the better we can
quickly react to them .S u b jcct 7
As a project manager, I often create the information. In terms of
requirements, I beg and plead with Marketing and keep interacting
with them until I get the requirements in the way that we can use them.
And sometimes I’ll even write a draft to say, ‘Well, this is what I think
. Subjects
you want.
The results also indicated that storing the information on different platforms
made it difficult for people to access and transfer information. From a marketing
manager’s point of view: “Information has to be on the platform that is easy for
marketing to use. I am using Windows system on PCs, but engineers are mostly on
Unix.” S u b je c t 6
In addition, different teams often had difficulties in accessing other’s
information. For example, a marketing manager responded that “engineers have a
36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 4
Summary of Question 3: How easy is
it to retrieve the information?
Subjects Descriptions
1 No ownership or responsibility for the different sections
of the codes.
2 It relies on the project manager to coordinate. The
information is not always available.
16 The quality and the level o f details may vary from person
to person.
3 The rationales are often times not easy to get down.
Different versions o f product specifications are not
clearly documented. It is hard to understand what the
system was supposed to do then and what it is supposed
to do now.
6 It is hard to get information across different platforms,
such as PC Mac, and Unix.
15 It is relatively easy to access one’s own information. But
it is more difficult to access and share information with
other team members.
11 We need to spend time searching for the right person to
get the information from when the document does not
exist.
37
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
tendency to hide information in some very secure way and it’s hard to access.”5* 1 ^ 6 0 1 6
The developers’ viewpoints were different. For instance: “The product marketing
people have the business knowledge but have no technical background. It is difficult
to retrieve information the way that developers need.”S u b ject 8 However, the project
managers paid attention to different kinds o f information. They considered the day-to-
day operational tracking of the work as opposed to the more exciting technical
challenges of what new features can be taken advantage of. “Getting the managers to
think along what the project management needs was very difficult.”Subject9
Not only were there problems of accessing information between different
teams, but there were also problems o f accessing information within a team. ‘Tt is
relatively easy to access one’s own information. But it is more difficult to access and
share information with other team members.”S u b ject 1 5 “Usually I go to the
documentation. Sometimes you have to just read the source code. And mostly I like to
talk to the developer because the documentation is out of date. Even though people
write design documents, a lot of times they don’t write what the purpose was or what
influenced a design decision.”S u b ject 1 0
There was only one interviewee that did not have the problem o f retrieving
information. “It’s very easy for us to get the information we need since we have other
people working on this full time. If the information is not clear or if there’s anything
38
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
missing, those people will resolve the conflicts and issues and send us the information
, ^Subject 13
we need.
The study also found out that the development teams required both internal
and external information. With most leading edge projects, development teams
needed information from vendors. “We’re very reliant on Netscape’s technology and
Microsoft’s technology and there we have this real problem of trying to get the
information, because most of these companies are trying to move away from printed
books.”S u b ject 5 This indicated a new problem o f using on-line information:
We all know how to use printed books. We can sort of scan the book.
But when it’s on the web and the web sites are constantly changing,
it’s extremely frustrating because you don’t know what’s there. What
was there last week may not be there this week. And they may change
the form o f the information. And there’s no way for you to know what
changed. So you’re forced to reread the same thing over and over
again to find out what’s changed. Or you end up just giving up and
trying to go without that information. In the days of books, books
would come out periodically. And while they’re out, they’re stable.
You can throw bookmarks in there. You can throw Post-it’s. You
know where it is. It becomes yours, but a web site just is beyond
_ , Subject 5
control.
Questions 4 ,5 , and 6: How is information structured, stored, updated, and
shared?
Structure. Table 5 summarized the findings. The results suggested three ways
to structure the information:
39
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 5
Summary o f Question 4A: How is
information structured?
Subjects Descriptions
5,9 Providing templates to distill information and adding an
extra level o f filtering to show the significant project
issues.
9 Web sites with the project status information, having one
person identify what is the minimum subset of
information that’s important to track.
6 An intelligence system keeps track o f the decision
making process so that people know what is happening.
10 We are storing our documents in just a file directory;
I try to put them into the source code control system.
2 It’s important to separate out the functionality,
specification-oriented documentation from the programs.
40
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
1) Using templates to guide people to document the minimum information
needed; people had tendency to put out too much information. “Using
templates helps to distill information down to a bare minimum of just what
is needed to move forward. If you keep it small, people are more likely to
update it.’’S u b jcct 5
2) Identifying the valuable information to track down and to filter out the
unessential; “Because there were so many components and so many
issues, it was hard to know what was really significant and what wasn’t, so
an extra level of filtering would probably have been helpful. And I tried to
provide a template for each manager so that the information would be
presented in the same way.”Subject9
3) Using an intelligent computer system to capture the decision making
procedures; “An intelligence system keeps track of the decision making
process so that people know what is happening; by when and who needs to
be informed; where I can get the information; and who I can
contact.”S u b j“ *6
Storage. Table 6 summarized how information was stored. Storing
information in a way that people could easily get access to appears on most
interviewees’ answers as a critical factor for a successful software development
41
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
project. The findings showed that information was usually stored in a database and
was provided with the capability of version control, which allowed people to trace the
historical changes o f a particular piece o f documentation. “A small, simple and easy
to use knowledge repository that allows team members to check-in and check-out
design specifications, to check schedules, and to log the changes.”S ubjcct 1 5
Documenting took time and resources. The research found out that there were
not many companies that document information in an organized manner. They mostly
communicated verbally except for the very large companies. The two examples were
following:
“We have the full time employees analyze information and store the
information in a public database that only a particular group of people can access.
Everyone with access permission can go update it.”S u b jcct 1 3 “Per ISO-9000 process,
we have a department library which keeps all relevant project meeting m inutes,
requirements, and software design documents electronically. We even have a librarian
who keeps track o f all department publications and disseminates information when a
new document is available.”S u b jc ct 1 6
Another aspect of storing information was to be able to easily access the
information. “A powerful and easy to use on-line tool is needed because of the
limitation of 'paper’ documentation. For instance, each technical support engineer
42
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 6
Summary of Question 4B: How is
information stored?
Subjects Descriptions
1 I tried to use on-line document system once or twice and
it was such a nuisance.
2 The software development process is well defined, and
information database keeps history and was adapted to
users.
8 The information is stored in Word documents and in
Lotus Notes, but not stored under any source code control
system.
11 The information is stored in hard copy manuals. An
easier way to access these manuals on line with a search
function will be very helpfuL
16 A software configuration management tooL
12 The information is created in Framemaker format and
stored in hard copy.
14 Information is often stored in a database.
13 Full time employees analyze information and store it in a
public shared database that only particular group can
access it.
43
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
needs a whole set of documents for each release. We have 4-7 binders for each
release and each binder is three inches thick.”S u b ject 1 1 If the information was
structured and stored in an easy way for access, such as on-line documentation with
smart search functions, it would be very helpful. “If the software development
process is well defined, historical information is provided, and tools are adapted for
people to use, then I think it would be easier for the developers to perform their
tasks.”S o b j“ ' 2
Update. The results indicated that keeping information updated was a
challenging task. Table 7 summarized the findings. “Information needs to be updated
at the point that the change was made.”S ubjcct 5 “We need a tool which can identify a
change in the document and automatically generate e-mail to a list o f interested
„ „Subject 6
parties.
“Initially, our company is very good at documenting things. But later the bug
fixes and minor changes are poorly updated. But changes are not automatically posted
to other team members.”S u b jcct 1 0 “Team members use e-mail to inform others about
the changes but the information is fragmented and dispersed.”Subject 1 5 “We used to
have a problem that people did not know the information had been updated. For this
version, our program manager started to send out e-mail whenever they updated the
information. Everyone in the group could go get the updated information.”S ubject 1 3
44
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Share. The findings showed that software development teams used multiple
ways to share their information, such as group meetings, e-mail, on-line news groups,
the Web, a librarian, and hard copy. (See Table 8.)
Group meetings were the best way for sharing information. “You ask probing
questions about what each person believes we’re doing or the assumptions they’re
making about the specification. Try to flush out their understanding so that if there
are conflicts, enough words are going to be said that are meaningful.”S ubjcct 5
Table 7
Summary of Question 5: How is
information updated?
Subjects Descriptions
5 Updating the project information at the point the change
is made is important
8 The document is manually updated. The person also has
to inform other people by himself.
10 It is hard to mandate people to update information.
16 A software configuration management tool that allows
updates to the documentation with version control
capabilities.
1 3 Everyone with access permission can go to the shared
database and update the information. The program
manager starts to send out e-mail whenever the
information gets updated.
45
i
, i
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 8
Summary of Question 6: How is
information shared?
Subjects Descriptions
1 It would have been good to be able to see demonstrations
from other groups and what they were working on instead
o f just wondering about it.
5,9 Meetings are the best way of sharing information.
We had meetings where each manager presented their
component status to the whole management team.
7, 12,14 Publishing information through the Web.
The information would be easily accessed on the Web.
Information is on the Web pages.
15 E-mail
13 Information is stored in a public share. Everyone in the
group can go get it
16 We have a department library which keep all relevant
project meeting minutes, requirements, design documents
electronically and a librarian who keeps track o f all
department publications and disseminates available new
document
7, 12 Sometimes you're just getting a hard copy o f a spec from
some member of the team.
Hard copy dissemination.
46
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The Internet and Intranets are the biggest network we have had in this
century for publishing and getting information. The amount o f
information that is suddenly open to you is unbelievable. A relatively
large company uses the Internet to distribute information, and you
could look and use it at any time you need it.S ubjcct 7
The results indicated that the Web sites with the project status information
were useful for information sharing.
The best way is to have one person identify the m inimum subset of
information that is important to track. And then everybody tracks at
least that much information in the same format. So that our vice
president could look at anybody’s web site and say, ‘Oh. I see what
your issues are. I understand the red flags’.S ubjcct 9
Question 7: What are the information-related barriers?
Table 9 summarized the information-related barriers. The results showed that
information that was missing or not updated were the big barriers. Awkward
information accesses and difficulties in transferring information across different
platforms, information dispersed, and not having the same interpretations of
requirements were also barriers. For instance, “It would be beneficial to disseminate
the updated, accurate information in a timely manner to all parties involved.”Subject 1 6
The following was an example of the problem o f information dispersed.
47
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 9
Summary of Question 7: What are
the information-related barriers?
Subjects
Descriptions
15 Related information is dispersed. It becomes difficult to
piece all the related information together.
16 Different parties have different interpretations to the
changes.
3, 7,11 Information is not updated.
2,5,10,14 No corporate culture support; different agenda among
teams.
1,6 Awkward procedures for accessing information.
4 Missing a crucial a design step.
8,10,12 Missing documents
5 Not providing the context for communication.
5, 13 Product built based on still under development
technology.
48
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Not being able to select and connect related information. For example,
not being able to link between e-mail and Word documents.
Information related in content is separated and dispersed in different
information spaces and tools. It becomes difficult or impossible to
piece all the related information together. Too many connections are
stored is human memory rather than an easily retrievable knowledge
. Subject 15
system.
Another problem was lack o f the cultural support for documenting and
communication. The following were some sample responses: “We need an
organization that emphasizes communication, we need to know the context that you
are operating in.”S u b jc c t 5 “We do not get immediate support from MIS for computer
environment problems.”S u b jcct 1 4 “You try to establish culture and enforce the rules on
where to get information.” S u b ject 2 “I think it’s hard to have a process to require
people update a document every time they check in source code; they would become
rebeUious.”Subjett 1 0
Question 8: Evaluate the effectiveness of communication channels
Table 10 summarized the advantages and disadvantages of each
communication channel. “The channels are ways to communicate. It’s just some are
more effective for different phases in the development than others are.”S ubjcct 9 “I use
all o f those, but just for different things, different situations, and different
„Subject S
purposes.
49
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 10
Summary of Question 8: Evaluate
the effectiveness of communication
channels
E-mail Subjects Description
Advantages 5 Allow putting in detail information
3, 16 Allow more time to think on the subject
9 Extra distance to feel more comfortable
1,2, 5,15 Good for notification and information
sharing
Disadvantages 3 Time lag; lack of big picture
9 Not an interactive medium
6 Lack of action enforcement
2 Extra cost to make sure information is
received
Group
Discussion
Subjects Description
Advantages 1,5,15 Sharing common understanding
11,9 Achieving consensus
2 ,3 ,5 Agenda and meeting summary are effective
Disadvantages 15 Time consuming
50
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 10 (continued)
Summary of Question 8: Evaluate
the effectiveness of communication
channels
Phone Subjects Description
Advantages 6,7 Specific, quick response
9 Lobby individually
Disadvantages 10 No records kept
5 Cannot have detail information
3 Hard to reach consensus when more than one
person involved
Face to face Subjects Description
Advantages 5 Most effective way to get information
9,16 Gain deep understanding of a person’s needs
Disadvantages 10 No records kept
5 Cannot have detail information
3 Hard to reach consensus when more than one
person involved
Printed
Memo
Subjects Description
Advantages 1 ,2 ,5 ,6 Good for meeting agenda, summary,
specifications
8 Most official
Disadvantages 7,8,11 Static, not allow to change quickly, less
efficient than electronic form
51
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The following discussion explained the strengths and disadvantages of each
communication channel and which ones were best for each purpose. E-mail was the
most popular method to communicate. It was good for notification to a large group. It
served as a reminder or a to do list. “It allows putting in detail information. Because it
is asynchronous, it gives extra distance for people to feel more comfortable
discussing issues.”Subject 9 “It was also good at the early design stage to get ideas and
think through the problems.”S ubject 1 3
However, e-mail had its disadvantages, such as “using e-mail needs an
additional cost to make sure everybody is acknow!edged.”S ubject 2 “E-mail is only
good for notifying. Honestly speaking, e - m ail can be abused. The etiquette of using e-
mail is not well understood.”S u b ject 6 ‘ I t is hard to organize all the e-mail. It is not a
truly interactive medium.”Subject5 One o f the limitations of e-mail was its time lag.
E-mail goes back and forth, there’s a time lag associated with it. By
the time you get to read the answer, there are several different things
that have gone on. Because of the time lag, it’s hard to establish what’s
been said before when someone’s responding to you. Things tend to be
not read in the same order. And there’s typically a lot o f cases where
people basically take the same portion, repeat it, and then they take the
part of it that they want to talk about, and they tack that piece on. And
then someone else tacks on responding back to that, and it gets very
hard to put the whole thing back together to get the big picture on
.g Subject 3
Group Discussion. Group Discussion was good for sharing a common
understanding, brainstorming and getting input from the general staff. The results
52
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
showed that group discussion was the best way to get agreement among developers
and to come to a consensus. To make the meeting more effective, agenda should be
set at the beginning o f meetings and followed by documenting the outcome o f the
meetings. The disadvantage was that group discussion could be very time consuming.
Phone. Phone was good for specific issues, for quick and urgent talks.
Furthermore, “You can lobby independently if you want to get to each individual
person. But it is hard to keep records or to put in detail information. It is just a verbal
communication with no document to follow up with.” S u b ject 9 “it is not as valuable
for things that need a broad consensus or for problems that are fairly complex, which
oftentimes require that more than one person be involved.”S u b jc c t 3
Face-to-face. Face-to-face communication was the most effective and
decisive way to get information. “It helps to make sure people are still on the same
wavelength, both parties understand and draw things ou t”S u b jc c t 5 “It allows you to
gain deep understanding o f a person’s needs and feelings.”S u b jc ct 9
Printed Memo. Printed Memo was a good choice for a meeting agenda,
meeting summary, announcement, and design specification. It tended to be static, and
does not allow things to change quickly. It was less effective than an electronic
document but it is the most official.
53
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Question 9: Describe an ideal information infrastructure
The responses fell into three categories: small teams with a sufficient
communication network, a web-based information repository to ensure information
exchanging, and a supportive corporate culture that promoted com m unication,
coordination, and collaboration. Table 11 provided a summary of the responses.
Small Team. Small team was the answer from most of the respondents. The
team must fit together easily and had the ability to have constant communication so
that information exchange was not difficult. For instance, “A very small development
team whose team members are able to talk to each other; They should be in the same
place; to have a ownership o f a section of the project is very important. Whoever
owns that thing knows it inside out and they’ll be able to make changes much more
quickly without breaking things.” S u b je c t 1
“I think all parties involved need to have a common understanding o f their
goal. For example, if one wants to conserve resources and the others are trying to
come up with extravagant features to please the customers, no matter what the
information infrastructure is the software development will be hard to converge and
be productive.”S u b ^ cct 1 5
“ A n ideal information infrastructure requires a complete design and
development process from analysis of the problem, to architecture, to design, to
review, to update design, to implementation and to review repeatedly. Every member
54
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
in the team should get involved.”S u b ject 1 3 The requirements flow top-down and the
information for the schedule and resources desired comes bottom-up, while the
schedule should include the time for training, testing, and management.”S u b ject 8
The Web and Knowledge Repository. The results showed that the World Wide
Web is increasingly becoming a dominant medium for information access, sharing
and distribution.
“The Web that makes things immune to movement and being able to link-in
all features in all documents; also introduces a time dimension, enables you to see
revisions to a particular page.”S u b jcct 5 “An intelligent system that keeps track o f the
decision making process and automatically informs the right people.”S ubjcct 6 “Share
software requirements through a database or Web.”S u b je c t 1 2 “A live problem tracking
system that prompts you to keep your information more updated; and that has ability
to query for more details on as needed basis.”S u b ject 1 0
A centralized knowledge repository that contains design specs and
discussion threads (e-mail) associated with the spec. There should be a
bi-directional hyperlink between the specs and the discussion threads.
Both the design spec and discussions are full-text search able and
shared among the team members. They should have access control
(permission and access privilege). Team members can create their own
private logs.S u b ject 1 5
Supportive Culture. “Culture has to be there; understanding and support has to
bethere.”S u b j“ , 2 It is better to have a full-time person be in charge. “Full time person
55
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
to update, analyze and store information in a shared and easy-to-access database. This
person also notifies everyone as the information gets updated.”Subjcct 1 3 “A corporate
culture that promotes continual learning to increase the knowledge and skill o f the
team.”Subjcct9
Table 11
Summary of Question 9: Describe an
ideal information infrastructure
Subjects Descriptions
1,3,4 Small team that ensures information sharing and each
section o f the project has assigned responsible owner.
2,15 Culture establishment for documenting and information
sharing.
7,8 A complete software design and development process.
3, 5, 6, 15,
9, 10, 11,
12,13
A Web-based or knowledge-based com m unication
system that helps information tracing, and sharing.
56
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Analysis by Themes
This section analyzed the answers based on themes, which were derived from
the literature review chapter. The themes were:
1) A shared goal and requirements.
2) A Networked communication System
3) An information repository.
4) Policies and protocols.
5) Feedback and control.
6) Performance measurement.
The responses were analyzed and the essence of each theme was summarized
in Table 12.
Shared Goal and Requirements
Define the Problem and Problem Solving Strategies. The results showed that
setting a goal was the most important thing in software product development and it
must be derived from the understanding of customer's needs and problems. “Define
the project goals. If you don’t know what the goals are, you’ll never reach
them."Subjcct5
Based on the goal, the software teams develop strategies to solve the problem,
which includes plans, schedules, requirements and functional specifications. “The
57
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
first two steps are what’s the problem we’re trying to solve and what’s the strategy
we’re going to use to solve it.”S u b je ct 5 “What’s it supposed to do; the wish list or not
even a functional specification yet, but requirements. The requirements for what you
are going to write this software.”S u b je ct 1
“I saw projects that first failed to find out what they were solving. They
usually started with a vague definition of a product. And they spend a lot of time and
money, and at the end you’re making something that is not exactly what your
customer wants.”S ubject 7 “First of all is to know as much as possible about the
problem that we are trying to solve. And the second thing is the feasibility. Do we
have enough power to solve it the way that we think?”S u b jcct 7
The results also indicated that the requirements had to be commonly
understood and accepted among team members.
It’s somewhat easy for somebody to write down some goals, but unless
the marketing people have seen the goals in a way that makes sense to
them so they’re not going to change it part way through. And the
engineers understand it so that they can understand the risks if the
project has to change course midway.Subjcct5
The result also suggested that it was important for software companies to
recognize the function of a software designer. The designer blueprints a product
based on what customers want. “To really know what your users’ current problems
are and how to solve their problems is the key. People maybe spend a lot o f hours
debating over something that users don’t really care about.”S u b ^ cct 2
58
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Table 12
Summary o f Six Essential
Information Processes
1 Themes Essence Literature
Shared Goal • Define problem and
requirements
• Define solving strategy
O’Connell, 1996;
Schwarz, 1994;
Sundstrom, 1990
Networked
Communication
• Communicate under the
context
• Use Web and multiple
communication channels as
necessary
• Fellowship team
Paepcke, 1996;
Karut & Streeter,
1995;
Rada, 1991
Information
Repository
• Contents:
Capture rationale,
assumptions, issues,
and design documents
• Functions:
(a) Traceable,
(b) Accessible,
(c) Searchable,
(d) Temporal and spatial
views o f information
Conklin, 1993;
Smith, 1994;
Schatz, 1993;
Pressman, 1993;
Maguire &
Kazlauskas, 1993
Policies and
Protocols
• Corporate Culture
• Guidelines and templates
ISO-9000; CMM
Control and
Feedback
• Tracking changes
• Managing changes
internally and externally
• Ownership
Fisher, 1992;
Brown, 1995;
Eisenhardt, 1995;
Bflrner & Arnold,
1996; Remesh, 1993
Performance
Measurement
• Scheduling
• Monitoring progress
• Testing on quality
Humphrey, 1990;
Pressman, 1993;
Simon, 1981
59
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Networked Communication System
Context. Software teams require intensive communication. The results found
that people needed to know the context in order to make the conveyed information
understandable. “Know the context that you are operating in, so that you can actually
think about the whole picture.”S ubjcct 5
The research also indicated that during different phases o f software
development, the communication pattern was various. For example, the design phase
required more communication than the development phase in order to reach the
consensus o f the requirements and functional specifications.
You might want to have different levels o f com m unication and
interruption at different times. There is a distinction between the kind
o f communication that needs to take place when you’re coming up
with this initial design, and the communication that needs to take place
once you’ve really got the design down and you’re implementing it. At
that point in time, a lot o f communication for the people who are
writing code can, in fact, be counterproductive. While at the design
phase, team members need to have constant c o mmunication with the
other people.5* 1 ^**4
World Wide Web. A networked communication system, which allows
members to easily and effectively share and distribute information, becomes essential.
The study found that the Web was increasingly becoming an important medium for
team members to communicate both internally and externally. “The Web will be the
medium in the future for information sharing.”Subject 1 3 “Information architecture
based on the Web is beginning to appear within organizations. We tried to set up a
60
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
web page so that everybody could add their little notes and stuff.”Subject 1 0 “It would
have been really helpful is if each component team had a web site where they could
track their schedule, their issues and all the necessary information.”Subjcct9 “Web sites
with the project status information; having one person identifies what is the minimum
subset o f information that’s important to track. And then everybody tracks at least
that much information in the same format.”S u b jcct 1 0 “We have an internal web site for
things everywhere from a hierarchy organizational chart to design guides. And it’s
much easier to find, and everybody has access to it. The links are there. It’s much
more flexible and faster; you don’t have to have any trick knowledge.”Subject 1
However, the study also revealed the problem of information overload on the
Web. The Web usually did not have the search capability and the information
structure. It made information available but did not help judging the information.
An Information Repository
The results showed that development team members needed a knowledge
database that not only connected the design specifications, source code, test cases,
and bug logs; but also linked to the decision making process, the design rationale, the
design assumptions, and issues.
61
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The other piece that we’ve not done a good job of capturing is the
scope that you’ve originally designed, such as how big o f a design or
property or database do you expect to be working on. How many
users, what type of algorithms are going to be running on top o f it, etc.,
there’s typically assumptions that you’ re making there and those
change over time because you never actually go back and review
those.Subjcct3
One important point mentioned in the study was that an information
repository had to be independent to the reorganization of a company. The information
structure had to be solid enough and permanent enough to not be impacted. For
example, one interviewee responded “No matter what happens in the company, our
Problem Tracking System (PTS) will be there. No matter who owns the management
o f PTS. Everybody knows about PTS. The information is always there.”S u b jcct 9
The results indicated that a repository information needed to be organized and
structured in the ways that information can be easily accessed, searched, and updated.
Functionally, an information repository needed to provide the capabilities o f tracing
information, searching information, and presenting information in different views.
Trace-ability. Information should be managed in such a way that it can be
easily retrieved. A repository must provide two views, the temporal historical view
and the spatial view. A historical view stated what the purpose of each change was; a
spatial view presented what all the relationships were between the documents.
62
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Sometimes you can just track what’s changed in context without
reading the whole thing again. But there are other times when you do
have to see the whole document because you are trying to get a
complete picture. You’re trying to build some tests on it or you’re
trying to implement the code. You don’t care when it changed but just
want to know what it is today.S u b jcct 5
Once a project starts out, you need a way to keep track o f what the
problems are, what commitments have been made to fix those
problems, and what the solutions are, so that customer support can
work with the customer or the customer can go to an on-line database
, c , Subject 3
and find an answer.
Search-ability. Searching with a full general query capability was valuable.
“You need to narrow the information down to any occurrence o f this problem or what
was written in this spec or when was this changed. For example, search for changes
that were made in this particular range o f times, or releases, or during this phase of
the project”S u b ^ ect 3
A database gives you the ability to query for details in a certain area,
and goes back to the developers and prompts them to update that
section. But it is more on an as-needed basis. Not just having to do it
all initially, because I think it’s too hard for people to do initially, to
anticipate what type o f information people are going to want to know.
Then it would be nice if maybe these things got stored later on. It
would end up being like a growing e-mail file where it’s connected.
Like this query led to this answer and this answer and this
conversation through e-mail ended up like that.S u b ject 1 0
Multiple purposes. The study found that a database system that tied together
the specifications, the source code, the tests, the scheduling and the bugs tracking
would be valuable. Developers needed a system, which provided multiple views of
63
' i
,!
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
information for teams to retrieve. For example, the marketing people could keep track
of the features that customers wanted in the product; the support engineers could
identify when the features or the bugs would be fixed; and the product release team
could estimate how close this release would be done.
You want one system that you can use for internal problems and also
for tracking features that you might want to implement. It almost
becomes a project management tool at times. Because one of the ways
that people try to manage the project is by looking at where you are in
terms o f the number of bugs of a product. People tend to, depending
on the culture, discourage the use o f that system because it’s a
management tool and it’s easier to get a release out of if bugs go
down. You really need to decide whether you want to use it as a
release management tool or as an issue tracking system.S u b ^ cct 3
Policies and Protocols
Corporate Culture Establishment. An ideal infrastructure has to be an
environment that understands software development and allows the right processes to
be developed. Corporate culture was emphasized during the interviews. “You want to
have the management team create the right environment and set the right goals so that
people, whether they have the tools or not, will be doing things in the right direction
and communicating the right things and be recording the right information.”Subject 5
The results showed that software companies needed to establish a corporate
culture to promote the discipline o f capturing and updating the knowledge during the
process o f software development process. This knowledge is not only the source
code, the test cases against specifications, and the bug reports, but also the design
64
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
rationale, the design assumptions, and the decision making process and the issues
associated with the product development “If the corporate culture is there, you’re
expected to do it.”S u b je c t 1 “I think you have to establish the discipline and the culture,
and have both development engineering teams and marketing teams respect that
Otherwise it would fall apart ”S u b ject 2
Guidelines. Guidelines stipulate a sequence of broadly stated steps for
producing a software product It ensured consistent information exchange among
team members.
Guide individuals to the location o f needed information. Provide
pointers to those who possess information so that they can elaborate on
i t and provide context and meaning. You could have general
guidelines on where to search for, or, if necessary, where to look.
Where are the programming standards? Where are the reference
materials? Where are the samples? Who are the people who are willing
to be considered as contacts for the graphics engine or the command
interpreter or whatever? You could have a set o f support people to
answer general questions.S ubjcct 1
The results also showed that most software companies had some policies for
“checking in” source code into a database to ensure the integrity of the source code.
For example, Some software companies required developers to get all the source code
compiled, built, and then run the basic test suite. Once the code passed the test suite,
developers could store it into the source code database.
Software companies had different degree o f code management requirements.
For example, the result showed that a company used forms for submission,
65
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
developers were supposed to fill out the forms before checking code in. The idea of
using forms was code management team to go through these submissions and pulled
out the pertinent parts of what got changed and then updated a change list that people
could look at.
The consequences o f not having guidelines could be serious. “Developing
software is very individual personal knowledge intensive. It can be a danger: what if
this person walked out of the company? This person’s knowledge could never be
recaptured.”S u b jc c t 9 “... what ends up happening is that all the information is
maintained in their head, and then you're very vulnerable to employee turnover. At
least in the long-term aspect o f it.”S u b jcct 3 The results suggested that software
companies needed to document all the steps of why a decision or assumption made.
Because assumptions may change during time, and after a while the original purpose
might be lost.
You can write all the specs you want. But if people don’t know where
to find it or they let it get out o f date, they were useless after a little bit
of time. And then what happened is that we were running the project
with no information at all. It was all in peoples’ heads. And at that
point, scheduling started slipping about two days for every one day,
because you add stuff and then you find out you’re adding it wrong,
and then you find out you didn’t add the way this other guy wanted
you to add it_ S u b ject 5
The approaches software companies took to manage the continuous changes is
to have specifications embedded with the code. Programmers were more diligent
about keeping the changes up to date in this way. But it still limits the amount of
66
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
documentation and the form of it, because it tends to focus just on what individual
routine or module is but less an overview.
Using Templates. Templates were designed to capture the essential
information during product development.
“What you really want to do is distill that down to a bare minimum of
just what is needed to move forward. So you could have templates, but
you almost want to give people instructions about, ‘Your job is to
figure out how many o f these you can eliminate and still get the point
across.’ If you keep it small, people are more likely to update it. If
you’ve got the same stuff spread out 15 places, then people are going
to say it’s just too much o f a pain. I don’t know all the places to
update. People just give up. I try to encourage everybody to go for
conciseness. Then it’s easier to encourage people to update.”S u b ^ ect 5
Compatibility Management. A software product has new releases every six to
twelve months. Developers face the problem o f making sure new product supports the
older version of the product The results indicated that compatibility management
could be critical.
The problem in compatibility is that you need to be able to look at two
different versions o f the spec and try to figure out how to support the
things. What we do not capture well is compatibility. We need
document how to take new features and implement them in the way so
that they don’t have negative side effects on older versions.
Compatibility interfaces are an example where you may provide them
but not have carefully documented that there are performance
implications with those. ubjcct3
67
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Feedback and Control System
Tracking changes. Three pieces to a project that needed to be kept in sync: the
specifications, the code, and the tests and the test environment. The results showed
that typically people focus on the first two, keeping the specifications and the code in
sync. But they lack in keeping the test cases in sync with the specifications. The
research suggested that a software environment basically needed to establish a
tracking mechanism, which tracked which tests had become outdated. It was more
than just notification; notification could completely overwhelm the people. For
instance, establishing correspondence system between the tests and the specifications
could make sure that the right tests got enhanced if a developer made a change to
something.
The results also suggested that assigning a responsible person or a group to
handle the process of change was very important This group was to filter the
information, to analyze the information, to coordinate the information integrity, and
to reconcile the out-of-sync information. “We used to have a problem that people did
not know that the information has been updated. For this version, our program
manager starts to send out e-mail whenever they updated the information.”S ubject 1 3
Some companies were using software control tools to automatically track the
modifications through the entire dependency hierarchy. “We plan to use a software
tool to help control the flow of information. One can set the dependency between the
68
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
documents. Once you change a section o f the marketing requirement, it will inform
you about the changes needed in the corresponding functional specification.”5 1 1 1 * ’ 6 0 1 8
“The biggest barrier is that specs are never kept up to date with the
design. It’s tedious and often times people don’t view it as productive
to update specs from their perspective. From an overall perspective it’s
very limiting in the project because you can’t bring new people in on
the project when you go to do follow-up work. The specs have limited
value and that may actually be misleading to people. u b ^ c c t 3
Managing External Changes. The results indicated that managing the external
changes became important. Because most leading-edge software products often used
third party vendors’ tools, their new releases also impacted the product schedules.
The managers need to really understand the technical environment to make the risk
analysis o f whether or not they should adopt the new releases. For instance:
Microsoft keeps coming out with new versions of software
development tools, such as Visual C++. They’re not backward
compatible, and they don’t continue to sell older versions once they
have a new version out. So, if you have a long project as we did with
product release 3.0, you have to keep upgrading to a new version of
C++ and recompile all your stuff and make a bunch of changes, and it
takes some period of time. And as a project manager, you have to be
aware o f that risk and consider those schedules. You need to know
what the problems are if you don’t upgrade, and how it will impact
your customer. And also, if you do upgrade, what’s the cost to the
schedule?5u b j6 0 t 9
The study found that developers felt the most challenging thing was to
upgrade existing products to newer versions. “We have to update the current
operating system, current compiler, and other layers o f our products such as our
69
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
server and connectivity layers. Keeping track o f all the changes and making sure that
they are still compatible and behaving the same way is the most difficult.”S ubject 1 0
The study also pointed out the complex development environment was
another barrier to make control difficult. “We have trouble in setting up our
development environment because it’s so complex. We have used so many third
parties’ products. And we also work on many different platforms, at least Unix and
Windows. It is very tricky to know all the details.”S u b jcct 1 0
Performance Measurement
Constant Monitoring. The research showed that software product
development required constantly monitoring during the entire software development
process. The research suggested assigning a dedicated person to oversee the entire
process and its progress. This person played a role like a film director who had
comprehensive knowledge of the product and control of all the interdependencies.
At least one person or one group should constantly monitor the project
progress. Because it is like a big ocean, you only see a certain part of
it. If somebody looks at the entire project from the top, he can watch to
see if the entire teams are on the wrong path, or if we should focus
more on a certain area and pay less attention to other parts.S u b ject 7
The problem often happened in software companies was a piece o f software
component lost it ownership. For instance, one team got involved in the early stage of
the product development. But when they were done, they considered that task was
done. They passed it to another group and let that group maintained it. The original
70
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
designers were working on some other project; they were no longer involved- But the
second group was not aware of how things got started. To avoid the problem o f no
one being in charge of the code, at least one person should be in charge from the
beginning to the end. This person, played a role as a film director, owned this
product.
The advantage of having a person in charge was that he could lead the entire
teams and coordinate their priorities and dependencies. This person helped
prioritizing the tasks and making sure that the whole organization understood what
tasks were important. A manager reflected the problem of having different agenda
among different teams: “I was trying to get information I needed from other groups.
And that wasn’t important for them in doing their job, so they weren’t going to put
much priority on it.”S u b je c t 9 Having a person in charge of the entire development
process resolved this problem.
Scheduling. Scheduling was another critical procedure in measuring
performance. There were three aspects o f the schedule that needed to be tracked. 1)
What were the original plan and the estimated completion date? 2) What changes had
been made to the original plan? 3) How well were people performing relative to that
changed plan?
A manager responded to the issue of scheduling. He stated that often in
software development, new things got added when people understood more about the
71
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
problems. Therefore the project planing process had to be flexible enough to
recognize the evolutionary changes.
One thing I would like to know is how did people perform in the past
relative to the original plan they started the project with? How many
more plan paths did they add towards the end? If you have a sampling
o f these, you can say, on the average with the way we do a design, we
anticipate 50 percent o f the tasks up front. Then you could actually set
your end date by allowing 50 percent expansion. Another approach is
you have to periodically change the duration of the project. Some
people believe that you should always plan only for what you know
about, so that there is pressure on people to do well. Because if they
know there’s any extra time in the schedule, the work will expand to
fill it. And then you will still need to add extra time for the tasks that
you didn’t plan for.S ubjcct 5
Various Product Life Cycles. The research found that various product life
cycles required different focuses on measurements. A product at its early innovative
stage had different criteria for performance measurement than what it would have had
at its mature, maintenance stage. An innovative product was technology driven, while
a mature product was more market-driven. “In the high tech industry, to a large
extent, marketing could play more o f a supporting role in more innovative
products.”S u b ^ cct 6 The results provided two examples of measurement from two
different products: ProductX was the third version of a product. Quality and stability
and backward compatibility were very important, people had to spend a lot o f time at
the back-end doing compatibility testing and migration testing. Much effort was to
make sure that each new feature didn’t break any function that used to be there. The
interviewee continued:
72
I
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Whereas the web-based stuff we’re doing now is completely new. You
can’t wait to fully qualify the product. You have to stick it on the net
and let somebody download it and play with it. So the whole way o f
doing risk assessment is totally different, because you have to weigh
the time to market much more heavily. What’s your window? When
do you have to get this product out? What’s the absolute least number
o f features you can get away with and still call it version 1.0? Even the
development process itself becomes very different because you may
not have enough time up front to analyze your market requirements to
understand the paying points o f your customers.S u b ^ ect 9
Summary
This chapter presented the research findings. There were two sections in this
chapter. The first section grouped together answers from different interviewees for
each question. This second section analyzed the answers based on the six themes
derived from the literature review. Table 2 to Table 11 gave summation to each
question and Table 12 gave an overall -s um m ary of each theme and its related
literatures.
The six information processes for making a software development
environment productive were summarized below. Setting goals and defining
requirements were the most critical pieces o f information during the software product
development. Networked communication was like a nervous system that helped
information flow freely. Information repositories served as an organizational
memory, which captured and stored the collective knowledge and intelligence o f team
members. Policies and protocols ensured that the information was stored in a manner
that was traceable, accessible, and understandable. Feedback ensured that the changes
73
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
got tracked and managed. Performance measurement guaranteed the quality and
productivity were carried out during the process o f software development.
74
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Ch apter 5
DISCUSSION, SUMMARY AND IMPLICATIONS
Introduction
In this chapter the research results, insights, and their implications are
discussed. Recommendations for further research are also made.
This research raised the question of how to improve software development
productivity in the networked and fast-paced information age. It proposed a solution
o f incorporating six essential processes in a software development environment. This
research used a qualitative method by conducting in-depth interviews with a total of
sixteen software developers, managers, and system architects from nine software
companies. The interviewees were asked a set of questions referring to their
information needs; the way information is retrieved, structured, stored, and updated;
the information-related barriers during the course of software development; and an
open-ended question asking them to describe an ideal information infrastructure.
Discussion
Strengths and Weaknesses
Most o f the software developers interviewed in this study have been involved
in commercial software product development for more than fifteen years. They were
75
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
representative of this field when discussing the needs and issues of software
development. The researcher, who was also the interviewer, has been in the software
field for more than thirteen years. The total assembled experience establishes the
creditability and the quality of the inquiry.
The interviews were tape-recorded and transcribed by a professional court
reporter. The research used multiple methods to examine the data, analyzing by
questions and by themes. The summary tables for the questions provide the factual
data analysis. These tables offered cross-references for the data analyzed by themes.
However, the research did not test the validity o f the six processes by asking the
original interviewees to evaluate them in the results.
Although the research reviewed literature from different theoretical
frameworks, it placed the most emphasis on information processing. The areas of
team interactions, corporate culture, and motivation were not included in this study.
This research concluded that six processes contribute to the productivity of software
development, but the research could not give quantitative predictions on that
productivity.
Trends, Agreements, and Issues
The results confirmed the trends in the software development environment.
These trends included the following:
1) Component-based paradigm of computing (Pressman, 1993;
Rumbaugh, 1991; Graham, 1991; Jacobson, 1992).
76
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
2) Active role customers play (Wheelwright, 1993; Pressman, 1993).
3) Emerging computer tools for managing projects, for setting up integrated
knowledge repositories, and for assisting communication and decision
making (Donaldson & Siegel, 1997; Sachs, 1995; Pressman, 1993;
Winograd, 1995; Yakemovic, 1993; Huber, 1991; Ancona & Caldwell,
1990).
4) Cross-functional teams, collaborative corporate culture and clear
leadership (Sundstrom, 1990; Schein, 1990).
The software development model is changing. Object-oriented technology and
its reuse of program components have dominated the software industry since the early
1990s. It has moved software development from the traditional sequential
programming model to an iterative and fast time-to-market model based upon
component reuse. Also, third party tools and more customers’ input is now involved
in this evolutionary development process.
Customers play a more important role in the process o f software development.
Software development teams need to anticipate actively in customers’ needs. These
needs should be part of the early design phase, during identification of the problem
and software product requirements. In the later product pre-release stage, customers
often participate in evaluating the product and providing feedback.
77
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
The software development environment requires tools to control source
versions, to automate quality assurance tests, to track changes, and to manage project
progress. The greatest power of the tools is expected to lie in supporting collaboration
as team members come to a shared view of what is necessary to accomplish the tasks.
The research strongly indicated that the development environment needs an
integrated database system to use as a knowledge repository, and a networked system
to ensure communication and information sharing.
The research showed that software product development required a dedicated
person to constantly monitor the entire process and its progress. This person played a
role like a film director who leads the entire team, and had comprehensive knowledge
of the product and control o f its interdependencies. In addition, managers under this
person must be technically strong to manage changes and to analyze any risks
incurred by the changes.
New Findings
Besides the proposed information processes, this research found that the
concept o f teams, the corporate culture, and the Web were emphasized during the
interviews. The next section briefly comments on these three topics.
Team Considerations. The research reflected that software development is not
only technical but also social. The responses to describing an ideal information
infrastructure pointed out the importance o f teamwork. They indicated that
developers cared about who they worked with and how they communicated among
78
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
one another. The results showed that team members not only had to be proficient in
their domains, but also had to work well with each other. Team spirit was encouraged
and team members were considered to be equal. Each team member had ownership
o f their work, with a sense of accountability and accomplishment for it. Small teams
foster all these qualities. The results found that team sizes of five were desirable.
Culture Establishment. Software companies need to establish a corporate
culture that promotes communication and collaboration, especially in capturing and
updating knowledge during the process o f software development. This knowledge is
not just the source code, the test cases, specifications, and the bug reports, but also the
design rationale, the design assumptions, the decision making process, and the issues
associated with product development. Integrated problem solving across functional
teams is more easily accomplished with the proper corporate culture.
The Web as a collaborative tool. The results showed that the World Wide
Web is increasingly becoming a dominant medium for information access, sharing
and distribution. However, the study also indicated problems with the Web. There
was too much information with too little structure. It was hard to navigate through
and search for the information. There was no indication o f the information changes,
and there was a lack of an overall picture to indicate to users where they were.
79
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Summary
This study concluded that six essential information processes contribute to the
productivity of software development. The interview data agreed with the research
literature reviewed. Furthermore, this research offered an integrated view on how to
make an environment productive. The results are summarized below:
Goal. The developers needed a goal and well-defined requirements. The
results showed that the most critical information to have was the goal and problems to
solve. The research suggested that the goal must be clear, commonly accepted, and
derived from an understanding o f customers’ needs. Ultimately the goal was to solve
the customers’ problems.
Networked Communication. Software teams required intensive
communication. The study found that developers needed to know the context of the
information. In addition, the communication pattern varied during different phases of
software development. For example, the design phase required more co m m unication
than the development phase in order to reach consensus on the requirements and
functional specifications, while the implementation phase needed fewer meetings than
the design phase. The evaluation o f different channels provided good suggestions for
how to combine those channels to achieve the best outcome. Most o f the development
teams used various communication channels — e-mail, phones, group discussion,
and/or memos. For maximum effectiveness, teams used different media in different
situations and for different purposes, such as using e-mail for notification, group
80
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
discussion to achieve consensus and face-to-face meetings to gain deeper
understanding of each other’s needs. Each communication channel had its own
strengths and weaknesses.
An Information Repository. The results showed that development team
members needed a knowledge database that not only connected the design
specifications, source code, test cases, and bug logs; but also had links to the decision
making process, including the design rationale, the design assumptions, and design
issues. The results suggested that the information or knowledge should be organized
and structured so that the information in the database could be easily accessed,
searched, and updated. This information repository should provide a temporal
historical view and a spatial view for team members to retrieve the information. For
different users, the repository should provide different information views for their
particular needs.
Policies and Protocols. Guidelines and policies were required to control what
and how information needed to be documented and shared. The study found that one
company out of the nine used ISO-9000 standards as guidelines to control the
documents. The remaining eight companies developed their own policies for coding,
documenting, and testing.
Templates needed to be designed to capture the essential information during
product development. They need to be clean and concise so as to encourage their use.
There should be a full time person or group that can analyze the information, check
81
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
the information’s integrity, and reconcile out-of-sync information. If the information
could not be kept up to date, it became useless.
Feedback and Control. A control process that is able to manage the internal
and external changes, and track the dependencies affected by the changes, is
necessary. The results indicated that managing the external changes was important.
Because most leading-edge software products relied on new technologies, their
suppliers’ new releases also impacted the product schedules. Adjustment and
adaptation to the changes became inevitable. Managers needed to analyze the risk
with regards to change impact on the project schedule.
Performance Measurement. The research found that various product life
cycles required different focuses on measurements. A product at its early, innovative
stage had different criteria for performance measurement than what it would have had
at its mature, maintenance stage. An innovative product was technology driven, while
a mature product was more market-driven. For example, the requirements o f an
innovative product were not clearly defined in the beginning, its developing process
was more iterative and incremental, and therefore the criteria of performance were
different from a product in its maintenance stage.
Implications
This study found the essential processes that make an environment productive
for software development. The findings can be applied to similar knowledge work
82
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
settings. A work setting starts with a clear and understandable goal and with
acceptable strategies to achieve that goal, including clearly defined requirements,
procedures, and milestones. The development teams should be small, with members
having different areas of expertise to perform the different functions that are required
to reach the goal. Networked communication channels provide many-to-many, one-
to-many, and one-to-one channels for people to communicate synchronously and
asynchronously with each other and the outside world. The protocols, templates and
guidelines that are necessary to ensure comprehensible and consistent information
sharing must be available. Monitoring systems are needed to provide feedback for
correcting mistakes and adjusting to changes in specifications. The backbone o f the
working environment is a knowledge repository that captures the all the decision
processes, documents, and final intellectual products.
Recommendations
The following topics are recommended for further research:
1) More attention should be paid to capturing information in the software
development environment. Companies need to allocate sufficient
resources to manage all forms of intellectual capital. The knowledge in
“people’s heads” is a major asset o f software companies. Many times,
there is not an adequate process for capturing the design rationale and the
corresponding assumptions. It is hard to reconstruct the rationale and
assumptions if the original designer becomes unavailable. The
83
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
consequences of this can be serious, affecting the quality of the products
and the time to release to market. Research is needed on procedures to
capture all the pertinent information regarding the decision making
process.
2) The CMM and ISO 9000 standards placed stronger emphasis on the
activities and tasks of the process o f software development, and less
emphasis on the information aspects. This study found that team members
spend large portions of their time creating, capturing, locating, accessing,
and sharing information. How the information is captured, organized and
shared among team members is worth more attention and requires more
guidelines. Although software design is an individual intellectual
endeavor, it is also collective and collaborative work. Guidelines and
templates need to be set in order to gather the important information. For
example, guidelines could be designed to direct developers on what to
capture, where to store, how to access, when to update, why a certain
design algorithm is chosen, and who is the owner.
3) This study only focused on the information process aspect of software
product development. The team interactions, motivation factors, and the
corporate culture that promotes collaboration are a potential area for
further research. By comparing the successful teams to the unsuccessful
84
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
ones, a study can find out the important ingredients o f how to compose a
successful team.
4) The study provided some suggestions for the design of computer tools to
integrate and automate the process o f information capturing, organization,
and distribution in the software development environment. The tools
include: a) automatically capturing the decision processes, tracking
changes and their interdependencies; b) searching, tracing, and connecting
Web-based information; c) presenting information in relationship to “the
larger perspective” with its revision history.
85
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
REFERENCES
Baker, R. L., & Elam, R. J. (1978). Managing the development of
comprehensive instructional systems. NSPI Journal, 6-11.
Bohner, S. A., & Arnold, R.S. (1996). Software change impact analysis. Los
Alamitos, CA: IEEE Computer Society Press.
Brooks, Jr. F.P. (1995). The mythical man-month. Berkeley: Addison-Wesley.
Brown, J. S., & Duguid, P. (1991). Organizational learning and communities-
of-practice: Toward a unified view o f working, learning, and innovation.
Organization Science, 2(1), 40-57.
Brown, J. and Duguid, P. (1994). Borderline issues: Social and material
aspects o f design. Human-Computer Interaction, 9(1), 3-36.
Brown, S. L., & Eisenhardt, K. M. (1995). Product development: Past
research, present findings, and future directions. Academy o f Management Review,
20(2), 343-378.
Budd, R. W., Thorp, R. K., Donohoe, L. (1967). Content analysis o f
communications. New York: The Macmillan Company.
Software Engineering Institute (SEI) at Carnegie Mellon University. (1995).
The capability maturity model: Guidelines for improving the software process.
Reading, MA: Addison-Wesley.
Conklin, J. (1993). Capturing organizational memory. In R. Baecker (Ed.),
Groupware and computer-supported cooperative work, (pp. 561-565). San Mateo,
CA: Morgan Kaufmann.
Donaldson, S.E. & Siegel, S.G. (1997). Cultivating successful software
development. New Jersey: Prentice Hall PTR.
Eisenhardt, K. M., & Tabrizi, B. (1995). Accelerating adaptive processes:
Product innovation in the global computer industry. Administrative Science
Quarterly, 40, 84-110.
86
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Fischer. G., Girgensohn, A., Nakakoji, K., & Redmiles, D. (1992). Supporting
software designers with integrated domain-oriented design environments. IEEE
Transactions on Software Engineering, 18(6), 511-522.
Fischer, G. & Reeves, B.N. (1992). Beyond intelligent interfaces: Exploring,
analyzing and creating success models o f cooperative problem solving. Journal of
Applied Intelligence, 1, 311-332.
Gilb, T. (1988). Software engineering management. New York: Addison-
Wesley.
Graham, I. (1991). Object-oriented methods. Reading, MA: Addison-Wesley.
Greif, I. & Sarin, S. (1987). Data sharing in group work. ACM Transaction on
Office Information Systems, 5(2): 187-211.
Huber, G. P. (1990). A Theory o f the effects of advanced information
technologies on organizational design, intelligence, and decision making. Academy of
Management Review, 15(1), 47-51.
Huber, G. P. (1991). Organizational learning: The contributing processes and
the Literature. Organization Science, 2(1), 88-115.
Humphrey, W. S. (1987). Characterizing the software process: A maturity
framework, technical report, software engineering instated (Tech. Rep. No. CMU/SEI
87-TR-l 1). Pittsburgh, PA: Carnegie Mellon University, Software Engineering
Institute.
Humphrey, W. S. (1990). Managing the software process. Reading, MA:
Addison-Wesley.
Ancona, D.G. & Caldwell, D.F. (1990). Informatin technology and work
groups: the case of new product teams. In J. Galegher, R. E. Kraut, & C. Egido
(Eds.), Intellectual teamwork: Social and technical bases of collaborative work (pp.
173-190). Hillsdale, NJ: Erlbaum.
International Standards Organization (1991, June). Quality management and
quality assurance standards - Part 3: guidelines for the application o f ISO 9001 to the
development, supply and maintenance o f software. (Reference No. ISO 9000-
3:1991(E)). Geneva, Switzerland: Author.
87
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Iansiti & West ( 1997, June). Technology integration: Turing great research
into great products. Harvard Business Review, 75(3), p. 69-79.
Jacobson, I. (1992). Object-oriented software engineering. Reading, MA:
Addison-Wesley.
Jenner, M. G. (1995). Software quality management and ISO 9001: How to
make them work for you. New York: John Wiley & Sons.
Kraut, R. E. & Streeter L. A. (1995). Coordination in software development.
Communications of the ACM, 38(3), 69-81.
Maguire, C., Kazlauskas, E. J., & Weir, A. D. (1994). Information services for
innovative organizations. San Diego, CA: Academic Press.
Malone T.W. & Crowston K. (1993). What is coordination theory and how
can it help design cooperative work systems? In R. Baecker (Ed.), Groupware and
computer-supported cooperative work (pp. 375-388). San Mateo, CA: Morgan
Kaufmann.
McCarthy, J. (1995). Dynamics of software development. Redmond:
Microsoft Press.
O’Connell, F. (1996). How to run successful projects II. New York: Prentice
Hall.
Paepcke, A. (1996). Information needs in technical work settings and their
implications for the design o f computer tools. Computer Supported Cooperative
Work Journal, 5(1), 63-92.
Patton, M. Q. (1990). Qualitative evaluation and research methods. Newbury
Park: SAGE Publications.
Paulish, D. J. (1993). Case studies o f software process improvement methods
(Tech. Rep. No. SEI-93-TR-026). Pittsburgh, PA: Carnegie Mellon University,
Software Engineering Institute.
Pressman, R.S. (1993). A manager’s guide to software engineering. San
Francisco: McGraw-Hill.
Putnam,L.H. & Myers, W. (1997) Industrial strength software: effective
management using measurement. Los Alamitos, CA: IEEE Computer Society Press.
88
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Rada. J. (1991). Hypertext: From text to expertext. New York: McGraw-Hill
Book Company.
Ramesh, B., & Dhar, V. (1992). Supporting systems development by
capturing deliberations during requirements engineering. IEEE Transactions on
Software Engineering. 18(2), 498-510.
Rumbaugh, J., Blaha, M., Eddy, F., & Lorensen, W. (1991). Object-oriented
modeling and design. New Jersey: Prentice Hall.
Sachs, P. (1995)* Transforming work: Collaboration, learning and design.
Communications o f the ACM, 38(9), 36-44.
Schatz, B. (1993). Building an electronic community system, In R. Baecker
(Ed.), Groupware and computer-supported cooperative work (pp. 550-560). San
Mateo, CA: Morgan Kauftnann.
Schein, E.D. (1990). Organizational culture. American Psychologist, 16(2),
109-119.
Schwarz, R.M. (1994). The skilled facilitator: Practical wisdom for
developing effective groups. San Francisco: Jossey-Bass Publisher.
Simon, H. A. (1981). The sciences o f the artificial. Cambridge, MA: The MIT
Press.
Smith, J. B. (1994). Collective intelligence in computer-based collaboration.
Hillsdale, NJ: Lawrence Erlbaum Associates.
Sundstrom, E., Meuse K. P. De, & Futrell, D. (1990). Work teams:
Applications and effectiveness. American Psychologist, February, 120-133.
Tingey, M. O. (1997). Comparing ISO 9000, Malcolm Baldrige, & SEICMM
for software. New Jersey: Prentice Hall PTR.
Walsh, J., & Ungson, G. R. (1991). Organizational memory. Academy of
Management Review, 16(1), 57-91.
Winograd, T. (1995). From programming environments to environments for
designing. Communication, ACM 38,6, 65-74.
89
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Wheelwright, S.C. & Clark, K. B. (1993). Revolutionizing product
development. New York: the Free Press.
Yakemovic, B. (1993). Report on a development project use o f an issue-based
information system, In R. Baecker (Ed.), Groupware and computer-supported
cooperative work (pp. 566-579). San Mateo, CA: Morgan Kaufmann.
Zubrow, D., Hayes, W., Siegel, J., & Goldenson, D. (1994). Maturity
questionnaire (Tech. Rep. No SEI-94-SR-007). Pittsburgh, PA: Carnegie Mellon
University, Software Engineering Institute.
90
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
A pp end ix A
INTERVIEW GUIDE
I am a student at the University o f Southern California pursuing my doctoral
degree in Instructional Technology, School o f Education. My dissertation researches
the collaborative information processes in the software development environment. It
involves the understanding of the information requirements critical to the
development process and the information barriers, which prevent developers from
working effectively. The purpose of this study is to improve software development
productivity.
I would like to have a 30 minutes interview with you. I believe your
experience and thoughts will help find an infrastructure that improves software
development productivity. I will be glad to share the results with you when the
research is completed.
Thank you in advance for your time and participation. Please let me know
when the best time is to meet you. Please suggest a place to meet as well.
Attached are the questions I will ask during our interview:
1) What kind o f information is most critical to you during the process o f software
development?
2) How do you get and use the information to accomplish your tasks?
91
!
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3) How easy is it to retrieve the information you need? Is there any information
missing, conflicting, out dated, or overloaded?
4) How is information structured and stored? Do you have any suggestions for
improvement in this area?
5) How is information updated? Do you have any suggestions for improvement in this
area?
6) How is information shared? Do you have any suggestions for improvement in this
area?
7) What are the information-related barriers that prevent you from doing your job
effectively, such as out-of-date materials, awkward access procedures, etc.?
8) Evaluate and rank the effectiveness of these communication channels as they help
you get the task done: group discussions, phone conversations, e-mail, face to face
meetings, and printed memos.
9) Describe an ideal information infrastructure that will help a software development
team to be successful.
92
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

The Effects Of A Team Training Program And Inferences For Computer Software Development

PDF

A Model For Cooperative Management Of Community College Television

PDF

The effects of instructional designs matched to individual differences in cognitive styles on concept learning in geometry: a trait-treatment interaction study

PDF

Effective Sales Training And Transfer

PDF

A representation for semantic information within an inference-making computer program

PDF

Computer-Based Instruction Applications Using Hypertext Environments For The Instruction Of The Shortest Path Algorithm

PDF

Changes in performance of high school students in mathematics and reading tests subsequent to participation in integrated learning systems

PDF

Critical factors that undergird teachers' change in science knowledge and pedagogy

PDF

Computer anxiety, self-efficacy for self-regulated learning, and self-efficacy for computer technologies in a distance learning course

PDF

Evaluation Of A Modified Daily Schedule At Glendale High School

PDF

Bayesian analysis of software cost and quality models.

PDF

An Analysis Of Affective And Cognitive Responses To Three Types Of Added Visual Prompts In Programed Instruction

PDF

Communication patterns with electronic mail within a central school office

PDF

Assessing the critical behavioral competencies of information technology (IT) project managers at Southern California Edison

PDF

Auditory Blending: Effects Of Presentation Method, Word Frequency, Word Category, And Number Of Word Parts On Word Identification

PDF

A study of the effects accounting systems have on capital equipment replacement policies

PDF

Communicating at the bonding stage of relationships: The role of self-disclosure and relational competence in dyadic adjustment.

PDF

Data warehouse: A case study of the factors effecting user satisfaction

PDF

A study of the intonation patterns of black and Standard English speaking children in formal and informal situations

PDF

Proactive Effects In Meaningful Verbal Learning And Retention In Eighth Grade Students

Asset Metadata

Creator Chang, Christine Pao-Fang (author)

Core Title Analysis of information process for software development productivity

Contributor Digitized by ProQuest (provenance)

Degree Doctor of Education

Degree Program Education

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag business administration, management,Computer Science,OAI-PMH Harvest

Language English

Advisor Kazlauskas, Edward (committee chair), Dembo, Myron (committee member), Knirk, Frederick (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c17-299720

Unique identifier UC11352701

Identifier 9816085.pdf (filename),usctheses-c17-299720 (legacy record id)

Legacy Identifier 9816085.pdf

Dmrecord 299720

Document Type Dissertation

Rights Chang, Christine Pao-Fang

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA