問題と対処方法 - narui_shota @ ウィキ

思いついたら即追加！

○全体

• UMLの知識にばらつきがあった。

　対処:教科書をベースに、分かる人が適宜教えあった。
　　　それでもよく分からない点は、先生にアドバイスを求めた。

• PCが1台のため、作業効率が悪い。

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

• 予定が遅れた。

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

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

• JUDEの使い方がよく分からない。

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

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

○分析

• 要求分析の時点で度重なる新規問題点が発生。

　ユースケースの作成に予定よりも時間がかかった。

• 項目や用語のずれ

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

• イベントフローやシナリオ作成後の名詞の統一。

　レビュー時の修正に時間がかかった。

• 設計要素の排除

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

• セキュリティの問題

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

• 問題や解答が複数存在する場合。

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

• 図の描き方にばらつきや誤りがあった。

　対処:気づいた箇所については、その都度描き方の確認と統一を行った。

○設計

• データベースの問題

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

• クラス間の関係に悩む