<< January 2018 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>

プロジェクトマネージャ ITEC模試の結果

ITEC模試の結果が届いた。

 得点平均点偏差値順位判定
午前86/11066.7466.089/236B
午後173/12061.6456.4366/267C
午後250/10043.2254.01141/252C
総合209/330171.3561.1920/216C


論文には、「準備不足の感があります」と書かれた。
まったく、そのとおり。

ちなみに、PMでは、午前免除の人がいるので、総合(午前・午後1・午後2の合計)は意味がないと思う。
ss2004 * プロジェクトマネージャ * 22:01 * comments(6) * trackbacks(0)

プロジェクトマネージャ H12 PM1-1 プログラム開発工程における進捗管理

設問1(1)
経過1か月半以降が進捗が大きく遅れている。親会社のシステムとの連携が決定されたことにより、業務共通サブシステムにおけるデータベース関連のプログラムに仕様変更が生じたからである。

設問1(2)
「このほかに」というのは、進捗のこと以外と判断する。
「時系列的に」というのは、仕様変更(親会社システムとの連携決定)前と後を区別することと判断する。
管理すべき項目は、開発工数である。
そのねらいは、仕様変更による追加工数を明らかにし、必要があれば、契約の相手方に追加費用を請求するためである。

設問2
業務2開発チームは、1か月経過以降の進捗が遅れている。新規要員のスキルアップを想定していたが、不安を感じており、さらに、その点について対策を講じているフシも見られない。このままでは、進捗状況と計画のかい離がさらに広がり、以降の工程への影響も考えられる。

設問3
「データベース関連のプログラムについてはこの工程の期間内での挽回は不可能であり、」とある。
したがって、できるところから次工程に進む。すなわち、仕様変更の影響を受けていない部分から結合テストを行い、その間に並行して、仕様変更部分の開発を進める。
ss2004 * プロジェクトマネージャ * 21:53 * comments(0) * trackbacks(0)

プロジェクトマネージャ H17 PM1-4 コールセンタの機能拡張

設問1
総合テストの環境を前倒しして提供することにより、サブシステム間結合テストが総合テスト環境で実施できる。
したがって、結合テストと総合テストの環境が異なることによる不要な手戻りが防止できる。

設問2
L課長が示した方針は、「作り直す連携プログラムは、従来使用していた連携プログラムと極力同じインタフェースになるように設計する」ことである。
この設計方針により、プログラムの再利用が可能になる。再利用は、品質確保、費用削減に結びつく。
ただし、2点を答えるのに、1つの理由(再利用だから)で良いのかが気にかかる。

設問3(1)
M社の改修計画では、総合テスト開始までに改修が完了していない。→稼働に間に合わなくなる。

設問3(2)
まず総合テストに間に合わせなくはならない。15本のプログラムが対象であるため、15本のプログラム修正→15本の単体テストと進めるよりも、プログラム修正ができ次第単体テストを行うことにより並行作業ができ、全体の期間が短くて済む。特に、同じ誤りを修正するので、テスト・バグ修正が他のプログラム修正作業にフィードバックでき、並行化の効果が大きい。

設問3(3)
M社が対応できないとなった場合、それから他の対応策を考えても間に合わない。2月末に完了させることが必須であるから、他の対応策が可能かどうかも確認しておく。

設問3(4)
N社との請負契約には含まれていない内容であるので、当然に、別契約となる。
ss2004 * プロジェクトマネージャ * 21:35 * comments(0) * trackbacks(0)

プロジェクトマネージャ H17 PM1-3 性能評価

設問1(1)
現時点で可能な性能の評価方法。「要件定義にさかのぼって見直す」とのことなので、仕様は確定していない。「同種のシステム開発経験が豊富である」ことから、類似のシステムから類推する位しか方法がない。

設問1(2)
(1)の性能評価は、その時点でできる仮のものである。この性能評価を過信されて計画を進めてしまうと、機器導入後に不具合が発覚し、問題化するおそれがある。「内部設計終了後に、改めて性能評価を行い、それに基づいて機器導入を行う」ことを約束しておく。

設問2(1)
すべてにおいて最良な対策案というのは通常存在しない。納期や予算などの条件を勘案して決定する。

設問2(2)
この問題では、A社・B社のどちらの言い分が正しいかを考えてもしょうがない。あくまでも、速やかに膠着状態を解消することが目的である。
ある点について両者の話がつかない場合には、その点はペンディング(解決を先送り)にして進められるところから進めるという方法が多く用いられるが、この問題では、それも不可能(対策案1・2のいずれをとるか決めなければ進められない)。
開発日程に重大な影響を及ぼすことを知りつつも膠着するということは、結局のところ、お互いが自分の裁量では判断がつけられないからである。

設問3(1)
根本的な対策を実施した場合のリスク。
改修に十分な時間がかけられないため、納期に間に合わない、品質不足などのリスクが考えられる。

設問3(2)(3)
「図2 データ量の推移」に注意。n年を1とするとn+4年が2になるこのグラフ(と「年率約20%でデータ量増加を想定」という旨の記述)。どこかで必要になると思っておかなくてはいけない。
負荷がデータ量目標の60%を超えると、目標値に達しないとあるので、グラフから、n+1年後までは問題が発生しないことが分かる。
ss2004 * プロジェクトマネージャ * 20:39 * comments(0) * trackbacks(0)

プロジェクトマネージャ H17 PM1-2 プロセス改善

設問1(1)
委託先選定方法の問題点
1点は、「委託先選定の手順や判断基準が不明確である」点。
2点目は、強いていえば「R社への委託の場合にチェックが甘くなる」点。

設問1(2)
一般にチェックリストを用いることによって、

  • 条件の漏れがなくなる
  • 恣意的な判断が抑制され、客観性が担保できる
などの利点があるが、この場合は後者。

設問2(1)

  • T社は、要員動員力が劣るため、納期遅延が予想される。
  • U社は、財務の健全性が劣るため、受託事業の完成に不安がある。


設問2(2)
負荷テストを早く行うことによって、問題が発覚した場合に余裕を持って対処できる。

設問3(1)
想定されるリスクは、「技術力不足による納期遅延と品質の低下」。
ちなみに、「工数が無駄にかさみコストが超過する」というリスクは、請負契約であるのでR社側のリスク。
Q課長が検討した方策は、「R社と、T社・U社との共同開発」というのが公式解答だが、なぜそうなのかは不明。本文中にそれらしい記述はないし、共同開発というのは3者契約を意味するのだろうか?

設問3(2)
下請法の対象になるかどうかは資本金の額により決まるので、チェックリストに資本金額という項目を追加する。
下請法の対象になる場合は、支払に遅延が生じないよう注意する。

設問3(3)
CMMIレベル3は、「標準プロセスに基づいて、各プロセスが定義され、実行されている状態」であるから、「委託先選定プロセスが定義され、手順に基づいて委託先が選定される」ようになることが必要。
ss2004 * プロジェクトマネージャ * 07:19 * comments(0) * trackbacks(0)

プロジェクトマネージャ H17 PM1-1 基幹系システム再構築の変更管理

設問1
変更管理要領の導入の目的
 →無秩序な要件変更を抑止し、納期遅延や予算超過を防ぐため。

設問2(1)
変更要求の窓口を一元化する理由
 →担当者同士で勝手に変更を行うことを防ぐため。
が公式解答例だが、それならば、開発チームXとYに、それぞれ変更管理責任者を置くことで可能なはず。
 →変更要求間の整合性をとるため。
ではないのか?

設問2(2)
契約変更が必要になる場合
 →納期や金額が変更になる場合

設問2(3)
再構築の目的は決算の早期化の実現であるので、「決算の早期化の実現に資するかどうか」が判断基準である。

設問3(1)

  • 変更要求に対する杓子定規な対応(承認されるまでは一切対応しない)は、「発注者」に「納期遅延」のリスクが発生する。
  • 変更要求に対する柔軟な対応(承認を待たずに開発を進める)は、「受注者」に「コストが回収できなくなる」リスクが発生する(変更要求が承認されなかった場合に無駄な作業となるため)。


設問3(2)
現在の対応では、(1)のようなリスクが発生するので、緊急な変更要求に対しては迅速に承認・非承認の決定を下さなければならない。したがって、緊急の変更要求に関する承認プロセスを定める。
ss2004 * プロジェクトマネージャ * 23:59 * comments(0) * trackbacks(0)

プロジェクトマネージャ ITEC模試 午後2

まったく勉強をしていない午後2の論文試験。
とりあえず、分量と時間を実感するために参加。

もちろんプロジェクトマネージャの経験はないので、社内システムを念頭に(本当はただの一利用者だが)、受注者側のプロジェクトマネージャになりきって書いてみた。これが意外と面白い。

何とか文字数はクリアした。時間ギリギリだったので、尻切れトンボだったが問ウまで行った。

今後は、プロジェクトマネージャ合格論文集を、写経よろしく書き写すこと(22論文あるので1日1論文目標)と、なりきり論文でっち上げ体験(できれば3つくらい)をやって本試験に臨みたい。
ss2004 * プロジェクトマネージャ * 22:27 * comments(0) * trackbacks(0)

プロジェクトマネージャ ITEC模試 午後1

当初、問題の選択に当たって、「数値が示されているものは答えやすい」と考え、問1・問2を選んだ。
しかし、いざ解いてみたところ、問1が取り組みにくかったので急遽変更し、問2〜問4を選択した。

問1
オフショア開発におけるリスク管理というくくりだが、解答・解説を見る限り、「相手方とは初めての共同開発」、「相手方に運送業務システムの開発の経験がない」という点がリスクの要因であるようだ。言葉の問題に縛られすぎると、答えが見えなくなる。
  • 相手先に常駐して、情報連携を行うSEをブリッジという。


問2
品質管理の問題だが、不適切な問題と感じた。
アイテックの解答・解説には、プログラム設計・製造・テストを請負契約で外注しているという視点が抜け落ちている。
例えば、プログラムテスト工程において、プログラム単位の品質状況の管理が必要であるとして、T課長が示したフォーマットでは、プログラムごとに開発担当者、消化テスト項目数、発見バグ数、修正済みバグ数などを記入することになっている。
このフォーマットで委託者側に提出することになれば、テストの進捗状況を委託者が管理することになってしまう。また、各プログラムの開発担当者は誰かも委託者側に報告することになってしまう。
請負契約においては、完成責任は負うものの作業の進め方は受託者の自由裁量である。特別の契約がない限り、テストの進捗状況を逐一報告させる行為、プログラム設計書のレビューを行わせるなどの行為は、契約の範囲を逸脱していて不適切である。

問3
「プロジェクト要員の育成について・・・」と書かれているが、中身はプロジェクトマネージャへの育成である。
この問題が、SL理論のことを問うているのだとは気がつかなかった。
なので、設問4は、「管理型でなく相手のモチベーションを引き出す方がよい」というX理論・Y理論型の答えをしてしまった。SL理論なら、「時と場合によって管理型と放任型を使い分ける」式の答えでなければダメだな。

問4
俺自身が、ユーザ企業のシステム部門に席を置き、経験なしスキルなし外部ベンダ依存型なので、耳の痛い問題。
ss2004 * プロジェクトマネージャ * 22:11 * comments(0) * trackbacks(0)

プロジェクトマネージャ ITEC模試 午前

問15
CMM(プロセス成熟度)の高い順

  1. プロセス自体の継続的な改善が自動的に実現されている
  2. プロセスの品質が測定基準に基づき定量的に把握・管理されている
  3. 管理と作業のプロセスが確立され、標準プロセスとして文書化して定義されている
  4. 基本的な管理プロセスが存在し、プロセスが反復的に実行され、再現可能である。


問17
受付処理をデータの流れで三つに分割する。

  • 顧客 −(注文)→ 受付 −[受注ファイル]→ メーカ窓口
  • 顧客 −(キャンセル)→ 受付 −(キャンセル)→ メーカ窓口
  • 顧客 −(問合せ)→ 受付 −(回答)→ 顧客


問19
UMLでは、

シーケンス図
オブジェクト間のメッセージングを時系列に記述
アクティビティ図
システム内部の詳細な処理手順やビジネスプロセスを記述


問25
オブジェクト指向における品質測定(ソフトウェアメトリクス)

  • サブクラスが多いということは、再利用性は高く(高いから多くのサブクラスで再利用されている)、保守性は低い(影響を見極めるのが困難になる)。
  • スーパークラスが多いということは、承継が利用されていて、再利用性は高いが、保守性は低くなる。
  • 承継以外の方法で結合されているクラスは、一般に保守性が低い。
  • メソッドが複雑であるからといって機能性が高いとはいえない。


問28
COCOMOによる見積は、

  • 予想コード行数を基礎とする。
  • 同一言語内で適用する。
  • 分析工程は見積もれない。
  • プログラマのスキルは反映されるが、組織の成熟度は反映されない。


問29

  • 差分バックアップは、フルバックアップ取得以降に更新されたデータだけをバックアップする。
  • 増分バックアップは、前回のバックアップ(フルバックアップor増分バックアップ)取得以降に更新されたデータだけをバックアップする。
  • ∴ 差分バックアップ量≧増分バックアップ量


問38

JIS Q 14001
環境マネジメントシステムに関する要求事項
JIS Q 15001
個人情報保護に関するコンプライアンスプログラムの要求事項
JIS Q 27001
ISIMS認証基準
JIS X 5070
製品・システムのセキュリティ特性を評価するためのJIS規格


問44
情報戦略の策定手順

  1. 経営戦略の確認/現行業務分析/現行システム評価
  2. 情報システムでの解決策の検討
  3. 情報戦略の策定
  4. 経営トップ層へのレビュー
  5. 見直しと最終調整
  6. 情報戦略の明文化


問49
RFM分析とは、

  • Recency: 最新購買日
  • Frequency: 購買頻度
  • Monetary: 累計購買額
による分析

問51
下請代金支払遅延等防止法では、支払期日を、物品等を受領した日から60日以内で出来る限り短い期間内で定めなければならない。
定めなかった場合には、60日と定めたものとみなす。

問52
著作権法第113条第2項
2 プログラムの著作物の著作権を侵害する行為によって作成された複製物を業務上電子計算機において使用する行為は、これらの複製物を使用する権原を取得した時に情を知っていた場合に限り、当該著作権を侵害する行為とみなす。

著作権法第20条
第20条 著作者は、その著作物及びその題号の同一性を保持する権利を有し、その意に反してこれらの変更、切除その他の改変を受けないものとする。
2  前項の規定は、次の各号のいずれかに該当する改変については、適用しない。
三  特定の電子計算機においては利用し得ないプログラムの著作物を当該電子計算機において利用し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に利用し得るようにするために必要な改変


問53
労働者派遣法では、以下の業務について派遣事業を行うことを禁止している(禁止が限定列挙)。

  • 港湾運送業務
  • 建設業務
  • 警備業務
  • 医師・歯科医師などの医療関係の業務

ss2004 * プロジェクトマネージャ * 21:40 * comments(0) * trackbacks(0)

プロジェクトマネージャ H16 PM1-4 営業支援システムの構築における計画変更

設問1(1)
PDAソフトウェア開発とPDAシミュレータ開発を同じ会社に委託することで、情報共有が図られ、作業が円滑に進むことが期待できる。
また、題意から、Z社がPDAハードウェアを提供することとは、直接関係がない(Z社がPDAハードウェアを提供するからシミュレータ開発が適任というのは×)。

設問1(2)
PDAシミュレータがない場合には、PDA提供が遅れる1か月間、PDAソフトウェア開発の内部結合テストが遅れ、サービス開始も遅れる。

設問1(3)
PDAを多数用意しなくても、ピーク時の負荷テストを行える。
また、「PDAソフトウェアの内部結合テスト終了を待たずして、PDA・サーバ間結合テストを行える」のは、シミュレータ開発による利点であって、負荷テスト機能の実装によるものではない。

設問2(1)
外部設計 ←→ 総合テスト
サーバ間インタフェース設計 ←→ サーバ間結合テスト
ウォーターフォール開発モデルをV字に当てはめて考える。

設問2(2)
公式解答では、「外部設計から総合テストまで一貫した責任を負わせたいため」などとなっているが、実は、サーバ間インタフェース設計、PDA・サーバ間インタフェース設計とサーバ間結合テスト、PDA・サーバ間結合テストについては請負契約となっていない。
これらが、請負契約に出来なかった理由を考えると、「外部設計と総合テストは、受託業者が単独で完成責任を負うことが出来るから。」が正しいと思う。

設問3(1)
人的リソース、すなわち、PDAソフトウェアの内部設計を行った要員をシミュレータの内部設計に回せる。

設問3(2)
PDA・サーバ間結合テストが終了する8月半ばに集中してバグ改修を行うことにより、効率的に、手戻りなくバグ改修が行える。

設問3(3)
営業部員が有する情報やノウハウは、個人的に管理され、紙媒体で共有されていた。
したがって、営業部員はPDAを使った情報共有に慣れていない。人間が、システムに慣れるための期間が必要である。
ss2004 * プロジェクトマネージャ * 22:41 * comments(0) * trackbacks(0)
このページの先頭へ