システム設計の流れ - Qiita
昔のメモを整理してると出てきました。今となっては心底どうでもいい。 上流工程に関するあれこれ 大まかな流れ 基本的な流れとしては要件定義→外部設計→内部設計→開発の流れが採用される。 ここで外部設計は基本設計、内部設計は詳細設計とも呼ばれる。 一般にウォーターフォールモデルでの考え方では外部設計までが上流工程と考えられるようだ。 要件定義 要求開発(超上流工程) [ 業務フロー ] 業務とその流れを表現するもの。素人にもわかるように → アクティビティ図 業務機能関連図 [ 業務モデル ] 業務を静的に表現する。 → ERD クラス図 要件定義 システムの範囲を決定する。何を作って何を作らないかを明確にすること。 1.機能要件 ユースケース一覧 機能一覧 2.非機能要件(FURPS+) >機能 機能要求 >使用性 UIの指針、ユーザ教育、マニュアル >信頼性 管理、監視、保守、復旧 >性能
基本/詳細設計って呼び方やめませんか - Qiita
システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう？ 各ドキュメントはどうやって関連付けるといいんだろう？ 基本設計書と詳細設計書はなにが違う？ 開発 なんでこういう設計になっているんだろう？ 設計されていない組み合わせのデータはどう処理すればいいんだろう？ 試験 試験データのパターンや量はどれくらい用意すればいいんだろう？ 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や
システム開発に欠かせない見積もり前提条件について | DevelopersIO
こんにちは！おおはしりきたけです！今日はシステム開発に欠かせない見積もり前提条件について書きたいと思います。 ■はじめに 弊社では、受託開発を多くやっております。受託開発は、最初のスタートが重要です。私見ですが最初のスタートで成功確率の80%は決まっているといっても過言ではないと思っております。そのくらいスタートというのは大切だと思っております。エンジニアの方々の中には、営業さんが「あとはヨロシクッ！」と言って金額しか決まっていないプロジェクトを経験し苦い思いをした方も多いのではないでしょうか。弊社では、そのような事が起こらないよう営業さんとは密な連携を取りプロジェクトが成功可能かという判断をし、成功可能なプロジェクトに対し開始するということを行っています。その作業の中でも特に重要なのは、見積もりの前提条件です。 ■なぜ前提条件が必要か 見積もりを出すときの流れは大まかにいうと以下のように
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
