This chapter describes the prototype definition, who should do it, and how it should be done. The chapter first describes what the prototype definition is; next, it makes suggestions on setting up the project team; then, it explains how to develop the prototype definition; finally, it tells how to document the definition, to plan the work, and to secure equipment for prototyping.
Why should you do a prototype definition? The motto might be:
Know what you are going to do before you do it.
The prototype definition will be the basis for building the prototype. Since the prototype is the basis for the system, the prototype definition will be the basis for the system itself.
The prototype will be the vehicle for developing the full requirements for the system, and its definition will be the preliminary requirements for the system. Just as you do not need to develop the full requirements before you build the prototype, you also should not attempt to build the prototype without some kind of a definition of it.
Defining the prototype before building it helps users and Information Systems people think through the basic functions of the system. It is a valuable thing to do, even if the prototype may change considerably when the user actually begins to see its outputs.
One criticism that is often made of prototyping is that the requirements phase of a project using prototyping is too expensive, and keeping the requirements and design phases from running into each other is too hard. If those who are prototyping do not know what is needed for the prototype nor when they may begin building it, they may waste time and resources.
Why define reports and screens on paper? Why not go immediately to layouts or sample reports with a report generator? Often a person from Information Systems must start a user's thinking process by suggesting a layout. But, doing so is difficult for the Information Systems person if he has no idea of the contents, sequence, totaling, and uses of the reports. Even if the users will produce the reports with a report generator, beginning with the report generator now would be premature. You still need a prototype database with some sample data on it, before work with a report generator is meaningful.
Report generators and screen painters will be useful in building the prototype later, but what you need at this point is software for building data dictionaries and structuring databases.
What will the prototype initially be and look like? It will be a working model of the system that will include the major program modules, the database, the essential screens, the reports, and the interfacing inputs and outputs used to communicate with other systems. It will be a skeletal version of the system and will not contain all the processing and validation rules that the system will finally have.
Table IV-1 lists the contents of the prototype definition. The definition has two parts:
1. what the system should do
2. how it should do it
The logical definition describes what it should do. The physical definition, which some call the physical design, describes how it should do it. Neither definition should be complete and exhaustive, since you should not try to make the initial prototype complete and exhaustive.
. Reports
. Screens
. Information
. Functions
. Controls
. Interfaces
. Database
. System Flow
Prototype Definition Contents
The system whose prototype you are defining may be one of the following:
The definitions of both a batch and an on-line system will be similar. The documentation of packages and existing systems should be adequate as a basis. The project team should only need to add definitions for those parts of the enhanced or modified system that are new or different. One exception is when the existing system or package does not have a well-defined database and the new system is a significant modification. Then, you should consider defining the entire database as part of the prototyping effort.
The logical definition of what the system should do includes a description of the reports and screens the system should produce, the functions it should perform, and the information it should require.
The description of each report should include its purpose, a list of the information elements the report should contain,
the source of the information, how many pages it may contain, the sequence it should be produced in, how it should be totaled, how often the report should be printed, whether special forms should be used, how many copies of it should be produced, and who should receive them. Table IV-2 lists the contents of report descriptions.
. Purpose
. Contents
. Sequence
. Volume
. Source of Information
. Totals
. Frequency
. Distribution
. Special Forms
Report Description
Screens
Systems use screens in conversations for entering information and responding to inquiries. The screens include menus that list options, input screens, screens that are partly input and partly output, and screens that display the responses to inquiries. The description of screens should include their purpose, a list of the information elements to be displayed on each screen, the sources of the elements, the sequence in which screens will be displayed, the number of screens that will be entered during a time period, the relationship of different screens in a conversation, and who should be allowed to view the screen. Table IV-3 lists the contents of screen descriptions.
. Purpose
. Contents
. Source of Information
. Volume
. Sequence
. Relationship to Other Screens
. Access
Screen Description
Information
The description of information tells what useable data the system develops and maintains as a database. It should include a description of the information elements and the records which contain them. You should use some sort of automated data dictionary system for maintaining this information. The system may be a purchased package or something that you develop, possibly using a microcomputer DBMS.
The information element definitions you develop for the prototype definition will not be complete and exhaustive, yet you should take great care in developing them. The success of the prototype and the system will depend on whether it is based on a good initial understanding of the information elements. Even though both the users and the Information Systems people may think they understand the information as they begin the definitions, they may learn that they do not. Persevering to produce good definitions willpay dividends for the rest of the system development process.
Table IV-4 lists the contents of a complete information element description and specifies which parts should be done for the prototype definition.
. Element Name Yes
. Element Abbreviation No
. Characteristics Yes
. Element Definition Yes
. Subelements Yes
. Processing Rule Yes
. Alias Names No
. Validation No
. Headings No
. Responsible for Changes No
Information Element Description
The element name is the best name by which the information element is known. Although all the alias names do not need to be found and recorded during this phase, if you know of other names that are used for the element, record them.
The element abbreviation is a short form of the element name that is often used in programs and database definitions.
The characteristics of an element include its size, what kind of characters (alphabetic/numeric/special) it contains, whether it contains any decimals, and whether, if numeric, it is always positive or negative.
The definition of the element is a word description of it. This is similar to a definition in an English language dictionary.
Subelement descriptions, including the positions within the element that they occupy, are important for defining an element. Many elements contain subelements. For example, a telephone number element may consist of an area code, a prefix, a station number, and an extension.
Some elements have a processing rule which tells how to develop or calculate them. A processing rule applies to an element, if the element is always developed or calculated the same way, using the same elements as sources, regardless of what databases or tables it appears on. An example of a processing rule for an amount net pay element would be:
Amount Net Pay = (Sum of all pay and additions) - (Sum of all deductions and reductions)
The validation rules for an element tell what its allowable values are. They are not necessary for the prototype definition, but easily stated ones, such as validate cost center identification against a cost center table, may be helpful.
The headings describe the standard headings to be used for an element on reports and screens. Spending time to develop them for the prototype definition is not advisable, so choose something quickly.
The identification of the organization responsible for changes to the element definition is also a part of the final element definition, but it is not needed for the prototype definition.
Table IV-5 lists the contents of a complete record description and specifies which parts should be done for the prototype definition. The record characteristics describe the record itself. The record contents describe the information elements in the record.
Table IV-6 lists the criteria for defining a record. Adhering to these criteria will help you develop a third normalized form of the record definition. Gane and Sarson provide more information on how to develop this.
Every record must have a unique key. Define the record so that no two occurrences of the same type of record would have the same value for the key.
No elements should repeat within a record. No record definition should allow an element to occur more than once for each record. Analysts have a natural inclination to define records that contain twelve monthly summaries. They might be earnings for each month of the year. The first one would be for January, for example, and the third one for March. Doing so violates this rule and the following one that no meaning should be given to relative position within a record.
No meaning should be given to relative position within a record. The value an element may have should depend on its definition and its key, not on what happens to be next to it.
Each element in a record is identified by the whole key. A corollary to this rule is that no key should apply only to one or more elements. When the analyst in the example above realizes that he cannot have twelve earnings elements differentiated by position, he may want to distinguish them by a month code. The month code would further identify them, but would not apply to the other elements on the record, thus violating this rule as well as the one against repeating elements.
No element should depend on any other non-identifying element. If it does, the non-identifying element probably should be an identifying element. The analyst in this running example might have first viewed the month code as a non-identifying element, because in his mind it was clearly not part of the record's key. In one last attempt to keep the earnings summary elements on the record, the analyst may define them as twelve different elements with names like "Earnings Summary Month One" and "Earnings Summary Month Two." Doing that violates the rule that you should have no needless multiplication of elements. It also adds unnecessary elements differing from each other only trivially to the data dictionary.
Table IV-6 lists the contents of a record description. The description of the record characteristics include the name of the record.
CONTENTS NEEDED FOR PROTOTYPE
DEFINITION
.Record Characteristics
- Name Yes
- Estimated Number No
- Trigger for Preparation or Yes
Update
- Allowable Response Time No
- Retention Period or Disposition No
Criteria
- Responsible for Changes No
.Record Contents (Information Elements)
- Sequence Yes
- Element Name Yes
- Source Yes
- Constant Value Yes
- Whether Standard Definition No
Applies
- Whether To Be Edited No
An estimate of the number of the records that will be used in or produced by the system will aid the final design of the system, but you do not need this estimate for the prototype definition.
The trigger for producing or updating a record is important information. If the record is an employee paycheck, the trigger may be a scheduled processing date. If the record is an employee profile, the trigger may be the receipt of an inquiry on an employee. Include the triggers for producing records in the prototype definition, if you know them.
The allowable response time for producing a record after the trigger occurs establishes service constraints for the system design, but is unnecessary for the prototype definition.
The retention period or disposition criteria tell when or for what reason records are removed from active status. This is not needed for the prototype definition.
The organization responsible for changes to the record description should be a part of the record description, but it is not necessary for the prototype definition.
The names of the elements on the record should also be a part of the prototype definition.
Records are organized by keys composed of information elements, so the sequence is a function of the elements on the record. Identify as keys all of the elements that would be logically required to sequence a record, regardless of whether they would physically be a part of the record when it is implemented in a DBMS. For example, in Figure IV-1 Employee Number would be shown as a sequencing element in the Earnings Record, even though it might not actually be used if the physical implementation were in a hierarchical DBMS. This information is necessary for the prototype definition.
PARTIAL PAYROLL DATABASE STRUCTURE
____________________
| EMPLOYEE RECORD |
| |
| . Employee Number |
| . Employee Name |
| . Home Address |
| . Date Hired |
| . |
| . |
| . |
|____________________|
| |
| |
| |
| |
______|______________
| EARNINGS RECORD |
| |
| . (Employee Number) |
| . Pay Period |
| . Code Earnings |
| . Amount Earnings |
| . |
| . |
|_____________________|
Partial Payroll Database Structure
Describe the source of each element on output or updated records. An element is either unconditionally posted unchanged from another record or it is placed there by a process, including conditional posting. You should identify the source of unconditional posting for the prototype definition, but you do not need to define in detail the process for producing it.
Sometimes certain elements always have the same value when they appear on a record. For example, if the element is a transaction code, it may always have a value of "CAY" on a certain record. If that is the case, that constant value should be defined as part of the prototype definition.
The standard definition, used to edit an element on inputs, may allow for a large number of possible values, but the element may have a more restricted set of values on the particular record you are describing. For example, a two-digit numeric element may normally have any value from "00" through "99." But, when it appears on the record you are describing, it will only have values between "00" and "10." If it has a more restricted use, then the standard definition does not apply for a particular record. You do not need to define that for the prototype definition.
Whether or not each element on an input should be edited is an important part of the record description, but it is not necessary for the prototype definition.
The description of the functions the system should perform should include a description of what the system should do, with references to the information in records that it should use and produce, and any outputs, such as reports and screens, it should produce.
A function description must at least be adequate as a caption for a function symbol on a data flow diagram. The description should sufficiently identify the symbol for those working on the prototype definition. The description must also be adequate as a title for a "black box" on a subsequent system flow diagram.
The designation of the function's inputs, the records it will use, and the outputs it will produce must also be clear.
An example of a function description may be "Calculate Net Pay." Its inputs may include records containing recurring and one-time deductions and earnings. It may use payroll master records. Its outputs may include paychecks, check stubs, payroll registers, and updated payroll master records. Good notes on the present system's way of doing it may have been included with the data from the study of the present system. They may be useful as a detailed description of it. But, whether more detailed notes are available or not, a clear caption and specific identifications of information and outputs are enough for this part of the prototype definition.
The definition of the controls should describe the controls on input, the program-to-program controls, and any controls for output. Even though the controls should not be implemented in the initial model of the prototype, "pegs" for them should be left in it. Controls on input coming from people are usually batch controls. Controls on input coming from an interfacing system are usually totals that must be agreed with. Controls on output going to people are usually control totals. Controls on output going to interfacing systems are usually totals that the interfacing system must agree with. Program-to-program controls usually specify elements to be totaled in one program and compared in another and instructions on what to do if the totals do not agree from program to program.
The description of the interfaces describes the inputs to the prototype from feeding systems and the machine-readable outputs it should produce for the use of other systems.
The physical definition of the prototype is the design of the initial model of the prototype. It should include the database structure and contents, the system flow, and the principal controls on its inputs and outputs. The system flow should also include the design for prototyping whatever conversion will be required from the former system to the new one. Database
The definition of the database structure and contents depends on the record descriptions, the choice of records to be grouped together into a database, and whether you will eventually replace the database you use for the initial model of the prototype with a another implementation for the final version of the system.
You should not need to modify the record descriptions you prepared as part of the logical definition. Preparing the database definition from them may involve no more than deciding what DBMS to use for the initial model and whether grouping the records will require any additional elements. The frequency, volume, and sequence of reports and inquiries (screens) the system will produce from the database may also influence your final definition.
If you will group two or more records into the same database, each record should already have a unique key to distinguish it from any other occurrence of the same record. Nevertheless, you should determine whether you need to add key elements to distinguish one record type from another.
If you will use a different DBMS strategy for the initial model of the prototype, that is what you should define now. You will develop the final version as part of the prototyping process itself. For example, you may expect to use a hierarchical implementation for the final version of the database, yet you might initially define the database as overlays on a fixed- length, indexed file. The fixed-length, indexed file is what you need to define first. Note that you may need to add an additional element or elements to distinguish the different record types that will be on the same database.
The system flow defines the structure of the prototype. It should show the movement of information within the system from inputs and interfacing systems, through programs, the database, and program-to-program files, and to outputs and interfacing systems. It should depict the sequence of all program-to-program files.
The system flow should also describe any conversion that will be required from an existing system to the new system. The conversion process should be built as part of the prototype and prototyped along with the new system.
The system flow should identify the database records, the program-to-program files, the screens and reports, and any interfacing systems. It should show each program that will process input either from outside the system or from another program, each program that will produce output, and each program that will use or update the database. A program's description on the system flow may be the only description of it. Its definition should be that of a "black box" which moves data around. A caption for the box should identify the function. Insofar as possible, you should also identify the individual modules within each program and the functions they will perform. A programmer should be able to write the command language for the prototype from the system flow, so its identification of the parts of the system must be specific.
The description of the program-to-program files will include an identification of each file and a record description for each record it will contain. See Record Descriptions above and Table IV-5 to learn what should be in a record description.
The project team responsible for the prototype definition will be composed of users and persons from Information Systems. The users who participate will do so because of their positions and what they know, not because of their skills in such things as requirements definition and system design.
The users should include the person who requested the system, the managers of the areas of the organization that will use the system, and the supervisors and other user specialists who understand the processing in that area of the organization. If they are good at visualizing new processing and expressing their needs, they will greatly aid the prototype definition process. If they are not good at those things, they may still help prepare an adequate definition. Remember that one deficiency prototyping is intended to remedy is the inability of many persons to visualize how something should work before it has been built.
The managers who establish the need for a report or a screen should say what it will be, what will be on it, and how it will be used. Similarly, the managers responsible for having work done should identify the functions the information system is to perform. The managers and supervisors who will be responsible for working with the system or producing data for it should understand what will be needed and why.
Table IV-7 lists the skills required for the Information Systems persons who will work on the prototype definition. The table does not imply that at least three persons from Information Systems must work on any prototype definition. One person may possess all of the listed skills. Or two persons between them may have all of them. Also, the table shows the management of the project as an Information Systems function, but in many organizations a user may manage development projects.
Even if the overall manager of the project will be a user, Information Systems management must choose the person whom they will view as the Information Systems project manager or project leader. This person should have the skills listed for management in Table IV-7. Whether he is also a business systems analyst, a systems analyst, a programmer, or a systems designer should depend on the other duties he might have on this project.
Until now different persons within Information Systems may have worked on the system request and the study of the present system. But, it is essential for the prototyping methodology that one or more persons stay with the project beginning with the prototype definition and continuing through the implementation of the resulting system. Thus, the most important consideration in picking persons from Information Systems is to select one or more who will provide continuity for the project through its life.
User management must also identify those managers and supervisors who will participate in the prototyping process from definition through implementation. If it is their responsibility, user management should also designate someone as their project leader or project manager, or even as the overall manager of the project. User management may also pick some managers and executives to serve with Information Systems management representatives on an executive review committee to review the progress of the prototyping project.
REQUIRED INFORMATION SYSTEMS SKILLS
MANAGEMENT
. Project Management
. Project Leadership
. Communication Facilitator
REQUIREMENTS DEFINITION
. Ability To Work with Others
. Interviewing Skills
. Definition of System Function
. Information and Database Definition
. Knowledge of System Area
. Knowledge of Commercial Systems
. Familiarity with Current Application Systems Trends and
Techniques
PHYSICAL DESIGN
. Knowledge of Installed and Planned Hardware and Software
. Knowledge of Current Hardware and Software Trends and
Techniques
. System and Communication Design
Required Information Systems Skills
Developing the Logical Definition
The first part of the prototype to be defined is that part called the logical definition. It is the definition of the prototype's functions, screens, reports, and information. Table IV-8 shows the tasks necessary to do the logical definition.
LOGICAL DEFINITION TASKS
___________________________________________________________
| TASK | TO BE | TO BE
|
| | DONE BY | REVIEWED BY
|
|________________________|____________________|_____________|
| Talkthrough system | Entire Group | Management |
| | | |
| Define screens | User-Analyst Teams |Entire Group |
| | | |
| Define reports | User-Analyst Teams| Entire Group |
| | | |
| Describe functions | User-Analyst Teams |Entire Group |
| | | |
| Define controls | User-Analyst Teams | Entire Group|
| | | |
| Define interfaces | Analyst | Entire Group|
| | | |
|_Define_information_____|_User-Analyst_Teams_|_Entire_Group|
The logical definition should begin with a system talkthrough of the prototype. A system talkthrough is a series of discussions by all the involved users and Information Systems persons of what a system will do, use, and produce. Table IV-9 shows the results you should obtain from a system talkthrough. The data flow diagram will briefly show the functions and the information flow. Additional notes on processing details that were discussed and the frequency of doing each function should accompany the data flow diagram.
Lists of outputs, including reports and screens, are another important result of system talkthroughs. If the discussion of reports encompasses their contents, sequence, and totaling, you should include notes on these things. But, the most important aspects of reports are their purpose, the frequency of producing them, and who should receive them. Likewise, if the discussion of screens identifies contents, at least partially, include notes on the contents as part of the results. Nevertheless, the most important information about screens is their purpose, frequency of processing, who should be allowed access to the information on them, and their relationship to other screens in on-line conversations.
System talkthroughs enable all the members of the group that are responsible for the new system to work as a team in defining the elementary requirements of the prototype. Everyone can hear the users' listing what is to be done and Information Systems' suggestions of what to use, such as screens, reports, and the database. These system talkthroughs also establish group identity and help the team members learn to work with one another.
A system talkthrough should be two to three hours in length. More than one session will probably be necessary to define everything. No more than three weeks should elapse between the first and the last session. The group should meet as often as necessary to finish in that time period.
RESULTS OF SYSTEM TALKTHROUGH
Logical Data Flow Diagram showing for each function
. Function Title
. Input Identification
. Output Identification
. Database Identification
Notes on each function, including
. Frequency of processing
List of reports and other outputs, including
. Purpose
. Frequency of processing
. Distribution
. Contents (partial)
. Sequence (partial)
. Totals (partial)
List of screens
. Purpose
. Frequency of processing
. Contents (partial)
. Relationship to Other Screens
. Access Allowed
List of interfaces with other systems
List of controls
Results of System Talkthrough
The group should meet in a comfortable conference room large enough to enable everyone to use materials they may bring and to allow the use of visual aids.
During a talkthrough everyone should be able to see what is being identified. Recording notes on a flip chart, a blank overhead projector foil, or a blackboard will allow this. Also, someone, including possibly a secretary or someone else who is not a member of the group, should prepare notes on the discussions in each talkthrough. The group should review the notes from each previous session at the beginning of the next one.
The project leader should play the role of the discussion facilitator. He should be responsible for guiding the discussions to the intended results. One approach which may help is concentrating individual sessions on specific topics.
The first topic for discussion might either be output or functions. The other topics might be input, controls, and interfaces.
Even the best project leaders have trouble focusing the discussions of a group on a constrained topic, such as output, especially when the members of the group are meeting together for the first time. The most the project leader may be able to hope for in the first one or two talkthroughs is a wide-ranging and somewhat free-wheeling discussion which hits on the principal functions and outputs of the system. The project leader should actually encourage such discussions. They may be among the most productive of any of the talkthroughs. Nevertheless, without being too forceful, the project leader should keep the discussions businesslike and ensure the participants are aware of the functions and outputs that they are identifying.
A good way to begin the first talkthrough is to ask the participants what they want the system to do or what they imagine the system doing. As the participants mention ideas the project leader should list them for all to see. He should guide them into listing as many things as possible. After the group has spent its original enthusiasm in listing the main functions and outputs, the project leader should categorize what they have said. They have probably mentioned functions, reports, screens, and possibly even interfaces with other systems.
He should make sure the group completes its discussions of each. Naturally, to talk about functions without mentioning outputs or to talk about outputs without mentioning functions is almost impossible. Similarly, the discussions will disclose information on inputs, controls, and interfaces. The project leader must check that notes are taken when new information is mentioned and that all items are adequately discussed.
As the participants discuss the system's functions and its information flow, the project leader should sketch the results as rough data flow diagrams. Documentation assistants should make neater data flow diagrams for review at the next session.
As the discussions move to screens and reports the project leader will list the information that is developed. He should also show what information should be developed for each.
As source material, the talkthrough participants should draw on the service request and their knowledge and experience. Also, the material that was produced in the study of the present system should be useful as a source for discussions and as a checklist for making certain that all the functions of the present system are considered.
When the talkthroughs are finished, the project leader should review the results of the system talkthroughs with both user and Information systems management, either separately or together.
The entire project team is responsible for the completion of the screen, report, and function descriptions. But, after the talkthroughs are finished, the team may break into individual user-analyst teams to prepare the detailed descriptions. The limit to the number of teams would be the limit of the number of analysts or users or functional areas involved in the project.
Naturally the skills and experience of the individuals are also important factors in deciding what they should work on. Users who will use reports or who are familiar with the information that will be included on them should participate in the report descriptions. Analysts who have a feeling for screen design should participate in the screen descriptions.
Since the descriptions are ultimately the responsibility of the entire group, the entire team should meet at least once a week to review the descriptions that the various teams have developed.
As was mentioned earlier, screen-painting and report generating should not be done now. Team members who have used advanced tools for painting screens and generating reports may want to use them rather than bothering with paper. But, to do so will be a distraction at this point in the project. If they use them, they will want to test the reports and screens by setting up some test data, and the prototype building phase will have begun. This is the last chance the team will have to plan the system in a relatively calm atmosphere before beginning the more active parts of the prototyping methodology. Enjoy it.
Data Dictionary Entries
A small user-analyst team should develop the data dictionary entries. Although they should have the best knowledge of the information to be defined, they should also draw on the knowledge of other members of the group and even of persons outside the group as they work.
But, why dawdle over the data dictionary? You will know what should be in the reports and screens. Why not just throw something together for the database and start building the prototype?
Prototyping will be chaotic unless it is based on a good knowledge of the information. You should understand at least 80% of the content and structure of the data. If you do not have that before you build, you will have to make too many drastic, frustrating changes in the prototype. The effort may well fail.
So, take the time while you are still in the definition phase to develop a good understanding of the information the system will process. Developing this understanding and recording it is called making the data dictionary entries.
Should you actually use some kind of data dictionary system? If you can, yes. The data dictionary system may be a purchased package or a system you develop. Ideally it will contain the features listed in Table IV-10. A DBMS on a micro-computer is useful for developing your own data dictionary system, but including all the desirable features may be too difficult when you build your own.
A good data dictionary system should allow you to record a thorough description of each Information Element. This should include all that is listed in Table IV-10 for prototyping.
The data dictionary system should let you show the grouping of elements together into records and the grouping of records into files or databases.
You should be able to generate coding for at least the definition of the database, if not also for some of the processing, such as posting and validating, from the entries in the data dictionary.
The data dictionary should also enable you to find all the uses of elements and records in both programs and DBMSs.
To be useful in a production environment, a data dictionary should allow the recording of different versions of elements and records that were effective for certain periods of time.
If a data dictionary already exists, it should be reviewed to determine whether it contains entries for files that will be affected by the prototype. If you are modifying an existing system, it certainly should. The team working on the data dictionary should modify and augment any entries that exist. The entire project group should also review the data dictionary entries that the user-analyst team develops.
If the initial model will be developed with different tools than the later version of the prototype, design it for the tools that you will use first. The use of the other tools will be adopted as the prototyping progresses. One or more design analysts and database administrators, who may not be members of the project team, should work with the Information Systems project leader to produce the physical definition. They should do it after the completion of the logical definition and should base it on the logical definition.
After they have completed the design they should do a walkthrough of it with the other team members and anyone else designated by the organization to participate in the walkthrough of a new physical design. The purpose of the walkthrough is to verify that the design provides a good framework for the initial model of the prototype and that it meets the organization's design standards.
. Database Structure and Contents
. System Flow
- Prototype
- Conversion
The project leader should make sure that copies of the written results of the logical and physical definition of the prototype will be maintained as a part of the project records. The database will change. The reports and their distribution will not be stable. The screen descriptions will not be the last word. Yet the completion of the written definitions is a critical milestone in the project and maintaining a copy of them is important to the history of the project. See System Documentation in Chapter VII.
The definition of the prototype establishes the basic requirements of the new system and the framework of the prototype. Establishing a plan for the definition and monitoring adherence to the plan will ensure a good definition is produced with a reasonable expenditure of resources. Table IV-13 lists the tasks that comprise the definition. You will find a list of elements considered essential to the success of the phase in Table IV-12.
Securing the cooperation and enthusiasm of team members is the responsibility of the project leader with the help and support of both user and Information Systems management. The team members should identify themselves with one another and with the project and should accept responsibility individually and as a group for the new system's success. To accomplish this the project leader should make certain that all the team members understand what they must define in this phase and the steps they will take to do it. He should also discuss with them the different tasks they may work on to complete the definition.
The team will identify the system features in the talkthroughsbefore doing the rest of the definition. The framework they produce will be the basis for all that follows in this phase as well as the remainder of the project. Again the project leader must be responsible for creating an atmosphere in which the team members can work productively.
If the team does not understand the database and define it well, the prototyping will certainly flounder, if it does not fail. The results of the screen, report, and function definitions should prompt the information definition, even though they can proceed at the same time. The team members who are responsible for the definition of the information should be persistent, thorough, and able to judge the completeness of their results. As mentioned in Chapter III, estimate the work to be done, plan it, schedule it, publish the schedule, and adhere to it. You should not need to allow for iteration of the tasks in this phase. In fact, the team should complete the logical definition before the physical definition begins. But, after the talkthroughs are finished, you may define the screens, reports, functions, and information simultaneously, if enough persons are available. Since the number of reports and screens and the complexity of the information may not be known until after the talkthroughs, you may want to prepare a preliminary plan and schedule for this phase before the talkthroughs begin, then modify them after they are completed.
The project leader and both user and Information Systems management should monitor the quality, quantity, and timeliness of the work that the team produces.
If a system extends on-line processing for the first time to some part of the organization, new or additional equipment may be needed. Users will be exercising the prototype after it is built. They should not have to leave their area to work with the prototype. The ideal is to place terminals for prototyping an on-line system in the user area. The project team should ensure that equipment is installed4 in the user area by the time the exercising of the prototype begins.
If sufficient equipment of the same type that will be used in the real system, or of a type close enough to it, will not be available when exercising the prototype begins, you should consider buying or possibly even temporarily renting equipment.
Also, if the new system will include communications with outlying parts of the organization, such as branch offices, equipment and communications should be provided in at least one nearby location for prototyping.
The next three phases of the project include:
1. Building the prototype
2. Exercising the prototype
3. Implementing the system
Since you have defined the prototype, you should have a good basis for estimating what will be needed to build it, exercise it, and implement the system that it becomes. If this is the first time you have prototyped, you may want to read ahead before completing your estimates and developing your plan. But, develop your first detailed plan for the next major phases of the project now, before continuing with the project. A schedule and cost estimates should accompany the plan.
As you develop your plan, remember the importance of milestones to it. The project must have milestones - points in time when all agree that the requirements have been defined, the system has been designed, the acceptance testing has been completed.
The project team must produce documents that describe the requirements and the acceptance test plan. The team may prepare these documents while the phase that they are to document is underway. What happens during the phase must conform to the document, or the phase cannot be considered to have been successfully completed. Neverthess, the beginning of the phase does not have to be delayed until the document is ready.
As an example, the testing must conform to the test plan. But there is no need to delay beginning the testing, while waiting for the test plan. All should agree, though, that the testing cannot be considered completed, until the test plan has been completed. Only then, can it be known whether the testing conforms to the plan.
How can the testing begin before the test plan has been developed? Testing is not an after-the-fact proof that something has been done; it's exercising the prototype. It's determining what the system should do, modifying it, putting test data through it to ensure it has been done, then modifying it again and testing it again. The test plan then is a description of this exercising.
. The prototype definition will be the basis for building the prototype.
. Contents of the prototype definition:
- Logical Definition
The logical definition describes what a system should do.
. Record definition criteria:
. The project team responsible for the definition will be composed of users and persons from Information Systems.
. A system talkthrough is a series of discussions by all the involved users and Information Systems persons of what a system will do, use, and produce.
. Schedule the prototype building through implementation phases, paying particular attention to definite milestones.
. Install equipment in the user area for prototyping.
. Elements essential to the success of the definition:
- Secure cooperation and enthusiasm of team members
- Identify the system features in the talkthroughs
- Understand the database
- Follow a firm schedule
- Monitor quality and quantity of work