All of the points enumerated above have been extensively analyzed and solutions have been proposed. Most of the solutions result in a shorter initial period of systems development – say, three to six months – after which periodic new releases of the system provides additional functionality every three months or so. While many authors had started promoting Rapid Application Development (RAD) in the early 1990s, this did not become generally accepted until the race to create web-based applications towards the end of the decade. However, by the time the e- bubble burst in March, 2001, RAD and incremental releases had become the norm for all but the most ambitious systems development projects. Even though the pace of creation of web applications has leveled off, we have not seen a return to large, big-bang projects.
A consequence of this trend is that maintenance has now become the normal mode of application creation. In the past, you might have a large team working for three years on the initial development of an application, followed by a team reduced to one-half or one-third the initial team, working for ten to twenty years to do maintenance. This would imply a ratio of initial development to maintenance of 1 to 2 or 1 to 3. With the new model, the initial development would take place with a smallish team over three months and maintenance would still last for ten or twenty years with a team of the same size or slightly smaller, giving us a ration of development to maintenance of 1 to 50 or 1 to 100 in extreme cases.
This tremendous shift has not attracted the interest of researchers and authors. IS departments have realized it, however, and the best-run organizations articulate their work around maintenance as the default activity, initial development being almost an afterthought.
In the new model, you do not have a unidirectional flow from requirements (supposed complete) through design to construction. Rather, you have system change requests flowing from any part of the process (wherever an issue has arisen) to any other part of the process (wherever the request has an impact).
Most IS departments use the following classification for their system change requests:
Type 0: Emergency fix. The system has a critical error and is not operational; no bypass is available.
Type 1: Error correction. The system does not work according to specifications. A temporary bypass is available. Type 2: Enhancement. The system does not work satisfactorily: there are reliability, usability or performance issues
Type 3: Extension. The system needs new or modified functionality to respond to external changes or to increase its business value.
Type 4: No system change required. The request is one that can be satisfied by more information or by routine action (such as a password reset). This category is included here only for the sake of completeness.
In the standard case, Type 0 requests are addressed immediately. Type 1 and simple type 2 requests are bundled together in what is often called a “dot” release, typically monthly (or in some cases weekly). More complex type 2 and all type 3 requests are bundled in major releases, typically every three months (or in some cases every month).
The resulting life cycle might look somewhat like.
- 瀏覽次數：1304
