Jackson System Development (JSD) is a linear software development methodology developed by Michael A. Jackson and John Cameron in the 1980s.
JSD was first presented by Michael A. Jackson in 1982, in a paper called "A System Development Method".[1] and in 1983 in System Development.[2] 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.
JSD continued to evolve, and a few new features were introduced into the method. These are described in a 1989 collection of papers by John Cameron, JSP and JSD,[3] and in the 1992 version (version 2) of the LBMS JSD manual.[4]
Development of the JSD method came to an end in the early 1990s as Jackson's thinking evolved into the Problem Frames Approach with the publication of Software Requirements and Specifications (1995) and Problem Frames: Analyzing and Structuring Software Development Problems (2000).
Three basic principles of operation of JSD is that:
When it was originally presented by Jackson in 1982,[1] the method consisted of six steps:
Later, some steps were combined to create a method with only three steps.[5]
In the modeling stage the designer creates a collection of entity structure diagrams and identifies the entities in the system, the actions they perform, the time-ordering of the actions in the life of the entities, and the attributes of the actions and entities. Entity structure diagrams use the diagramming notation of Jackson Structured Programming structure diagrams. Purpose of these diagrams is to create a full description of the aspects of the system and the organisation. Developers have to decide which things are important and which are not. Good communication between developers and users of the new system is very important.
This stage is the combination of the former entity/action step and the entity structures step.
In the network stage a model of the system as a whole is developed and represented as a system specification diagram (SSD) (also known as a network diagram). Network diagrams show processes (rectangles) and how they communicate with each other, either via state vector connections (diamonds) or via datastream connections (circles). In this stage, the functionality of the system is defined. Each entity becomes a process or program in the network diagram. External programs are later added to the network diagrams. The purpose of these programs is to process input, calculate output and to keep the entity processes up-to-date. The whole system is described with these network diagrams and are completed with descriptions about the data and connections between the processes and programs.
The initial model step specifies a simulation of the real world. The function step adds to this simulation the further executable operations and processes needed to produce output of the system. System timing step provides synchronisation among processes, introduces constraints. This stage is the combination of the former ‘Initial model’ step, the ‘function’ step and the ‘system timing’ step.
In the implementation stage the abstract network model of the solution is converted into a physical system, represented as a system implementation diagram (SID). The SID shows the system as a scheduler process that calls modules that implement the processes. Datastreams are represented as calls to inverted processes. Database symbols represent collections of entity state-vectors, and there are special symbols for file buffers (which must be implemented when processes are scheduled to run at different time intervals).
The central concern of implementation step is optimization of the system. It is necessary to reduce the number of processes because it is impossible to provide each process that is contained in specification with its own virtual processor. By means of transformation, processes are combined in order to limit their number to the number of processors.
Normally there would be only one action underneath a RecurringConstruct.
The difference between a state vector connection and a data stream connection lies in which process is active. In a datastream connection, the process with the information, A, is the active process; it actively sends a message to the datastream reader B at a time that it (A, the sender) chooses. In a state vector inspection, the process with the information, A, is passive; it does nothing but let the reader process B inspect its (A's) state vector. B, the process doing the inspection, is the active process; it decides when it will read information from A. Roughly speaking, datastream connection is an abstraction of message passing, while state vector inspection is an abstraction for polling (and for database retrieval).