Software Development Lifecycle Fundamentals

Introduction

Software rarely succeeds because of code alone. Successful software products emerge from coordinated activities that transform a business or social need into a usable, secure, maintainable and valuable system. These activities include understanding requirements, designing a solution, building and integrating components, testing, deploying, operating and improving the product. The organised framework used to manage these activities is the Software Development Lifecycle (SDLC).

For DevOps practitioners, SDLC knowledge is foundational. DevOps does not replace the SDLC; it changes how lifecycle activities are coordinated. It encourages collaboration between development, operations, security, quality assurance and business stakeholders, while promoting automation, rapid feedback, traceability and continuous improvement.

An SDLC model is not simply a diagram or a fixed sequence of tasks. It is a management and engineering approach that defines how work is planned, authorised, performed, reviewed and improved. Selecting an appropriate model depends on factors such as requirements volatility, risk, regulatory obligations, technical uncertainty, delivery urgency, team capability and the cost of failure.

Learning Objectives

By the end of this chapter, you should be able to:

• explain the purpose and major stages of an SDLC;
• identify key stakeholders, deliverables, controls and decision points;
• distinguish verification from validation and relate both to lifecycle activities;
• compare Waterfall, V-Model, iterative, incremental, Spiral, Agile and hybrid models;
• select a lifecycle approach for a given project context;
• explain how DevOps practices extend lifecycle feedback and accountability;
• evaluate lifecycle limitations, governance concerns and ethical responsibilities.

1. The Meaning and Purpose of the SDLC

The SDLC is a structured set of activities used to plan, create, assess, release, operate and retire software. It provides a common language for technical and non-technical participants. Without a lifecycle, organisations may begin construction before understanding the problem, release untested changes, lose decision records or discover essential constraints too late.

The SDLC has several purposes:

1. Coordination: It clarifies who performs work and when.
2. Quality assurance: It creates opportunities to detect defects and omissions.
3. Risk management: It makes uncertainty, dependencies and failure consequences visible.
4. Governance: It provides evidence that decisions, approvals and controls were applied.
5. Prediction and planning: It supports estimates, budgets, schedules and resource allocation.
6. Learning: It creates feedback loops through reviews, testing, monitoring and retrospectives.

A lifecycle should not be confused with a project schedule. A schedule specifies dates and tasks for a particular project; a lifecycle defines the logic and control structure by which software work is performed. Similarly, a methodology may prescribe roles, practices and artefacts, while a lifecycle model describes the broad pattern of progression and feedback.

Important terminology

• Product: The software system and associated services, documentation, data and operational capabilities.
• Project: A temporary effort undertaken to create or change a product.
• Process: A defined set of activities and controls used to achieve an outcome.
• Lifecycle model: A representation of how lifecycle activities are sequenced, repeated or overlapped.
• Baseline: An approved version of a requirement, design, code or other item that can change only through controlled change management.
• Milestone: A significant decision or completion point.
• Gate: A formal review at which continuation, modification or termination is decided.
• Traceability: The ability to relate requirements to design elements, code, tests, releases and operational evidence.
• Technical debt: The future cost created by choosing a quick or inadequate technical solution instead of a more sustainable one.

2. Core SDLC Stages

Different organisations use different names and may combine or divide stages. The following stages represent a complete conceptual lifecycle rather than a rigid sequence.

2.1 Initiation and feasibility

The lifecycle begins when a problem, opportunity, legal obligation or strategic objective is identified. Stakeholders clarify the proposed product, expected benefits, affected users, constraints and initial risks.

A feasibility assessment commonly considers:

• Technical feasibility: Can the required capabilities be built and operated with available technology and skills?
• Economic feasibility: Are expected benefits sufficient in relation to development and operating costs?
• Operational feasibility: Can users and support teams adopt and sustain the solution?
• Legal and regulatory feasibility: Are privacy, accessibility, licensing, safety and sector requirements manageable?
• Schedule feasibility: Can the solution be delivered within the required time?

Typical deliverables include a problem statement, business case, stakeholder register, initial risk register, feasibility report and project charter. A major control is the authorisation decision: the organisation should not commit substantial resources without an explicit understanding of purpose, constraints and authority.

2.2 Requirements analysis

Requirements describe what the system must provide and the conditions under which it must operate. Functional requirements specify behaviours or services; non-functional requirements specify qualities and constraints such as performance, security, usability, availability, accessibility, auditability and maintainability.

Requirements work includes elicitation, analysis, prioritisation, documentation, validation and change control. Techniques include interviews, workshops, observation, document analysis, prototypes, scenarios and user stories.

A good requirement is sufficiently clear, necessary, feasible, testable and traceable. Ambiguous requirements create disputes and make testing subjective. For example, “the system must be fast” is weak. “The system shall display the account summary within two seconds for 95% of requests under the agreed workload” is more testable, although the workload and measurement method must also be defined.

Deliverables may include a requirements specification, product backlog, acceptance criteria, data requirements, process models and a traceability matrix. Controls include stakeholder approval, prioritisation rules, version control, requirements reviews and formal or lightweight change management.

2.3 Architecture and design

Design transforms requirements into a technical and interaction model. It may address system architecture, components, interfaces, data structures, algorithms, user experience, infrastructure, security controls and deployment topology.

Architectural decisions should consider both immediate functionality and long-term operation. Important questions include:

• Where is state stored and how is it protected?
• How do components communicate and fail safely?
• How will the system scale and be monitored?
• How are identity, access and secrets managed?
• How can components be tested and changed independently?
• What are the recovery, backup and continuity requirements?

Design deliverables include architecture decision records, models, interface specifications, database schemas, prototypes, threat models and deployment designs. Reviews and threat modelling are important controls because design errors can be expensive or impossible to correct safely after deployment.

2.4 Implementation and integration

Implementation converts approved design into source code, configuration, infrastructure definitions, tests and documentation. Professional implementation involves coding standards, peer review, dependency management, secure development practices, branching or integration policies and reproducible builds.

Integration combines components and exposes incompatibilities in interfaces, assumptions, data formats and environment configuration. Continuous integration encourages frequent merging and automated validation. Build artefacts should be versioned and identifiable so that an organisation can determine what was built, from which source, with which dependencies and under what process.

Deliverables include source code, configuration, executable artefacts, unit tests, build scripts and updated documentation. Controls include protected repositories, review policies, automated checks, dependency scanning, segregation of duties where appropriate and access management.

2.5 Verification and validation

Verification asks, “Did we build the product correctly according to specified requirements and design?” It includes reviews, static analysis, unit testing, integration testing and configuration checks.

Validation asks, “Did we build the right product for its users and intended purpose?” It includes acceptance testing, usability evaluation, operational trials and stakeholder feedback.

Testing is not a single event at the end. Testing levels may include:

• unit testing of small components;
• component and integration testing;
• system testing of the complete product;
• security, performance, accessibility and resilience testing;
• user acceptance testing;
• regression testing after change.

Testing provides evidence, not an absolute proof that software has no defects. Test results depend on coverage, environment, data, oracle quality and the behaviours selected for examination. A quality control process should also consider defects found in production, escaped defects, unresolved risks and the suitability of test environments.

2.6 Release and deployment

A release is a version made available for use or distribution. Deployment is the technical act of installing or enabling that version in an environment. A release may be deployed to a test environment without being released to customers.

Release planning considers scope, dependencies, migration, communication, training, support readiness, rollback or recovery, monitoring and approval. Deployment strategies include:

• Recreate or replace: Replace the existing environment with a new one.
• Rolling deployment: Update instances gradually.
• Blue-green deployment: Maintain two production-like environments and switch traffic between them.
• Canary deployment: Expose a change to a small population before wider rollout.
• Feature flags: Deploy code while controlling whether functionality is enabled.

Controls include change records, deployment approvals where required, automated pipelines, segregation of duties, release notes, backup verification and post-deployment checks.

2.7 Operations, maintenance and retirement

Once deployed, software must be monitored, supported, secured and improved. Operations includes incident management, problem management, capacity planning, backup, vulnerability remediation, service-level monitoring and user support.

Maintenance may be corrective, adaptive, perfective or preventive. Operational feedback can reveal requirements that were invisible during development. Useful evidence includes logs, metrics, traces, user feedback, incident reports and business outcomes. Monitoring must be designed responsibly: excessive collection can create privacy risks, while insufficient observability can delay detection of harm.

Retirement involves migration, archival, contract closure, removal of access, secure disposal of data and communication to affected stakeholders. Retirement is a lifecycle activity, not an afterthought.

3. Stakeholders, Deliverables and Controls

Stakeholders

Stakeholders are individuals or groups that affect, are affected by or have an interest in the system. Typical stakeholders include:

• customers, end users and representatives of vulnerable users;
• product owners, sponsors and business managers;
• developers, architects, testers and user-experience specialists;
• operations, platform, database and service-desk teams;
• information security, privacy, legal, procurement and compliance specialists;
• suppliers, partners and regulators;
• communities and members of the public affected by system outcomes.

Stakeholders may have conflicting goals. A sponsor may prioritise speed, a security specialist may prioritise risk reduction, and users may prioritise simplicity. Effective lifecycle management makes trade-offs visible and provides decision rights rather than assuming that conflict will disappear.

Deliverables

Deliverables are outputs produced for use, review, approval or evidence. They may be documents, models, code, test results, infrastructure definitions, training material or operational records. Agile teams may use lightweight artefacts, but lightweight does not mean absent. The required level of documentation should reflect risk, complexity, turnover, regulation and the cost of reconstructing decisions later.

Controls

Controls are mechanisms that reduce the likelihood or impact of undesirable outcomes. Examples include:

• peer review and independent assurance;
• version and configuration management;
• requirements and test traceability;
• access control and separation of duties;
• automated quality and security checks;
• change approval and emergency-change procedures;
• risk registers and risk treatment plans;
• audit logs and evidence retention;
• release gates and rollback procedures;
• privacy impact and threat assessments.

A control should be proportionate. Excessive approval bureaucracy can delay urgent improvements and encourage workarounds; weak controls can expose users and the organisation to unacceptable risks.

4. Verification, Validation and Traceability

Traceability links an identified need to requirements, design, implementation, tests and operational evidence. A simplified chain is:

Figure: Traceability connects purpose, construction, evidence and operational learning.

Traceability supports impact analysis when requirements change, demonstrates compliance, helps investigate incidents and confirms that high-priority needs have corresponding tests. It should not become a clerical exercise: links are valuable when they support decisions and reliable evidence.

5. Lifecycle Models

5.1 Waterfall

Waterfall organises work into largely sequential phases, commonly requirements, design, implementation, testing, deployment and maintenance. Each phase generally produces approved outputs before the next begins.

Strengths: clear milestones, predictable governance, straightforward contract boundaries and useful documentation when requirements are stable.

Limitations: feedback arrives late, assumptions may remain hidden, changes can be expensive and users may not see working software until late in the project. Waterfall is often misrepresented as having no feedback at all; in practice, reviews and change processes exist, but the model generally emphasises progression through defined stages.

Waterfall can suit a stable, well-understood product with fixed interfaces, strong documentation requirements and limited requirement volatility. It is risky when the problem itself is uncertain.

5.2 V-Model

The V-Model extends sequential thinking by pairing development activities with corresponding verification and validation activities. Requirements are associated with acceptance testing, system design with system testing, architectural or component design with integration testing, and detailed design or coding with unit testing.

Its central principle is that test planning begins early rather than after implementation. The model is valuable where evidence, safety, traceability and formal verification matter. However, it can still suffer from late discovery of misunderstood needs and can be costly when requirements change frequently.

5.3 Iterative development

In an iterative model, the product is repeatedly revisited and refined. Each cycle may include analysis, design, construction and evaluation. The purpose of an iteration is learning and improvement, not necessarily delivery of a complete new feature set.

Iteration is useful when the team expects to learn about user needs, technical feasibility or design quality. Early prototypes may be deliberately incomplete. A risk is uncontrolled rework if iteration lacks priorities, decision criteria and a clear definition of progress.

5.4 Incremental development

Incremental development delivers the product in usable or potentially usable portions. Each increment adds capability to what already exists. For example, a student portal might first provide authentication, then enrolment, then payment and finally reporting.

Incremental delivery provides earlier value and feedback and can reduce the size of each release. It requires architecture and interfaces that support safe extension. Increments that are individually unusable may merely be partial construction rather than meaningful incremental delivery.

Iterative and incremental approaches are related but distinct: iteration improves understanding or an existing solution; increment adds a usable slice of capability. A project may be both iterative and incremental.

5.5 Spiral model

The Spiral model organises development around repeated risk analysis. Each cycle typically identifies objectives, evaluates alternatives and risks, develops and verifies a solution, and plans the next cycle. It is particularly relevant to large, complex or high-risk work involving technical uncertainty.

The model makes risk management explicit, but it requires skilled risk analysis and can become expensive or bureaucratic. It is not automatically Agile simply because it repeats cycles.

5.6 Agile approaches

Agile approaches favour frequent delivery, close stakeholder collaboration, responsiveness to change and working software as an important measure of progress. Agile is not one lifecycle diagram or a license to omit engineering discipline. Frameworks such as Scrum, Kanban and Extreme Programming implement Agile values differently.

Common Agile practices include prioritised backlogs, short cycles, demonstrations, retrospectives, automated testing, continuous integration and cross-functional teams. Agile works best when stakeholders can provide timely feedback and the team can deliver in small slices.

Agile may be difficult when requirements cannot change because of physical dependencies, fixed external contracts or strict regulatory commitments. These constraints do not make Agile impossible, but they require appropriate planning, documentation, evidence and release controls. “Responding to change” does not mean accepting every change immediately; it means making informed trade-offs.

5.7 Hybrid models

A hybrid model combines lifecycle characteristics to fit a particular context. An organisation may use formal feasibility and architecture gates, iterative development, automated testing, and a controlled release process. Another may use Agile delivery within a regulated governance framework.

Hybrid approaches are often realistic, but they can fail if they merely combine the disadvantages of several models. Responsibilities, decision rights, artefacts, feedback paths and approval criteria must be explicit.

Comparison of lifecycle models

6. Selecting an Appropriate Lifecycle Model

Lifecycle selection should be treated as a context-sensitive engineering and management decision. The following questions are useful:

1. How stable and understood are the requirements?
2. How costly or dangerous is failure?
3. How quickly is value required?
4. Can users provide frequent, knowledgeable feedback?
5. What technical uncertainty exists?
6. Are there regulatory, safety, privacy or audit obligations?
7. Can the system be divided into independently valuable increments?
8. How much change can the architecture and contract accommodate?
9. What skills and delivery infrastructure does the team possess?
10. What evidence must be produced before release?

A simple decision is often more reliable than selecting a model by fashion. Stable requirements and high documentation obligations may support a V-Model. Uncertain requirements and frequent stakeholder access may support Agile iterative-incremental delivery. Novel technology and severe risks may justify Spiral practices. Mixed conditions commonly require a hybrid model.

The chosen model should be revisited when assumptions change. Lifecycle tailoring is a controlled adaptation, not an informal abandonment of process.

7. DevOps and the SDLC

DevOps extends the SDLC by making development, operations and other responsibilities more connected. Its practices seek to shorten feedback loops while preserving reliability and security. Examples include:

• version-controlled application and infrastructure configuration;
• continuous integration and automated tests;
• continuous delivery with controlled promotion;
• infrastructure as code;
• automated security and dependency checks;
• observability through logs, metrics and traces;
• progressive delivery and rapid rollback;
• shared ownership of service outcomes;
• blameless learning from incidents.

DevOps does not mean deploying every change without review. A mature pipeline automates repeatable controls and makes exceptions visible. In high-assurance environments, automated evidence can strengthen governance by recording what was tested, approved and deployed.

Security should be integrated throughout the lifecycle, often described as DevSecOps. Privacy should also be considered from initiation through retirement. Threat modelling, least privilege, secure defaults, vulnerability management, data minimisation and incident response are lifecycle responsibilities, not final-stage additions.

Artificial intelligence can assist with code suggestions, test generation, documentation, defect detection and operational analysis. However, AI-generated outputs require human review because they may contain insecure code, licensing problems, fabricated explanations, biased behaviour or undiscovered defects. Organisations should define acceptable use, protect confidential data and retain accountability for decisions.

8. Applied Case: A Digital Clinic Appointment Service

The following is an illustrative case.

Background

A regional clinic wants an online service allowing patients to search for appointments, receive reminders and cancel bookings. The service will integrate with an existing clinical scheduling system. Patient data is sensitive, and service outages could disrupt care.

Problem and analysis

The clinic initially proposes a two-year Waterfall project because it wants a fixed budget and detailed documentation. Discovery reveals that patients have different accessibility needs, the existing scheduling interface is poorly documented, and the clinic is uncertain whether patients prefer web, mobile or assisted booking. Privacy, identity verification, auditability and availability are significant concerns.

A purely sequential model would postpone important usability and integration learning. A completely informal Agile approach would not provide sufficient assurance for patient data and clinical operations.

Approach and solution

A hybrid lifecycle is selected:

• initiation includes a feasibility assessment, privacy impact assessment and stakeholder mapping;
• a short discovery iteration prototypes accessible booking journeys and tests the legacy interface;
• architecture and threat-model reviews establish identity, authorisation, audit and integration controls;
• incremental delivery begins with staff-assisted booking, then authenticated patient booking, reminders and cancellation;
• each increment passes automated tests, security checks, accessibility checks and operational readiness review;
• canary deployment is used for a limited clinic population;
• monitoring measures failed bookings, response times, support contacts and security events;
• retrospectives and patient feedback guide subsequent increments.

Formal evidence is maintained for privacy decisions, access control, test results, release approvals and incident handling. The product team, clinic staff, operations team, security adviser and patient representatives share defined decision rights.

Outcome

The clinic obtains early evidence that the integration can support safe booking and discovers that some patients require large-text and screen-reader-compatible workflows. The first release delivers limited capability but reduces risk before broader adoption. Later releases expand functionality only after operational and user evidence supports doing so.

Learning points

• The lifecycle should reflect both uncertainty and consequence of failure.
• Incremental delivery can coexist with formal governance.
• Accessibility and privacy are requirements, not optional enhancements.
• Operational monitoring provides evidence about whether the product is achieving its intended outcome.
• Hybrid models require explicit interfaces between adaptive delivery and formal controls.

9. Challenges, Limitations and Professional Responsibilities

No lifecycle model eliminates uncertainty. Estimates can be wrong, requirements can conflict, dependencies can fail and users can change their priorities. Models also influence behaviour: a phase-gate process may encourage teams to hide problems before a gate, while poorly governed Agile may reward visible activity rather than valuable outcomes.

Common challenges include:

• confusing output, such as features completed, with outcome, such as improved service;
• treating documentation as either bureaucracy or unnecessary work;
• measuring speed without measuring reliability, security and user impact;
• allowing technical debt to accumulate without recording its consequences;
• separating development and operations so that failures become someone else’s problem;
• ignoring accessibility, privacy, environmental cost or vulnerable users;
• relying on tools while neglecting communication and professional judgement.

Ethical practice requires more than compliance. Teams should consider foreseeable misuse, discriminatory outcomes, deceptive interfaces, data protection, accessibility, safety and the effects of failure on people who have limited alternatives. Where automated or AI-supported decisions affect individuals, accountability, explainability appropriate to the context, reviewability and appeal mechanisms may be necessary.

Best practice is therefore contextual: make work visible, involve affected stakeholders, test important assumptions early, automate repeatable checks, preserve useful evidence, design for operation, learn from real usage and tailor controls to risk.

Chapter Summary

The SDLC provides a structured way to transform needs into software and to manage the product through operation and retirement. Its major activities include initiation, feasibility, requirements, design, implementation, integration, verification, validation, release, deployment, operation, maintenance and retirement. Stakeholders supply knowledge, authority and feedback; deliverables provide usable outputs and evidence; controls reduce risk and support governance.

Waterfall emphasises sequential progression, the V-Model connects development with planned verification and validation, iterative models refine solutions through cycles, incremental models deliver capability in slices, and Spiral development makes risk analysis central. Agile approaches support frequent feedback and adaptation, while hybrid models combine practices to fit mixed constraints. No model is universally superior. Selection should reflect uncertainty, risk, delivery needs, stakeholder access, technical structure, regulation and team capability.

DevOps strengthens the lifecycle through collaboration, automation, continuous integration and delivery, observability, security integration and operational learning. Responsible lifecycle management also addresses privacy, accessibility, safety, sustainability, ethical use of technology and accountability for AI-assisted work.

Key Terms

SDLC: A structured lifecycle for planning, developing, testing, releasing, operating and retiring software.

Stakeholder: A person or group that affects, is affected by or has an interest in a system.

Requirement: A needed capability, quality or constraint of a system.

Functional requirement: A requirement describing a service or behaviour the system must provide.

Non-functional requirement: A requirement concerning qualities or constraints such as security, performance or accessibility.

Deliverable: An output produced for use, review, approval or evidence.

Control: A measure intended to reduce the likelihood or impact of an undesirable outcome.

Baseline: An approved version of an item controlled through change management.

Traceability: The ability to connect needs, requirements, design, implementation, tests and operational evidence.

Verification: Evaluation of whether the product was built according to specified requirements and design.

Validation: Evaluation of whether the correct product was built for its intended users and purpose.

Waterfall: A predominantly sequential lifecycle model.

V-Model: A lifecycle model pairing development activities with corresponding verification and validation activities.

Iterative development: Repeated refinement of a solution through cycles.

Incremental development: Delivery of additional capability in usable or potentially usable portions.

Spiral model: A risk-driven lifecycle model organised into repeated cycles.

Agile: An approach emphasising collaboration, frequent delivery, feedback and responsiveness to change.

Hybrid lifecycle: A deliberately tailored combination of lifecycle practices or models.

DevOps: A collaborative approach connecting development, operations, security and feedback through automation and shared responsibility.

Technical debt: Future cost created by expedient or inadequate technical decisions.

Review Questions

Short Answer Questions

1. What is the purpose of the Software Development Lifecycle?
2. Distinguish verification from validation.
3. Name four common SDLC deliverables.
4. What is the main difference between iterative and incremental development?
5. Why is traceability useful in software projects?

Long Answer Questions

1. Explain the major SDLC stages and identify typical deliverables and controls for each stage.
2. Compare the Waterfall and V-Model approaches, including their strengths and limitations.
3. Explain how Agile and DevOps influence feedback, testing and operational responsibility.
4. Discuss the role of stakeholders in resolving competing lifecycle priorities.
5. Explain why privacy, accessibility and security should be treated as lifecycle responsibilities.

Analytical / Application Questions

1. A government benefits system has stable legal requirements, strict audit obligations and severe consequences for incorrect payments. Which lifecycle model or combination of practices would you recommend, and why?
2. A start-up is developing an untested mobile service. Users are available for weekly feedback, but the technical architecture is uncertain. Select a suitable lifecycle approach and describe the first three delivery cycles.
3. An organisation has adopted Agile but experiences frequent production incidents and cannot demonstrate what was tested before release. Analyse the likely lifecycle weaknesses and propose controls that preserve adaptability while improving assurance.

Multiple Choice Questions with Answers

Question 1

Which activity primarily determines whether the proposed software initiative is technically and economically viable?

A. Feasibility assessment

B. Unit testing

C. Deployment monitoring

D. Code refactoring

Correct Answer: A. Feasibility assessment

Question 2

Which statement best describes validation?

A. Checking whether source code follows formatting rules

B. Checking whether the product meets the intended user and business purpose

C. Checking whether a build can be reproduced

D. Checking whether a database index exists

Correct Answer: B. Checking whether the product meets the intended user and business purpose

Question 3

Which lifecycle model explicitly pairs development activities with corresponding testing activities?

A. Spiral model

B. Incremental model

C. V-Model

D. Kanban model

Correct Answer: C. V-Model

Question 4

A project delivers authentication first, appointment booking second and reminders third, with each release providing additional usable capability. This is primarily an example of:

A. Incremental development

B. Pure maintenance

C. Big-bang deployment

D. Requirements elicitation

Correct Answer: A. Incremental development

Question 5

Which characteristic is most associated with the Spiral model?

A. Risk-driven cycles

B. No stakeholder feedback

C. Mandatory single release at the end

D. Avoidance of prototypes

Correct Answer: A. Risk-driven cycles

Question 6

Which situation most strongly supports an Agile iterative-incremental approach?

A. Requirements are uncertain and users can provide frequent feedback

B. All requirements are legally fixed and no feedback is possible

C. The system must never be tested until final deployment

D. The team has no ability to prioritise work

Correct Answer: A. Requirements are uncertain and users can provide frequent feedback

Question 7

What is the main purpose of a traceability link between a requirement and a test?

A. To prove that the requirement has corresponding verification evidence

B. To eliminate the need for user involvement

C. To guarantee that the requirement will never change

D. To replace source-code version control

Correct Answer: A. To prove that the requirement has corresponding verification evidence

Question 8

Which deployment strategy exposes a change to a small population before wider rollout?

A. Canary deployment

B. Waterfall deployment

C. Static analysis

D. Requirements baseline

Correct Answer: A. Canary deployment

Question 9

Which statement about DevOps is most accurate?

A. It removes the need for testing and governance

B. It connects development and operations through collaboration, automation and feedback

C. It requires every change to be deployed manually

D. It applies only to infrastructure teams

Correct Answer: B. It connects development and operations through collaboration, automation and feedback

Question 10

A project has uncertain requirements, high technical risk and strict regulatory evidence requirements. Which approach is most defensible?

A. An informal process with no documented decisions

B. A hybrid approach combining iterative risk reduction with formal assurance controls

C. A purely sequential process that prohibits all prototypes

D. Immediate full-scale deployment before testing

Correct Answer: B. A hybrid approach combining iterative risk reduction with formal assurance controls