Information Technology Reference
In-Depth Information
face-to-face communication, continuous, synchronous team work in design
meetings, shared decision-making, and consensus (Holtzblatt and Beyer
1995
).
• Involvement and Control: Requirements can only be effectively defined when
all members of the development process are involved. No one likes to feel out of
control of their time, their work activities or their goals. Team members don't
want their activities dictated to them. Team members really owns their process
and have skills to solve particular problem. A successful requirements process
includes effective ways to foster partnership between customer and designer and
team members. It must reveal the ownership of the activities of the design by
customers and team members (Holtzblatt and Beyer
1995
).
• Client-Developer Links: A software project is built of techniques or channels
that allow customers and developers to exchange information. We refer to these
as links. A wide variety of links are available to software developers. The
tremendous variety of links that are available today represents both opportunity
and a challenge for software development managers. Opportunity is easier to
obtain inputs from clients and challenge is deciding on the type of links. By
focusing on links we are able to draw insights on degree of participation that
should be used to engage customers in development process. Keil and Carmel
lay out three basic guidelines regarding these links: the more links the better;
avoid indirect links; and always be sure to consider links that may be considered
non-traditional for the environment (Keil and Carmel
1995
).
6.3 Analysis Modeling Concepts
In the case of Object-Oriented Analysis Design (OOAD) with UML, your models
consist primarily of diagrams: static diagrams that depict the structure of the
system, and dynamic diagrams that depict the behavior of the system. The
dynamic diagrams allow you to trace through the behavior and analyze how
various scenarios play out. With the static diagrams, you can ensure that each
component or class has access to the interfaces and information that it needs to
fully carry out its responsibilities. The best part is that it's very easy to make
changes to these models, such as: adding, moving, or deleting a line. It is also great
for reviewing the change in a diagram which takes only minutes. Contrast that with
actually building the code, which can take hours to simply implement the change
and hours more to test and review it.
Your core artifact of the OOAD process is the model. In fact, you will likely
have multiple models:
• Analysis Model. This is a model of the existing system, the end user's
requirements, and a high-level understanding of a possible solution to those
requirements.
