Software engineering standard

This standard establishes the minimum requirements for Commonwealth agencies to build and maintain the critical software engineering capability which underpins the data, digital and cyber discipline required to support all government activities.

Applicability of this standard

These statements detail how agencies can meet this standard and comply with the Software engineering policy.

Apply consistent software engineering practices

Using defined software engineering methodologies such as modern agile, DevOps and DevSecOps practices and methodologies support agility, security, and user-centric service delivery. The ISO/IEC/IEEE guidance for software engineering in an agile development environment can support this.

Agile methodologies, DevSecOps principles and automated support for software engineering activities, such as automated test and continuous integration / continuous delivery (CI/CD) are encouraged for use. They enable secure and continuous optimisation of government services and value production from both architectural design and software engineering activities.

Key practices to consider:

Shift Security Left: Integrate security testing and practices early in the development process, rather than at the end, to identify and fix vulnerabilities sooner, reducing costs and time.
Automate Security Testing: Implement automated security checks at various stages of the Continuous Integration / Continuous Delivery (CI/CD) pipeline, such as static and dynamic code analysis, vulnerability scanning, and penetration testing.
Secure Coding Practices: Provide developers with secure coding guidelines and training to minimise vulnerabilities from the start.
Threat Modeling and Risk Assessment: Regularly assess potential security threats and vulnerabilities to prioritise security efforts and resources.
Continuous Monitoring and Alerting: Implement real-time security monitoring to detect and respond to threats as they occur.
Security as Code: Embed security policies and controls into code, infrastructure, and configurations using Infrastructure as Code (IaC) and Policy as Code.
Collaboration and Communication: Foster a culture of collaboration between development, security, and operations teams to ensure shared responsibility and knowledge.
Incident Response and Recovery Planning: Develop clear procedures for handling security incidents and recovering from potential breaches.
Leverage Security Tools: Utilise a variety of tools for vulnerability scanning, static/dynamic analysis, penetration testing, and security information and event management (SIEM).
Regular Evaluation and Iteration: Continuously evaluate and improve DevSecOps processes based on feedback and lessons learned.

Additional best practices to consider include:

Aligning all services that engage inter-agency (and ideally intra-agency) to documented API-first approach such as RESTful or GraphQL APIs to better facilitate sharing.
Using Open Source (and contribution back to) software to reduce risk around vendor lock-in and ultimately reduce costs.
Implementing consistent and common Data Models, ensuring that “UserID” or “Address” format is consistent across the enterprise.
The role ofUsing Single Points of Truth (SPoT) such as AusTender, or the Australian Government Organisation Register, to develop common and consistent naming conventions. Within an agency, considering the role of a Single Source of Truth (SSoT) to develop a consistent, reliable data source that may consolidate these SPOTs across government for reuse internally in digital service development and delivery.
Adopting Cloud-Native architectures aligned to the Australian Government Architecture’s Cloud Computing Policy. This should include consideration on the role of microservice and containerisation (like Docker/Kubernetes) over traditional on-premises VMs.

Agencies may choose to take an active role in APS Communities of Practice and Special Interest Groups such as:

The key standards and guidance for Software Engineering professional practice are best embodied and most accessible in the IEEE Software Engineering Body of Knowledge.

The following standards and best practices are highlighted for further guidance:

IEEE (Institute of Electrical and Electronics Engineers)

IEEE 12207 – Software Life Cycle Processes
IEEE 828 – Standard for Configuration Management in Systems and Software Engineering
IEEE 1012 – Standard for Software Verification and Validation
IEEE 730 – Standard for Software Quality Assurance Processes

ISO/IEC (International Organization for Standardization / International Electrotechnical Commission)

ISO/IEC 12207 – Systems and Software Engineering – Software Life Cycle Processes
ISO/IEC 25002 – Systems and Software Quality Requirements and Evaluation (SQuaRE)
ISO/IEC 29119 – Software Testing Standards
ISO/IEC 38500 – Governance of IT for the Organisation

W3C (World Wide Web Consortium)

Every new system requires a defined ‘end-of-life' strategy to prevent it from shifting to legacy. This roadmap should be reflected in an Agency's Digital investment plan where appropriate aligned to the Australian Government’s Digital investment plan (DIP) policy.

Build secure, compostable and sustainable solutions

The ASD’s Secure by design advice articulates these practices and agencies are encouraged to become familiar with the advice before embarking on any software engineering program of work or capability development.

Using secure-by-design principles is advisable, as well as aiming for modular, composable, loosely coupled, vendor- and technology-agnostic software components and products. This helps minimises vendor lock-in, supports proactive security management, and enables agility to adopt new technologies or alternative software components over time.

Key characteristics of composable software design include:

Modularity: Software is broken down into smaller, self-contained units (components or microservices) that perform specific tasks.
Reusability: Components are designed to be used in multiple contexts, reducing the need for duplicated components across organisational silos.
Flexibility: The modular nature allows for easy modification, replacement, or addition of components as needed, enabling systems to adapt to changing requirements.
API-first: Components communicate and interact with each other primarily through well-defined APIs, facilitating seamless integration.
Cloud-native: Often enabling software development, build, and deployment of workloads in various computing cloud environments (public, private, hybrid cloud) to meet their agency’s needs at scale in a programmatic and repeatable manner.

Software engineering activities need to ensure that module verification of identity, including within internal networks, occurs to support a Zero Trust Architecture approach.

Software engineering practices need to ensure all software is usable by people with disabilities and considers the experience of regional and rural connectivity constraints. These requirements are articulated by the Australian Government’s Digital Experience Policy.

Embedding site reliability engineering practices into software engineering practices ensures that Service Level Indicators (SLIs) or Objectives (SLOs) are designed for early. This includes concepts such as heartbeats and synthetic transactions for complex services. The Australian Government’s Digital Experience Policy articulates this further under the Digital Performance Standard.

Software products are expected to consider the automated development and maintenance of a machine-readable Software Bill of Materials (SBOM). The SBOM includes all third-party libraries to support the management of supply chain risk and aligns with the relevant technical standard specified by the Australian Signals Directorate (ASD).

Taking a product approach helps government agencies to build adaptable, resilient, and user-focused digital services that can evolve alongside public needs and policy directions. It can help to:

Meet and proactively align to user needs through continuous user engagement and feedback, not just initial requirements. This encourages human-centred design and iterative validation, reducing the risk of unused or misaligned features.
Enable faster, incremental value delivery by delivering in small, usable increments rather than big-bang releases, to realise benefits earlier and to reduce risks.
Improve quality and reliability by continuous integration, automated testing, regular releases, embedded quality assurance and effective maintenance and security controls.

In adopting a product approach, agencies are also encouraged to seek and operate strategic partnerships with Australian industry and academia to strengthen Australia’s sovereign capability and support Australian GovTech and Digital Public Infrastructure initiatives.

Establish integrated governance and assurance

An integrated governance mechanism for software engineering will incorporate and align:

organisational strategic governance
enterprise architecture governance
product and service governance
systems and software engineering governance
implementation governance.

Software engineering is supported by clear roadmaps and plans for digital investments and projects and signed off by relevant governance bodies established by the agency. Managing this through the integrated governance mechanisms ensures all data, digital and cyber activities align with agency and whole-of-government strategic goals.

Considering records management requirements during software engineering can help to ensure that National Archives standards are met.

In cases where software engineering activities include AI tools , an AI-assisted software engineering capability may comprise one or multiple use cases. Agencies may use multiple AI-enabled tools across the software engineering lifecycle, including tools that are also used more broadly across the enterprise. These tools may support the development of public-facing services, staff-facing systems, or software that handles information ranging from general business data to sensitive or protected information. Agencies may refer to the definitions of ‘AI use case’ and ‘in-scope use case’ in the appendix to the Policy when determining how the capability can be assessed.

Agencies should also consider the Technical standard for government's use of artificial intelligence when establishing practices and assurance measures for the AI tools used in software engineering activities. Software engineering is evolving from primarily writing and maintaining code to directing, validating and governing increasingly capable AI-assisted engineering systems. As AI tools become more capable of generating code, tests, documentation and other software artefacts, the primary responsibilities of the software engineer are shifting towards understanding problems, architecting solutions, applying critical thinking, assuring quality and making informed decisions.

People

Clarifying the roles and responsibilities of software engineers helps APS agencies ensure that human judgement, oversight and accountability remain central to software engineering decisions and outcomes. Key responsibilities for consideration include:

Systems thinking and architectural awareness: Software operates within broader technical, organisational and operational systems. Improvements in one area can introduce risks or unintended consequences elsewhere. Software engineers need to understand dependencies, interactions and manage trade-offs across those systems. As AI tools become more capable of generating implementation details, systems architecture remains critical for ensuring systems are secure, reliable, maintainable and fit for purpose.
Problem framing and contextual understanding: Understanding requirements, identifying constraints and success criteria are important. Techniques such as problem decomposition, root cause analysis, design thinking and experimentation can help software engineers understand complex problems before solving them.
Critical thinking and judgment: This covers validating assumptions, understanding limitations, considering alternative approaches and seeking additional evidence. Software engineers are responsible for selecting appropriate tools, methods and data for the task, and applying judgment before accepting AI-generated artefacts or recommendations.
Documentation of intent, rationale and trade-offs: While AI can generate documentation for a code base, source code only describes how a system works and rarely captures why decisions were made. Software engineers are responsible for documenting intent, rationale, trade-offs, architectural decisions and operational knowledge so that important context is not lost over time.
Quality assurance and operational validation: Software engineers play a critical role in assuring quality, security and reliability of software they develop. This includes independently verifying AI-generated outputs, reviewing and testing before they are accepted. Code quality measures, tests and reviews provide important evidence, but they cannot fully predict how a system will behave in real-world environments. Understanding operational evidence, including user feedback, real-world performance, impacts on affected groups and behaviour in the intended environment helps software engineers learn valuable insights from operational experience.

AI-enabled software engineering processes

Agencies can support the responsibilities of software engineers by defining and implementing controlled engineering workflows that enable independent verification, informed decision-making and accountability for outcomes. A typical workflow is:

The engineer starts by defining the intended outcome. This includes requirements, constraints, rationale and acceptance criteria.
The AI agent then generates or modifies the code. The agent may decide how to implement the change within the scope and constraints set by the engineer.
The software engineer ensures the change undergoes verification appropriate to the risk and context. This may include peer review, manual inspection and automated verification tools that are separate from the AI agent that generated the code. Tools include static analysis, dynamic testing, unit tests, integration tests and code coverage checks. See Independent verification of AI-generated code for more examples.
The software engineer reviews the code and supporting evidence, including relevant test and assurance results, applies judgement, and determines whether the change is fit for purpose.
The software engineer makes one of three decisions:

Accept the change if it meets the intent and passes the required checks
Revise the change if further work is required, whether by the software engineer, another engineer, or the AI agent
Reject the change if the intent, assumptions or approach need to be reconsidered

Record key decisions, including the rationale and supporting evidence, in a way that is proportionate to the risk and context.

Step 5 creates a control loop. If the change needs revision, it may return to the software engineer, another engineer, or the AI agent, depending on the nature of the issue. If the change is rejected, the intended outcome, assumptions or approach may need to be reconsidered. The loop helps ensure that AI-generated code is subject to appropriate independent verification and human review and is accepted only when the responsible software engineer is satisfied with the evidence.

Tools

AI-assisted coding approaches

AI tools can support software engineering with different autonomy levels. Start with the simplest approach to build familiarity before moving into increasing autonomy. Higher autonomy requires stronger enterprise guardrails.

Prompt-based coding uses natural language instructions to generate or change code. This can be useful for small, well-defined tasks, examples, prototypes or boilerplate. It works best when the engineer understands the problem and can assess the output.
Agent-assisted coding involves delegating parts of the software engineering workflow to AI agents that can plan and execute multi-step tasks.
Agentic engineering shifts from humans writing code with AI assistance to humans orchestrating AI systems that perform engineering work.

Independent verification of AI-generated code

Automated quality controls provide assurance about quality, security and reliability of AI-generated code. While these support efficient and independent verification, these do not fully determine whether software is fit for purpose in its intended operating environment. Software engineers remain responsible for interpreting results, understanding limitations and making informed engineering decisions. The examples below are illustrative, not exhaustive.

Quality control	Capabilities and limitations	Examples
Coding style and consistency checks	Whether code conforms to agreed formatting, style and maintainability standards.	Formatters, linters
Type and static checks	Whether code contains type errors, likely defects or insecure patterns; most effective for issues that can be detected through defined rules.	Type checkers, static analysis, security static analysis
Automated tests	Whether the code behaves as expected; strong where tests are well designed and comprehensive.	Unit tests, integration tests, dynamic analysis
Test adequacy checks	Whether the test suite exercises sufficient code and is likely to detect meaningful defects.	Code coverage, mutation testing
Robustness checks	Whether software handles malformed, unexpected or random inputs without failing unsafely; useful for identifying crashes, edge cases and unintended behaviours.	Fuzzing, property-based testing
Security and dependency checks	Whether code, dependencies or images contain known vulnerabilities or exposed secrets.	Software composition analysis, secrets scanning, container scanning, dynamic application security testing
Infrastructure and configuration checks	Whether infrastructure and deployment configuration follow defined rules.	IaC/configuration scanning, container scanning