…というコトで，今日のサマーコースでは，
まず，名刺交換のマナーに関する講義を行ってから，
その後，昨日決めてもらった仮想の会社と役職を元に名刺を作り，
それを使って，実際に名刺交換を行いました！

それが終わった後は，各会社ごとに「みんながなりたい人物像」というテーマで，
ブレーンストーミングと KJ 法をやってもらい，結果を発表する…という流れでした。

特に，授業後半のブレーンストーミングと KJ 法については，
私も過去にやって，かなり苦戦した思い出があったので，
どんな結論に至るのか，そもそも収拾がつくのか，いろいろと不安だったのですが，
各会社とも，きちんと発表できていて良かったです！

私の貧相なボキャブラリーでは，良い言葉が思いつきませんが，
なんというか，学生さんの底力を見たような気がします(笑)

————— ｷﾘﾄﾘｾﾝ 8X —————

さてさて。

サマーコースがスタートしたことにより，そちらの準備にかまけすぎて，
ここ 2 日間，ソフトウェア開発技術者試験の勉強をまったくしてません…。

俗に言う，中だるみってヤツでしょうか？（ちょっと違う気もしますが）

しかし，おかげさまで，ストック（第 6 章の間違った問題）がまだあるので，
昨日を含め，更新作業は続けられています。

嬉しいような，悲しいような…(涙)

そんなこんなで，以下がストックされていた第 6 章の問題とその解説。

[問題1]
工数が 500 人日と見積もられたプロジェクトで開発を 5 人で開始したが，開発に遅れが出てきた。あと 40 日を残すところで，まだ 300 人日の工数が必要と見込まれるので，プログラマを増やすことにした。次の条件がある場合，予定どおり，40 日でプロジェクト開発を完了するには，少なくとも何人のプログラマを増やせばよいか。

　＜条件＞
　　1. 最初からプロジェクトに参加しているプログラマのうちの 1 人が，増やしたプログラマ全員に対して
　　　 5 日間の教育を行う
　　2. 作業の再分割のために，さらに (0.5a ＋ 6) 人日の工数が必要となる（a は増やしたプログラマの人数）
　　3. プログラマを増やしたことによるその後のコミュニケーションのオーバーベッドは無視できる

　(ア) 3　　　(イ) 4　　　(ウ) 5　　　(エ) 6　

この問題の答えを導くには，最初に今の時点でどれだけの遅れが出ているかを求め，
次に，その遅れ分を追加の人員，何人でカバーすれば良いかを考えます。

このまま 5 人で 40 日間作業を行うとすると，
この人数でこなせる作業量は，以下のようになります。

　5 × 40 ＝ 200 (人日)

しかし，問題文にあるように，まだ 300 人日分の作業が残っているので，
以下の分だけ，追加人員でカバーしなければならないことが分かります。

　300 － 200 ＝ 100 (人日)

ただし，実際には，作業の再分割と追加人員への教育を行っている間は作業が行えないので，
この 100 人日とあわせて，それらについても，追加人員がカバーする必要があります。

ここまでをふまえると，新たに追加されたプログラマが担当しなければならない作業量は，
「残りの作業 ＋ 作業の再分割中に行えたはずの作業 ＋ 教育中に行えたはずの作業」なので，
問題分の条件より，

　100 ＋ (0.5a ＋ 6) ＋ 5　　　… (*)

となります。

また，残りの 40 日間で追加人員 a 人が作業できるのは，
教育を受けている 5 日を引いた 35 日間で，この間の追加人員の作業量は，

　(40 － 5) × a （人日）

となり，これが (*) と等しければよいので，以下のような式が成り立ちます。

　100 ＋ (0.5a ＋ 6) ＋ 5 ＝ (40 － 5) × a

これを解くと，

　100 ＋ 0.5a ＋ 6 ＋ 5 ＝ 35a
　　　　　　　(35 － 0.5)a ＝ 111
　　　　　　　　　　　　　　a ＝ 111 ÷ 34.5
　　　　　　　　　　　　　　　＝ 3.217391304　　← 3 よりも大きいので，3 人だと足りないことが分かります 　

よって，答えは (イ) となります。

いよいよ今日から，サマーコースの第 2 クールが始まりました！

以前のブログにも匂わせていた？とおり，私も，仲良しのある先生と一緒に，
「素敵な大人になるために ～手取り足取りビジネスマナー講座～」なるものを開講しています。

ビジネスマナーというと，ものすごくお堅いイメージがありますが，
この講座の目的は，マナーそのものを身につけることももちろん大切ですが，
それよりも，社会人として必要となる社交性とか積極性とか，
どちらかというとそちらに重きを置いて，「講義 ＋ 実技」という形で授業内容を組んでいます。

初日の今日は，現時点でのマナー度を知ってもらうためのマナーチェックと簡単な講義を行ってから，
学生さんをくじ引きでランダムに振り分けて，仮想の会社を作り，
会社の名前はもちろん，グループのメンバー内で，役職（社長・部長・係長）を決めてもらいました。

やはり最初は，校舎も学科も学年も違う社員（グループのメンバー）同士，お互いに遠慮がちでしたが，
学生さんたちに，より仲良くなってもらうために行った「会社対抗・ビジネスマナークイズ」の後は，
わりと打ち解けてくれていたようで，安心しました！

ちなみに，この講義では，授業開始後すぐに，
人前でしゃべることに慣れるのを目的とした 60 秒間スピーチ（時間は少しずつのばします）を
受講者全員にしてもらっています。

今はまだ話す内容にとまどっている感じですが，
最終日に，皆さんがどれくらい話せるようになるのかが，すごく楽しみです！

————— ｷﾘﾄﾘｾﾝ 8X —————

前置きが長くなってしまいましたが，第 6 章の間違った問題の続きです！

[問題1]
システムインテグレーションに関する記述のうち，適切なものはどれか。

　(ア) システムインテグレーション事業を行うためには，経済産業省に届出が必要である
　(イ) システムの企画からシステム構築，運用，保守までに必要となる業務を一貫して
　　　 請け負うサービス形態であり，一定基準を満たす事業者に対して優遇税制もある
　(ウ) ユーザが，情報システムの開発，運用，保守などに関するすべての作業，
　　　　または一部の作業を外部の専門企業に発注し，トータルなコスト削減を
　　　　図ることである
　(エ) ユーザの問題を解決するために，システム統合パッケージを利用した総合的な開発を
　　　　行うことである

[問題2]
TCO(Total Cost of Ownership) に関する記述のうち，適切なものはどれか。

　(ア) システム上にデータベースを独占的に構築しているユーザが負担すべき費用の総和である
　(イ) 情報システムについて，導入から維持管理に至るまでの費用の総和である
　(ウ) ソフトウェアについて，企画から保守に至るまでの費用の総和である
　(エ) パソコンの購入に関して，ユーザが負担する機器およびソフトウェアの費用の総和である

以下，問題の解答と解説です！

[問題1] (イ)
システムインテグレーションとは，システムの企画からシステム構築，運用，保守までに
必要となる業務の一部，あるいはすべてを一貫して請け負う事業（サービス）のことを
いいます。
　(ア) システムインテグレーション事業を行うために，経済産業省への届出は必要ありません
　(イ) SI 事業者としての一定基準を満たした業者は経済産業省が認定し，情報サービス企業台帳に
　　　　登録され公表されるという SI 登録制度（有効期間は 2 年間で，2 年ごとに更新が必要）が
　　　　あります
　(ウ) アウトソーシングに関する記述です
　(エ) システムインテグレーション事業は，「開発」のみを請け負うことではありません
　　　 また，システム統合パッケージの利用は条件としていません

[問題2] (イ)
TCO(Total Cost of Ownership) は，運用。保守費用はもちろんのこと，教育研究費，
ユーザサポート費など，情報システム部門や利用者部門で発生するすべてのコストであり，
「システムの導入から維持管理に至るまでのすべての費用の総和」を意味します。

今日は 6 年に 1 度の皆既月食が見られる…ということで，
なかなかウキウキしていたのですが，肝心の天候があいにくの曇天！

月食どころか，空自体が見えるか否かという，そんなレベル。
まだ生まれてこの方 1 度も見たことがなくて，
楽しみにしていただけに，かなりショックです(涙)

ただ，天気ばかりはどうしようもないので，
おとなしく ネット上のニュース画像 で我慢しておきます…。

————— ｷﾘﾄﾘｾﾝ 8X —————

さてさて。

第 6 章の間違った問題も，早くも第 3 弾…ということで。

[問題1]
内部設計書のデザインレビューを実施する目的として，適切なものはどれか。

　(ア) 外部設計書との一貫性の検証と要求定義の確認
　(イ) 設計記述規約の遵守性の評価と設計記述に関する標準化の見直し
　(ウ) テストデータ仕様の確定とテストケースの網羅性の評価
　(エ) 要求定義の内容に関する妥当性の評価と外部設計指針の見直し

[問題2]
2 つの独立したテストグループ a，b が，あるシステムについて一定期間並行してテストを行い，それぞれ Na 個および Nb 個のエラーを検出した。このうち，共通のエラーはNab 個であった。グループ a，b のエラーを検出する能力および効率は等しいものと仮定する。このシステムの総エラー数 N を予測する式はどれか。ここで，Na ＞ 0 ，Nb ＞ 0，Nab ＞ 0 とする。

　(ア) N = Na + Nb – Nab　　　(イ) N = Nab × Na × Nb
　(ウ) N = (Na + Nb) / Nab　　(エ) N = (Na × Nb) / Nab

[問題3]
ソフトウェア品質特性に関する記述のうち，保守性を表しているものはどれか。

　(ア) 運用管理が容易である　　(イ) 故障しても容易に回復できる
　(ウ) スループットが高い　　　　 (エ) プログラムの解析が容易である

ここまでの解答と解説！

[問題1] (ア)
内部設計では，外部設計で定義された各機能をプログラムに分割し，
プログラム間の関連や，データや処理の流れを明確にします。
また，内部設計書のデザインレビューのポイントは，以下のとおりです。
　　　・外部設計書との整合性（機能がもれなく設計されているか，など）
　　　・プログラム間インタフェースの誤り，論理的な矛盾はないか，など
　　　・設計書（ドキュメント）が標準に準拠しているか
　　　・次工程であるプログラム設計へ配慮された内部仕様書となっているか

[問題2] (エ)
2 段階エディット法は，まったく独立した 2 つのテストグループ a，b が
テストケースやテストデータをそれぞれのグループで用意し，一定期間
並行にテストを行います。その結果，グループ a が検出したエラー数が Na 個，
グループ b が検出したエラー数が Nb 個であり，そのうち Nab 個が
共通するエラーであった場合，システム総エラー数 N は下記の式によって
推定できます。
　　　　　　　　　　　N = (Na × Nb) / Nab

[問題3] (エ)
保守性とは，システムの変更・拡張がどれくらい容易に行えるかということであり，
保守性を高めるためには，以下の事項が重要となります。
　　　・解析性：バグの修正作業の際，設計書やプログラムの解析が用意に行える
　　　・変更性：システムの変更や拡張がしやすい
　　　・安定性：システムの一部の修正がほかの部分に影響を与えない
　　　・試験性：修正後のテストが容易である
なお，(ア) は使用性（運用性），(イ) は信頼性（回復性），(ウ) は効率性（時間効率性）を表します。

[問題3] は，「保守」って，「運用」とセットでよく聞くので，
ついつい (ア) が答えかと思ってしまいました…。

案の定，それで間違えたわけですけども(涙)

朝から嫌なモノを見つけてしまいました。

鏡に映ったカーテンにへばりついていたのは，

なんと…ムカデ！！

ティッシュペーパーを使って，ちょっとだけ戦ってはみたのですが，
気持ち悪いのなんのって，もうハンパないです(涙)
しかも，出勤前の貴重な時間を割いたにも関わらず，最終的には敵を見失うという大失態！

こうしている今も，部屋のどこにいるか分からないので，
今日はちょっとうちに帰りたくありません…。

————— ｷﾘﾄﾘｾﾝ 8X —————

気を取り直して，間違った問題，第 2 弾！

[問題1]
ソフトウェアの要求定義や分析・設計で用いられる技法に関する記述として，適切なものはどれか。

　(ア) 決定表は，条件と処理を対比させた表形式で論理を表現し，複雑な条件判定を
　　　　ともなう要求仕様の記述手段として有効である。プログラム制御の条件漏れなどの
　　　　チェックにも効果がある
　(イ) 構造化チャートは，システムの "状態" の種別とその状態が遷移するための
　　　　"要因" との関係をわかりやすく表現できる
　(ウ) 状態遷移図は，DFD に "コントロール変換とコントロールフロー" を付加して，
　　　　制御系システムに特有な処理系形態を表現することができる
　(エ) 制御フロー図は，データの "源泉，吸収，流れ，処理，記憶" を基本要素とし，
　　　　システム内のデータの流れのネットワークを表現することができる

[問題2]
データ中心アプローチに関する記述として，適切なものはどれか。

　(ア) 設計の初期の段階から，論理設計と物理設計を一体のものとして扱う
　(イ) データ中心アプローチによって開発されたシステムでは，複数の業務が
　　　　それぞれ個別に構築したデータベースを利用する
　(ウ) データの構造は変わりやすいが，プロセスの仕様は対象業務が変わらない限り
　　　　比較的安定している，という前提に立つ
　(エ) データを共有資源とみなし，その一貫性や完全性維持を重視して資源側から
　　　　ソフトウェアを規程する，という考え方に基づく

[問題3]
トップダウンテストと比較したときのボトムアップテストに関する記述のうち，適切なものはどれか。

　(ア) 既存のシステムを修正してシステム開発する場合よりも，新規に開発する
　　　　システムに適用すると効果がある
　(イ) テストの最終段階で，モジュール間のインタフェース上の問題が発見されたときの
　　　　影響が大きい
　(ウ) 未開発の上位のモジュールを代行するスタブが必要になる
　(エ) モジュール数の多い下位の部分から開発していくことになるので，開発の初期の
　　　　段階ではプログラミングとテストの並行作業が困難である

ここまでの解答と解説！

[問題1] (ア)
決定表（デシジョンテーブル）は，複雑な条件とそれによって決まる処理を
分かりやすく表形式にまとめたもので，複雑な論理の説明を行うのに有効な手法です。
(イ) は状態遷移図，(ウ) は DFD を拡張して制御とタイミングを
表現できるようにした制御フロー図（変換図），(エ) は DFD の説明です。

[問題2] (エ)
データ中心アプローチ（DOA：Date Oriented Approach）とは，最も安定した情報資源である
データに着目し，データ構造からシステムあるいはソフトウェアを開発することです。
　(ア) 概念設計，論理設計，物理摂家の順に行われます
　(イ) システムの安定性や拡張性を保証するうえでも，個別データベースではなく，
　　　　全社的なデータベースを利用する
　(エ) データを共有資源とみなし，その一貫性や完全性維持を重視して資源側から
　　　　ソフトウェアを規定する，という考え方に基づく

[問題3] (イ)
以下，自分メモ参照。

★ ボトムアップテスト

　・モジュール数の多い下位の部分から開発していくことになるので，最初から
　　プログラミングとテストの並行作業が可能です。
　・テストの最終段階で，モジュール間のインタフェース上の問題が発見されたときの
　　影響が大きくなります。
　・既存のシステムを修正してシステム開発する場合に適しています。

★ トップダウンテスト

　・モジュール数の少ない上位モジュールから開発していくことになるので，
　　初期段階では，プログラミングとテストの並行作業が困難です。
　・重要度の高い上位モジュールが何回もテストでき，上位モジュールの
　　インタフェースの信頼性が高くなります。
　・新規に開発するシステムに適用します。

第 6 章の問題集にチャレンジしてみました。

範囲が広いのと，カタカナの暗記モノが多いのとで，
惨憺たる結果（16 問不正解）になりました…。
なので，当分は第 6 章の間違った問題でこのブログが賑わいそうです(汗)

…以下，間違った問題たち，第 1 弾！

[問題1]
プログラム言語に関する記述のうち，正しいものはどれか。

　(ア) オブジェクト指向言語である Smalltalk-80 では，すべてのデータは
　　　　オブジェクトであり，また，すべての計算はオブジェクトにメッセージを
　　　　送ることによって行われる
　(イ) 関数型言語である Lisp では，逆向き推論や，バックトラックという
　　　　すべての処理の組み合わせを漏れなく実行するために機能が用意されている
　(ウ) 手続き型言語である Pascal では，リストや 2 分木などの再帰的データ構造を
　　　　直接的に定義するしくみが用意されていて，自分自身のプログラムもリストで
　　　　表現される
　(エ) 論理型言語である Prolog では，基本的命令を単純に逐次的に実行するだけでなく，
　　　　現在の変数の値に従って命令の実行の仕方を変化させることができる

[問題2]
Java の特徴に関する記述のうち，適切なものはどれか。

　(ア) Java コンパイラがソースコードをバイトコードに変換し，Java 仮想マシンが
　　　　バイトコードを実行する
　(イ) Java で開発したプログラムを実行するためには，ブラウザが必要である
　(ウ) Java で開発したプログラムを別のプラットフォームで実行するためには，
　　　　再コンパイルが必要である
　(エ) アプレットは，セキュリティ上の理由から，ブラウザが動いているマシン以外とは
　　　　通信できない

[問題3]
ウォータフォールモデルによる開発工程で作成されるドキュメントに関する記述のうち，適切なものはどれか。

　(ア) 外部設計レビュー報告書を，内部設計フェーズに入って最初のステップで作成する
　(イ) 結合テスト計画書を，プログラム設計フェーズで作成する
　(ウ) システム化計画書および要求仕様書を，外部設計フェーズで作成する
　(エ) 単体テスト計画書を，プログラムのコーディングと同時に作成する

ここまでの解答と解説！

[問題1] (ア)
オブジェクト指向言語は，オブジェクト指向を実現する言語であり，すべてのデータを
オブジェクトとして扱い，また，すべての計算はオブジェクトにメッセージを
送ることで実現されます。
　(イ) 論理型言語である Prolog では…，とすれば正しい
　(ウ) 関数型言語である Lisp では…，とすれば正しい
　(エ) 手続き型言語である Pascal では…，とすれば正しい

[問題2] (ア)
Java の最大の特徴は，開発・実行においてプラットフォームを選ばない点にあります。
Java は，ソースコードのコンパイルによって生成されたバイトコードのレベルで互換性がとれているため，一度生成されたバイトコードはそれぞれのプラットフォームに用意されている仮想マシンによって実行が可能となります。
　(イ) Java で開発されたプログラムの実行に必要なのは仮想マシンです。
　　　　実際にはアプレットに呼ばれ，仮想マシンを実装したブラウザ上で動く
　　　　プログラムもありますがが，厳密にはブラウザがプログラムを
　　　　実行するわけではありません
　(ウ) バイトコードのレベルで互換がとれているため，再コンパイルの必要はありません
　(エ) アプレットのように Web サーバなどからバイトコードをダウンロードし，
　　　　ブラウザ上で実行させるようなプログラムは，セキュリティ上の理由から
　　　　サーバホストとの通信しか許されません

[問題3] (イ)
ウォータフォールモデルにおける各フェーズの手順と主な成果物については，
この記事の下の自分メモを参照。

全部で 78 問あったので，62 問正解（正答率：約 79 ％）できたことになるのですが，
午前の問題全体でそれくらいの正答率じゃないといけない…と考えると，
やっぱり，まだまだ勉強不足ですね(汗)

精進します！

————— ｷﾘﾄﾘｾﾝ 8X —————

以下，問題 3 の解説と連動？した自分メモ！

★ ウォータフォールモデルにおける各フェーズの手順と主な成果物

　　　[基本計画]　　システム化計画書，要求仕様書，開発化計画書
　　　　　↓
　　　[外部設計]　　外部設計書，外部設計レビュー報告書
　　　　　↓
　　　[内部設計]　　内部設計書，内部設計レビュー報告書
　　　　　↓
　[プログラム設計]　プログラム設計書，プログラム設計レビュー報告書，総合テスト計画書
　　　　　↓
　[プログラミング]　モジュール設計書，単体テスト計画書(*)，ソースプログラム
　　　　　↓
　　　　[テスト]　　各テストの報告書

(*) … 単体テスト計画書は，プログラムのコーディングの前に作成する

夏休み短期集中講座ということで，今日からいよいよ，
サマーコースの第 1 クール（23 日 ～ 29 日）がスタートしました！

今年は初の試みで，学生の皆さんからいただいたアンケートを参考に
開講科目を決定しているので，
昔はなかった科目なんかもあって，例年よりもおもしろそうです。

第 2 クール以降はまだ申し込みがいけるみたいなので，
良かったら今からでも申し込んでみてくださいね！
（ちなみに，学外の方向けのサマーコースもあります！）

そんな私も，第 2 クールに開講予定なので，
今日からまったり準備開始。

久しぶりの授業（前期以来）になるので，ちょっと緊張です(汗)

————— ｷﾘﾄﾘｾﾝ 8X —————

そんなこんなでなかなか進まない第 6 章。

焦らずマイペースをモットー（むしろ，自分にそう言い聞かせてます）に，
続・自分メモということで！

★ モジュール分割技法

　・STS 分割
　　→ プログラムを入力処理機能（源泉：Source），変換処理機能（変換：Transform），
　　　　出力処理機能（吸収：Sink）の 3 つのモジュールに分割します。
　　　　また，「入力とはいえない点まで抽象化された地点」である最大抽象入力点と
　　　　「はじめての出力データといえる形を表す点」である最大抽象出力点で
　　　　分割を行います。

　・TR 分割（トランザクション分割）
　　→ 入力トランザクションの種類により実行する処理が異なる場合に有効な分割技法です。
　　　　トランザクションを入力するモジュール，トランザクションを属性ごとに
　　　　各モジュールに振り分けるモジュール，トランザクションごとの処理モジュールの
　　　　3 つに分割します。

　・共通機能分割
　　→ STS 分割，TR 分割などで分割されたモジュールの中に，共通する機能をもった
　　　　モジュールがある場合，それを共通モジュールとして独立させる方法です。

　・ジャクソン法
　　→ 出力データ構造に基づいて分割を進める構造化設計技法です。
　　　　データ構造は JSP 木を用い，「基本」，「連続」，「繰返し」，「選択」の
　　　　4 つの要素を組み合わせた階層的木構造で表現します。

　・ワーニエ法
　　→ 集合論に基づく構造化設計技法です。
　　　　入力データ構造を元に「いつ，どこで，何回」という考え方でプログラム全体を
　　　　ブレイクダウンし，展開していきます。
　　　　なお，プログラムの基本論理構造は，「スタート部」，「処理部」，「エンド部」の
　　　　部分集合から構成されます。

ちなみに，赤字がデータの流れに着目した分割技法で，
青字がデータの構造に着目した分割技法です！

うーん。

正直，覚えられない！(汗)