Over 30 forms are required to support the SDT methodology. It is provided here as an example of what the CIMS task forms management facility can do. You will be able to take a look at this supported tasks and then analyze how to set up your own task forms management facility in support of simple or complicated tasks.
There are two parts to this document:
There is a need for clarification of the MULTI TASKING environment of the SDT methodology. Due to the nature of the SAVIC system, programming will begin at the start of the documentation process. Thus the documentation will proceed along with the programming initial effort. This can only be done in a SAVIC environment. The advantage is that the user can see results almost immediately and in the simulation mode, make changes that could effect the schedule and budget at an early stage of the project. This feature is supported by the cognitive software architecture of the SAVIC system.
STRUCTURED DEVELOPMENT TECHNIQUE
The SDT, Structured Development Technique, was developed in 1970 an utilized in over 35 projects. The need for the Structured Development Technique was the emergence of the SAVIC system which could produce a new on line application or system in weeks rather than months. The SAVIC system also required some forms to be set up for the development of code using the QPL real time compiler. The (S) of SAVIC stands for Structured Development Technique.
The methodology was highly comprehensive yet streamlined to the point that while the documentation was being prepared in the early stage of the project, a simulated system was ready for viewing in the same week. Needless to say that the user management community was very impressed at the response.
The methodology is primarily designed in support of On Line rapid application development either on mainframe or micro. The process is multitasking in that there is adequate information on the front end for a programming staff to begin the programming task by programmers before the documentation effort is complete. All steps in the mythology are supported by specialized forms. The utilization of these forms is supported by the CIMS, Computerized Idea Management System, as a result of the integration of micro software with mainframe needs, specifically in support of the SAVIC system.
For small projects forms may not be required where the intent of the forms are preserved on a few pages of documentation. In other words the thought process follows the same pattern.
The Structured Development Technique manual was accepted as a Standard of Excellence at American National Insurance Company. It was released to Serge Grant after a legal challenge as part of the SAVIC system. It was then transferred to ECM International Inc. Since it was originally developed at Hallmark Cards, it was also released by Hallmark as part of the SAVIC system to Serge Grant on request. The primary elements of the system are:
- FUNCTIONAL ANALYSIS
- SYSTEM ANALYSIS
- PROJECT ANALYSIS
- COMPUTING ANALYSIS
- APPLICATION ANALYSIS
- PROGRAM DESIGN
- PROGRAMMING
- TESTING
- PRODUCTION IMPLEMENTATION
- PERFORMANCE ANALYSIS
- SYSTEM MAINTENANCE
- ON LINE SUPPORT FACILITY
FUNCTIONAL ANALYSIS
- FUNCTIONAL DESCRIPTION
- DEVELOPMENT REQUIREMENTS
- DEVELOPMENT TEAM
- FUNCTIONAL PHASING
- PROBLEM/ENHANCEMENT
- SUGGESTED COMPUTER RELATED FUNCTION
- CORPORATE ADVANTAGE
- FEASIBILITY STATEMENT
The next item was the Development Requirements & Development Team are key primary documents. The development requirements include a list of all the SDT documents that will be necessary to complete this task. An X is placed in the items required column for all documents that are required. If user support is required it will be marked as such. If computing management overview is required,it will be marked as such. Finally when the document is complete, it will be marked as complete. The development team form lists the individuals that will participate in the effort. This establishes commitment of individual resources.
Functional Phasing is a critical form since it defines manageable project elements to be completed in phases. With the SAVIC method, it is not impractical to assume that phase 1 could be completed in the first couple of weeks. With the simulation capability in place and the documentation complete a rapid development process begins. Since some of the documentation is dependent on the user, the schedule must be committed to by both the computing department and the user department. While the system is just out of the starting blocks, the user will see progress at an early stage of the effort which builds confidence and cooperation between the departments.
Note that this may not be the case at the start of the utilization of the SAVIC system but as modules and program are built it becomes quite apparent that the same modules can be reused for new applications. This is the cognitive aspect of the SAVIC system. It assumes that most on line applications are similar in nature so building blocks can be reused with some modifications.
For complex systems a System Study is required. Because of the requirements imposed by
the user some aspects may require modifications and enhancements to the way computing
tasks are being performed so as to support the new system. A systems analyst would
develop a free form document detailing the requirements and how he or she envisions
the computing department response would be.
The system design is simply either a hardware configuration or a data flow configuration
but not a logic flow through a program. Logic flow through a program may or may not be
required depending on the programmers experience. Sometimes it takes more time to
develop the flow chart as it does to develop the code. Experienced programmers develop
the logic flow in the minds in a matter of seconds and proceed to code.
Each support person for this project will now be required to develop an
algorithm of tasks that he or she will be responsible in order to complete
this task. As the project progresses, this work sheet may be enhanced especially
if the staff member does not have experience in the process.
The project monitor and cost control document is one that the project manager completes. It is a schedule
that includes:
The COMMITTED SCHEDULE is a form that each of the staff members completes. It is
slightly different in that it permits breakdown of programming tasks for phasing.
If some of the items listed on the form do not apply, a NA for not applicable
is entered. On the other hand if a task is dependent on the completion of
a task listed then that persons name should be entered and the completion
target date obtained from the dependent staff member. Sometimes it is a good
idea to get this date initialized.
The schedule also includes the projected hours and cost to date. It is usually
updated once a week or at most once a month.
The I/O & MODULE FLOW CHART is in most cases a single page that shows terminals,
programs, databases, files, printers. It shows also the interface to networks
and batch cycle systems.
The ON LINE TRANSACTION REQUIREMENT form includes the on line transaction code
to activate the program, program name, support modules, database names
sensitivity and other pertinent information related to the program.
The BATCH JOB REQUIREMENTS may be needed in support of the On line development.
Usually the On line system feeds transactions to batch jobs rather than updating
directly. This provides for additional controls to the overall environment.
It includes the description of the process, recovery requirements, scheduling
and an algorithm of the programs that will be run in support of this task.
The DATA SET REQUIREMENTS include tape files, disk files, and dependent files.
The important item for tape files is retention. Disk files require estimated disk
space, and format. Dependent files simply require a qualifier as to whether
it is a (TO OR FROM) and dependent program name.
The DATABASE REQUIREMENT requires the database name and structure, segment names and
key names if primary. It also requires all the file names and other pertinent
information. The control module that access this database and makes all the
controls transparent to the application program must also be listed.
The HIERARCHICAL STRUCTURE of the database must also be provided. This is a graphic
description of the interrelationship of segments of a database starting with the
primary and possibly inter linking to other databases.
The PSB REQUIREMENT is a document that is prepared to support the setup of a
new database into the system. It provides for the database name and all the
segment names and a cross reference to a parent segment name. It must specify
all relevant information so as to be able to GEN that entry into the database
scheme.
The TERMINAL REQUIREMENTS specifies if there is a need for more terminals or
will current terminal use this application. Also which of the terminals will
be considered for use in simulation. In the early stages of development and
because on line menu code can be developed before the application program is
ready for it permits the user to start first evaluating the new system and
then start training them in that new system. Usually some suggestions are generated
by the user staff that results in changes and in the long run produces a better
system. This is achieved by the QPL language, Artificial Intelligence, and
database simulator facilities of the SAVIC system.
The DATA FORMAT forms provided are as follows:
The Edit form is free form in nature but each edit must have a full description. Edits on input fields are coded as request for edit in the virtual modules and the code resides in the application module.
The TABLES and VECTORS FORM also is free form for a description of any tables that may be
used in the program. It also must have a edit table where the edits of the previous
page are assigned a letter or number code. Each application program can have up to 36
different edits.
The PROGRAM STRUCTURE is a flow chart of the routines that make up a program and how
these routines will be organized within the program. This will be a work in progress
since it is unlikely that all the routines will be figured out at the start of the
programming effort.
The FUNCTIONAL WORK THRU is a description of a particular function that the program is
to perform. Some are simple and do not require walk thru's. On the other hand others
are not and should be described. The functional walk thru is write writing bullets
in a presentation. Each bullet is an activity that may be started by a user entering
a code and then proceeding within the program as to the steps necessary to accomplish
that function.
Once the about preparation is complete it will provide you an environment conducive
to program development. I wash shocked a few years back when I did a small contract
for NASA and found then using the same methods that I used 20 years ago. My support
facilities were so advanced to theirs that I had difficulty with the budgets
presented to NASA from this company. What they said would take months, I usually
completed in less than a week.
STRUCTURED PROGRAMMING is a requirement in any programming effort. In the cognitive
structure of programming, the system will be developed using various programming
languages depending on the level of the effort. System code will be done in
assembler, application control code can be performed in COBOL, and visual
formats and processing related to the terminal and printer would be done in
Virtual Code developed by ECM.
While the SDT method of development does not impose a lot of restraints to coding,
there are a few musts:
VIRTUAL PROGRAMMING is the heart of the SDT methodology. This permitted the rapid
deployment of systems which required a new mythology to support it. My intent at
both Hallmark and American National was not to divulge the method. Thus I made it
a point to develop all the virtual code. I do not intend to go into detail here
either, but I can say that as a project manager and system analyst who managed
all the on line development efforts and developed most of documentation, I also
developed over 250,000 lines of virtual code for over 1,000 virtual modules in
support of most of the corporate on line requirements. This the reason why
I was able to program on the average over 10 years 3,000 lines of code each month.
The reason for assigning this name to this approach is that IBM in their operating
system utilized a virtual swapping method in MVS based on statistical data. In our
method we use a logical swapping method within an application control program of
virtual modules the same size as was used by IBM.
Virtual programming is supported by a A VIRTUAL PROGRAMMING COMPILER that converts
the Quasi programming language into machine instructions that are inserted into
the virtual module and can be used immediately. A form is provided to support of
the Quasi programming language select to view
This approach reduces the development time by
Furthermore, the Quasi programming language has less that 15 instructions.
There is no logic involved in this code. It performs 5 functions. Display
headings to screen, display data to screen, process data from screen,
request edit of data, reformat data for verification, and print data to
a report.
A corporation could set up user analysts that work in the user area that
could do this programming task. This would take 30% of the workload
off the programmer whose primary concern is to develop support application
and system control programs that process these virtual modules.
If implemented outsourcing would be a thing
of the past. Of course a programmer could
handle both tasks and still save time and money for the corporation.
For platform support an Artificial Intelligence facility was developed as
part of the SAVIC system that generates highly professional displays in a
given software platform which require an MFS gen.
The first type of testing performed is UNIT TESTING. The unit testing is performed
as each element in the program synthesis is complete. A SUB SYSTEM test is performed
when a group of programs need to work together to achieve a particular result.
In a sub system test these programs are run to verify the expected results. A sub
system test should in most cases be performed at the end of each phase.
A PARALLEL TEST is performed whenever a new system replaces an old one. The total
new system is run in a limited production environment and the test results are
compared with the current system results. A parallel test is conducted as the Last
test before production implementation.
Once the system is in full operation the computing systems staff will check the performance.
It should match the results of the simulation test conducted early in the project life
cycle. Because of the impact simulator we never were surprised as the results when
the system hit production.
Work Orders come in for a change to the system. The MAINTENANCE SIGN OFF form is
basically blocks for entry, signature, date, staff responsible. It is divided into
two parts. A list of the tasks that need to be performed to complete the work order.
A list of impact points that needs to be tested as a result of the changes. Once the
system is implemented the user analyst again performs all the tests in a production
environment to make sure that everything was tested as was on the maintenance sign off form.
If it is a major change then all the staff involved should give their input as to what
should be included in the maintenance sign off form based on the user work order.
The second item as to the SDT mythology is that once a program is in production,
any change to the program as a result of system maintenance must include a comment
related to the description of the modification. The modification should have the
work order number as well as a letter code. When a change is made in the program, the
programmer should add the letter code to a comment section of the line being changed
as [a] if it was modification A. Note the use of the []. If you encounter a problem
you can then use the FIND command to check the change by modification code.
Usually the changes impact output. Output is fed into a reformatted and transforms
the data to records that can be processed by subsequent systems. If by chance a
change was implemented to soon and caused the distributive system to fail SAVIC
has a build it recovery facility. Case in point. A new manager came aboard who did
not know of the capability. I left for Houston on a business trip. I received a call
saying that the distributive system keeps failing and re starting and he wanted to
know what to do since he was called in by the computing operators. I simply told him
don't worry, once the recovery facility removes all the transactions that are causing
the problem the system will run to completion will all good data. And it did.
For this review we will use the SDT methodology. You will select option (D) Task Forms Management.
When you select it, it will first will ask you for the three or four letter acronym
for your project. Once entered that project profile will be loaded. If it is a new project
a new directory will be set up with the project acronym as the name of the directory and
all SDT forms will be loaded to it from the base system as well as all control files.
Thus the acronym for the project works the same way as the initials for an individual
when it comes to CREATIVE IDEA SUPPORT. You can work multiple projects on the same computer.
All you need to do is post the project acronym into the CIMS system.
Menu's can now be developed dynamically to support every aspect of the
documentation procedure that you are responsible for. The menu line items
refer to either another sub menu or a text document. This is the same as in the
CREATIVE IDEA SUPPORT facility. The free form word processing facility is utilized.
So as not to be repetitive in documentation, please review Setup of
creative idea system for the procedure of setting up menu's and text document access.
There is one distinct difference. In the Task Forms Management process, there are forms for each
aspect of the project life cycle to help developers formulate adequate and complete
documentation for a project.
Now we will proceed to describe the method of utilizing the CIMS system in support of the
SDT methodology for a software project. We will address only the unique features
as it relates to project setup and forms acquisition and processing.
When you first access the CIMS system, you will get the following display:
SYSTEM ANALYSIS
The development plan consists of three documents. The first simply states the
purpose, objective, and strategy for the project. The second document established
a schedule for all the tasks so that when they are completed the circle dots are
filled. The system milestones are listed as to the responsible group and phase of
development. When completed a date is entered.
PROJECT ANALYSIS
The user request is a series of bullets that start out with words like:
provide, modify, develop. They are provided by the user department as a translation
of the general requirements stated in the Functional Analysis as provided by the
Vice President of the department.
Now this is where the multi tasking takes place. The start date on any of these
tasks will overlap the completion dates. The program development phases are all
inclusive as well as the production implementation phases. Phases basically
include the following tasks:
COMPUTING ANALYSIS
First let me say that not all of these forms will be used for a specific project.
These forms are usually completed by the data base analyst in cooperation with
the project manager.
APPLICATION ANALYSIS
As we continue on in the development life cycle of a project, there is more and
more detail so that a three line statement by a department vice president results
in over 100 pages of documentation and 30,000 lines of code.
The Application analysis is the most detailed documentation that will be generated
and it is support by the most forms. They are:
The CONTROL form provides for the entry of control information to activate
the virtual module, control program. In the SAVIC system it requires you to enter a application program code, and function control parameters which are common across
different applications. Print control is usually a field on the screen which gives
you that option. In the control document all this is described.
This document not only
provides for the support of the programming effort but can be used in the
training process. It also is designed to describe any special processes and
functions that the application performs.
PROGRAM DESIGN
The PROGRAM SYNTHESIS is a pyramid style form that is to be filled out for each phase
of the project. The reason for the pyramid method is that as we proceed through the
phase, there are more tasks to perform. As the pyramid gets larger you will be able
to enter concurrent tasks that need to be completed. As you progress through the
phases these will be routines that need to be developed in support of the process.
Although it is all inclusive since it may include special tasks, documentation,
and testing depending on the scope of the individual's effort. The primary goal
is entering the phrase for each routine that is to be developed in their respective
program.
PROGRAMMING
Of course the PROGRAMMING SUPPORT FACILITIES does not have a form associated with
this element in the Structured Development Technique. Rather it is how you prepare
for the development of the programming effort. Now the process is different for
mainframe and micro software development. One needs to preset an environment so that
all the programs to be worked on are at your fingertips. A system such as C~GATES
would provide such an environment. C~GATES provides the capability of setting up
menu's dynamically that would include a list of all the programs that would be
developed, a test environment, a test data setup facility, a test database setup
facility, a selective printout of errors and sub routines if the printout is
routed from the mainframe. A test option of running in foreground or background
for fast response to the checkout process.
TESTING
This section does not have any support documents although the project management
section has the Project Schedule which includes the TESTING entry. Once successful,
you would make an entry in it.
PRODUCTION IMPLEMENTATION
STRUCTURED DEVELOPMENT SIGN OFF by the user department vice president. His staff reviews
the test results and signs the production acceptance line in the structured development
sign off form. The system is now ready for SYSTEM INTEGRATION. This will require an
integration list of elements to be transferred into the production library. Once
transferred the system is ready for use. PROJECT FINALIZATION is usually in the form
of a party when the system is finalized by a toast.
PERFORMANCE ANALYSIS
Performance Analysis is not supported by any new document although a sign off is
required on the structured development sign off form by the computing section
manager. Now the SAVIC system the performance analysis is not the last element
of the mythology alone. Performance analysis is conducted at the start of the
project by a simulation feature of SAVIC. When the user department provides
information about the use of the system, the impact simulator can be loaded with
controls that will trigger bogus transactions similar to the new application.
The system staff will notice a spike in the activity for a day. If the performance
analysis shows no degradation in performance then we can assume that there will
not be any problem with the production implementation.
SYSTEM MAINTENANCE
Once the system is in production, users always come up with enhancements to the system.
Once in a while the find problems with the system that was not caught in the test
phase. Due to the cognitive software structure care must be undertaken in the
modification of any code. If there is a flaw in the mythology and software design
it is here.
SETUP PROCESS FOR TASK FORMS MANAGEMENT FACILITY
The CIMS software system designed for the micro computer in support of CREATIVE
IDEA MANAGEMENT is an excellent tool to use to document projects. It is perfectly
suited to support a major documentation effort. To show an example of this the
system is pre loaded with the SDT methodology. You can utilize it or set up your own.
Just replace the menus with your won requirements and set up the forms necessary
to support it using the forms builder in the word processing facility. Full
details are described in the On Line Documentation facility.
So now we will return to the primary project menu by pressing the ESC key.
We will want to change the header to FUNCTIONAL ANALYSIS SUPPORT MENU and add four lines accessing the following documents:
- FUNCTIONAL DESCRIPTION BY THE USER
- FUNCTIONAL PHASES BY THE PROJECT MANAGER
- DEVELOPMENT TEAM BY THE SECTION MANAGER
- DOCUMENTATION REQUIREMENTS BY THE PROJECT MANAGER
- FREE FORM WORD PROCESSOR
- PARAGRAPHIC WORD PROCESSOR
- FORMS WORD PROCESSOR
The DELETE and INSERT keys are not active. If you try to override a boarder the program will BEEP and not permit you to do so. If you need to get to a field in the form simply press the tab key. All forms are pre tabbed. If the specs require extensive detail we suggest you use the regular free form word processing facility and attach it to a form as page 1.
That concludes the graphic documentation for the Task Forms Management Facility. The presentation is not all inclusive but clearly shows the benefit of such a program.