業務系システム開発初心者入門講座
データベースでテーブル設計の列になる項目を抜き出してみましょう。 題材として使っているのは、スーパーの領収書を、 ・領収書(レシート) 前回、分解してデータをグループごとにまとめましたね。 こんな感じになりました。 ・会社情報に関する部分 ・売上伝票の鑑部になる部分 ・売上伝票の明細になる部分 これらが各テーブルの原型になります。 テーブルの列になる項目を抜き出す時のコツは、 基本的に計算で出せる部分を省くことです。 必要な時は、計算して表示すれば良いだけですから、 わざわざテーブルにデータを保存する必要がないからです。 例外としては、集計結果などをどうしても高速で検索したい時に、 処理に余裕がある時に、あらかじめ計算しておいて、 あえてデータを保存しておく手はありますが。 それではまず、会社情報に関する部分から、 必要な項目を抜き出してみましょう。 これは簡単ですね。 会社名、店名、TE
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
Joel on Software - やさしい機能仕様 - パート 1: なぜわざわざ書く必要があるのか?
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/10/2 The Joel Testを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければならないということだった。仕様書はデンタルフロスみたいなもので、みんな書かなきゃいけないと思ってはいるが、誰も書かない。 なぜ人々は仕様書を書きたがらないんだろう? 人々は仕様書作成フェーズを飛ばせば時間を節約できると主張している。彼らは仕様書作成がNASAのスペースシャトルのエンジニアか巨大な保険会社で働いているような人たちのための贅沢品であるかのように振舞っている。戯言だ。何よりも仕様書を書かないというのは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクである。それは着替えだけリュックに詰めて、その場になれば何とかなることを期待してモハーベ砂漠の横断に出発するの
2相コミット - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "2相コミット" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2015年10月） 2相コミット（Two-Phase Commit）とは、コンピュータネットワークやデータベースにおいて、分散システム内の全ノードがトランザクションのコミットに合意するための分散アルゴリズムあるいはプロトコルである。ネットワーク障害やノード故障の場合も考慮され、結果としてトランザクションはコミットが成功するか失敗するかのいずれかの状態となる。しかし、Dale Skeen とマイケル・ストーンブレーカーの研究によれば、2相コミットは同時に複数のサイトが（無作為に）
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ITPro: 基本設計におけるレビューの勘どころ
どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「考慮していない外部システムとの連携が詳細設計で見つかった」，「仕様間の不整合が実装フェーズで発見された」――。どんなに基本設計をしっかりやっても，その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し，進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。基本設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが，基本設計の成果物の品質を向上させるプロセスは，(1)設計作業を実施する，(2)成果物をレビューして欠陥を洗い出す，(
Part4 Eiffelに学ぶ「正しいオブジェクト指向」
ソフトウェア開発コンサルタント。（有）デザイナーズデン代表取締役。要求記述やシステムモデリング，既存システムのリエンジニアリング，リファクタリング，フレームワーク設計，テスト，構成管理，文書化，プロジェクト管理などに関するコンサルティング，教育，開発，著述，翻訳等を手がける。対象ドメインはエンタープライズ・システムから，組み込み機器まで多岐に渡る。最近の関心事は信頼性の高い仕様記述手段の普及と実践。 オブジェクト指向言語といえば，現在ではC++やJavaを思い浮かべる人が多いでしょう。こうした言語で正しいオブジェクト指向プログラミングを行うには，よく考えてクラスの設計を行う必要があります。ただ，正しい設計を行う能力は一朝一夕には身に付きません。こうした訓練に適した言語はないのでしょうか。あります。それがEiffelです。Eiffelは，正しいクラス設計をプログラマに強制します。 Eiffe
[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提（状況／状態）は何か。 成り立つ事が単に多いだけ／今はたまたま成り立っている、と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ