Jackson Structured Programming JSP is a program design methodology, overview and timeline

Jackson Structured Programming (JSP) is a program design methodology developed by British software consultant Michael A. Jackson in the 1970s. It focuses on mapping the structure of a problem—specifically its data structures—directly onto the structure of the program used to solve it.

Overview of Jackson Structured Programming

JSP is designed to create programs that are easy to maintain and modify because the program’s control structure naturally handles the input and output data structures.

Core Principle: Requirement changes are typically minor tweaks to existing data structures. By aligning program structure with data structure, small changes to inputs or outputs translate into small, manageable changes in the code.
Methodology: The technique involves analyzing the structure of input files and output files, constructing diagrammatic representations of these, and then creating a program structure that handles both.
Key Constructs: JSP utilizes three basic structures for both data and programs, which can be visualized as a form of regular expression:
- Sequence: A series of operations performed in order.
- Iteration: The repetition of operations until a specific condition is met.
- Selection: Choosing between different operations based on a condition.
Diagrams: JSP uses structure diagrams rather than flowcharts to represent the design, breaking down complex tasks into smaller, simpler parts.

Excerpts from my HND project which made use of Jackson Structured Programming (JSP) as part of the program design phase

Detailed Historical Timeline

Early Years (1960s–1974): Conceptualization and Founding

1960s: Michael A. Jackson works in data processing, encountering limitations in program reliability and seeking more systematic approaches to software design.
1968: Jackson contributes to the early modular programming movement, collaborating with other pioneers.
1970: Jackson leaves John Hoskyns & Company to found Michael Jackson Systems Limited, aimed at fully developing a new design methodology.
1971: JSP becomes the core product of Michael Jackson Systems Limited, offering consultancy and training services.
1974: The name “Jackson Structured Programming” is coined by a Swedish licensee of the company.

Established Method (1975–1979): Documentation and Adoption

1975: Jackson publishes “Principles of Program Design,” the definitive text documenting JSP.
1975: Michael Jackson Systems Ltd. begins offering software tools to support JSP design for COBOL programs.
1977: JSP is widely recognized and adopted in Europe, the US, and Asia.
Late 1970s: The UK government adopts JSP (under the name “SDM” – System Development Methodology) as its standard program design method.
Late 1970s: The World Health Organization adopts JSP as a standard for program specification.

Evolution into System Design (1980s): JSD

Early 1980s: Building on the principles of JSP, Jackson develops Jackson System Development (JSD) to address the design of entire information systems, not just individual programs.
1983: Jackson publishes “System Development,” formally introducing JSD.
1983-1989: JSD continues to evolve, with new features introduced in subsequent publications and manuals.

Maturity and Retrospective (1990s–Present)

1990s: Jackson develops the Problem Frames Approach, his third major methodology focusing on requirements analysis.
1997: Jackson receives the Stevens Award for Software Development Methods.
1998: Jackson receives the British Computer Society Lovelace Medal.
2001: At a conference, Jackson provides a retrospective analysis of JSP’s driving forces and its relevance to modern software engineering.
Present: While overshadowed by object-oriented and agile methods, JSP principles remain useful for programming “in the small” and handling specific batch processing or embedded software tasks.

Jackson Structured Programming JSP is a program design methodology, overview and timeline

Agile Framework Methodology Key Criteria for Selecting

Waterfall project management is a linear, sequential methodology

Waterfall project management is a linear, sequential methodology where progress flows steadily downward through defined phases, much like a physical waterfall. In this model, each stage—such as requirements, design, implementation, and testing—must be fully completed and approved before the next one begins.

Waterfall Project Plans, .xls and .mpp file formats respectively

Core Characteristics

Sequential Design: No overlapping phases; each “cascades” into the next.
Documentation-Driven: Extensive upfront planning and detailed records are required at every step.
Fixed Scope: Requirements are gathered at the start, making the project’s timeline and budget highly predictable but difficult to change.
Specialised Use: Best suited for regulated industries like aerospace, construction, and healthcare, where changes are costly or safety is paramount.

Historical Timeline by Era and Year

The following timeline tracks Waterfall from its origins in post-WWII engineering to its current role in hybrid project management.

Examples, Waterfall Plan On a Page POaP in MS PowerPoint format

The Pre-Formal Era (1950s – 1969)

Software development adopted structured, sequential approaches from engineering, largely driven by complex, high-risk projects.

1956: Herbert D. Benington documented a sequential process for the SAGE project, establishing the technical roots.
Late 1960s: NASA applied linear, rigid methodologies to Apollo missions, setting a precedent for high-stakes, documentation-heavy development.
1968: The NATO Software Engineering Conference highlighted the “software crisis,” prompting a push for formal, disciplined development models.

The Formalisation Era (1970 – 1979)

The model was officially, yet ironically, described and named.

1970: Dr. Winston W. Royce published his foundational paper on managing large software systems, often cited as the origin of the “Waterfall” model, though he originally presented it as a cautionary, flawed approach.
1976: T.E. Bell and T.A. Thayer likely first used the term “Waterfall” in literature.

The Institutional Era (1980 – 1999)

Waterfall became the mandatory standard for large-scale, complex projects.

1985: The U.S. DoD mandated DOD-STD-2167, cementing Waterfall as the standard for military software.
1989: The UK Government introduced PRINCE2, deeply influenced by Waterfall principles.
1994: The U.S. DoD formally abandoned strict Waterfall mandates for more flexible methods.

The Modern & Hybrid Era (2000 – Present)

Waterfall transitioned from the default standard to a specialised methodology.

2001: The Agile Manifesto marked a shift toward iterative development, reducing Waterfall’s dominance.
Present Day: It remains vital in regulated sectors (e.g., aerospace) and is often combined with Agile in hybrid approaches.

Waterfall project management is a linear, sequential methodology

Click on the link in the website banner above to purchase example, editable template project plans shown and many others.

Agile Scrum Methodology Summary Breakdown Overview

Scrum is a lightweight framework within the broader Agile methodology used to manage complex work through iterative, incremental delivery. It organizes work into fixed-length cycles called sprints, typically lasting two to four weeks, to deliver a usable “increment” of value at the end of each cycle.

Core Components (The 3-5-3 Structure)

The framework is built around three accountabilities, five events, and three artifacts.

1. Three Accountabilities (Roles)

Product Owner: Represents the customer and stakeholders. They manage the Product Backlog and prioritize work to maximize the value delivered by the team.
Scrum Master: A servant leader who coaches the team on Scrum theory and removes impediments that block progress.
Developers: A cross-functional, self-managing team that does the actual work to create the product increment.

2. Five Events (Ceremonies)

The Sprint: The container for all other events; a time-boxed period where work is performed.
Sprint Planning: The team defines what will be delivered in the sprint and how the work will be achieved.
Daily Scrum: A 15-minute daily check-in for developers to synchronize progress and plan the next 24 hours.
Sprint Review: Held at the end of the sprint to inspect the outcome with stakeholders and adapt the Product Backlog.
Sprint Retrospective: An internal team meeting to reflect on the process and identify improvements for the next sprint.

3. Three Artifacts

Product Backlog: An ordered, evolving list of everything needed for the product.
Sprint Backlog: The subset of product backlog items selected for the current sprint, plus a plan for delivering them.
Increment: The concrete sum of all completed backlog items that meet the Definition of Done.

The Three Pillars of Empiricism

Scrum is founded on empirical process control, which relies on:

Transparency: The process and work must be visible to everyone involved.
Inspection: Frequent checks of artifacts and progress to detect variances.
Adaptation: Adjusting the process or product if an inspection reveals unacceptable deviations.

Key Values

Success with Scrum depends on the team’s commitment to five core values: Commitment, Courage, Focus, Openness, and Respect.

Agile Scrum Methodology Summary Breakdown Overview