迅速で良い:(要件->検証->設計）自己使用のためですか？
必要なソフトウェアエンジニアリングと設計を何気なく行うにはどうすればよいですか？
私は経験の浅い開発者であり、次の問題に直面しています。
- 私の会社は新興企業であり、ソフトウェアエンジニアリングシステムの修正はありません。
- 私には、あまり明確で矛盾する要件を持つタスクが割り当てられています。
- 設計に従う必要も、要件を公式に検証する必要もありません。
問題：
- 私は一日中コーディングし、最終的に要件が競合する場所で行き詰まり、最初からやり直す必要があります。
- 適切なSRSまたはSDDを実行するために多くの時間を費やすことはできません。
どのようにすればよいですか：
- 自分の要件をリストアップしてください。（公式文書ではありません）
- 要件を確認および検証する方法は？
- それらを視覚化する方法は？
- 最小限の労力でそれらを設計する方法は？（私だけと一緒になるので）
要件の競合などによって崩壊するものをコーディングするのに時間を無駄にしたくありません！
品質に妥協したくはありませんが、予期していなかった変更についてすべてを書き直したくありません。
思考プロセスの図を作成して、図自体の矛盾を示し、最後に図を修正することを想像します。設計を決定し、インターフェイスなどの観点からコードを構造化します。
そしてついに私のデザインの実装を開始します。
体系的なアプローチの欠如を感じることはできますが、どうすればよいかわかりません。
要件検証のために話し合った図をどのように作成できますか？
あなたが一人で働いているからといって、あなたがすでにあなた自身のために経験したように見えるので、あなたが適切な工学技術を無視するかもしれないという意味ではありません。
コンポーネントの適切なアーキテクチャと設計を考えて文書化することを避ける方法は絶対にありません（些細なコンポーネント以外のものを考慮して）。あなたは変化に直面しなければならず、あなたのデザインは進化しなければならず、それがあなたの脳とあなたのコードの間のどこかにしか存在しない場合、あなたはある時点でそうすることに失敗するでしょう。
あなたの場合に私が提案するのは、一種のアジャイルアプローチです。いくつかのプロセスがそれを要求するので、それを文書化するために何かの文書化を作成する必要はありません。代わりに、あなたにとって本当に重要なことに集中してください。文書化しないでおくと後で問題が発生すると思われる場合は、文書化してください。
また、要件の管理を避けることはできません。このためにいくつかのツールが存在し、起動して実行するのに最小限の時間を費やすことができるツールを使用する必要があります。ツールは、視覚化と検証（テストカバレッジ、相互依存性など）にも役立ちますが、検証には役立ちません。検証は、ある種の顧客（あなたの場合は上司である可能性があります）がいる場合にのみ可能です。
最後に、最も重要なポイント。あなたの声明 "私はできません-適切なSRSまたはSDDを行うのに多くの時間を費やすことができません。"はあなたの思考プロセスの大きな欠陥です。作業を再実装して無駄にする時間を考えてください。最終的にここに投稿することにつながる、遭遇したすべての問題について考えてください。次に、適切なエンジニアリング手法に本当に時間を費やすことができない場合は、もう一度考えてみてください。上司がそれに時間を無駄にしないように言った場合、あなたは長い議論のために座る時が来ています。なぜなら、あなたは両方ともどこにも行かない道にいるからです。
文書化へのアプローチの努力に関しては、バランスを取るべき典型的な対立が常にあります。そして、私はそれがどこにあるかを言うためにあなたの言葉を引用します-
適切なSRSまたはSDDを実行するために多くの時間を費やすことはできません。
vs.
要件の競合などで崩壊するものをコーディングするのに時間を無駄にしたくありません!!
これは、ほとんどすべての人が直面する一般的なパターンです。そして、これを共有する他の人がいないという基準を削除すると、私たちがさらに避けられなくなります）dontドキュメントに移動します。しかし、あなたは「ドキュメンテーションを行うかどうか」よりも「ドキュメンテーションを行う方法」という質問に光を当てています。
私が言いたかったのは、本質的に努力と明快さのバランスです。より単純なアプローチが役立つかもしれません。
不必要な形式主義を避けてください-それは多くの人々をより速く行かせます。タイピングが遅くなるわけではありませんが、正式な文章を探すのは面倒です。
箇条書きやメモとして物事をもっと入れてください-時々、あなたは外のもののようなより多くのエッセイをしてそれをリンクすることができます。
すべての読み物、考え、質問を適切な場所にダンプし続け、メモに、そしてトピックに急速に進化します。整理してください。たとえば、最初は、protocolにどの要素があり、classes。時間の経過とともに、プロトコルに関連するすべての要素をグループ化してセクションに配置します。このようにして、正式なドキュメントを進化させ続けることができます。
理由を書き留めてください。 （自分で）文書化する最も重要な理由は、戻ってなぜいくつかの決定が行われたかを確認することです。これが必要なときにどのような選択肢がありますか。だから、あなたが彼らに質問する必要があるとき、それは非常に重要になります。
最後になりましたが、最も重要なのは、同じ場所に行き続けることです。ほとんどの場合、ある程度の速度に達したときにメモについて心配する必要はありません。正式ではなく、自分らしくなりましょう。
適切な開発に時間をかけないと、その10倍の時間を本番環境でのソフトウェアの修正に費やすことになります。さらに悪いことに、あなたは仕事を失い、あなたの会社に費用をかける可能性があります。
開発者が直面する問題のほとんどは、プロジェクトの納期に関してなされたコミットメントに起因する可能性があります。時間の必要性について経営陣に明確にしてください。
会社にリソースがない場合は、次のことが可能です。
1-システムの最も必要な部分を優先し、指定された時間内に上位の部分を実行するように依頼します2-より多くの人を雇って支援します3-すべてを実行しなくても、機能する既製のソフトウェアを購入します必要な作業
あなたの質問は、ソフトウェアエンジニアリングと要件管理のすべての文献、およびソフトウェアスペクトルの他の部分をカバーしているため、完全な答えを与えることは不可能ですが、ここに簡単なものがあります。
どのように私はすべきですか：
1-自分の要件をリストアップします。 （公式文書ではありません）2-要件を検証および検証する方法は？ 3-それらを視覚化する方法は？ 4-最小限の労力でそれらを設計する方法は？ （私だけと一緒になるので）
回答1：ビジネスエリアをより小さなものに分割する必要があります（大きい場合）-入力データとビジネスルールをそれぞれ明確かつ簡潔な言語で明確に文書化し、読みやすいリストとして提示します。重要なアクティビティのユースケースをいくつか作成してみてください。
回答2：上記の回答1の成果物と、上記のタスクの完了時に出てくる質問は、要件の検証についてお客様と協力するように依頼するのに役立ちます。
回答3：結果を1と2からクラス図やERD、ユースケースとシーケンス図、またはBPM図に変換します。
回答4：可能であれば、ORM、サードパーティのGUIコンポーネント、コードジェネレーターなどのツールを使用してください。
次のことを明確に理解する必要があります。
システムの目的
システムのさまざまなタイプのユーザーとセキュリティへの影響
ソリューションに最適なプラットフォームは何ですか
ドキュメントは時間の無駄ではありません
ユーザーコミュニケーションは必須です-早期に参加させてください
経営陣の関与とコミュニケーションは必須です-早期に関与する
現実的な目標と見積もりは必須です
幸運を