2.2Software Development Management Technology

Even for the same system, you can proceed by "planning everything up front, then building" or by "building small pieces and checking as you go." Understanding this difference in development approach (model), and how to estimate scale and effort, is the theme of this section.

2.2.1Development models

• The waterfall model proceeds through each step from requirements to acceptance in order, assuming no going back. It is easy to plan, but if a problem surfaces in a later step, rework tends to be large.
• Agile is an umbrella term for development approaches that repeat planning, building, and checking in small units (short periods), adapting flexibly to changing requirements. Scrum is agile's representative framework: it repeats short periods (sprints) while building the highest-priority features first.
• XP (Extreme Programming) is an agile method that emphasizes practices such as pair programming (two people share one screen, one writing code while the other checks it), frequent testing, and continuous integration.

2.2.2Common Frame and estimation

• The Common Frame defines, in shared terminology and work items, what should be done at each step of software transactions and development, to prevent misunderstandings between the customer and the developer.
• The function point method is an estimation technique that quantifies development scale based on the number and complexity of user-visible functions, such as screens, reports, and files. Its advantage is that it can be estimated relatively early, without deep knowledge of internal program structure.
• Effort expresses the amount of work as "number of people x duration" (e.g. person-month = the amount of work one person does in one month). Estimated scale is converted into required effort, which feeds cost and schedule planning.

Consider a project to renew a business system. If the requirements are largely fixed and unlikely to change much midway, the waterfall model suits proceeding methodically through requirements to acceptance in order. On the other hand, for something like a new smartphone app, where "you don't really know what's needed until you try it," an agile approach such as Scrum, repeating short sprints, suits better—releasing high-priority features bit by bit and adjusting the plan based on user reaction. If the team wants to emphasize quality further, adopting XP"s pair programming, where one person writes code while another checks it on the spot, front-loads some of the benefit of review during development itself. Early in a project, before detailed design is fixed, when a rough estimate of development scale and cost is needed, the function point method is used, counting user-visible elements such as screen counts and input/output file counts to derive scale. From that scale, required effort (e.g. "20 person-months") is estimated, which then feeds staffing plans, deadlines, and cost feasibility. Also, if the customer and the developer disagree on what "design" or "testing" actually covers, it tends to cause trouble later, so aligning the definition of steps and work items along the Common Frame becomes the foundation for the contract and progress management.

2.2.3Section summary

• Waterfall = steps in order, no going back assumed; agile = repeats small units, adapts well to change (Scrum = framework; XP = practices such as pair programming)
• The Common Frame is a guide that prevents misalignment of terms and work items between customer and developer
• The function point method estimates scale from the number and complexity of user-visible functions. Effort is "people x duration" (e.g. person-months)