■ながら開発手法
コーディングしながらソフトウェアの
構造の設計もやってしまう
→仕様・検証の品質が低い→脆弱なソフト
→出荷直後の不具合が多く、時間が経つにつれて少なくなる

■フロントローディング開発
ドキュメントベースで上流工程を見直し
手戻りを防ぎソフトウェアの品質を向上

■組込みエンジニアの資質
①システムに求められた機能や性能を分析し、理論やルールに基づいたモジュール分割を行う力
②エンジニア自身が楽になるためには時間的な制約をクリアし機能的独立性を高める技術が必要
③企画担当者と一緒に求められた機能や性能の実現性を判断し、製品仕様を決める力

■プロジェクトマネージャー
からプロダクトマネージャーへ
・何を作れば売れるのか
　顧客が知る由もない
・でも製品を購入するのは顧客
・『プロトタイプをとにかく早く作る』
・ユーザーに評価してもらい
　フィードバックを得る
・失敗と改善のサイクルを早くし
　洗練されたプロダクトへ

ソフトウェアにおける各担当の役割

■カスタマ・企画担当
　1.要望要求から要件に選別する
　2.要件に対する仕様を記述する
■設計担当
　3.仕様を満たすように設計する
■実装担当
　4.設計通りに実装する
■各担当でテスト振分け
　5.仕様＆要件の実現を確認する

■ソフトウェア品質で求めるレベルは
　各担当者目線で異なる

プログラマ目線：仕様通り、バグがないこと
設計者目線　　：機能が実現されていること
カスタマ目線　：使いやすく簡単で美しい

各目線を合わせるには
『デザインルール』共有するのが得策
と思われる

■状態遷移図を設計で活用しよう
・状態遷移図は遷移表とセットで作成すべし
・以下の三要素の関係を可視化する
　①状態②イベント③遷移
・テストケースはデシジョンテーブルで洗い出すべし
・設計時にテストケースまで考慮出来ていれば状態遷移の
　パターン漏れを防げるだろう😉

■ソフトウェアの資産化アプローチ
①要求を分析し設計へ落とし込むソフトウェアの構造化、モデリング（上流設計）
トップダウン：設計意図を明確にしてソースコードへ反映する

②汎用的な機能の部品の共通モジュール化（下流設計）
ボトムアップ：既存コードを部品化して洗練化・資産化していく

■ソフトウェア要求の変遷

昔は、専⾨知識のある特定ユーザーが操作するため、多少の解り難さや不具合は許容されたが、現代ではソフトウェアが至るところで身近となり『誰でも使いやすい』がスタンダードに。ユーザビリティが求められる。

だから
『ソフトエンジニアはますます忙しくなる😅』

■打合せを行う目的
的確に次の局面への打ち手を洗い出すため

■打合せを行うまでに準備すること
・解決シナリオを自分の中で描いておく
・議題を関係者に事前に周知しておく

■打合せで決めること
・いつまでに、誰が、何を行うか明確にする

準備を怠れば『打合せ』は炎上必死😌🔥

■不具合（バグ）管理表に記録する項目
①バグの概要
②発生条件とタイミング
③再現手順やフロー
④発生原因
⑤対策内容
⑥対策の効果確認

■その他確認事項
・発生日と発生したSWバージョン
・バグ対策に伴うSWの変更点
・変更の影響範囲・波及性

不具合の原因と対策を記録しよう