5.2Software Development Management

The best approach for building a system varies with how likely requirements are to change and how frequently releases are demanded. The goal here is to master how to choose a development model, DevOps and CI/CD for automating and accelerating development and release, and techniques for estimating scale numerically, so you can make situational judgments.

5.2.1Development model characteristics and selection criteria

• The waterfall model is the traditional model that proceeds through requirements definition, design, implementation, and testing in sequence, on the assumption that there is no going back. Each stage produces a clear deliverable, making it well suited to progress management on large projects, but it is poorly suited to projects where requirements are hard to fix mid-development (the later a requirement change happens, the larger the rework).
• Agile development is the umbrella term for development approaches that prioritize rapid response to changing requirements, incrementally building working software through repeated short periods (iterations/sprints). Scrum is one of the representative agile frameworks, in which work items are selected each sprint (a short, fixed period) from a priority-ordered product backlog. XP (Extreme Programming) is an agile method that emphasizes practices such as pair programming, test-driven development (TDD), and refactoring.
• Selection criteria: waterfall suits projects where requirements are clear, change is minimal, and large-scale, rigorous progress management is needed, while agile suits projects where requirements are likely to change and early user feedback needs to be incorporated. The key understanding is that the two are not a matter of superiority but of different applicable conditions.

5.2.2DevOps, CI/CD, and IaC

• DevOps is the culture and practice of Development and Operations collaborating to raise the frequency and reliability of releases. CI (Continuous Integration) is the mechanism of running automated builds and automated tests on every code change to catch integration problems early. CD (Continuous Delivery/Deployment) is the mechanism that automatically makes code that has passed CI ready to release to production (or actually releases it). CI/CD reduces manual release steps, helping achieve both release frequency and quality.
• IaC (Infrastructure as Code) is the technique of describing and managing infrastructure configuration—servers, networks, and so on—as code (definition files). Compared with manual provisioning, it offers higher reproducibility (the same code can build the same environment repeatedly) and the ability to version-control the history of configuration changes.

5.2.3Estimation techniques and configuration management

• The function point (FP) method estimates development scale by scoring the number and complexity of functions visible to the user--screens, reports, input/output data items, and so on. Its distinguishing feature is that it is independent of the programming language or implementation approach and measures scale from the user's viewpoint, allowing estimation from an early stage of requirements definition.
• COCOMO (Constructive Cost Model) is a model that estimates effort and development duration by formula, based on the estimated size (lines of code) of the program. Depending on development complexity there are three modes--organic, semidetached, and embedded--each with different coefficients. In contrast to the function point method, which starts from "the number of functions," COCOMO starts from "code size (lines of code)."
• Configuration management is the activity of systematically managing the versions and change history of deliverables such as programs and documents. Version control (systems) are the tools that record the change history of source code, enabling diff inspection, restoring past versions, and concurrent editing by multiple people (branching/merging). Configuration management is the broader concept, and version control is positioned as one of the core means of realizing it.

Take the launch of a new web service as an example of how these techniques connect. If requirements are still fluid and the plan is to add features while watching user reactions, rather than fixing everything up front with waterfall, it is better suited to proceed with Scrum, repeating short sprints to build the highest-priority features first and continually revisiting the product backlog. In the early estimate, since the implementation language and internal structure are not yet fixed, the function point method--which derives scale from the number of screens and input/output data items--is used to estimate "the amount of functionality visible to the user," setting a rough budget and schedule. As implementation progresses and the code-size outlook becomes clearer, a code-line-based model such as COCOMO is used to re-estimate effort and check the gap against the original estimate--this kind of role division happens in practice. As development proceeds, source code is managed in a version control system (such as Git), with feature additions developed in parallel via branches, reviewed, and merged--running a configuration management process. Every time code is merged, CI runs automated tests to immediately catch integration problems, and code that passes moves, via the CD mechanism, into a state ready for automatic release to staging and production environments. Furthermore, if server and network settings are captured as IaC definition files instead of manual work, staging and production can be built reproducibly from the same code, reducing failures caused by environment drift. Seeing that development model, estimation, configuration management, and CI/CD/IaC are not independent techniques but are connected by the common axis of how likely requirements are to change and how much automation is needed makes it easier to judge which technique fits a given situation.

5.2.4Section summary

• Waterfall suits clear requirements, large scale, rigorous management. Agile/Scrum/XP suit rapid response to changing requirements and early feedback (Scrum uses sprints + a product backlog)
• CI = early integration verification via automated build/test; CD = automated release preparation/execution. IaC turns infrastructure into code for reproducibility and version control
• Function point method starts from the number of functions (user viewpoint); COCOMO starts from lines of code. The core of configuration management (managing deliverable versions/change history) is the version control system