|
| |
Training Approach
This section discusses the kinds of training that are necessary for the
different business partners according to their function and ability to influence the
process. Specifically, it discusses two tracks: Management Training and Developer
Training.
Management
Training
Although several managers and decision makers are versed in object-orientation
and reusable software development techniques, we should provide an
opportunity to create a shared, unilateral vision of the process
and its potential impact.
The following list of topics will consume approximately 6 hours (one
day or two-half days):
Management Topics
| TOPIC |
DESCRIPTION |
| Overview |
an explanation of reusable software and the
techniques required to achieve this; a brief connective history placing technology into
context |
| Benefits |
reasons why these techniques are important
(strategic) to the enterprise and the short and long term benefits |
| Risks |
critical success factors that must be managed
(tactical). This will set the expectations of management |
| Change Management |
expectation-setting of the various change
dimensions: organizational; work breakdown; project management; rewards; etc. |
| Costs |
key areas of expense such as tools, education,
etc. |
| Human Resources |
the challenge of acquiring, educating, and
maintaining personnel. Also, partnering with external sources (outsourcing) |
At the end of the seminar, all participants will understand the benefits
and risks of employing new techniques and will have a shared understanding of its impact
on the organization. Also, expectations will be set and each attendee will know how they
will participate in achieving the objectives.
Developer
Training
First, I define developer as any person participating in the development of any
deliverable in the software development process. That is, a business partner and
the analyst/programmer are both developers in the scope of this discussion. Most of
the training areas will include business partners and analyst/programmers,
except for specific disciplines where special training is clearly necessary. Here I use
the terms technical developer and business developer to make this
distinction.
In keeping with the aggressiveness of most organizations, the appropriate method for
training is using a ‘just-in-time’ (JIT) approach. This approach ensures that
the education process blends workshop with the business context. This, coupled with the
mentor's assistance, provides for knowledge transfer while reducing the risk of project
failure. Risk is reduced further by the discrete and controlled scope of the Pilot
Project.
This brings up a very important point that will be discussed in the Pilot Project
section. This method couples one training effort with one project effort
(although there are some training topics which non-team members may participate). As we
move from pilot project to future projects, we will iterate through the training,
as both a refresher and as an opportunity to refine the process and to train on
"lessons learned." This continuous, iterative, and incremental approach to
training will result in:
 | a relevant, context-based education; |
| internal trainers (reducing the need for external training services). |
The following table represents the training areas. Each area represents a phase in the
project.
Developer Topics
| Topic |
Description |
Audience |
| OO Overview |
an overview of the techniques, benefits,
examples, etc. This is part of the project "kick-off." |
All |
| Tools |
a general category that will include all of
the relevant tools. This requires a further discussion that will result after a choice has
been made. |
Dependent upon role (e.g. Project Manager,
DBA, etc.) |
| Requirements Gathering |
discuss the approaches and techniques of
performing contextual requirements gathering (use case). See Requirements Phase on
pages 5-8. |
Developers |
| Requirements Analysis |
discuss the methods and techniques of
analyzing the use case to partition it into a logical representation. See Requirements
Phase on pages 5-8. |
Developers |
| Design |
discuss how to evolve the logical model into
one that includes the requirements for the environment (non-functional) and end-user
(human) and process interfaces. This assists in determining the appropriate set of
architectures. |
Developers |
| Architecture |
discuss specific development styles and idioms
for application development. This includes further refining the structures and discovering
patterns. |
Technical Developers |
| Physical Design |
discuss specific programming styles and idioms
for specific implementation languages and platforms. |
Technical Developers |
| End-User Documentation Development |
discuss the methods for optimizing
communication for business partner understanding of how to use the new solution
(software). (This may fall into the Support Function.) |
Business Developer |
| Code Documentation |
discuss the framework for creating clearly
documented and readable source. This includes standards and styles. (May fall into Support
Function.) |
Technical Developer |
| Conducting Walkthroughs and Reviews |
discuss the various types of review processes.
For each phase (or deliverable) there can be different review types: requirements
walkthroughs; code reviews; technical walkthroughs; etc. |
Dependent on deliverable |
| Testing |
discuss the methods to ensure that all
functional and non-functional requirements have been addressed as well as meeting business
and technical expectations. |
Business Developer |
| Training |
general discussion on training. (May fall into
Support Function.) |
Business Developer |
| Implementation |
discuss the methods used to deliver and to
roll out new versions of software. |
All |
|
Assisting enterprises in learning, exploring, reengineering, and implementing component-based/object-oriented software solutions using best-in-class methods.