1.1. REDESIGNING COMPLEX LEGACY SYSTEMS: CHARACTERISTICS OF PROJECTS
Typically, these systems are a set of transaction-oriented, mainframe-based systems for administrative and/or customer service purposes. Systems for public administration, managing a financial/insurance portfolio for a customer, or managing supply, warehousing, and distribution are popular examples. In terms of the characteristics mentioned above, these projects can be described as follows:
- The project is an in-house application for several thousand users across one or many countries with a unilingual or multilingual user interface.
- The project is an application upgrade. Existing work flows and tasks are redesigned a little so that users become more sales and customer-service oriented: users become advisors to customers about a wider range of products and services offered by their organization. In fact, the new technology serves as a vehicle to introduce a major shift in organizational culture, including changes to required staff expertise (the new system requires generalists rather than specialists; the system provides the specialist knowledge), staffing levels and staff organization, and rewards.
- The user interface will be a unifying Graphical User Interface (GUI) facade so that all the applications are presented to the users as a single integrated application, rather than as a set of stand-alone applications. A set of stand-alone mainframe-based systems is migrated to a client-server environment employing object-oriented technologies or a client-server front end is developed leaving the legacy systems intact at the back end.
- Frequently there is at least one piece of so-called commercial-off-the-shelf (COTS) software, i.e., a commercial software package that addresses part of the required functionality. By implication, the COTS software has its own idiosyncratic user interface, and the design challenge is to fit the additional software (frequently labeled COTS extensions though the extensions are often more substantial than the COTS core) with the COTS software. The degree of COTS integration may vary considerably, from no integration at all to modifying the COTS user interface architecture and code so that the user is unaware of the separate pieces of software.
- Frequently the software is developed in part or in whole by an outside software development company, i.e., a systems integration or consulting firm adding the complexities of a customer/supplier relationship to the project.
- There are 30 to 100 software developers and a total project staff of 100 to 300 people (including business representatives, technical writers, trainers, roll-out planners, etc.).
- The duration of the project, including roll-out, may be 2 to 4 years.
- The organization is at the lowest of the five levels of the Software Capability Maturity Model (Paulk, Curtis, Chrissis and Weber, 1993), Level 1(Initial) and occasionally at Level 2 (Repeatable).
- The nature of the assignment may be firefighting or fire prevention.
- One or two usabililty engineers are available for firefighting, three to six are available for fire-prevention (the number of usability engineers is more often dictated by the project budget rather than project size or type).
- In a fire prevention assignment, usability engineers are involved during systems analysis and design full time for 6 to 12 months, part time during coding for ongoing feedback to developers and quality assurance, and again full time during field trials and acceptance testing.
- Real users are available, though in very limited numbers only. Typically, three to six users are seconded to the project full time or part time, with additional users being available part time for testing to represent the diversity of users. While a larger number of users is desirable to ensure representation of a large and often diverse user population, three to six users full time or part time is usually all that is possible (and it may take weeks to secure their participation because of management concerns).
|