Information Technology Reference
In-Depth Information
The term “process” as used in our pedagogic context for architected applications
development (AAD), carries the connotation of process models designed to view the real
world from the viewpoint of architectural software development. Thus, the process to be
described is an abstract description of the software development activities within the service-
based architecture (Stapleton, 1997). We are interested in a two-tier process to achieve an
AAD methodology: the solution process, and the component process. The former is aimed
at development of solutions, typically in terms of user services, to maximize reuse of existing
services and provide early user value. The latter is aimed at developing components that
provide commonly used business and data services across different departmental systems
or for use by third parties. It is important to notice that we often need to use elements of both
processes adapted to our specific needs. Typically, the key driver of the solution process
is a set of specific requirements to meet the needs of a business process. Various models are
produced throughout the process, which evolve in detail as the process unfolds. We
continually seek opportunities to extend and refine existing generic models. Such models are
often selected on a use-case by use-case basis (Jacobson et al., 1992) for incremental
development of user services. On the other hand, the generic business requirements that
drive the component process may come from the need to reuse existing legacy assets, and
the feedback from solution projects. An important part of the component process is to evolve
the models so that they can be specialized and refined by solution builders to form an evolving
set of components.
In practice, the use of a process by a software development team should assist project
management in numerous tasks. These include identification and partitioning of work,
identification of progress achieved, planning of the staff resource profile, planning of the
requirement for physical resources, and provision of cost and time scale estimates for the work
yet to be performed. From a technical viewpoint, a process should assist in such areas as
identification of preconditions required before each activity is started, specification of the
products and deliverables required from each activity, techniques that may be used during
each activity, and experience gained from earlier work. Clearly, building and refining generic
models is an important aspect of CBD, where we want to leverage model reuse more than code
reuse. Service packages provide a means of structuring a project in terms of architectural
context and allow us to build on and capitalize on the best work of others. A service package
can be effectively employed in a component process to contain a generic model, which can
be refined and extended to meet the specific needs of a solution process. The model solution
space evolves to contain more detail as a project moves through the iterations of the process.
Eventually, portions of the model are mature enough to be transformed into code. The tested
code represents the model at its most detailed level of abstraction. As for deliverables, they
are simply views of a maturing model. Indeed, the service-based process for AAD is an
adaptive process that can be tuned and customized to specific organizational needs.
Checkpoints can also be built into the process to help evolve it. This includes documenting
the lessons learned so that others can avoid making the same mistakes.
TEAM SKILLS DEVELOPMENT FOR
MANAGING SOFTWARE REQUIREMENTS
To partially address the requirements challenge in architectural IS solution develop-
ment, we often suggest some team-based activities (DeMarco, 1982; Jacobson et al., 1992;
