学生のための学食のカロリー管理システム

小笠原研究室B班

目次

1. システム要件概要

2. プロジェクトマネジメントの結果

1

3. 総括

Quality : 品質

Cost : コスト

Delivery : 納期

1. システム要件概要

2

背景

現在、カロリー管理に関する病気が増加している。

大学の学食ではカロリーが表示されていない！

しかし…

3

（1）カロリーが一目でわかる

（2）そのカロリーが消費できる運動情報が得られる

学食のカロリー管理システム4

課題と改造内容

学食のカロリー管理システム

(1)学食のメニューが固定ではない。

→管理者が編集できるようにする。

5

ユーザ画面・メニュー一覧表示機能・カロリー計算機能・運動内容表示機能

学食のカロリー管理システム

当サイトの主な機能

管理者画面・ログイン機能・メニュー追加機能・アカウント作成機能

6

画面イメージ

(1)トップ画面(2)学食メニュー一覧表示画面(3)計算結果表示画面(4)管理者ログイン画面(5)管理者トップ画面

1.メニュー追加画面2.アカウント作成画面

7

http://ogasawarab.******.****/

2. プロジェクトマネジメントの結果

8

1. 目標・目的の達成

3. 品質尺度

2. 成果物・提供したサービス

評価内容

Quality : 品質

9

システムの目的

明らかになっている以下の課題を解決する webシステムを開発する．

・明らかにされていない学食のカロリーを表示すること．

・摂取したカロリーを消費するのに適した運動量を表示すること．

・表示した運動の詳細を表示すること．

Quality : 品質

プロジェクト目標

本プロジェクトの最終的な目標をいかに記述する．

品質 品質マネジメントにおいてインスペクション技法を用いて，システムの品質を向

上させる．

コスト ＰＭ：1500円/時給

一般：1200 円/時給

プロジェクト終了時点での総人件費は予算を含め 786000 円以内に抑える(総時間

524×ＰＭ時給 1500円)に抑える．

資材費に関しては，予算費を含め 35万以内に抑える．

納期 7月 13日までに完了する．

1. 目標・目的の達成

10

Quality : 品質

2. 成果物・提供したサービス

全て達成！

11

成果物名達成

チェック

要件定義書 ☑

プロジェクト憲章 ☑

プロジェクトマネジメント計画書 ☑

外部設計書 ☑

テスト計画書 ☑

コスト見積書 ☑

契約書 ☑

内部設計書 ☑

プログラム ☑

テスト報告書 ☑

納品書 ☑

QCD評価報告書 ☑

マニュアル ☑

Quality : 品質

3. 品質尺度

本プロジェクトではシステム品質を以下の内容で評価する．

・テスト計画書に基づいたテストにおいて全て合格すること．

・内部設計書とコードにおいてインスペクション技法を用いて検出できた欠陥が除去

できていること．

・プロジェクト品質

→メンバ全員が成果物のレビューを実施し，成果物の内容確認を行う

・システム品質

→インスペクション技法を活用して成果物の欠陥を除去し，保証する．インスペクシ

ョンの対象は内部設計書とコードとする．

12

Quality : 品質

方針 : 品質マネジメントにインスペクション技法を導入

成果物内の問題を検出するために，事前に定めた観点でチームメンバがレビューを行い，開発プロセスの評価を行う技法。

3. 品質尺度

13

インスペクション技法

14

インスペクション技法の実施方法

メンバとシニアが対象成果物のチェックを行う．

Quality : 品質

メンバとシニアの4人で指摘内容について1時間話し合う．

話し合った内容を基に対象成果物を修正する．

Quality : 品質

インスペクション技法

対象成果物 : 内部設計書

詩的内容 区分 影響度ページ番号が無い． 欠陥 軽微IDのシーケンス設定が空である． 欠陥 軽微

Null制約⇒"Not"Null制約の可能性が高くID以外が逆になる．

欠陥 重大

15

648,500円

Cost : コスト

予定人件費 実際の人件費

604,500円-

= 44,000円成功！

16

Delivery : 納期

開始 終了 期間 開始 終了 期間 開始 終了要件定義書 4月27日 5月25日 18日 4月27日 5月25日 18日 0日 0日プロジェクト憲章 5月11日 5月25日 15日 5月11日 5月25日 15日 0日 0日プロジェクト計画書 5月17日 5月31日 15日 5月17日 6月1日 16日 0日 1日コスト見積書 5月29日 5月31日 3日 5月29日 6月29日 31日 0日 28日契約書 5月24日 5月31日 7日 5月24日 7月13日 50日 0日 43日外部設計書 5月24日 6月1日 9日 5月24日 6月1日 9日 0日 0日テスト計画書 5月30日 6月1日 3日 5月30日 6月1日 3日 0日 0日内部設計書 6月17日 6月22日 12日 6月17日 6月29日 13日 0日 1日プログラム 6月21日 7月7日 17日 6月21日 7月19日 30日 0日 13日テスト報告書 7月1日 7月7日 7日 7月1日 7月19日 19日 0日 12日納品書 7月1日 7月7日 7日 7月1日 7月7日 7日 0日 0日マニュアル 7月5日 7月6日 2日 7月5日 7月7日 3日 0日 1日QCD評価報告書 7月12日 7月13日 2日 7月12日 7月19日 8日 0日 6日

タスク名基準計画 実績 差異

17

納期の成功基準は１４日以上超過しないこと．

成功！

Delivery : 納期

納品日に完成していない。

18

理由1 成果物の勉強時間の見積もりが甘かった．

理由2 事前に終わらせておくべき成果物が終わっておらず，次の成果物に取り掛かる時間が遅かった．

3. 総括

19

20

プログラミングの工程で遅れが生じた．

Delivery

Quality✔

✔

✔ Cost 成功！

21

中間発表時点での課題

成果物の修正が多く進捗に影響していた．⇒メンバ個々のレビューを強化

メンバー全員でレビューをする時間を設けたところ，成果物の修正が1度のみになってしまった．改善できたといえる．

22

1. 画像ファイルの追加がうまくいかず仕様変更し，納品した．

反省・改善策

2. 進捗，納期が遅れたこと．

⇒

23

勉強時間の見積もりが甘く，予定よりも超過していた．

⇒全員の知識を把握し，各々のLevelにあった作業分担をする．ガントチャート作成時に成果物に対する勉強時間を確保しておく．