decision systems, inc.

grade_of_membership_pure_type
Jackson Systems Development DSIGOM Beta v. 1.01
What is GOM?
order
faqs
technical support
Jackson System Development
HOME


Modeling | Network | Implementation | Projects and Plans


Jackson System Development
Overview


Jackson System Development (JSD) is a method of system development that covers the software life cycle either directly or, by providing a framework into which more specialized techniques can fit. Jackson System Development can start from the stage in a project when there is only a general statement of requirements. However, many projects that have used Jackson System Development actually started slightly later in the life cycle, doing the first steps largely from existing documents rather than directly with the users. The later steps of JSD produce the code of the final system. Jackson’s first method, Jackson Structured Programming (JSP), is used to produce the final code. The output of the earlier steps of JSD are a set of program design problems, the design of which is the subject matter of JSP. Maintenance is also addressed by reworking whichever of the earlier steps are appropriate.

From the technical point of view there are three major stages in Jackson System Development, each divided into steps and sub-steps. From a manager's point of view there are a number of ways of organizing this technical work. In this overview we first describe the three major technical stages and then discuss JSD project planning, the variation between plans, and the reasons for choosing one rather than another.

JSD: The Modeling Stage

In the modeling stage the developers make a description of the aspects of the business or organization that the system will be concerned with. To make this a description they must analyze their business, choosing what is relevant and ignoring what is not. They have to consider the organization as it will be, not as it is now.

The model description is written very precisely. This precision forces the developer to ask detailed questions. It encourages good communication and understanding between developers, users, and everyone else involved with the new system.

The model description consists of actions, entities and related information. An action is an event, usually in the external reality, that is relevant to the system and whose occurrence the system must record. In implementation terms, actions might cause database updates. We start Jackson System Development by making a list of actions with definitions and associated attributes. Diagrams describe ordering relationships between actions. The diagrams describe the entities, people or, things that the system is concerned with.

The data that is to be stored for each entity is then defined. In effect we are choosing what is to be remembered by each entity about the actions that affect it. The full definition of this data includes an elaboration of the entity diagram to show in detail the update rules.

The result of the modeling stage is a set of tables, definitions and diagrams that describe:

JSD: The Network Stage

In the network stage we build up a precise description of what the system has to do, including the outputs that are to be produced and the way the system is to appear to the user. This description is in terms of a network of programs. More precisely, it is a network of Communicating Sequential Processes (CSP), a concept developed by Tony Haoare. We start this network by making one program for each of the entities that was defined during the modeling stage. The network is then built up incrementally by adding new programs and connecting them up to the existing network. New programs are added for the following reasons:

There are two means of connecting programs in the network. These are by data streams (represented on our network diagram of circles) and by state vector inspection (represented on our network diagrams by diamonds). Whatever kind of connection is appropriate, the entity programs play a pivotal role in the construction of the network. Most of the new programs can be connected directly to the entity programs.

We draw a whole set of network diagrams to describe the system. Different networks usually only have entity programs in common. The complete system is represented by the overlay of all the diagrams.

The diagrams are supported by textual information describing the contents of the data streams and state vector connections. The new programs that are added to the network are defined using the same diagrammatic notation used to describe the ordering of actions. These new programs are designed using the JSP (Jackson Structured Programming) method, which is now a subset of JSD.

JSD: The Implementation Stage

The result of the implementation stage is the final system. This stage is the only one directly concerned with the machine and the associated software on which the system is to run. Therefore, as well as producing and testing code, the implementation stage covers physical design issues. In particular it covers:

Physical data design is about the design of files or databases. The details of database design depend on the particular DBMS being used. However, the necessary information about the application is all available from the network stage. The most important is the data defined for each entity and the high volume accessing of that data as defined by the frequently used state vector connections.

The result of the network stage is a highly distributed network of programs. Often, for convenience or efficiency, we convert programs into subroutines, in effect combining several programs into one, so that a fragment of the network is implemented as a single program. The network is reconfigured from a form appropriate for specification into a form appropriate for implementation.

JSD: Projects and Plans

We have presented the three stages of JSD as a simple linear progression. On a project, however, the stages overlap to a greater or lesser degree, and not just because people make mistakes that have to be corrected later. The stages and substages are nevertheless important because they classify and organize the technical work, they clarify the choices open to a project manager, and illuminate the risks when a decision has to be taken out of order.

The following are some examples of the overlap of the stages:

None of these overlappings is compulsory. A set of circumstances exists that makes each sensible. A project plan is made based on the technical framework of JSD and on the political and organizational circumstances of the project.

This article is translated to Serbo-Croatian language by Anja Skrba from Webhostinggeeks.com.





top of page