5.1System Development Techniques

System development proceeds through stages, from the upstream work of deciding "what to build" to the downstream work of confirming "does it work correctly." Understanding what gets fixed at each stage, together with the techniques that raise design and implementation quality (decomposition guidelines, test coverage criteria, reviews), is the foundation for practical understanding that carries into the Applied Information Technology exam.

5.1.1The development process and design layers

• Requirements definition is the stage that clarifies the business requirements of users and clients, defining what the system must achieve. The requirements fixed here become the baseline for every later stage, and the later a requirement change happens, the larger the rework cost.
• External design (basic design) is the stage that designs the screens, reports, and interfaces visible to users. Internal design (detailed design) is the stage that designs, from a programmer's viewpoint, the internal structure, module decomposition, and data structures needed to realize the external design. The distinction is one of viewpoint: external design is "what the user sees," internal design is "what the developer implements."
• Module decomposition is the design technique of splitting a program into functional units. The quality of a decomposition is evaluated on two axes: module strength (cohesion—how tightly related the processing inside one module is; higher is better) and module coupling (how strongly modules depend on each other; lower is better). "High strength, low coupling" is the guiding principle for good design.

5.1.2Object-oriented design and UML

• Object-oriented design gathers data and processing into a single object (class), using encapsulation (hiding internal implementation), inheritance (reusing the properties of existing classes), and polymorphism (achieving different behavior through the same call) to increase modularity and reusability.
• UML (Unified Modeling Language) is the standard diagrammatic notation for expressing object-oriented design. Representative diagrams include the class diagram (static relationships between classes), the sequence diagram (message exchange between objects over time), the use case diagram (functionality as seen by users), and the state transition diagram (state changes). The right diagram type is chosen for the purpose at hand.

5.1.3Testing techniques and coverage criteria

• White-box testing focuses on a program's internal structure (logic and branches), designing test cases to cover the code's paths. Coverage criteria include statement coverage (C0), which exercises every statement at least once; branch (decision) coverage (C1), which exercises the true/false of every branch at least once; and condition coverage (C2), which exercises the true/false of every individual condition. C0 is the loosest, and coverage that combines conditions is progressively stricter.
• Black-box testing designs test cases from the relationship between inputs and outputs, without looking at internal structure. Representative techniques include equivalence partitioning, which divides inputs into valid/invalid ranges (equivalence classes) and picks a representative value from each, and boundary value analysis, which focuses verification near the edges of a range (the boundary itself and just inside/outside it). The advantage of boundary value analysis is that it is good at catching errors at boundaries (such as off-by-one mistakes).
• Reviews are the technique of manually examining code or documents to find defects early. Inspection is the most formal and rigorous review, following predefined roles (such as a moderator) and procedures. Walkthrough is a relatively informal verification technique in which the author leads the session and explains the work to participants. Reviews conducted at earlier (upstream) stages are considered to have a larger effect in curbing rework cost.

Trace the link between design and testing through the example of developing an order-amount calculation module. In internal design, if you carve out a module responsible for just one cohesive piece of work—"determine the discount rate and compute the total"—its module strength will be high. Conversely, if this module were built to directly overwrite another module's internal variables, coupling would rise, and a change on one side would more easily produce unexpected effects on the other. In test design after implementation, from a white-box perspective you would first confirm with branch coverage (C1) that "every branch for a 10%, 20%, and 0% discount rate is exercised at least once." Then, from a black-box perspective, if the discount rate is defined as "0% under 10,000 yen, 10% from 10,000 up to but under 50,000 yen, and 20% at 50,000 yen and above," boundary value analysis would focus testing on values near the boundaries, such as 9,999 yen, 10,000 yen, 49,999 yen, and 50,000 yen. Understanding that a boundary error (an off-by-one mistake)—say, "exactly 10,000 yen" unintentionally falling into the 0% branch—is easy to miss with equivalence partitioning's representative values alone, but is exactly what boundary value analysis is good at catching, helps you choose the right technique both in practice and on the exam. Finally, when this logic goes to code review, a light check just before release might be fine as a walkthrough, but for important logic like amount calculation where an error has a large impact, an inspection with a moderator following a set procedure is better suited to catching defects early.

5.1.4Section summary

• Development process = requirements definition -> external design (user viewpoint) -> internal design (developer viewpoint) -> implementation -> testing -> operations. High module strength, low coupling is good design
• UML diagrams are chosen by purpose: class diagram (static relationships), sequence diagram (time-ordered messages), use case diagram (user viewpoint)
• White-box testing focuses on internal structure (statement/branch/condition coverage); black-box testing focuses on input-output (equivalence partitioning/boundary value analysis). Inspection is the most formal; walkthrough is relatively informal