事後報告?

ある先生に撮影してもらったビジネスマナー講座の画像のデータを
先ほど,いただいたので,アップしておきます。

ビジネスマナー講座の様子です

これは最終日の,ビジネス文書についての講義を行っているところです。
(本当はもっと実践してるっぽい感じの画像が良かったのですが…)

昨日,終わったばかりなはずなのに,
なんとなく懐かしい気が…(汗)

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

さてさて,サマーコースも落ち着いてきたので,
そろそろ本格的に,勉強にも身を入れていかないとなぁ…と思う今日この頃。

とりあえず,第 3 章の自分メモをば。

★ RAID について
 RAID とは,安価な磁気ディスク装置を複数組み合わせることで,
 全体として高い安全性を得る手法のことです。
 用途に応じて,RAID0 ~ RAID7 までの様々な段階があります。

 ・RAID0
  → 信頼性の向上ではなく,性能の向上を目的としたもので,データを
    複数のハードディスクに分散して配置する「ストライピング」により,
    高速な読み書きを実現します。
    ただし,1 台でもディスク装置が故障すると読み書きが不能になるため,
    全体としての信頼性は逆に低下します。

 ・RAID1
  → 2 台のハードディスクにまったく同じデータを書き込みます(ミラーリング)。
    片方の装置が壊れてもそのまま業務を継続することができますが,
    実質的な記憶容量はハードディスク全体の 2 分の 1 となります。

 ・RAID2
  → RAID0 にエラー修正データを付加して,ディスクが壊れた際のデータ復元が
    できるようにしたものです。
    エラー訂正データにハミング符号を利用するため,ディスクが 2 台同時に壊れても
    データを復元できるのが特徴です。
    ただし,コスト効率が悪いため,あまり利用されていません。

 ・RAID3
  → RAID2 のエラー訂正のしくみを簡略化させたものです。
    エラー訂正のデータに,パリティビットを利用するので,
    2 台同時に壊れるような事態には,対応できません。

 ・RAID4
  → RAID3 で行われるビット/バイト単位でのストライピングを,RAID4 では
    ブロック単位で行います。

 ・RAID5
  → 3 台以上のハードディスクを使用して,各ハードディスクにデータとパリティを
    分散配置する方法です。

 ・RAID6
  → RAID5 にパリティディスクを追加して,2 台以上のディスクが故障した場合でも,
    データの読み書きが行えるようにする方法のことです。

RAID は何回も覚え直している,苦手な部分の 1 つなのですが,
こうやって書き出しても,やっぱりなかなか覚えられません…(汗)

うーん。

記憶は苦手。

comments

宇宙花火

先日の皆既月食のリベンジもかね,本日は,宇宙花火というものを見るために,
夜の 7 時頃から,京都駅の大階段の上(屋上?)で,張り込みを決行しました!

西日本側だったら,観測できるだろう…ということだったので,
Web を参考に,南南西の空を凝視していたのですが,ちょうどその部分だけ雲がかかっていて,
花火どころか,星すらも思うように見れないという状態でした(涙)

とはいえ,この宇宙花火。
初の試みなのか,本当に見れるかどうかも分からないし,
たとえ見れなかったとしても苦情は受け付けません,ということだったので,
「見れたらラッキー!」くらいの感覚ではあったのですが…。

とりあえず,他の地域では,こんな感じに見えていたらしいです。

あまり,天体観測?には恵まれていないようなので,このウップンをはらすべく,
帰りがけに京都駅の八条口で,大盛り(LL サイズ)のパスタをたいらげてきちゃいました!

パスタのLLサイズです

↑豚肉と九条ねぎの和風パスタ

このお店,名前はパスタモーレ(PASTA MORE)というのですが,
パスタのサイズが,M サイズと L サイズと LL サイズとあり,
どのサイズを注文しても,なんといっさい値上げはナシ!
すべて同じ値段(780 円)で食べられるのです!

いやー,実にすばらしい!!

ガッツリ食べたいよ,っていうときにオススメです!

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

さらに。

いつまでも 第 6 章をやり続けているわけにも行かないので,
今日からようやく第 3 章を読み始めました!

第 3 章の内容は「ハードウェア」ということで,
学生時代から何回もやってきている範囲でもあるのですが,
さらなる知識の定着を目標に,頑張っていきたいと思います。

comments

9 月になりました

当初,9 月中に午前の範囲を終える予定だったはずなのですが,
見事に,スケジュールを押しています。
現時点で残っているのは,第 3 章 ~ 第 5 章と第 7 章 ~ 第 8 章です。

正直,終わっている範囲の方が少ないという…(汗)

どうあがいてもそれが現状なので,
とりあえず,今後はもう少し巻き気味でいきたいと思います!!

ちなみに。

第 6 章の間違った問題をもう 1 度解き直してみました。

全問正解できなかったのが残念ですが,
なんとか 1 問間違いまでに押さえることができたので,
最低でも現状維持を目標に…ということで。

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

余談ですが,せっかくのお休みにもかかわらず,
ムカデに続いて,今度はクモが出ました。

朝に出るクモは良いクモだ,というジンクスを聞いたことがあるので,
今回もやはり見なかったことにしようと思います。

小指の先ほどのサイズだったのが,せめてもの救い…(汗)

comments

ビジネスマナー講座・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