Defining IMS application requirements
One of the steps of application design is to decide how the business processes, or tasks, that the end user wants performed can be best grouped into a set of programs that efficiently performs the required processing.
To analyze processing requirements, consider:
- When the task must be performed
- Will the task be scheduled unpredictably (for example, on terminal demand) or periodically (for example, weekly)?
- How the program that performs the task is executed
- Will the program be executed online, where response time is crucial, or by batch job submission, where a slower response time is acceptable?
- The consistency of the processing components
- Does the action the program is to perform involve more than one type of program logic? For example, does it involve mostly retrievals and only one or two updates? If so, you should consider separating the updates into a separate program.
- Does this action involve several large groups of data? If it does, it might be more efficient to separate the programs by the data they access.
- Any special requirements about the data or processing
- Security
- Should access to the program be restricted?
- Recovery
- Are there special recovery considerations in the program's processing?
- Availability
- Does your application require high data availability?
- Integrity
- Do other departments use the same data?
Answers to questions like these can help you decide on the number of application programs that the processing will require, and on the types of programs that perform the processing most efficiently. Although rules dealing with how many programs can most efficiently do the required processing do not exist, here are some suggestions:
- As you look at each programming task, examine the data and processing that each task involves. If a task requires different types of processing and has different time limitations (for example, daily as opposed to different times throughout the month), that task might be more efficiently performed by several programs.
- As you define each program, it is a good idea for maintenance and recovery reasons to keep it as
simple as possible. The simpler a program is—the less it does—the easier it is to maintain, and to
restart after a program or system failure. The same is true with data availability—the less data
that is accessed, the more likely the data is to be available. The more limited the access
requested, the more likely the data is to be available.
Similarly, if the data that the application requires is physically in one place, it might be more efficient to have one program do more of the processing than usual. These are considerations that depend upon the processing and the data of each application.
- Documenting each of the user tasks is helpful during the design process, and in the future when
others will work with your application. Be sure you are aware of standards in this area. The kind of
information that is typically kept is when the action is to be executed, a functional description,
and requirements for maintenance, security, and recovery.
For example, for the current roster process described previously, you might record the information shown in the following form. How frequently the program is run is determined by the number of classes (20) needed by the Education Center each week.
Documenting user task descriptions: current roster example
USER TASK DESCRIPTION
NAME: Current Roster
ENVIRONMENT: Batch FREQUENCY: 20 per week
INVOKING EVENT OR DOCUMENT: Time period (one week)
REQUIRED RESPONSE TIME: 24 hours
FUNCTION DESCRIPTION: Print weekly, a current student roster, in student
number sequence for each class offered at the Education Center.
MAINTENANCE:Included in Education DB maintenance.
SECURITY: None.
RECOVERY:After a failure, the ability to start printing a particular
class roster starting from a particular sequential student number.