ポートフォリオサイトの作成の準備 3/27 発表

・参考サイト探し (今日から
・サイトマップとコンテンツマップ(1/22説明)
・素材の準備(画像や文章の用意)
・ワーヤーフレーム、デザインカンプ(2/22,2/26授業)
・HTML CSS 
・JavaScript

ITパスポート演習⑦

マネジメント系

〇企画・要件定義プロセス  PDCAを意識しよう 計画、実行、評、改善

  • ソフトウェアライフサイクルプロセス
    SLCP

ソフトウェアの規格、要件定義、開発、運用、保守までの一連の活動

  • 共通フレーム

共通の物差しとなるガイドライン 一緒に確認していくレシピのようなもの

  • 企画プロセス

システム全体の構想や計画を策定するプロセス 仕事を効率化する こんなのが欲しい

システム化構想

システム化計画

経営上のニーズや課題を確認し、全体最適化を図る

システム化の基本方針を策定 費用対効果などを検討

  • ROI 費用対効果

投資額に対して利益の割合を表した指標 利益÷投資額×100

  • 要件定義プロセス

情報システムの機能や性能を明確にするプロセス

機能要件定義
非機能要件定義

顧客が求めている具体的な機能を定義
実装する機能以外 裏側の見えない機能を定義

  • 調達

RFI 情報提供依頼書
RFP 情報依頼書

情報提供を依頼する文書 依頼元からベンダに渡す
提案書の提出を依頼する文書 依頼元からベンダに渡す

  • NDA

秘密保持契約 企業間で知りえた相手の秘密情報の守秘義務について契約したもの

  • 重み付け評価

重視する度合い

  • 一般競争入札

入札情報を広報やHPに公示したうえで、一定の参加資格を有する参加者から、最も良い条件を提示した入札者と契約する方式

〇開発プロセス

  • 開発プロセス

開発者が利用者の要件を取り入れながら、実際にシステムを開発するシステム
1 システム要件定義 → システムの応答処理時間、信頼性の目標値を決定
2 ソフトウェア要件定義 → 画面や帳票のレイアウトなどを決定
3 システム設計 → ハードウェア構成、ソフトウェア構成を決定
4 ソフトウェア設計 → ヒューマンインタフェースの設計、モジュールの決定
5 ソフトウェア構築 → 設計書に基づきプログラムをおこなう

  • 検討会議

レビュー 定義書は設計書の不備や誤りを早期に発見する目的で工程ごとの検討会議
共同レビュー 開発者と利用者が共同で行うもの

  • ソフトウェアの品質特性

機能性
使用性
信頼性
効率性
保守性
移植性

仕様書通りの結果が出る 
操作がしやすいこと
故障時には速やかに回復できること
応答処理時間など求められる性能が備わっている
修正がしやすいこと
他の環境へ移しやすいこと

  • コーディング規約

標準的な記述のルール

  • セキュリティバイデザイン

システムの企画・設計段階から、セキュリティ対策を組み込んでおこうという考え方

〇テスト手法と運用・保守プロセス

  • テスト

単体テスト→結合テスト→結合テスト→システムテスト→運用テストの順に実施

  • テスト手法

モジュール(部品) ソフトウェアを機能単位でとらえ徐々に積み上げていく方法

  • テストケース

予想と結果が合うかどうか 

  • 単体テスト

プログラム(モジュール)単位のテスト ベンダが実施

  • ホワイトボックステスト

プログラムの内部構造に着目、プログラムが正しく動いているか確認

  • ブラックボックステスト

内部構造は考慮しない、入力と出力だけに着目し外部使用を満たしているか確認

  • 結合テスト

ベンダが実施 プログラム間のインターフェースを確認するテスト

  • システムテスト

ベンダが主体、利用と協力して実施 システム全体の機能や性能を確認する

  • 運用テスト

利用者が主体、ベンダと協力して実施 本番環境下でシステムを運用してテストする

  • 受け入れテスト

利用者が主体 ベンダは支援する 納品されたシステムを、利用者がうけいれるかどうかを確認するテスト

  • ソフトウェア保守

本番稼働中のソフトウェアに対するバグの修正や、新しい要件に対応すること
1 不具合が発生したので修正する
2 法律改正に伴いソフトウェアを修正する
3 修正にともない、設計時のドキュメントを修正する など

  • レグレションテスト

ソフトウェア保守にあたり、修正箇所が他の箇所に影響を及ぼしていないことを確認するテスト

〇ソフトウェア開発手法

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

開発工程を要件定義→設計→開発→テストと上流から下流へ順番に進めていく手法

特徴
・全体のスケジュールをたてやすい
・開発の進捗が把握しやすい
・開発工程ごとに作業が完了してから次に進む
・手戻りが発生しないよう、各工程が終了する際に綿密にチェックを行う

欠点
・開発途中での利用者要件を取り入れにくい
・仕様変更が発生すると手戻り作業による影響が大きい
・最後の工程で不具合が起こると、遡りによるコストが膨大になる

  • アジャイル開発

短い開発工程を何度も繰り返し、迅速かつ段階的に完成度を高めていく手法
利用者のニーズを取り入れながら、短時間で素早く開発する

特徴
・少人数のチームで協力しながらすすめる
・ドキュメントよりソフトウェアの作成を優先
・変化する利用者の要望を取り入れやすい
・軽量で仕様変更しやすい

欠点
・全体のスケジュールが立てにくく、進捗管理も難しい
・開発の方向がぶれやすい

  • エクストリームプログラミング

アジャイル開発の一つ 短い間隔で開発ができる
イテレーション 短いサイクルでプログラムをつくること
ペアプログラミング 2人1組でプログラミングする
リファクタリング 外部から見たプログラムの動作を変更せずに、内部構造を改善する
テストファースト プログラムを書く前にテストケースを作成する

  • スクラム開発

アジャイル開発の一つ 共通のゴールに到達するために、一体となりコミュニケーションをとる
プロダクトオーナー 社長
スクラムマスター 工場長
チーム 作業員
スプリント 短いサイクルで動作するプログラムを作ることを繰り返す
デイリースクラム 毎日のミーティング

  • プロトタイピングモデル

システム開発の早い段階から試作品を作成、利用者の確認を得ながら開発をすすめる手法
認識のずれなどを確認するため

  • スパイラルモデル

システムをさらに独立性の高いサブシステムに分割、サブシステムごとに要件定義や設計開発テストを繰り返しながらシステムを完成する手法

  • RAD

高速アプリケーション開発 PDCAでいうCAを繰り返し開発時間を短縮する手法

  • DevOps デブオプス

開発部門と運用部門が協力しながらシステムの改善を進めようという考え方
作る側と使う側が問題を改善しながらすすめる

  • リバースエンジニアリング

既存のプログラムを解析してそのプログラムの仕様書を導き出すこと

  • ファンクションポイント法

各機能の複雑度を考慮した重み付けをしてソフトウェアの規模を見積もる手法

  • 類推見積法

過去の類似したシステムの実績値をもとにソフトウェアの規模を見積もる手法

  • 開発工数

人月、人日  人月=人数×月数
ステップで見積もるときはソースコードの行数が使われる

〇プロジェクトマネジメント

  • プロジェクト

決められた期間のなかで独自のサービス

  • プロジェクトマネージャー

プロジェクトを管理する人  コスト スケジュール スコープ(作業範囲)
プロジェクトメンバ 業務を遂行する人
ステークホルダ 利害関係者 プロジェクトの影響を受ける全ての人

  • プロジェクト憲章

プロジェクトの目標や期待される効果など  理想像

  • PMBOK

プロジェクト管理に必要な知識を体系化した文書  事例集

  • ディファクトスタンダード

事実上の標準 当たり前になってるもの

  • スコープマネジメント

作業範囲を明確にし、必要な作業を洗い出す

  • タイムマネジメント

予定の期間内に完了させるため、スケジュール、進捗管理を行う

  • コストマネジメント

予定の予算内に完了させるため、コスト管理を行う

  • 品質マネジメント

要求される品質を確保するために品質管理を行う

  • 資源マネジメント

必要な人的、物的資源を管理する

  • WBS

プロジェクトの成果物や作業を段階的に分割した図

  • ワークパッケージ

WBSの最下位にある具体的な作業

  • スコープ

プロジェクトの成果物と、成果物を作成するための作業

  • 結合マネジメント

プロジェクトの制約条件である予算や納期、対象範囲などを統合的に調整して管理する分野
”納期に間に合わせるために、当初使える機能を削る”

  • プロジェクトマネジメントオフィス

プロジェクトマネジメントを支援する部署 各プロジェクトを管理する

投稿者 sochankun

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です