問題と対処方法


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

思いついたら即追加!

○全体
  • UMLの知識にばらつきがあった。
 対処:教科書をベースに、分かる人が適宜教えあった。
   それでもよく分からない点は、先生にアドバイスを求めた。

  • PCが1台のため、作業効率が悪い。
 対処:実験時間内では、レビューやユースケース図の作成などの
   並行作業ができない事だけを行うようにした。また、時間のかかる
   修正作業は、図書館のPCも使って並行作業した。

  • 予定が遅れた。
 対処:あらかじめ余裕を取っておいた、レポートやスライドの作成部分を短縮し、
   それまでの予定を1週間ずらした。

  • JUDEが扱いにくく、使用方法に時間をかけた。

  • JUDEの使い方がよく分からない。
 JUDEを使った事がないメンバーがいた。
 対処:分かる人が適宜、操作方法や便利な操作を説明した。

  • 作業を分担したために、意思疎通が図れない。

○分析
  • 要求分析の時点で度重なる新規問題点が発生。
 ユースケースの作成に予定よりも時間がかかった。

  • 項目や用語のずれ
 入力する項目や用語などを全体で事前決めなかったので、各自が勝手に想定してイベントフローやシナリオを作成した。その結果、ユースケース間で項目や用語にずれが生じた。
 対処:レビュー前に項目や用語を統一し、修正した。

  • イベントフローやシナリオ作成後の名詞の統一。
 レビュー時の修正に時間がかかった。

  • 設計要素の排除
 どこまでが設計要素で、どこまで排除すべきかを悩んだ。
 対処:レビュー時に排除基準を検討した。

  • セキュリティの問題
 「誰でも自由に」をコンセプトにしてきたが、悪意あるユーザによる
行為への対処を全く考えていなかった。
過去問情報、問題や解答の削除をどうするか、など。
 対処:システムの機能や処理の流れといった根本的な所から見直し、
   再分析をした。
   問題や解答は履歴を作成し、過去問情報は管理者を置くようにした。

  • 問題や解答が複数存在する場合。
 期末だけを想定して作ってきたが、中間や再試などはどうするか全く想定していなかった。
 対処:wikiを使って、中間や再試に対応すべきかや対応方法について話し合った。
   結果、今回は期末のみで統一した。

  • 図の描き方にばらつきや誤りがあった。
 対処:気づいた箇所については、その都度描き方の確認と統一を行った。

○設計
  • データベースの問題
 データベースを設計のクラスとして取り入れるべきか。
 対処:全体で徹底的に討論した。また、先生にアドバイスを求めた。
   データベースは実装の問題とし、設計段階では加味しないことに決定。

  • クラス間の関係に悩む