SDLC project only for Kibebe

*eaig C;si,f )-ai*'-'

€ese EmFa'pdrscFEon Maintenance of MyBroadway, the Web-based customer

relationship management system for Carrie Douglass, manager of the Centerville, Ohio, Broadway Entertain- ment Company, Inc. (BEC) store, deals with a phase of systems development with which the students from Stillwater State University are unfamiliar. None of the systems they have developed for programming and sys- tems analysis and design classes ever reached this phase. And MyBroadway' because it is a prototype, is not really designed to be maintained after the student team does its work. Professor Tann, instructor of their MIS project class, had encouraged all the student teams to consider the maintenance issue, even if the teams are not themselves involved in maintenartce of the systems they build for the course.

PreperEetg the $WeiaEfemsnee Flsa"c The MyBroadway team members discussed the con- cept of maintenance for their information system. They concluded that each prototyping iteration is similar to a maintenance step. At each iteration, a flaw in the sys- tem may need to be repaired (corrective maintenance), a new business requirement may have been identified (adaptive maintenance), a desirable system improve- ment may be made (perfective maintenance), or the system may change in anticipation of future issues ftlreventive maintenance). Already, the team has gone through many iterations of MyBroadway as additional modules are included or changes to the system inter- face are made. Prototyping is intended to be rather informal and user-driven, so tight controls on making changes would not be appropriate. On the other hand, making many small changes takes considerable effort, can seem trivial at each iteration to the end user, and is open-ended and difficult to mesh with the team mem- bers'busy class schedules. Thus, some systematic way to handle changes, even if not very formal, could make the team more Productive.

The Stillwater students decided that preventive main- tenance should be the lowest priority, to be done only when other changes are not requested or when the pre-

ventive change can be incorporated easily along with other changes. As with aII maintenance, corrective maintenance is a top priority. Prototlping is driven by the identification of adaptive and to some degree per- fective changes, so these must be important. The

CHAPTER 14 MAINTAINING INFORN/IATION SYSTEMS 525

students conclude that maintenance for prototSrping is the art of setting priorities and trying to cluster changes that can easily be done at the same time to get the most effect out of an iteration.

Given the above observations, the MyBroadway team

members came up with a procedure for handling requests for changes (see BEC Figure 14-1)' One source of requests would be the feedback forms sub- mitted by customers and employees after trying an iter- ation of the prototype, another source would be sug- gestions from Carrie and store employees for adaptive ind perfective features' and the final source would be ideas made by the team members' Any of these sources

could generate any type of request, although sugges- tions from Carrie, store employees, and the team mem- bers would likely not be corrective maintenance requests. No preference is given to any particular source, but changes will be grouped by module:

1. Movie suggestions 2. Movie rental agreement 3. Movie rental requests and inventory review 4. Rental status 5. Interface with Entertainment Thacker 6. The database

One team member is designated as the lead on each module. Corrective requests will be done as soon as possible without consideration of priority analysis or synergy with other requests' That is, whenever a team member has time to work on the system module for which he or she is responsible, he or she will try to make all corrective changes in the queue for that mod- ule and create a new iteration (version) of the proto- type including those changes. If there are no corrective maintenance requests waiting and a team member has time, he or she will work on any adaptive requests for his or her module. Perfective requests are held until an adaptive request involving the same module is being handled. Because there is a desire to rapidly iterate as productively as possible in order to develop a working prototype that handles cunently identified needs, pre- ventive requests receive the lowest priority and are not worked on unless no other request is being handled by ateam member.

The BEC student team believes that this procedure will give them both disc portunity to put their efforts into makin e iteration have the greatest impact. By categorizing changes by mod- ule, the student with the greatest familiarity with a module will be able to make the changes the most accurately and with the greatest motivation (it is "his" or "her" module).

526 PART V IMPLEMENTATIoN AND MAINTENANCE BEC FIGURE I4.I MyBroodwoy prototyping ond morntenonce monogement procedure

Team member is '.. available to work on " his or her module

re there'"'.-,.. rve requests

.. for module?

ecse Sumarnory This is the last BEC case. Do you sense a conclusion? Not really. The results of the MyBroadway project axe still to be determined by how well the Stillwater stu- dents handle all the changes for all the iterations of the system prototype. Their success is also determined by how well you have given them guidance in this and the preceding chapters by your ztrtswers to the case ques- tions. Success on a systems development project comes from the project team members doing outstanding work in each phase of systems development. As is often said by seasoned systems developers, "the proof is in the details." The project must be well planned, it must have proper resources that are well managed, user require- ments must be realistic and met or exceeded, and implementation must go smoothly. You have had a chance to critique the work of the Stillwater students at each step in systems development. We trust that you have found some flaws in their work and have sug- gested some significant improvements. Such critical review by peers is a cornerstone of professional sys- tems analysis and design.

Case Questions

1. Critically review the prototyping/maintenance pro- cedure outlined in BEC Figure 14-1. What sugges- tions do you have for improvement? Why?

2. What do you consider to be the strengths of assign- ing one team memberto each module? What are the wealcresses of this resource allocation model?

3. Does the procedure outlined in BEC Figure 14-1 adequately address the maintenance needs of a typ- ical Web site? What missing elements do you see?

4. What kinds of changes would be made that are assigned to the database module? What is the advantage of considering this as a separate module?

5. What kinds of changes will be made to the Entertainment Tfacker module? Would it be possi- ble to combine the database and Entertainment Ttacker modules under one team member? Justi$r your answer.

6. Maintenance includes not only the system itself, but also all the documentation about the system. Because the MyBroadway team is using a prototyp- ing methodology, what is the responsibility of each team member to update documentation produced from prior systems development phases when change requests relate to flaws or inadequacies in the requirements determination, systems analysis, or systems design of prior steps?

i.. corrective request ''-,.-for

module?....

* Me

next prototype ' . -T.*z:::''..:.:]::i,