🏠 Back to Exam Syllabus 📺 RooCloud on YouTube 🌐 RooCloud Practice Exams

System Development Methodologies (Part 1 of 2)

This episode of the ISACA Certified Information Systems Auditor (CISA) exam prep series introduces the structure behind how IT systems get built, covering the purpose of development methodologies, the main life cycle models available, and what happens in each phase of the system development life cycle. Knowing these phases tells an auditor where controls should exist and which deliverables to expect at each step.

What this episode covers

Watch the full episode above for the worked examples and detailed explanations of each concept.

Frequently Asked Questions

What are the three main system development life cycle models and their trade-offs?

The waterfall model is sequential and works best when requirements are stable, but it struggles with unexpected changes and delays user feedback. The V-shaped model pairs each development phase with a matching test level, boosting assurance but becoming rigid on complex projects. The iterative model cycles through phases repeatedly to improve the product and deliver features early, which suits large projects but demands more project management and can blur the final completion date.

What are the six phases of the system development life cycle?

The six phases are feasibility, requirements, then either selection or design depending on whether you buy or build, followed by configuration or development, testing and implementation, and finally postimplementation. If the organization buys a packaged system it selects and configures; if it builds in-house it designs and develops.

What is software baselining and why is it a critical control?

Software baselining is the design freeze, the cutoff point after which any change requires formal approval and impact analysis. It is the main defense against scope creep and it also triggers formal configuration management with version control. Without it, undisciplined changes accumulate and erode both quality and auditability.

Why must security and privacy requirements be captured in the requirements phase?

Identifying security and privacy needs early is far cheaper than retrofitting them after the system is built. The requirements phase is the point where stakeholders are consulted and conflicts resolved, making it the best opportunity to embed controls before the design is locked. Missing these requirements here typically means discovering the gap in testing or, worse, in production.

📚 Master the ISACA CISA Exam!

Ready to test your knowledge? Access chapter-specific Multiple Choice Questions (MCQs) and full-length practice exams for the ISACA CISA certification at RooCloud.com. Solve the chapter-wise questions to reinforce this lesson before moving to the next episode.


Reference: This article is based on concepts discussed in System Development Methodologies (Part 1 of 2).