Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
RAD, CASE, Low-Code
Building faster
A flat-pack wardrobe goes up far faster than one a carpenter builds from raw timber. But skip the instructions and the wall bracket, and it still falls over.
This article covers several ways to build software faster. They differ in how, but they share one rule the exam keeps coming back to: whatever the tool, the same SDLC controls apply: requirements, testing, change control, access control and documentation.
Rapid application development (RAD)
RAD aims to deliver a working system quickly, through:
- intensive user involvement in workshops
- iterative prototyping
- small, skilled teams
- timeboxing: the delivery date is fixed, and scope is adjusted to fit
- automated tools and reusable components
Benefits: speed, a close fit to what users need, early value.
Risks: controls, security and documentation get sacrificed for speed; poor scalability and integration; scope creep; systems that are hard to maintain later. RAD suits applications with a clear business owner and moderate complexity, not large or safety-critical systems.
CASE tools
Computer-aided software engineering (CASE) tools are software that helps build software:
| Type | Helps with |
|---|---|
| Upper CASE | Requirements and design: data models, process models |
| Lower CASE | Code generation, test data generation, debugging |
| Integrated CASE | Both, keeping models and code in sync |
They improve consistency and productivity. But they automate whatever has been specified, errors included. Generated code still needs review and testing.
4GLs and low-code platforms
Fourth-generation languages (4GLs) are high-level languages where you describe what you want rather than how to do it: report generators, query languages, application generators. Low-code and no-code platforms are the modern version, letting business users build workflow and data apps by dragging and dropping.
That’s powerful, and risky. The control concerns:
- apps built outside IT’s SDLC (shadow IT, end-user computing)
- missing access controls, audit trails and input validation
- no separation between development and production
- sensitive data connected without classification or approval
- no inventory of what apps exist or who owns them
Example. A finance analyst builds a supplier onboarding app on a low-code platform, connected directly to the ERP vendor table. Anyone in finance can create suppliers, with no approval step. The auditor finds the app only because vendor creation volumes spiked, not because IT knew it existed.
The answer isn’t to ban the platform, but to govern it:
Object-oriented and component-based development
- Object-oriented development models the system as objects that bundle data and behaviour together (encapsulation), using inheritance and polymorphism. It promotes reuse and easier maintenance.
- Component-based development assembles systems from reusable components, often from third parties, a bit like building with LEGO.
Reused components still need to be trusted, tested and kept patched.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Main risk of RAD | Controls and documentation sacrificed for speed |
| Tool type that generates code from designs | Lower CASE |
| Main risk of low-code platforms | Applications built outside SDLC controls (shadow IT) |
| Benefit of object-oriented development | Reuse and easier maintenance |
| Does tool-generated code need testing? | Yes |
In short
- Rapid application development (RAD) delivers quickly using prototyping, timeboxes, small teams and heavy user involvement.
- RAD's risks: controls and documentation sacrificed for speed, and weak scalability or integration.
- CASE tools automate parts of the SDLC: upper CASE for requirements and design, lower CASE for code generation, integrated CASE for both.
- Low-code and no-code platforms let business users build applications, raising end-user computing and shadow IT risks.
- Object-oriented development uses encapsulated objects and reuse; component-based development assembles reusable components.
- Whatever the tool, the same SDLC controls apply: requirements, testing, change control, access and documentation.
Exam traps
- CASE tools don't guarantee quality; they automate what's been specified, including errors.
- Low-code apps built by business users often skip security, testing and change control.
- RAD suits systems with clear business owners and modest complexity, not large safety-critical systems.
- Code generated by tools still needs review and testing.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Building faster
A flat-pack wardrobe goes up much faster than one a carpenter builds from raw timber. But if you skip the instructions and the wall bracket, it still falls over.
RAD, CASE tools, low-code platforms and reusable components are all ways to build software faster. Every one of them still needs requirements, testing, change control, access control and documentation.
Governing low-code