ビジネスマナー講座・2 日目

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

それが終わった後は,各会社ごとに「みんながなりたい人物像」というテーマで,
ブレーンストーミングと 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 人だと足りないことが分かります  

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

comments

ビジネスマナー講座・初日

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

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

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

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

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

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

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

————— キリトリセン 8X —————

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

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

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

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

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

以下,問題の解答と解説です!

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

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

comments

まだまだ暑いですね

今日も暑いなぁ…と思い,何気に部屋のエアコンのリモコンを見たら,
設定が「暖房」になっていました。

エアコンのリモコンです

…どおりで,暑いはずです。

ちなみに,明日から,私の担当するサマーコースが,
いよいよ開講になりますが,暑さに負けずに頑張りたいと思います!

————— キリトリセン 8X —————

なんだかんだで,第 6 章の間違った問題も,とうとう第 4 弾!

さすがに 16 問も間違えると,問題をアップする作業も
なかなか骨が折れます…。

[問題1]
ファンクションポイントの長所,短所を示すものはどれか。

 (ア) 長所:小規模のシステムでは制度の高い見積もりができる
    短所:単位作業までの分解がプロジェクトの初期では困難
        妥当な基準値の設定のために実績データの収集・評価が必要
 (イ) 長所:ソフトウェア規模から工数・工期を見積もるので,
       担当者の経験にあまり左右されない
    短所:プロジェクトの初期には適用が困難である
       開発規模の見積もりはできない
 (ウ) 長所:ソフトウェアの大局的な性質から,プロジェクト全体にかかる
       インテグレーションやマネジメントなどのコストを効率的に
       見積もることができる
    短所:個々の技術的な問題が見落とされやすい
 (エ) 長所:プロジェクトの比較的初期から適用できる
        ユーザとのコンセンサスをとりやすい
    短所:妥当な基準値の設定のために実績データの収集・評価が必要

[問題2]
ベームが開発した見積もりモデルである COCOMO について,適切な記述はどれか。

 (ア) 開発工程における WBS ごとに作業工数を積み上げるコスト見積もりモデルである  (イ) 開発の専門化が過去の経験から類推してソフトウェアの規模を見積もる
    モデルであり,デルファイ法によってその見積もり値を収束していく
 (ウ) ソフトウェアの機能を入出力の数やマスタファイルの数でとらえ,難易度を
    考慮しながらソフトウェアの規模を見積もるモデルである
 (エ) ソフトウェアの規模を入力変数として,コスト誘因とそれに対する係数を
    考慮しながら開発工数を計算するコスト見積もりモデルである

ここまでの解答と解説!

[問題1] (エ)
ファンクションポイント (FP) 法とは,システムがユーザに提供する
機能(ファンクション)を規定の方法により定量化し,ソフトウェア開発工数の
見積もり尺度とする方法です。特徴は,以下のとおり。
  ・ユーザから見える画面や帳票などを単位として見積もるため,
   ユーザにとって理解しやすい
  ・機能を定量化するため,過去の多くの実績データが必要となる
  ・見積もりを適用する際の,解釈の標準化が必要である

[問題2] (エ)
COCOMO(COnstructiv COst MOdel)は,ベームによって提唱されたコストモデルで,
プログラムの行数(KLOC:Kilo Lines Of Code)から統計的なモデルを用いて
開発工数(人月),開発期間を算出します。
     開発工数 P = a × K の b 乗 × 努力係数(人月)
     開発期間  = 2.5 × P の c 乗

上式の a ~ c は,見積もり対象の難易度,開発要因の構成といった対象の
システムの特徴,そして,見積もりレベルによって決定される定数です。
なお,(ア) は標準タスク法,(イ) 類推(概算)法,(ウ) はファンクションポイント(FP)法の説明です。

comments

皆既月食

今日は 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] は,「保守」って,「運用」とセットでよく聞くので,
ついつい (ア) が答えかと思ってしまいました…。

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

comments

うちに帰りたくない…

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

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

なんと…ムカデ!!

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

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

————— キリトリセン 8X —————

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

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

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

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

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

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

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

ここまでの解答と解説!

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

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

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

★ ボトムアップテスト

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

★ トップダウンテスト

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

comments

ボロボロ…

第 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 の解説と連動?した自分メモ!

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

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

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

comments

ケアレスミスが最大の敵!

問題文がうまく読めずに,
おバカなケアレスミスをしまくりなひじきです。

昨日に引き続き,テキスト第 6 章の章末問題ということで,
間違えた 3 つ目の問題(計算問題)についてやっていきます!

[問題1]
あるプロジェクトの工数配分は表のとおりである。基本設計からプログラム設計まで計画どおり終了した。プログラミング段階に入り 3,000 本のプログラムのうち 1,200 本が完了したところである。現在のプロジェクト全体の進捗度は何%か。

工数配分の表です

 (ア) 40   (イ) 44   (ウ) 54   (エ) 75

考え方は,それぞれの段階における進捗度の和を求めて,
答えを導いていきます。

まず,問題文の赤字の部分に,
「基本設計からプログラム設計まで計画どおり終了した」とあるので,
プログラム設計までの進捗度は,

 0.08 + 0.16 + 0.20 = 0.44(= 44 %)

次に,プログラミング段階で,3,000本 のプログラムのうち,
1,200 本が完了したとあるので,プログラミング工程での進捗度は,

 1,200 / 3,000 = 0.4(= 全体の 40 %ができている)
 0.4 * 0.25 = 0.1(= 10 %)

したがって,現在の進捗度は,

 0.44 + 0.1 = 0.54(= 54 %)

となるので,(ウ) が答えになります。

毎度毎度こりないのも,自分でもどうかと思いますが,
また,赤色の部分を読み飛ばしていて,
「答えがないー!!」ってなってました…。

今のうちからこんなくせが付いてしまって,
本番はどうなってしまうのか,かなり心配です(汗)

comments

思い立ったが吉日

なんとなく,突然の思いつきで,
風呂桶とイスを新しいモノに買い換えてみました!

風呂おけです

どこにでもある品ですが,なかなか快適です。

————— キリトリセン 8X —————

なんとか第 6 章を読み終え,章末問題にチャレンジ!

範囲が広いうえに,覚えることも多いので,
10 問中 3 問も間違えちゃいました…(涙)

以下,間違った問題たち。

[問題1]
ソフトウェアの要求分析に関する記述のうち,事象応答分析の説明として適切なものはどれか。

 (ア) 外界の事象に応じて,時間の流れとともにシステムが応答するという
    一連の動作を分析するための方法である
 (イ) システムの改善案を検討する場合などに,ある事象について思いつく
    様々な着想を視覚的なイメージ図にまとめ,参加者がこの図をもとに
    別の視点に立った新しい発想を生み出すことを支援するための方法である
 (ウ) システムの機能を入力データおよび出力データの両面から洗い出すための
    分析方法であり,4 つの要素(データ,情報,機能,条件)の相互関係を定義する
 (エ) システムの対象をモデル化する際に,実体と関連によって,その構造を
    分析するための方法である

[問題2]
データ中心アプローチを特徴づける言葉として,最も適切なものはどれか。

 (ア) カプセル化 (イ) シナリオ化 (ウ) 集約化 (エ) モジュール化

問題の解答は,以下のとおり。

[問題1] (ア)
事象応答分析とは,外部からの事象とその事象に対する応答の時間的な関係を
すべて抽出し,制御の流れを分析することです。
一般に,制御フロー図,ペトリネット図,状態遷移図が利用されます。
なお,(イ) は KJ 法,(ウ) は機能分析,(エ) はE – R ダイアグラム(E – R図)などによる
構造分析の説明です。

[問題2] (ア)
データとデータのライフサイクルを扱うプロセスは密接な関連を
もつものとして考え,データ構造を単に静的(固定的)なものとしてのみ
捉えるのではなく,プロセスをデータの固有の手続き(属性)として,
データ側に隠ぺいしようとするのがデータ中心アプローチです。これは,
オブジェクト指向におけるカプセル化と同じ概念です。

…章末問題で間違った問題の残り 1 つは,
計算問題なので,明日載せようと思います!

comments

サマーコース開講!

夏休み短期集中講座ということで,今日からいよいよ,
サマーコースの第 1 クール(23 日 ~ 29 日)がスタートしました!

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

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

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

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

————— キリトリセン 8X —————

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

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

★ モジュール分割技法

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

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

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

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

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

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

うーん。

正直,覚えられない!(汗)

comments

HAPPY BIRTHDAY !

今日は,普段からとても仲良くしてもらっている,
ある先生のお誕生日ということで,学生さんと一緒にお祝いをしました!

誕生日ケーキです

久しぶりに見た,ろうそくの立っているホールケーキ(= バースディケーキ)に,
ちょっとテンション高めです!

…とにもかくにも,お誕生日おめでとう!!

————— キリトリセン 8X —————

さらにさらに,しつこいくらいに第 6 章の自分メモ!

★ ソフトウェア開発モデル

 ・ウォータフォールモデル
  → 要求分析,設計(外部設計・内部設計・プログラム設計),プログラミング,
    テスト,運用・保守という工程順に,ちょうど滝(ウォータフォール)が
    上流から下流へと向かって流れるように開発を進める手法です。
    比較的大規模なシステム開発に向いています。

 ・プロトタイプモデル
  → 開発工程の早い段階で試作品を作成して,それらをユーザに試用してもらい,
    ユーザの意見を反映させながら仕様を確定していく開発手法です。
    開発の早期段階で,要求仕様のあいまいさが取り除かれるという利点があります。

 ・スパイラルモデル
  → ウォータフォールモデルとプロトタイプモデルの長所を取り入れた
    成長型モデルです。独立性の高い部分(機能)ごとに,開発プロセスを
    渦巻き状態に繰り返しながら,開発範囲を徐々に拡大していき,
    システムの完成度を高めていきます。

 ・成長モデル
  → システムの「核」となる部分を早期に開発し,ユーザからの要求や変更が
    あるたびに開発を繰り返すという方法で,同じ工程をサイクリックに
    何度も繰り返しながら,完成へと近づけていきます。

 ・RAD(Rapid Application Development)
  → 短期間(通常 2,3 ヶ月)での開発を重視した手法です。
    ライフサイクルの無制限な繰返しを防ぐため,「タイムボックス」と呼ばれる
    一定の開発期間を設定し,これによって短時間での開発を実現します。

 ・ラウンドトリップ
  → オブジェクト指向開発において,分析と設計,プログラミングを
    何度か行き来しながら,トライアンドエラーでシステムを完成させていく
    開発手法です。

 ・クリーンルームモデル
  → ウォータフォールモデルを基本的な枠組みとして,形式的記述法を採用し,
    正当性の検証を重視することにより,エラーの混入を防止しようとする
    開発手法です。

今さらですが,よくごっちゃになっていたスパイラルモデルとラウンドトリップ。

オブジェクト指向開発のスパイラルモデル = ラウンドトリップ

って感じで,ベースとなる言語?(環境?)が違うだけで,
似たようなものだったんですねー!

comments