高度午前 - 開発技術 - ソフトウェア開発管理技術

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

ソフトウェア開発管理技術

詳細 †

開発プロセス・手法 †

開発方針と開発モデル †

PMPのライフサイクル区分に近い話。IPA定義か。

• ウォーターフォール・モデル

  予測型（逐次的）ライフサイクル（完全計画駆動型手法）

• 段階的モデル

  反復型、漸進型ライフサイクル

• 進化的モデル

  適応型ライフサイクル（アジャイル手法、変化駆手法）

PMBOKと同様に単語的に判別付き難い。

エンジニアリング †

• ドメイン・エンジニアリング
  特定のドメインに特化して、ノウハウ・部品を整備・再利用する。

• コンカレント・エンジニアリング
  設計・開発・生産などの工程を出来るだけ
  並行して進める（タイト・マトリックス組織構造下で）。

• リバース、フォワード・エンジニアリング

• リバース・エンジニアリング
  プログラムから仕様を起こす。

• フォワード・エンジニアリング
  リエンジで起こした仕様でソフトウェアを開発する。

共通フレーム（SLCP-JCF） †

• IPAが発行している、ソフトウェアライフサイクル
  における用語や作業内容などを規定したガイドライン。

• 以下から構成される。
  • ソフトウェア・ライフサイクル・プロセス
  • システム・ライフサイクル・プロセス

• 最新版は、共通フレーム 2013

ソフトウェア・ライフサイクル・プロセス †

• ソフトウェアの構想から廃棄に至るまでの一連のライフサイクル。
• ISO/IEC 12207:2008 の翻訳である JIS X 0160:2012がベース

• 一般的には以下のサイクルを辿るとされる。
  • 企画プロセス
  • 要件定義プロセス
  • 開発プロセス
  • 運用プロセス
  • 保守プロセス

• ソフトウェア・ライフサイクル・プロセス >
  システム・ライフサイクル・プロセス > テクニカル・プロセス

• システム要求事項分析プロセス
  システム要求事項はステークホルダーに
  伝えられベースラインとなっている。

• システム方式設計プロセス
  システム要素を識別し、
  要求事項を満たす方式設計が定義されている。

• システム結合プロセス
  要求事項の優先順位に従って、
  システムを結合する戦略が作成されている。

• システム適格性確認テストプロセス
  要求事項への適合を評価するための基準が作成されている。

システム・ライフサイクル・プロセス †

• ソフトウェア・ライフサイクル・プロセスのシステム版

• ISO/IEC 15288:2002 の翻訳である JIS X 0170:2004がベース

• システム・ライフサイクル・プロセスを次の4つとする。

• 合意プロセス
  基本的には契約締結

• エンタプライズプロセス
  組織の遂行能力を管理

• プロジェクトプロセス
  基本的には進捗管理

• テクニカルプロセス（11プロセス）
  個々のアクティビティ
  • 利害関係者要件定義（Stakeholder Requirements Definition）
  • 要求分析（Requirements Analysis）
  • 方式設計（Architectural Design）
  • 実装（Implementation）
  • 結合（Integration）
  • 検証（Verification）
  • 移行（Transition）
  • 妥当性確認（Validation）
  • 運用（Operation）
  • 保守（Maintenance）
  • 処分（Disposal）

成熟度モデル †

• CMMI (Capability Maturity Model Integration)

• SPA (Software Process Assessment)
  • プロセスアセスメントの国際規格
  • プロセス毎に能力水準を診断するモデル
  • 代表的なSPAとしてCMMがある。

• システム開発能力について国際的整合性ある評価指標を活用
  • 開発者の開発能力
  • マネジメント能力

• SPI (Software Process Improvement)
  SPA結果から実際にソフトウェアプロセス改善する

• OPM3
  内部で複数のプロジェクトを実施する組織における
  プロジェクトマネジメント・プロセスを対象した成熟度モデル。

組込みシステムの開発 †

• コデザイン（co-design）：協調開発
  • ハードウェアとソフトウェアの設計を、
    開発の初期段階から協調して行うこと。

• 組込みシステムのコデザイン
  組込みシステム開発においては、シミュレーションを活用する。
  • シミュレーションで、ハードウェアとソフトウェアの切り分け
  • シミュレーションを活用しつつハード・ソフトを並行開発する。

• その他

• コンカレント開発
  ハード・ソフトを並行開発した後に
  組み合わせるので手戻り発生のリスクが高まる。

• プロダクトライン開発
  コア資産≒プラットフォーム化させたハードウェアとし、
  主に、ソフトウェア側で差別化することで
  短期間に多数の製品ラインナップを構築する。

SOAとマッシュアップ †

SOAは機能、マッシュアップはデータを対象とする。

• SOA (Service-Oriented Architecture)
  • サービス指向アーキテクチャ
  • 複数のWebサービスを組み合わせてサービス（システム）を構成する。
  • 技術的基盤として、以下がある。
    • SOAP
    • WSDL (Web Services Description Language)
    • UDDI (Universal Description, Discovery, and Integration)
    • BPEL (Business Process Execution Language)
    • BPMN (Business Process Modeling Notation)

• マッシュアップ (Mashup)
  • ウェブ上に公開されている情報を加工、編集することで新たなサービスとすること。
  • 様々な企業や団体が所有するデータを公開するWebAPIを整備するようになったため。

プラクティス関連 †

• アジャイルのプラクティス

• プロセス
  カバー範囲（XP < Scram < DSDM）

• DSDM (Dynamic Systems Development Method)
  契約やスコープ調整などの考え方

• Scram
  主にチーム開発プラクティス

• XP (extreme programming)
  主に技術的プラクティス
  重量開発手法（SPA、CMM）に対するアンチテーゼ
  軽量開発手法あるいはアジャイル開発手法の代表的手法
  

• 工程のプラクティス

• 反復（イテレーション、スプリント）
  開発サイクルの単位（Scram = スプリント、XP = イテレーション）
  適応型ライフサイクルの核（要求の変化に柔軟に対応することを目的とする）。
  バックログから拾ってきたストーリ（設計、実装、テストまで）を実現する。
  

• イテレーション計画
• 仕様確認レビュー
• フェーズ分割
• 進捗/コスト/品質/変更管理

• 技術的プラクティス

• ペアプログラミング
  2人のプログラマが1台のPCを共同利用しソフトウェア開発を行う手法
  コードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。

• リファクタリング
  外部仕様を変更せず、内部仕様を見直し保守性を高める。

• テスト駆動開発（TDD）
  プログラムの実装前にテストコードを書くプログラムの開発手法。
  テスト ≒ 仕様で、テスト自動化に繋げるような考え方。

• CI/CD
  継続的インテグレーション：自動ビルド・テスト
  継続的デリバリー：ステージング or 本番環境への反映
  

• 回帰テスト、退行テスト
  プログラム修正の影響（デグレードに繋がっていないかなど）を確認する。

• チームワークのプラクティス
  • 体制

• チケット管理

• スタンドアップ ミーティング
  スピーディーに各自の進捗報告だけを行い、
  その進捗を妨げる課題を特定する。

• レトロスペクティブ
  「チーム自体」やチーム活動の「プロセス」を振り返る活動

ツール関連 †

• アジャイルで利用するツール

• プロジェクト管理
  チケット管理、バグ・トラッキング、チャート（ガント、バーンダウン）、
  その他（ロードマップ表示、カレンダー表示、Wiki、リポジトリ連携）
  • Redmine
  • JIRA
  • Trello、Wrike、Asana、Restyboard、Scrumsiwe、Scrummate、Taiga、ProjectPlace?

• ドキュメント管理
  記法（Wiki、MarkDown?）と差分管理
  • Dokuwiki、Pukiwiki、MediaWiki?
  • GitHub Wiki(GitHubクローンのWiki)
  • Confluence、Esa.io、Qiita:team、docbase

• 構成管理
  Gitがデファクト的な雰囲気ある。

• その他、各プラクティスで使用するツール類

知的財産権適用管理 †

著作権の帰属先 †

記載が無い場合の標準では、ソフトウェアの著作権は請負人に帰属する。

特許権の実施許諾 †

「特許権の実施許諾」とは、日本において、特許権者から実施許諾を受けるコト。

• 必要になるケース
  • 実施には「生産、使用、譲渡、輸出、輸入」が含まれる。
  • 日本で生産性して海外に輸出するケースも該当する。

• 不要なケース
  • 日本では、特許の存続期間は、20年(医薬品などは審査期間を考慮し5年延長可能)
  • 特許出願前に、同党の技術を用い事業を行っていたことが証明できる場合。
  • 個人利用、家庭内利用

コンテンツの不正複製防止方式 †

コレ、ココか？

• CPRM (Content Protection for Recordable Media)
  デジタル放送の「1回のみ録画可」である映像をDVDに録画した後に、
  別の記録メディアにデジタルコピーできなくする著作権保護技術。

• CSS (Content Scramble System)
  松下などが開発したDVD-Videoのコピーガード。
  マクロビジョンなどとあわせて使われている。
  40ビット長の暗号キーにより暗号化される。

• HDCP (High-bandwidth Digital Content Protection)
  著作権で保護された映像コンテンツがHDMIやDVI、DisplayPort?などの接続規格で
  表示装置へ伝送される間に不正にコピーされるのを防止する暗号化技術。

• DTCP-IP
  
  • サーバ機器とプレイヤ機器間の相互認証後に暗号化通信する。
  • ルータの転送回数（TTL）、到達時間（RTT）に制限する。
  • DTCPをIPネットワークに適用しDLNA上で利用する。
    • DTCP(digital transmission content protection)
      著作権保護技術(DRM)により保護されたコンテンツを伝送する規格
    • DLNA(Digital Living Network Alliance)
      団体名の略称であり、この団体の定める規格も指す。
      機器間の相互認証をするらしいが仕様は団体メンバ以外に開示されないため不明。

構成管理・変更管理 †

構成管理 †

構成管理ツール(VSS, SVN, Git)

変更管理 †

コンフィギュレーション・マネジメント・システム（変更作業手順の定義）

• 構成管理・形態管理システム
  プロダクト領域の変更管理を行うメイン・システム。

• 変更管理システム
  プロジェクト領域の変更管理を行うサブシステム。

その他 †

• プロジェクト・マネジメント情報システム（PMIS）

• バグ・トラッカー