業務アプリ設計メモ

業務アプリ作成時のメモ

業務アプリ設計メモ
  アプリ面設計ポイント  
  画面遷移方法 同一画面で遷移するか、ポップアップ表示するかの検討。
①同一画面遷移
 データを更新する処理がある場合によい
 参照が主で、連続する場合は画面遷移が多くなってしまう
②ポップアップ表示
 元画面を参照する場合や参照データが連続する際によい。
 閉じた場合に元画面を操作されても不整合が起きないように制御する
③同一画面でタブ切り替え
 
  ポップアップ仕様の検討事項  同一画面で更新 or 複数許可
 同一画面更新の場合 クリック時の最前面に表示されるか
 ※後ろで更新されるとユーザに不具合と思われる
 
  詳細画面から一覧画面の遷移 元のページ、元の検索条件で戻るようにする
・1ページに戻ると元のページに戻るのが手間である
 
  一覧画面の期間選択 ・検索できる期間はレスポンスを考慮した設計が必要
・上限期間が短い場合は、期間入力の手間を減ら得るようにボタンクリックで期間を増減させる等の配慮をする
・過去や未来を選択した場合に当日選択ボタンがあると便利
 
  プルダウンが複数関連 プルダウン等が複数関連している際は選択値を維持できるとよい  
  操作ログ 各画面、ボタンの操作ログ(ユーザ、画面、ボタン操作等)があると障害時の調査に便利  
  メール送信機能ポイント ①メール受信目的
・作業依頼、通知、
 例:申請、承認、登録等
・承認する。作業する。部下やチームの状況を知る。
②タイミング
・都度
 普段利用しないシステムだと都度が良い。※放置される
 ただ、普段利用で1日100件を超えるようなシステムの場合
 迷惑メールになり無視される。クレームになる。
・一定期間に纏めて
 上記のような場合、定期的にそのシステムを利用しているため
 1日1回にxx件です。といった感じで送信するのがベスト
③メールの内容
・ある程度、本文に記載するのがよいが
 都度送信の場合だと、そのシステム・処理データへのリンクがあるのがよい。
④メール送信先
・基本は会社用アドレスになるが、モバイルや個人重視の場合
 個人所有のアドレスを設定可能にするのもあり。
 ※労務上、監査等で時間外労働にあたる可能性もある。
 
 
  一覧画面の検索仕様 ・検索条件:ID,氏名、部署、保有権限
・検索結果表示項目:
・初期表示条件、表示順
 
  データ閲覧範囲の制限と管理 登録したデータを閲覧、承認できる利用者の制御方法
・特定部署や担当者間で共有したいのか、ダメなのか。
・共有する場合は組織変更や人事異動時の対応を定義する。
・データ共有範囲の設定基準:部署、役職、権限、ユーザ個別等
・そのメンテ、運用手順
 
  データ削除時の動作 削除時に物理削除か論理削除か。
誤操作の復旧を想定すると論理削除になる。DB容量に注意する。
 
非機能要件ポイント  
  各種ログ 取得するログの種類とログローテート期間
期間は長ければより調査しやすいが、容量逼迫の原因ともなる
 
  アクセスログフォーマット 障害調査等、タイムやエージェント情報出力しておく  
  サーバの負荷状況出力 サーバのCPUやメモリ利用状況を取得しておく
LINUXならvmstat等
 
  DBバックアップ 不測の事態(誤操作による消去やハード障害)に備えて日次バックアップ等
可能なら別サーバにとる
 
  DISK利用状況 月次等で利用量を取得しておく。  
  システム環境 本番、PRE、開発、検証の4つあるとよい
開発>開発環境
検証>開発ソースの検証
PRE>本番リリース前の最終動作確認。DBは本番同期しておく
 

 

22/2/17

・エラーやワーニング、システム通知メールの文言。一貫性や言葉遣いを意識する。

 口調が強かったり、上から目線にならないようにする。