FC2ブログ

平成27年度春季 プロマネ試験を振り返る(その1)



平成27年度 プロマネ 午後2試験問1 解説



去る4月19日に、情報処理技術者試験が開催されました。

当方運営サイト「プロマネ受験対策室」では、メールマガジンで試験解答速報を行っています。
(午後の試験を中心に解説をしています)

まずは午後2小論文の解説をします。
午後2は、読み取れる題意と、論述の方向性をまとめた解説になります。
皆様振り返ってみましょう。


続きを読む

スポンサーサイト



派生開発プロジェクトでみんながハマる罠を回避せよ!Kindle出版です。

記事ジャンル:システム開発/プロマネ



派生開発プロジェクトでみんながハマる罠を回避せよ!


掲題の書籍を出版しました。Kindle限定です(安いですよ)。
ここのブログに記載しているエントリ内容をまとめて編集したものです。

情報処理システムの派生開発プロジェクトで、私たちが工夫したプロセス改善の内容をまとめています。

書籍はこちらから
派生開発プロジェクトでみんながハマる罠を回避せよ!



本書について


本書は、情報システム開発を行っている全てのエンジニアに向けて執筆しました。

システム開発の現場において現役のエンジニアである筆者が、実地体験を通じて試行錯誤した結果として、品質確保に効果のあった開発プロセス上の工夫について、具体的に記載をしたものです。


今回焦点を当てたのは「派生開発プロジェクト」です。

派生開発とは、母体システムへの機能追加・変更、欠陥是正の対応を行う開発プロジェクトのことです。新規開発プロジェクトとはまた別の特徴があります。派生開発といえば派生開発推進協議会 代表の清水吉男氏が第一人者であり、XDDPといった派生開発に特化した開発プロセスを提唱されています。筆者も派生開発推進協議会の会員として参加をさせて頂いております。

本書は、派生開発の中でも、特に母体システムの欠陥修正(改修)案件における開発プロセスについて焦点を当てて述べています。

欠陥修正案件は、派生開発プロジェクトの1つでありますが、機能変更や機能追加といった派生開発とはまた別の特徴も含まれています。具体的には以下のような特徴があります。

  1. 欠陥修正案件は極端に開発規模が小さくなりやすい

  2. 1つの欠陥修正にとらわれるあまり、関連する欠陥や欠陥の影響範囲を見逃しやすい

  3. デグレードの観点から開発規模とテスト規模が一致せず、テスト規模が増大しやすい


こうした特徴を踏まえた上で、開発現場で誰しもが陥りがちな罠を具体的にあげて、対処策を開発プロセスという形で記載しています。

ただし開発プロセスという形をとっていますが、特定の開発プロセス・モデルを規定する意図を含みません。

皆さんが現場で用いている開発プロセスや開発モデルにアドオンできる形になっており取捨選択ができます。

必要なものを必要な範囲で柔軟にテーラリングして頂けます。もちろんXDDPを適用している場合でも、それを補完する形で追加することも可能です。

今後は派生開発プロセスの1つであるXDDPについても、ますます研究や活動が活発になってくると思われるため、システム開発の現場で同じような問題意識や課題をお持ちの方には、何かしら参考になると考えています。



本書の構成


本書は3部構成になっています。

第1部では、派生開発とは何ぞや?ということで、派生開発の特徴を概観していきます。

そのうえで、派生開発プロセスのデファクトスタンダードになりつつあるXDDPについても概要を見ていきます。XDDPは清水吉男氏が提唱している開発プロセスで、多くのプロジェクトに適用されて効果が実証されています。これからXDDPを導入しようと考えている方にも参考になると思います。その後、当方が実際に遭遇した派生開発プロジェクトの問題点や解決策についても概要を示します。


第2部では、1部の最後に概説した、私達が遭遇した派生開発プロジェクトの問題提起と解決策について、具体的に掘り下げて内容を紹介します。

実際にどのようなプロジェクトで、どんな問題に遭遇したのか、といったところをご紹介します。これによって我々がどのような問題を解決したかったのかを理解して頂けるものと考えています。なお、具体的な解決策として提案させて頂く開発プロセスは3部で詳述します。


第3部は、品質確保に効果のあった開発プロセスを定義しています。

読み物というよりは開発プロセスの辞書のようなイメージです。PMBOKのような書式をイメージしてもらえれば間違いありません。誰にでも再現可能なように、できるだけ細かなテクニックまでも含めて記載をしたつもりです。プロセス単位でなくとも、1つ1つの手法のトピックだけでも読んで頂ければ何かしらのご参考になるのではないかと考えています。


本書はWORD文書で約200ページ弱の分量になっています。
やや冗長な印象はありますが、皆様もシステム開発の現場で得た知見を小冊子としてKindleストアで公開することをご検討されてみてはいかがでしょうか。簡単にノウハウを公開できますし、同業の皆様のお役にたつことができるのです。

本書が皆様のエンジニア・ライフを少しでも快適に、効率的にすることに貢献できれば幸甚に存じます。


書籍はこちらから
派生開発プロジェクトでみんながハマる罠を回避せよ!

【PR】汎用ログ解析ツール gpLog はいかがですか?

汎用ログ解析ツールとは?


システム開発に携わる皆さまには、こんな経験はないでしょうか?

・システムごとにログ形式が異なるので、ログ解析ツールを毎回自作しなければならず、手間がかかる


システム開発時はあまりログ解析について意識が及びにくいです。しかし、いざデバッグ、または維持管理フェーズに突入すると、欠陥の原因調査などで膨大なログに直面することになります。


その時に「あー解析面倒!! 解析ツール作るしか!」となって、付け焼刃のツールを作って対応・・・なんてことをプロジェクトごとに繰り返してないでしょうか。


その場しのぎのログ解析ツールは汎用性など持ちませんから、次のプロジェクトではまた解析ツールを作るはめになる、なんてことになります。


そこで汎用ログ解析ツールです。


ログ形式の違いを吸収できれば、汎用的な1つの解析ツールで事足りるはず。

そんなツールが必要なら gpLog があります。

続きを読む

派生開発プロセスの工夫(その17)



品質確保に効果のあった派生開発プロセスの工夫#17


掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次


まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4
   ⇒part5
   ⇒part6(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群




(2)派生開発プロセスの内容


1.対処検討プロセス群(part6)


対処検討プロセスを順に解説していく。今回は最後のプロセスである「1.5 対処決定」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定



※プロセスの全体像を参照したい場合はこちら



1.5 対処決定


1.5.1 プロセスの目的・概要


対処決定プロセスの目的は、「1.4対処案の検証」プロセスの結果を関係者間で協議し、決定することである。
採用された対処案が決定することで、本プロセスは終了となるが、次の「2.開発プロセス群」の実施に先立って、要求事項トレーサビリティ・マトリクスを作成する。本資料の作成によって、次工程の開発箇所を明確にすると共に開発量の見積りを行うことができる。

続きを読む

派生開発プロセスの工夫(その16)



品質確保に効果のあった派生開発プロセスの工夫#16


掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次


まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの1つであるXDDPと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容(1部 レポート・サマリー)だけでも、本論述の概要はつかめると考える。その次の2部から、詳細なレポート内容を述べていく。

もちろん2部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。1部はサマリーのみであり、詳細情報は把握できないだろう。

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

(4)当方が遭遇した派生開発の問題と解決策の概要
   ⇒記事はこちら

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2
   ⇒part3

(2)派生開発プロセスの内容
 1.対処検討プロセス群
   ⇒part1
   ⇒part2
   ⇒part3
   ⇒part4
   ⇒part5(本記事が該当)

 2.開発プロセス群
 3.検証プロセス群




(2)派生開発プロセスの内容


1.対処検討プロセス群(part5)


対処検討プロセスを順に解説していく。今回は「1.4 対処案の検証」の解説を行う。

 ・1.1 原因特定
 ・1.2 スコープ定義
     ├─1.2.1 要求コンセプトの明確化
     └─1.2.2 要求仕様の特定
 ・1.3 対処案の特定
 ・1.4 対処案の検証
 ・1.5 対処決定



※プロセスの全体像を参照したい場合はこちら



1.4 対処案の検証


1.4.1 プロセスの目的・概要


対処案の検証プロセスは、特定された対処案の調査アイテムに従って、ソースコードやドキュメントを調査し、必要に応じてスペックアウトを行いながら、対処案が正常に動作することを検証するプロセスである。

対処案をリストアップした時点では、設計情報やソースコードの詳細までを確認しているわけではない。そのため、詳細な調査を行った結果、当初検討した対処案では要求仕様を満足できないことが判明する場合もある。

対処案の検証では、対処案が要求仕様を満足していることを徹底的に調査する。対処案の正常性を確認するのではなく、対処案が要求仕様を満たしていない事項がないかを検証していく。

続きを読む

プロフィール

so-tan

Author:so-tan
佐藤 創。仙台のIT業界でシステム開発に従事しながら、情報処理試験プロマネの受験対策を実施(「このブログについて」参照)。情報処理技術者システムアナリスト、プロジェクトマネージャ、中小企業診断士。日々自分のキャリアや様々な問題に悩みつつも、前向きに問題に立ち向かえる自分でありたいと願う。そんな日々の記録です。
Twitter → @sato__so__
FB → facebook.com/creative.1st.pm

人気の連載エントリ
当ブログではテーマに沿った連載エントリがあります。掘り下げた議論がお好きなら以下からどうぞ。
  1. 受託・派遣型の中小ソフトウェア業が抱える課題
  2. 情報サービス産業の今を俯瞰する
  3. 自分の強みを仕事に活かし仕事を楽しむ
  4. 情報システム派生開発プロセスの工夫
全記事表示リンク

全ての記事を表示する

カテゴリ
最新記事
最新コメント
最新トラックバック
月別アーカイブ
アクセスカウンター
検索フォーム
RSSリンクの表示
リンク