Acquisition, Development and Implementation · Topic 2 of 4
Development Methodologies and Control Design
Waterfall, agile, prototyping, RAD and DevOps, build versus buy, and input, processing and output controls such as edit checks and control totals.
- 4 min
- Waterfall suits stable requirements; agile suits changing ones.
- Build controls into requirements and design, including in agile backlogs.
- Input, processing and output controls each protect a stage.
What it is
A system development methodology is the structured way a team turns requirements into working software, whether it builds the system or buys and configures a package. Control identification and design makes sure the system includes the checks it needs, such as validation of input, accurate processing and controlled output, from the start.
How it works
Methodologies
| Method | How it works | Fits when | Watch for |
|---|---|---|---|
| Waterfall (traditional SDLC) | Sequential phases, each signed off before the next | Requirements are stable and well understood | Late discovery of problems; costly changes |
| Agile (for example Scrum) | Short iterations (sprints) delivering working increments, with close user involvement | Requirements evolve | Thin documentation, controls left out of the backlog |
| Prototyping | Builds quick models for users to react to | Requirements are unclear | A prototype pushed into production without controls |
| Rapid application development (RAD) | Fast delivery with prototypes, workshops and reusable components | Time pressure | Weak design discipline |
| DevOps and DevSecOps | Development and operations work together with automated build, test and deployment pipelines | Frequent releases | Segregation of duties and change approval in the automated pipeline |
In agile work, security and control requirements should be written as backlog items with acceptance criteria, so they are delivered like any other feature.
Build or buy
For a purchased package, the life cycle shifts: requirements lead to a request for proposal (RFP), vendors are evaluated against weighted criteria, and the package is configured rather than coded. Customizing the package heavily raises cost and makes upgrades harder. The auditor checks that requirements, including controls, drove the selection and that the contract protects the organization.
Application controls
| Stage | Controls | Examples |
|---|---|---|
| Input | Ensure only valid, complete, authorized data enters | Edit checks, authorization, batch controls |
| Processing | Ensure data is processed completely and accurately | Run-to-run totals, reconciliation, error handling |
| Output | Ensure output is complete, accurate and reaches the right people | Distribution controls, report balancing |
Common edit checks
| Check | What it does |
|---|---|
| Validity check | Value is one of the allowed values (for example a valid department code) |
| Range check | Value falls between limits |
| Limit check | Value does not exceed a maximum |
| Reasonableness check | Value is sensible compared with expectations |
| Check digit | A calculated digit detects transcription errors in numbers such as account IDs |
| Completeness check | Required fields are filled |
| Sequence check | Numbers follow in order, revealing gaps or duplicates |
| Duplicate check | The same transaction is not entered twice |
Batch and processing totals
| Total | Use |
|---|---|
| Record count | Number of items in a batch |
| Control total | Sum of a meaningful field, such as amounts |
| Hash total | Sum of a field with no meaning in itself, such as account numbers, to detect changed or missing items |
| Run-to-run total | Carries totals from one processing step to the next to show nothing was lost |
A check digit catches transposed digits in a number; it does not prove the transaction is authorized or reasonable.
How the exam asks about this
- "Requirements are expected to change often." Agile or iterative development.
- "Which control BEST detects a transposed account number?" A check digit.
- "In a DevOps pipeline, how is segregation of duties kept?" Automated tests and approval gates, with no single person able to push unreviewed code to production.
What to remember for the exam
- Waterfall suits stable requirements; agile suits changing ones.
- Build controls into requirements and design, including in agile backlogs.
- Input, processing and output controls each protect a stage.
- Know validity, range, limit, reasonableness, check digit, sequence and duplicate checks.
- Hash totals have no meaning except as a control.
A prototype that users like is not production-ready. Moving it live without controls, testing and documentation is a common finding.
Common mistakes
Assuming agile means no documentation or controls.
Heavily customizing a purchased package. It increases cost and upgrade risk.
Confusing control totals and hash totals. A hash total sums a meaningless field.
Check yourself
Which development method suits requirements that are expected to change?
Agile or another iterative method.
What does a run-to-run total show?
That no data was lost or added between processing steps.
What is a hash total?
The sum of a field with no meaning in itself, used only to detect changed or missing items.
Topic 2 of 4 in Acquisition, Development and Implementation
Test yourself on Acquisition, Development and Implementation
The full ISACA CISA question bank has 1,050 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.