# Software Development

> Source: https://aiwiki.ai/wiki/software_development
> Updated: 2026-08-03
> Fact-checked: 2026-07-31
> Categories: AI Tools & Products, Software Development
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Software Development." aiwiki.ai, 3 Aug 2026. https://aiwiki.ai/wiki/software_development
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**Software development** is the work of conceiving, specifying, designing, implementing, verifying, delivering, operating, maintaining, and eventually retiring [software](https://aiwiki.ai/wiki/software). It includes [programming](https://aiwiki.ai/wiki/programming), but it is broader than writing source code. Development also involves deciding what problem to solve, translating stakeholder needs into testable requirements, selecting an architecture, managing changes and dependencies, evaluating quality, releasing usable versions, observing the software in operation, and responding when its environment or users change. ISO/IEC/IEEE 12207 describes these activities as life-cycle processes that may be applied concurrently, iteratively, recursively, and incrementally rather than as one mandatory sequence.[1]

Software development is practiced at many scales, from a script maintained by one person to safety-critical systems built by organizations and suppliers over decades. The relevant evidence, documentation, controls, and division of work depend on the system's consequences, uncertainty, lifetime, regulatory setting, and exposure to attack. The Software Engineering Body of Knowledge therefore treats requirements, architecture, construction, testing, operations, maintenance, configuration management, security, management, process, quality, and professional practice as connected areas rather than isolated specialties.[2]

There is no single development method that is best for every project. A team may use a predictive plan where requirements are stable and formal approval is required, short iterative cycles where needs are expected to change, risk-driven prototypes where feasibility is uncertain, continuous delivery for an online service, or a combination. In each case, quality has to be stated in terms that fit the product and its users. ISO/IEC 25010 supplies a product-quality model for specifying and evaluating such properties, but the appropriate targets and evidence remain project decisions.[3]

## Scope and terminology

In everyday use, *software development* can mean either the full life cycle or the narrower implementation phase. This article uses the broader meaning established by current life-cycle and software-engineering references. Several neighboring terms overlap with it:[1][2]

| Term | Main emphasis | Relationship to software development |
| --- | --- | --- |
| Programming | Expressing algorithms and behavior in executable form | A central implementation activity, but not the whole life cycle |
| Software engineering | Systematic application of engineering knowledge, methods, and evidence to software | Often used for disciplined development, especially where scale or risk makes tradeoffs explicit |
| Product development | Discovering and delivering value for users or customers | Includes business, design, research, and market work as well as software |
| Systems engineering | Coordinating interacting hardware, software, people, data, facilities, and procedures | Supplies context when software is one element of a larger system |
| Operations | Running, observing, supporting, and recovering a deployed service or product | Part of the software life cycle, not merely work after development |
| Maintenance | Modifying software after delivery to correct, adapt, improve, or prevent problems | Continues development under the constraints of an existing system |

A *process* describes work to be performed and the outcomes sought. A *method* gives more specific practices or techniques. A *life-cycle model* arranges work over time. A tool implements or automates part of the work. ISO/IEC/IEEE 12207 expressly separates its process framework from any required model, methodology, modeling approach, or technique.[1]

The output is not limited to executable files. Source code, tests, build definitions, dependency declarations, schemas, configuration, threat models, interface descriptions, operating procedures, migration plans, user documentation, and decision records can all be part of the maintained product. Which items require formal control depends on their role. For example, a changed deployment manifest can alter production behavior even if no application source file changes.[1][2]

## Historical development

The phrase *software engineering* gained institutional prominence at the 1968 NATO conference in Garmisch, whose report collected discussion of large-system design, production, verification, maintenance, and what participants called the software crisis.[4] The report did not establish a finished discipline. It documented a period in which software projects were becoming larger and more consequential while methods, tools, and organizational experience were uneven.

Winston Royce's 1970 paper is frequently treated as the source of a simple one-pass waterfall model. The paper actually used a sequence of requirements, analysis, program design, coding, testing, and operations as a starting point, then argued that this implementation was risky for large systems. Royce recommended feedback between stages, preliminary program design, extensive documentation, a pilot version, planned testing, and customer involvement.[5] The historical label therefore should not be read as evidence that Royce endorsed development without iteration.

Iterative and incremental development also predates modern agile terminology. Craig Larman and Victor Basili documented examples from the 1950s onward, including staged delivery and repeated feedback in major government and commercial projects.[6] Barry Boehm's 1988 spiral model made risk analysis central: each cycle identifies objectives and alternatives, evaluates risks, develops and verifies the next-level product, and plans the next cycle.[7] The important distinction is not simply old versus new. It is how a project manages uncertainty, obtains evidence, and commits resources.

In 2001, the Manifesto for Agile Software Development stated four comparative values favoring people and interactions, working software, customer collaboration, and response to change while explicitly retaining value in the items on the other side.[8] Scrum later became one widely used framework for iterative product development. Its official guide defines a small set of accountabilities, events, and artifacts around a Product Goal and short Sprints, and describes Scrum as purposefully incomplete rather than a complete engineering process.[9] Teams still have to choose technical practices for design, testing, integration, security, and operation.

Evidence about agile methods is context-dependent. A 2008 systematic review by Tore Dyba and Torgeir Dingsoyr found 36 empirical studies that met its criteria out of 1,996 identified publications. It reported benefits in some settings but also methodological limitations and a need for more rigorous research.[10] Later practice and research are much larger, but the lesson remains useful: a process label is not a causal explanation of an outcome. Team capability, system architecture, organizational incentives, task type, and measurement choices can dominate the name of the method.

The spread of network services further connected development with deployment and operations. Practices grouped under DevOps seek faster and safer feedback across these responsibilities. Continuous integration, infrastructure as code, automated delivery, telemetry, and shared incident learning are compatible with agile work but are not synonymous with it. A packaged desktop application, an embedded controller, a mobile client, and a continuously operated service may all use iterative development while needing different release and support arrangements.[1][2][8]

## Life-cycle activities

Life-cycle activities overlap in real projects. A prototype may expose a missing requirement; a performance test may force an architectural change; an incident may add a regression test and revise an operating limit. The following table is a map of concerns, not a required order:[1][2]

| Activity | Questions addressed | Typical evidence or outputs |
| --- | --- | --- |
| Discovery and feasibility | Whose problem is being addressed, and is a software change justified? | Problem statement, user research, constraints, alternatives, feasibility experiment |
| Requirements | What behavior and qualities are needed, under what conditions? | Requirements, scenarios, acceptance criteria, traceability links |
| Architecture and design | How will responsibilities, data, interfaces, and deployment be structured? | Architecture description, interface contract, data model, decision record, prototype |
| Implementation | How is the design expressed and kept understandable? | Source, configuration, migrations, local documentation, review history |
| Verification and validation | Was the product built correctly, and is it useful for the intended purpose? | Reviews, analyses, test results, usability findings, acceptance evidence |
| Integration and release | Can a known set of inputs produce an identifiable, deployable artifact? | Build record, artifact, version, provenance, release notes, rollback plan |
| Operation and support | Does the product meet objectives in its real environment? | Telemetry, alerts, runbooks, support records, incident reports |
| Maintenance and evolution | How should defects, changed needs, dependencies, and accumulated design constraints be handled? | Patches, refactoring, migrations, deprecation and compatibility decisions |
| Retirement | How will users, data, integrations, and obligations move away safely? | Notice, export or migration path, archival and deletion evidence |

The work begins before a team commits to an implementation. Discovery tests whether a problem is understood and whether software is the right intervention. Feasibility work may examine technical unknowns, legal or licensing constraints, available data, operational cost, accessibility, procurement, organizational readiness, and alternatives such as changing a process rather than building a system. A prototype can reduce a specific uncertainty, but it should not silently become a production system without reassessing its assumptions and quality controls.[1][2][3]

Planning turns selected outcomes into work that can be coordinated. Useful plans expose dependencies, decision points, risks, and validation opportunities instead of treating an early estimate as certainty. Estimates are conditional predictions, not measurements of intrinsic task size. Their precision should reflect the evidence available. A distant release may be represented as a range or scenario, while a small, well-understood change can be planned more precisely.[2][7]

Traceability connects reasons to implementation and evidence. A critical requirement might link to its source, architectural treatment, code change, tests, release, and operational signal. Traceability does not require a single large document; it can be maintained through stable identifiers and links across controlled systems. Its value is the ability to answer why a behavior exists, what depends on it, and what evidence must be reconsidered when it changes.[1][2]

## Requirements and product decisions

Requirements engineering includes eliciting, analyzing, specifying, validating, and managing needs and constraints across the life cycle. ISO/IEC/IEEE 29148 defines requirements-related processes and information items for systems and software without limiting them to one project size or methodology.[11] In iterative work, requirements may be refined just before implementation, but that does not make them optional. The team still needs a shared, testable account of the change it intends to make.

Functional requirements describe behavior or capability. Quality requirements constrain observable properties: for example, response time under a stated load, recovery after a defined failure, access for a named role, keyboard completion of a task, compatibility with a protocol version, or ease of replacing a component. These examples are not the names of ISO/IEC 25010's nine top-level characteristics. The standard's public abstract establishes a nine-characteristic model for specifying and evaluating product quality, while each project still has to state measurable conditions. Other constraints can arise from law, policy, hardware, budgets, deadlines, data retention, or interoperability.[2][3][11]

Requirements come from more than the person funding the work. Users, operators, maintainers, security staff, support teams, affected non-users, regulators, and connected-system owners can hold relevant knowledge. Their needs may conflict. Product work makes those conflicts explicit and records a decision; it does not merely collect every request. For consequential systems, assumptions about the user population, environment, misuse, and failure consequences deserve the same attention as normal-use scenarios.[1][11]

Acceptance criteria describe evidence that would make a change acceptable. They can include examples, boundaries, error behavior, quality thresholds, manual observations, and operational conditions. They should not be confused with a complete specification. A few examples can leave entire input classes, concurrency behavior, state transitions, or recovery paths unspecified. Conversely, an exhaustive formal specification is not always economical. The chosen rigor should follow the cost of ambiguity and failure.[3][11]

Changes are inevitable, so requirements management is a continuing activity. When a requirement changes, the team evaluates affected interfaces, data, tests, documentation, schedules, controls, and users. A backlog records possible work, but priority is a decision about outcomes and constraints, not a property inherent in a ticket. Removing obsolete requirements is as important as adding new ones, because unused behavior and compatibility commitments carry continuing cost.[1][11]

## Architecture and design

Software architecture concerns the fundamental organization and properties of a system and the reasoning behind them. ISO/IEC/IEEE 42010 specifies requirements for architecture descriptions, including the use of viewpoints and model kinds to address stakeholder concerns.[12] An architecture is not identical to its diagram. The running system has an architecture whether or not it is documented; a description is a controlled representation used to communicate and evaluate it.

Design decomposes responsibilities, defines interfaces and data ownership, chooses mechanisms, and balances quality attributes. A decision that improves one property may weaken another. Replication can improve availability but complicate consistency. Caching can reduce latency but create invalidation and privacy risks. A highly generic abstraction can support variation while making common paths harder to understand. Tradeoffs should be evaluated against concrete scenarios rather than universal rules.[3][12]

David Parnas's 1972 comparison of modularization criteria argued for modules organized around design decisions likely to change, with those decisions hidden behind interfaces.[13] Information hiding is distinct from merely splitting code into small files. A useful module limits what other parts of the system must know and reduces the number of places affected by a change. Cohesion, coupling, dependency direction, and stable contracts are practical ways to reason about that goal.

Interfaces include function signatures, network APIs, events, file formats, schemas, user interactions, and operational contracts. Their design must cover normal behavior, invalid inputs, timeouts, partial failure, retries, compatibility, authorization, observability, and change. Schema and API evolution often require additive transition periods or translation layers because producers and consumers do not upgrade simultaneously.[2][3][12]

Architecture descriptions should match the decision being made. A context view can show people and external systems; a component view can show responsibility and dependency; a deployment view can show processes, nodes, trust boundaries, and networks; a data model can show ownership and integrity rules; a sequence can expose ordering and failure behavior. Combining every concern in one diagram usually makes none of them clear.[12]

Design decisions that constrain later work benefit from a short record of context, alternatives, decision, and consequences. The record should distinguish what was known at the time from later outcomes. It is then possible to revisit a decision when its assumptions fail without pretending that the original choice was irrational. Reversible decisions can remain lightweight; expensive or safety-relevant commitments require stronger evidence and review.[2][7][12]

## Implementation and configuration management

Implementation translates decisions into source code and other executable or interpreted artifacts. Readability is not cosmetic. Code is repeatedly read during review, debugging, extension, incident response, and security analysis. Clear names, limited responsibilities, explicit invariants, consistent error handling, and local explanations of non-obvious choices reduce the knowledge needed to change it safely. Comments are most useful when they explain intent, constraints, or surprising reasoning rather than restating syntax.[2][13]

Version control records identified states and changes over time. Git's documentation distinguishes centralized and distributed models and explains that a distributed repository contains a full history rather than only a checkout.[14] Regardless of tool, effective configuration management identifies controlled items, relates a change to its rationale and review, and makes releases reproducible. A commit is not automatically a meaningful unit of review, and a branch is not a substitute for integration.

Small, coherent changes are generally easier to understand, test, review, revert, and diagnose than mixtures of unrelated work. This is not a rule that every change must be tiny. Some migrations require coordinated updates. In that case, compatibility layers, feature flags, staged data changes, or parallel operation can reduce the amount committed at once and provide observation points.[14]

Dependencies include libraries, services, tools, base images, compilers, operating systems, models, and external data. Selecting one creates future work: monitoring updates, assessing vulnerabilities and licenses, testing compatibility, and planning replacement. A lockfile can identify resolved versions, but it does not establish that an artifact was built from them or that the dependencies are trustworthy. The build environment and distribution path are also part of the configuration.[1][2][14]

Team structure affects the design that teams can produce. Melvin Conway's 1968 paper observed that organizations tend to design systems whose communication structures resemble their own.[15] The observation is not a mechanical law, but it warns that an architecture requiring frequent coordination across boundaries may remain difficult even when its diagrams look modular. Ownership should provide clear responsibility without preventing contribution, review, or end-to-end learning.

## Review and collaboration

Review is a structured attempt to find problems and share understanding before or after a change is integrated. Michael Fagan's 1976 paper described formal design and code inspections with defined roles, preparation, meetings, rework, and follow-up.[16] Modern pull-request review is usually less formal, but it inherits the core idea that inspection is a distinct activity requiring attention and evidence.

An empirical study of modern code review at Microsoft found that finding defects was a central motivation, while knowledge transfer, team awareness, and discovering alternative solutions were also important outcomes. Reviewers reported understanding the change as a principal challenge.[17] This supports practices such as explaining context, limiting unrelated changes, providing test evidence, identifying risk, and assigning reviewers who understand the affected area.

Review can examine behavior, design fit, simplicity, failure handling, security, accessibility, tests, migration safety, observability, and documentation. Style checks that a tool can enforce should usually be automated so human attention remains available for reasoning. Approval means the reviewer found the presented evidence adequate under the project's standard; it is not proof that the change is defect-free.[16][17]

Pair or ensemble programming brings review into implementation by having multiple people work through decisions together. Asynchronous review allows independent inspection and works across schedules. Design review can occur before code exists. Each form has different latency and knowledge-sharing characteristics, and a team may combine them. The relevant question is which risks require independent judgment and when feedback will be cheapest to use.[16][17]

Collaboration also requires an environment in which concerns can be raised without retaliation. Incident learning and design critique deteriorate when disagreement is treated as disloyalty or when a person is blamed for a system-level weakness. Clear decision authority still matters: inclusive discussion does not mean every decision remains open indefinitely.[2][17]

## Verification, validation, and testing

Verification asks whether an artifact satisfies specified requirements or constraints. Validation asks whether the resulting product serves its intended use in its real context. The distinction is useful because software can conform to a mistaken requirement. Reviews, static analysis, formal methods, simulation, testing, usability studies, staged operation, and monitoring supply different kinds of evidence. None alone covers every failure mode.[2][11]

ISO/IEC/IEEE 29119-2 defines test processes that can be used with different life-cycle models.[18] Testing is often organized by scope:

- Unit or component tests exercise a small unit in controlled conditions.
- Integration tests examine interactions among components, databases, services, devices, or external systems.
- System tests evaluate the assembled product against system behavior and quality requirements.
- Acceptance tests supply evidence for stakeholder acceptance in a defined environment.
- Regression tests check that behavior previously relied upon has not been broken.

These labels describe purpose, not an exact technology. A test that calls one public API might exercise many internal units. A browser test can still use simulated external services. Test suites need an explicit model of what is real, replaced, controlled, or unobserved, because a passing result only supports claims under those conditions.[18]

Example-based tests cover selected cases. Input partitioning, boundary analysis, state-transition models, decision tables, and combinatorial techniques help select cases systematically. Property-based testing generates cases and checks general properties; QuickCheck introduced an influential approach in which programmers state properties and the tool supplies random test data and simplifies failures.[19] It is especially useful when broad invariants are easier to state than representative examples, but generators and properties can themselves omit important behavior.

Mutation testing changes the program in small ways and checks whether the test suite detects the changes. A surviving mutant can reveal weak tests or an equivalent transformation that does not change observable behavior. A survey by Yue Jia and Mark Harman describes mutation testing's development, techniques, and computational cost.[20] Mutation scores are therefore diagnostic evidence, not a universal quality target.

Fuzzing supplies generated or mutated inputs to provoke crashes, hangs, assertion failures, sanitizer findings, or other unexpected behavior. A 2019 survey by Valentin Manes and coauthors organizes modern fuzzing by input generation, execution, and observation techniques.[21] Fuzzing is valuable for parsers, protocols, memory-unsafe components, and complex input spaces, but the oracle matters: a program may return an incorrect result without crashing.

Static analysis examines artifacts without executing the program and can enforce type, data-flow, dependency, style, or security rules. Dynamic analysis observes executions and can detect memory, concurrency, performance, or resource problems under exercised conditions. Formal verification can prove a stated property of a model or program under explicit assumptions. The strength of a proof depends on the property, model, implementation correspondence, and assumptions; it does not establish every desirable behavior.[2][18]

Tests should be evaluated for signal quality. A test that fails nondeterministically delays work and teaches people to ignore alarms. A test coupled to irrelevant implementation details creates maintenance work without protecting behavior. A slow test may still be justified when it covers a high-consequence integration, but the team should understand its place in the feedback path. Production telemetry can reveal cases that pre-release tests missed, yet observation after release is not an ethical substitute for adequate pre-release assurance where failure could harm people.[2][18]

## Integration, builds, and release

Integration combines separately changed components and checks that they work together. Long-lived divergence increases the number of assumptions that can conflict at once. Martin Fowler's account of continuous integration describes developers integrating frequently into a shared mainline, with an automated build and self-testing used to detect problems rapidly.[22] Continuous integration is a feedback practice, not a claim that every successful build is ready for production.

A build transforms identified inputs into artifacts. It may compile source, resolve dependencies, generate code, run tests, package files, sign outputs, and create metadata. Reproducible Builds defines a reproducible build as one where the same source, build environment, and instructions produce bit-for-bit identical artifacts.[23] Reproducibility can help detect unexplained differences, but it does not show that the source is safe or that the build system was uncompromised.

Delivery makes a change deployable through a reliable process; deployment installs or activates it in an environment; release makes behavior available to users. These events can be separate. A mobile binary can be deployed to an app store before a server-side flag releases a feature. Database migrations may be deployed before code begins using the new schema. Separating steps can reduce risk if states and rollback constraints remain explicit.[22][23]

Version identifiers communicate identity and sometimes compatibility. Semantic Versioning 2.0.0 defines major, minor, and patch changes relative to a declared public API.[24] It is one convention, not a property automatically inferred from a version string. Products without a stable public API, date-based releases, continuously delivered services, protocols, and data schemas may need different compatibility policies.

Release engineering controls how artifacts are built, tested, identified, signed, promoted, deployed, and rolled back. Google's SRE account emphasizes self-service, high velocity, hermetic builds, and policy enforcement as principles for large-scale release systems.[25] These principles can be adapted rather than copied. A small project may need a short checklist and automated pipeline; a regulated system may need independent authorization and retained evidence.

Rollout strategies include all-at-once deployment, rolling replacement, canaries, phased cohorts, blue-green environments, and feature flags. Each changes exposure and recovery options. A canary only helps when the team can detect relevant harm before wider rollout. A rollback may be impossible after an irreversible data transformation or external side effect, so roll-forward and restoration plans must be designed in advance.[25]

## Security, privacy, and supply-chain integrity

Security is a life-cycle property, not a final penetration-test phase. NIST's Secure Software Development Framework supplies high-level practices that can be integrated into different development models to reduce vulnerabilities, limit the impact of undiscovered defects, and address root causes.[26] Its practice groups cover preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities.

Security work begins with context: assets, trust boundaries, attackers, abuse cases, exposure, and consequences. Threat modeling turns that context into design questions and testable controls. Secure defaults, least privilege, explicit authorization, input handling, isolation, cryptographic key management, logging, rate limits, and safe failure behavior are examples, not a checklist sufficient for every system. Controls also need operational ownership and a response path.[26]

CISA's Secure by Design guidance places responsibility on software producers to reduce the security burden on customers and emphasizes transparent, accountable product behavior and executive ownership.[27] This changes prioritization. A security feature that exists but is difficult to enable, unaffordable for ordinary customers, or disabled by default may provide less protection than its feature list suggests.

Privacy engineering asks what personal or sensitive data is necessary, how it is obtained, used, shared, retained, secured, corrected, exported, and deleted. The ACM Code calls for collecting only the minimum personal information necessary, defining and enforcing retention and disposal periods, and using personal information for legitimate ends without violating rights.[28] Those duties have to be translated into requirements and controls that match the system's actual data flows and the rules that apply to it.

Third-party components create both capability and supply-chain risk. An inventory should identify direct and transitive dependencies, versions, sources, licenses, and known vulnerabilities where feasible. The US National Telecommunications and Information Administration described minimum elements for a software bill of materials, including data fields, support for automation, and practices for generation and use.[29] An SBOM is an inventory artifact, not proof that listed components are trustworthy or that the running system exactly matches the document.

SPDX is an international open standard, ISO/IEC 5962:2021, for communicating information about software and related artifacts; the SPDX project lists version 3.0 as its current specification.[30] SLSA provides incrementally adoptable supply-chain security guidance and provenance mechanisms. Version 1.2 defines separate tracks and levels, with the Build Track covering levels 1 through 3.[31] Provenance can establish facts about how an artifact was produced, while review, testing, vulnerability analysis, and producer trust remain separate questions.

Secrets should not be stored in source or emitted to logs and build artifacts. Build and deployment identities should have only necessary privileges, and sensitive operations should be auditable. Dependency updates need testing, but indefinite pinning is also risky because security and compatibility fixes never arrive. A maintenance policy should define update cadence, emergency response, supported versions, and what happens when an upstream component is abandoned.[26][29][31]

## Accessibility, safety, and responsible practice

Accessibility concerns whether people with disabilities can perceive, understand, navigate, and operate a product. It belongs in requirements, design, implementation, content, testing, and support. For web content, WCAG 2.2 is a W3C Recommendation with technology-neutral, testable success criteria, while its supporting material explains techniques and interpretation.[32] Automated checks can find some defects, but keyboard use, focus behavior, assistive-technology interaction, language, cognitive load, and task completion also require human evaluation.[32]

Safety concerns unacceptable risk of physical injury or other harm. The required assurance depends on the domain and intended use. Medical, aviation, automotive, industrial-control, financial, and public-sector systems may be governed by different standards and regulators. A general web-development checklist cannot replace a domain-specific safety case, hazard analysis, independent verification, or legally required evidence.[1][2][28]

Responsible development includes examining foreseeable misuse, unequal impact, deceptive interaction, labor conditions, environmental cost, and the ability to contest or correct decisions. These are not all reducible to a model-accuracy metric. A product decision can be technically correct and still create avoidable harm through its defaults, incentives, access rules, or deployment context.[28]

The ACM Code of Ethics states responsibilities including avoiding harm, being honest and trustworthy, respecting privacy and confidentiality, producing high-quality work, and evaluating systems and their risks.[28] Professional codes do not settle every tradeoff, but they establish that responsibility extends beyond satisfying an immediate request. Escalation, refusal, independent review, or stopping a release can be appropriate when evidence is inadequate for the consequences.[28]

## Operation and reliability

Deployment exposes software to real workloads, integrations, users, failures, and adversaries. Operability therefore has to be designed. Useful telemetry includes enough context to understand behavior without collecting unnecessary sensitive data. Logs record events, metrics summarize measured quantities, traces relate work across components, and profiles show resource use. Their schemas and retention are part of the product because responders and users depend on them.[2][25][28]

A service-level indicator is a defined measure of behavior that matters to users, such as successful requests or latency. A service-level objective gives a target or range for an SLI. Google's SRE guidance recommends selecting a small set based on user needs and treating a permitted miss rate as an error budget rather than demanding 100 percent availability.[33] Objectives should specify population, window, aggregation, and exclusions; otherwise teams can report the same label while measuring different behavior.

Monitoring observes known signals. Alerting should identify conditions that require timely human or automated action, with ownership and a response procedure. Excess alerts create fatigue; missing alerts delay detection. Health checks can also be misleading if they test only that a process is running rather than whether users can complete a task.[33]

Incident response contains harm, restores service, communicates status, preserves evidence, and learns. Google's guidance on postmortem culture recommends blameless analysis focused on contributing conditions and corrective actions rather than punishment.[34] Blameless does not mean accountability is absent. It means the analysis seeks changes to design, tools, staffing, training, review, and response systems that make recurrence less likely.

Recovery objectives should be tested. A backup that has never been restored is only a claim. Disaster-recovery exercises can expose missing credentials, incompatible formats, insufficient capacity, undocumented dependencies, or unrealistic timing. Fault-injection exercises can provide evidence about resilience when scoped, authorized, observable, and designed to avoid unacceptable impact.[2][33][34]

Capacity and performance work connect forecasts with measured behavior. Load tests explore defined scenarios, while production observation reveals the actual distribution of requests and data. Averages can hide tail latency and burst behavior. Performance budgets and admission controls can make limits explicit before overload turns into cascading failure.[33]

## Maintenance and evolution

Maintenance begins as soon as other people or systems depend on the software. ISO/IEC/IEEE 14764 describes the maintenance process and defines maintenance types.[35] Maintenance includes correction, adaptation to changed environments, improvement, and work intended to prevent future problems. It can be constrained by data, interfaces, and user expectations that an original implementation did not yet have to preserve.[1][35]

Software evolution is constrained by history. Meir Lehman's 1980 paper described empirical laws for particular classes of evolving systems, including continuing change and increasing complexity unless work counteracts it.[36] These observations should not be universalized to every program, but they capture a common maintenance condition: a successful system accumulates stakeholders, integrations, data, and assumptions that make change consequential.

Ward Cunningham's 1992 experience report introduced the debt metaphor for the gap between expedient implementation and the design understanding needed to extend a system cleanly.[37] Technical debt is not simply all imperfect code. A deliberate shortcut may be rational when its consequence and repayment condition are understood. Calling every defect or disliked design debt hides whether the problem is correctness, risk, missing knowledge, obsolete technology, or a tradeoff that remains appropriate.

Refactoring changes internal structure while preserving intended observable behavior. Tests, static checks, reviews, and staged release provide evidence for preservation. Large rewrites trade accumulated constraints for migration, parity, and replacement risk. They can be justified, but only after identifying what the existing system actually does, which behavior users rely on, how data will move, and how long both systems must coexist.[18][35][36]

Compatibility has multiple dimensions: source, binary, protocol, schema, behavior, configuration, performance, and operational procedure. Deprecation communicates that a supported behavior is planned for removal. A useful deprecation policy states alternatives, timing, affected versions, and migration support. Silent removal transfers discovery cost to users and can turn a technically small change into an outage.[1][24][35]

Retirement is an engineering activity. It may require exporting or deleting data, revoking credentials, ending network routes, preserving legally required records, redirecting integrations, communicating deadlines, and verifying that dependent systems have moved. An unused service left reachable can remain a security and compliance liability.[1][26][35]

## Measurement and improvement

Measurement should begin with an information need and a decision, not with whatever a tool counts most easily. ISO/IEC/IEEE 15939 describes a measurement process for identifying needs, selecting and applying measures, analyzing results, and checking their validity.[38] A useful measure has a defined population, unit, collection method, interpretation, and limitation.

DORA's current software-delivery model uses five metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate.[39] DORA advises applying them to an application or service in context, using multiple measures, and avoiding targets that invite gaming or comparisons among dissimilar systems. The metrics describe delivery flow and instability; they do not by themselves measure user value, maintainability, safety, or individual contribution.

The SPACE framework likewise argues that developer productivity cannot be represented by one metric. Its dimensions are satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.[40] Measures should cover more than one dimension and more than one level, such as individual, team, and system. Lines changed, commits, tickets closed, review comments, and hours online can all be manipulated or misread when treated as productivity scores.

Good measurement supports learning. A team can establish a baseline, make a bounded process or design change, observe intended and unintended effects, and decide whether to keep it. Qualitative evidence from users and developers can explain why a numerical result changed. Segmenting by task or cohort can reveal harms hidden by an aggregate, provided privacy and statistical uncertainty are respected.[28][38][40]

Frederick Brooks argued in 1987 that no single development technology or management technique was likely to produce a tenfold improvement in software productivity within a decade, distinguishing difficulties inherent in specifying and designing software from accidental difficulties of tools and representation.[41] The prediction belongs to its historical context, but the distinction remains a warning against silver-bullet claims. Tools can remove substantial friction without deciding what should be built or making every tradeoff disappear.

## AI-assisted development

[Artificial intelligence](https://aiwiki.ai/wiki/artificial_intelligence) tools now assist with completion, search, explanation, translation, refactoring, test generation, review, and multi-step repository changes. Many are based on [large language models](https://aiwiki.ai/wiki/large_language_model) trained on natural language and source code. The 2021 Codex paper introduced HumanEval, a set of 164 handwritten Python synthesis problems, and reported pass-at-*k* results for models fine-tuned on public code.[42] These function-level tasks helped measure code generation, but they do not represent the full work described in this article.

[GitHub Copilot](https://aiwiki.ai/wiki/github_copilot), announced in private preview in June 2021, made model-generated completion directly available in an editor.[43] Later tools added chat, repository retrieval, file editing, command execution, and agent loops. AI-assisted review is one specialization. [Ellipsis](https://aiwiki.ai/wiki/ellipsis_dev) launched as a pull-request review agent that could post findings and generate a proposed fix after a developer mention.[50] This product example does not establish the accuracy of its findings or replace human review. These capabilities change the interface and amount of work a tool can attempt; they do not change who is responsible for a released result. Generated changes need the same requirements, review, tests, security analysis, provenance, and operational evidence as human-written changes, with extra attention to untrusted output and data sent to a provider.

Productivity evidence is mixed and tightly scoped. In a controlled experiment with 95 professional programmers, Sida Peng and coauthors found that participants with Copilot completed a specific JavaScript HTTP-server task 55.8 percent faster on average.[44] A later randomized trial by METR assigned 246 real tasks from mature open-source repositories to 16 experienced contributors. With early-2025 tools allowed, participants took 19 percent more time, even though they expected a speedup.[45] The authors explicitly limit the conclusion to their developers, repositories, tasks, and tools. Together, the studies show why neither result should be presented as a universal productivity effect.

Repository-level benchmarks test a different capability. [SWE-bench](https://aiwiki.ai/wiki/swe_bench) pairs real GitHub issues with repositories and tests whether a generated patch resolves the issue.[46] A score depends on the benchmark version, task filtering, test harness, model, agent scaffold, tools, retry budget, and evaluation policy. It does not directly establish maintainability, security, user value, or unattended performance in a particular organization.

Generated code can reproduce insecure patterns. Hammond Pearce and coauthors evaluated 1,689 Copilot-generated programs across 89 security-relevant scenarios and classified about 40 percent as vulnerable.[47] This 2021 product snapshot should not be treated as the vulnerability rate of every later model. It does demonstrate that plausible generation and security assurance are different questions.

Models can also invent dependencies. A USENIX Security 2025 study generated 576,000 Python and JavaScript samples using 16 models. It reported average hallucinated-package percentages of at least 5.2 percent for commercial models and 21.7 percent for open-source models under its experimental conditions.[48] A fabricated package name can become a supply-chain attack if it is later registered by an adversary. Mitigations include resolving dependencies against approved registries, checking package identity and provenance, restricting installation and build-network access, scanning lockfiles and artifacts, and reviewing whether a new dependency is necessary.

Effective use is task-dependent. AI assistance can be useful for bounded transformations, unfamiliar APIs, test ideas, repetitive migration work, or explaining a local fragment. It is less trustworthy when success depends on hidden organizational knowledge, recent external facts, broad architectural consistency, subtle security properties, or feedback the tool cannot observe. A reviewable workflow gives the model limited context and authority, records its changes, runs relevant checks, and keeps a human able to reject or revise the result.[17][44][45][47]

Privacy, confidentiality, license, and retention terms matter when code, logs, customer data, or credentials are sent to a model provider.[28] Agentic tools also create execution risk because files, websites, and data returned by tools can carry attacker-controlled instructions that hijack an agent.[49] NIST describes indirect prompt injection through controlled resources and notes that agent attacks can enable arbitrary code execution or data exfiltration.[49] Sandboxing, least-privilege credentials, constrained network access, protected branches, approval boundaries, and audit logs can limit the consequences of a mistaken or manipulated action.[26][31][49]

## Choosing and adapting a process

A process should be proportionate to risk and should create feedback soon enough to influence decisions. The following questions apply the life-cycle, security, measurement, and operational sources used throughout this article:[1][2][26][33][38]

- What outcome and user population define success?
- Which failures could cause serious, irreversible, or widely distributed harm?
- Which assumptions are uncertain, and what is the cheapest credible way to test them?
- What evidence is required before integration, release, and wider rollout?
- Which interfaces, data, and commitments must remain compatible?
- Who can make, review, approve, operate, and reverse each class of change?
- How will incidents, user feedback, security reports, and changed requirements return to development?
- How will the product and its data be supported, migrated, and retired?

For a low-risk internal script, answers may produce a short repository guide, automated tests, peer review, and a named maintainer. For a public service, they may add threat modeling, privacy review, staged delivery, on-call ownership, service objectives, and incident practice. For a safety-critical product, formal requirements, independent verification, configuration baselines, qualified tools, and regulator-defined evidence may be mandatory. More ceremony is not automatically more assurance; a control earns its place by reducing a stated risk or producing necessary evidence.[1][2][26][28][33]

Processes should themselves be reviewed. Retrospectives, incident analyses, delivery data, defect patterns, user research, security findings, and maintenance cost can expose a bottleneck or ineffective control. The response should be a testable change, not automatic adoption of a fashionable framework. Removing a redundant approval can improve both speed and responsibility, while adding an independent check can be justified where a single mistake has unacceptable consequences.[1][34][38][39][40]

The enduring structure of software development is a set of feedback loops. Stakeholder feedback corrects requirements. Prototypes and models correct design assumptions. Compilers, reviews, analyses, and tests correct implementation. Builds and deployment checks correct integration. Telemetry and support correct understanding of operation. Maintenance and retirement feed lessons into the next system. A capable development organization makes these loops visible, protects their evidence, and adapts their speed and rigor to the software's real consequences.[1][2][38]

## References

1. [ISO/IEC/IEEE 12207:2026, Systems and software engineering - Software life cycle processes](https://www.iso.org/standard/90219.html)
2. [IEEE Computer Society, Guide to the Software Engineering Body of Knowledge, Version 4.0](https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf)
3. [ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation - Product quality model](https://www.iso.org/standard/78176.html)
4. [NATO Science Committee, Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, 1968](https://www.peterkrantz.com/2011/software-engineering-in-1968/nato-software-engineering-conference-1968.pdf)
5. [Winston W. Royce, Managing the Development of Large Software Systems, 1970](https://www.praxisframework.org/files/royce1970.pdf)
6. [Craig Larman and Victor R. Basili, Iterative and Incremental Development: A Brief History, Computer, 2003](https://doi.org/10.1109/MC.2003.1204375)
7. [Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, 1988](https://doi.org/10.1109/2.59)
8. [Manifesto for Agile Software Development, 2001](https://agilemanifesto.org/)
9. [Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf)
10. [Tore Dyba and Torgeir Dingsoyr, Empirical Studies of Agile Software Development: A Systematic Review, Information and Software Technology, 2008](https://doi.org/10.1016/j.infsof.2008.01.006)
11. [ISO/IEC/IEEE 29148:2018, Requirements engineering](https://www.iso.org/standard/72089.html)
12. [ISO/IEC/IEEE 42010:2022, Architecture description](https://www.iso.org/standard/74393.html)
13. [David L. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules, Communications of the ACM, 1972](https://doi.org/10.1145/361598.361623)
14. [Scott Chacon and Ben Straub, Pro Git, Version Control chapter](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)
15. [Melvin E. Conway, How Do Committees Invent?, Datamation, 1968](https://www.melconway.com/Home/Committees_Paper.html)
16. [Michael E. Fagan, Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal, 1976](https://doi.org/10.1147/sj.153.0182)
17. [Alberto Bacchelli and Christian Bird, Expectations, Outcomes, and Challenges of Modern Code Review, ICSE, 2013](https://doi.org/10.1109/ICSE.2013.6606617)
18. [ISO/IEC/IEEE 29119-2:2021, Software testing processes](https://www.iso.org/standard/79428.html)
19. [Koen Claessen and John Hughes, QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs, ICFP, 2000](https://doi.org/10.1145/351240.351266)
20. [Yue Jia and Mark Harman, An Analysis and Survey of the Development of Mutation Testing, IEEE Transactions on Software Engineering, 2011](https://doi.org/10.1109/TSE.2010.62)
21. [Valentin J. M. Manes et al., The Art, Science, and Engineering of Fuzzing: A Survey, IEEE Transactions on Software Engineering, 2021](https://doi.org/10.1109/TSE.2019.2946563)
22. [Martin Fowler and Matthew Foemmel, Continuous Integration](https://martinfowler.com/articles/originalContinuousIntegration.html)
23. [Reproducible Builds, Definitions](https://reproducible-builds.org/docs/definition/)
24. [Semantic Versioning 2.0.0](https://semver.org/)
25. [Google, Site Reliability Engineering, Chapter 8: Release Engineering](https://sre.google/sre-book/release-engineering/)
26. [NIST SP 800-218, Secure Software Development Framework Version 1.1](https://doi.org/10.6028/NIST.SP.800-218)
27. [CISA and partner agencies, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software](https://www.cisa.gov/sites/default/files/2023-06/principles_approaches_for_security-by-design-default_508c.pdf)
28. [Association for Computing Machinery, ACM Code of Ethics and Professional Conduct](https://www.acm.org/code-of-ethics)
29. [US National Telecommunications and Information Administration, The Minimum Elements for a Software Bill of Materials](https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf)
30. [SPDX, Specifications](https://spdx.dev/use/specifications/)
31. [Supply-chain Levels for Software Artifacts, Specification 1.2](https://slsa.dev/spec/v1.2/about)
32. [W3C, Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/)
33. [Google, Site Reliability Engineering, Chapter 4: Service Level Objectives](https://sre.google/sre-book/service-level-objectives/)
34. [Google, Site Reliability Engineering, Chapter 15: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
35. [ISO/IEC/IEEE 14764:2022, Software life cycle processes - Maintenance](https://www.iso.org/standard/80710.html)
36. [Meir M. Lehman, Programs, Life Cycles, and Laws of Software Evolution, Proceedings of the IEEE, 1980](https://doi.org/10.1109/PROC.1980.11805)
37. [Ward Cunningham, The WyCash Portfolio Management System, OOPSLA Experience Report, 1992](https://doi.org/10.1145/157710.157715)
38. [ISO/IEC/IEEE 15939:2017, Measurement process](https://www.iso.org/standard/71197.html)
39. [DORA, Software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
40. [Nicole Forsgren et al., The SPACE of Developer Productivity, ACM Queue, 2021](https://doi.org/10.1145/3454122.3454124)
41. [Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, Computer, 1987](https://doi.org/10.1109/MC.1987.1663532)
42. [Mark Chen et al., Evaluating Large Language Models Trained on Code, 2021](https://arxiv.org/abs/2107.03374)
43. [GitHub, Introducing GitHub Copilot: your AI pair programmer, 29 June 2021](https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/)
44. [Sida Peng et al., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, 2023](https://arxiv.org/abs/2302.06590)
45. [Joel Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025](https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf)
46. [Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024](https://proceedings.iclr.cc/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-Abstract-Conference.html)
47. [Hammond Pearce et al., Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions, IEEE Symposium on Security and Privacy, 2022](https://arxiv.org/abs/2108.09293)
48. [Joseph Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025](https://www.usenix.org/conference/usenixsecurity25/presentation/spracklen)
49. [NIST AI 100-2e2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations](https://doi.org/10.6028/NIST.AI.100-2e2025)
50. [Ellipsis: Automated code reviews and bug fixes, Y Combinator, 2024](https://www.ycombinator.com/launches/KW7-ellipsis-automated-code-reviews-bug-fixes)