4.4Software Development Management (Agile, DevOps/CI-CD, Estimation, Configuration Management)

Software-development-management questions split into two broad types: judging which development model fits a given situation, and computing/tracing estimation and configuration-management procedures. The key to scoring is understanding the differing assumptions behind waterfall and agile (are requirements settled, or is change assumed?) for the former, and precisely grasping the calculation logic of the function point method and COCOMO for the latter. This section proceeds from development models through estimation to configuration management, following the flow of real-world decision-making.

4.4.1Development models (waterfall, agile)

• The waterfall model progresses requirements -> design -> implementation -> testing strictly downstream, in principle without going back. It suits large systems where requirements are settled early and change little. The spiral model repeats design, implementation, and evaluation accompanied by risk analysis, progressively refining a prototype through iterations.
• Agile development is an umbrella term for development models that repeat planning, design, implementation, and testing in short cycles (iterations/sprints), emphasizing early and continuous delivery of working software. It assumes requirements will change and welcomes responding to change, in contrast to waterfall.
• Scrum assigns roles — a product owner (prioritizing requirements and managing the product backlog), a Scrum master (supporting the team and smoothing the process), and a development team — and implements sprint backlog items within fixed-length sprints (typically 1-4 weeks). It has recurring events: a daily scrum (a short daily progress sync), a sprint review (demoing and reviewing the increment), and a sprint retrospective (reflecting on the process).
• XP (Extreme Programming) is an agile method built on practices such as test-driven development (TDD) (writing test code before the implementation), pair programming (two developers sharing one workstation, implementing and reviewing simultaneously), refactoring (improving internal structure without changing externally observed behavior), and continuous integration.

4.4.2DevOps, CI/CD, and IaC

• DevOps is a culture and set of practices in which development and operations collaborate closely, achieving both frequent releases and reliability. It aims to resolve the friction in traditional organizations where development and operations are siloed and tend to conflict — development wanting to release quickly, operations prioritizing stability.
• CI (continuous integration) is the practice of developers integrating changes into a shared repository frequently, running an automated build and tests on every integration to catch problems early. CD (continuous delivery/deployment) takes a build that has passed CI and either automatically keeps it ready to deploy to a production-equivalent environment (delivery), or automatically deploys it all the way to production (deployment). Distinguish the endpoint: delivery = staying deployable; deployment = actually auto-deploying.
• Infrastructure as Code (IaC) describes infrastructure configuration (servers, networking) as code (configuration definition files) rather than manual steps, subjecting it to version control and automated application. Benefits: reproducibility, a trackable change history, and reduced environment drift. SRE (Site Reliability Engineering) applies software-engineering methods to operational reliability, characterized by quantitative reliability management using SLI/SLO/error budgets.

4.4.3Estimation techniques and configuration management

• The function point method is an estimation technique that counts user-visible functional elements (screens, reports, files, external interfaces, etc.) and sums them, weighted by complexity. Its advantage is being independent of the programming language or code volume, and usable for estimation from early in requirements definition.
• COCOMO (Constructive Cost Model) estimates development effort based on program size (estimated lines of code), using coefficients that depend on the nature of the project (embedded, semi-detached, or organic). In basic COCOMO, effort = coefficient x (size)^exponent — a power-law relationship capturing the tendency for effort to grow faster than size itself as the project gets larger (diseconomies of scale).
• Configuration management is the activity of tracking change history while maintaining consistency among configuration items (source code, documents, configuration files, etc.). Version control (e.g. Git) is the core technology underpinning configuration management, managing change history through operations such as commits (recording changes), branches (parallel lines of change), merges (integrating branches), and tags (marking a specific point in history).
• Change management (the change-request process) ensures changes to configuration items are not made haphazardly, but go through a controlled process: change request -> impact assessment -> approval -> implementation -> recording. This preserves accountability for who changed what, when, and why, preventing unintended side effects from creeping in.

Trace how a company moves from traditional waterfall development to agile and DevOps, aiming to reconcile release frequency with quality, and see the role each element plays. Previously, requirements, design, implementation, and testing proceeded sequentially over six months, and a mismatch with requirements discovered at the testing stage tended to be overlooked because going back was so costly. The team adopts Scrum: the product owner continually reprioritizes the product backlog, and each two-week sprint switches to a cycle of actually delivering working software and gathering feedback in a sprint review. Within the team, XP's test-driven development (TDD) is adopted — writing test code before the implementation catches specification misunderstandings early — combined with pair programming to review code as it is written. For the release pipeline, CI is set up so every integration into the shared repository triggers an automated build and tests, and CD (continuous delivery) keeps a build that has passed those tests ready to automatically deploy to a production-equivalent environment. Server and network configuration is also codified as IaC, tracked through version control so configuration changes have a traceable history, preventing environment-to-environment drift (the classic "it only breaks in production" problem). To estimate the scope of new features, the team adopts the function point method, sizing work by user-visible functional count (screens, reports, external interfaces) rather than lines of code, so stakeholders can share a sense of scale even early in requirements definition. Meanwhile, for a large-scale core-system overhaul where requirements are settled early and change little, the waterfall model remains a good fit — the shortcut of assuming "agile is always superior" should be avoided.

4.4.4Section summary

• Waterfall = settled requirements, no going back; agile (Scrum/XP) = short iterations assuming change. Scrum's three roles and three events. XP = TDD, pair programming, refactoring
• CI = frequent integration + automated tests; CD = staying deployable, or actually auto-deploying. IaC codifies infrastructure configuration under version control
• Function point method = estimate from user-visible functional count; COCOMO = estimate effort as a power-law function of code size. Configuration management = consistently tracking change history