EbichanOO

ペルソナの設定

ペルソナ1：担当教員

• 職業
• 大学教員
• 生活パターン
• 研究と教育業務・事務作業
• 課題
• 採点業務に時間とエネルギーが取られる
• 採点基準がTAによってまちまち
• 採点基準が同課題の中でブレている
• 小さすぎて丸などの採点記号が判別できない
• 採点効率化のために独自のプログラムを組んだりしている

ペルソナ2：TA

• 職業
• 学生
• 生活パターン
• 授業やバイト、研究などの活動
• 課題
• 採点デバイスへのデータ移行が大変
• 採点基準を採点しながら修正する必要がある
• pdfに直接採点する場合採点を修正する手間がかかる
• 問題や答えのpdfが一枚だとどこを見るべきか直観的に分からない

ユーザストーリーマップ

　機能を順次追加する開発方針を取ろうと考えたためユーザーストーリーマップを作成しました。 ユーザーストーリーマップではペルソナごとにユーザーが行う行為、細分化された行為、システムが提供できる価値について記述しました。

システム図

　シンプルなシステム構成について記述しました。 サービスとして提供するものはWeb・AP・DBサーバで、サービスではweb上での採点-確認機能の他通知やデータの共有を行います。 またWeb・APサーバはローカルで動かすことで採点-確認機能を利用することができます。 ローカルの場合のデータ共有方法として、 アプリケーションを利用し採点結果や採点基準などのデータを規定の形式でデコードし、 Slackやメールなどで共有できることを想定しています。

業務フロー

　業務フローでは通常の業務フローとプロダクトを利用した業務フローについて記述しました。 プロダクトやサービスを利用することで、特に採点-確認業務の効率化を行います。
　採点業務を行う際、プロダクトを利用すると串刺し採点で全ての答案の設問単位で一度に採点することができます。 またシステム上のファイルなため、採点基準の変更やそれに伴う採点済み答案の編集が容易に行えます。 採点終了時には採点データや採点基準データなどを規定の形式で送ることで、 採点記号が小さい問題などを解決し確認が容易なデータを送ることができます。
　確認業務を行う際、プロダクトでデコードされたデータを利用するため不明瞭な点が無くなり、確認業務を効率的に行うことができます。
　ここでサービスを利用した場合、web上で簡単に採点-確認を行うことができまた、 アップロードされたデータの共有や採点リクエスト，採点終了，採点基準の変更リクエストの通知を行うことができます。

ER図

　ER図ではデータベースに必要なデータについて論理モデルで書き出しました。

• 科目テーブルは「線形代数」や「情報数学」などを保存します
• ユーザーテーブルはTAのデータや担当教員のデータを保存します
• セクションテーブルは科目の「第一回」や「第二回」に関わるデータを保存します
• 設問テーブルは課題内の「(1)」や「(2)」など1つの問題に対するデータを保存します
• 答案テーブルは提出された課題1枚のデータを保存します
• 採点テーブルは採点されたデータを答案・設問単位で保存します

また関係はほとんどが(1対0~多)ですが、採点者が登録していない段階で課題を登録したい場合があると考えユーザーとセクションは(0~1対0~多)で設定しました。

ユースケース図

　ユースケース図ではユーザーから見た機能について書き出しました。周辺データは採点基準等のデータを指します。 採点データのエンコードはTAがpdfに直接書いた採点をシステムにアップロードすることを指します。

自動CIの構築

　Github Actionを用いて自動テストを構築しました。自動テストはdevへのpush/pull requestとmainへのpull requestをトリガーにしています。 mainへのpushは禁止にし、pull requestは全てのテストが通過しないとマージ出来ません。

Github Projectの利用

　ISSUEにタスクを書き出し、それをToDO/In Progress/Doneのボードで管理しています。