図は開発するソフトウェアの動作ロジックを検討し,その結果を文書化した流れ図の一部である。このような作業を実施するのはソフトウェア開発のどの段階か。 - 判定「IN ≧ 1」 - No → 「“エラー”と表示」(以下省略) - Yes → 判定「IN ≧ 4 AND IN ≦ 9」へ - Yes → 「“上半期”と表示」(以下省略) - No → 判定「IN ≦ 12」へ - Yes → 「“下半期”と表示」(以下省略) - No → 「“エラー”と表示」(以下省略)
平成22年度 春期 ITパスポート試験 問50
This question's explanation and your answers so far.
問 50
Incorrectア
System architecture design is the stage that allocates each system requirement to hardware, to software or to manual work, and that fixes the framework of the system as a whole, such as how it is divided into subsystems and what its hardware and network configurations are. It works at the level of how the components are arranged; it does not go as far as fixing the decision conditions and the order of processing inside an individual program. Detailed branching like that in the figure does not appear in the deliverables of this stage.
Incorrectイ
System requirements definition is the stage that, starting from the users’ business needs, organizes what the system to be developed should provide — its functions, performance, reliability, constraints and so on — as a statement of what is to be achieved. It does not yet decide the means of realization, and it sits at the very front of the development process. The figure shows how the processing is to be carried out, so it is not a deliverable of requirements definition.
- ウ
正解 The correct answer is ウ, software detailed design. For the input value IN, the flowchart in the figure lines up the decisions “IN ≧ 1”, “IN ≧ 4 AND IN ≦ 9” and “IN ≦ 12” one after another, and it settles, without leaving anything out, which display (“Error”, “First half”, “Second half”) each Yes / No branch leads to. In other words, it works out the internal processing steps of the program that sort an input value representing a month into first half, second half or error — the algorithm, the branch conditions and the order of processing — down to a level of detail fine enough to be coded directly, and records them in a document. In the development process of the Common Frame, the stage in which the internal logic of each software component is made this concrete and put into a form that can be handed over to programming is software detailed design, and a flowchart is one of its typical deliverables. The wording in the question, “examined the operating logic and documented the result”, refers to exactly the work of this stage.
Incorrectエ
Software requirements definition is the stage that, for the part allocated to software in system architecture design, specifies what the software is to do: its functions, its inputs and outputs, its interfaces, its screens and report forms, and so on. The function of judging first half or second half and displaying it is indeed decided here, but turning that into concrete decision expressions such as IN ≧ 4 AND IN ≦ 9 and into a sequence of branches belongs to the later stage, software detailed design.
- The development process of the Common Frame runs in the order system requirements definition → system architecture design → software requirements definition → software architecture design → software detailed design → programming → testing, moving from what to build toward how to build it, and from the system as a whole down to the individual software. Splitting the stage names along two axes makes them easier to tell apart: a name containing “requirements definition” is about what to build and one containing “design” is about how to build it, while “system” means the whole and “software” means the software part.
- Software detailed design is the stage that fixes the algorithms, branch conditions and handling of data inside a component down to a granularity that can be handed straight to programming. Flowcharts, pseudocode and state transition diagrams are its typical deliverables, so when a flowchart shows up, suspecting detailed design first is a reliable rule of thumb.