2013年07月の記事一覧 | ビジネス書はこれを読もう

ずっと受けたかったソフトウェアエンジニアリングの授業２

ずっと受けたかったソフトウェアエンジニアリングの授業(2)ずっと受けたかったソフトウェアエンジニアリングの授業（2）著者：鶴保征城価格：2,100円（税込、送料込）楽天ブックスで詳細を見る第６章内部設計とプログラミング□ 内部設計設計工程とは・作成しようとしているシステムが外部仕様を満たしているかを検証し確認をとる工程が内部設計である。プログラム自身の設計ミスを未然に防ぐのもこの工程である。・内部設計では、お客様との合意が得られた外部設計書をもとに、ソフトウェアの具体的な実現方法について検討を行う。・内部データやクラスを定義し、サブシステムをモジュールへと分解し、機能仕様を満たすようにモジュールを設計する。・自動車の設計では、部品を設計する段階に該当する。生産性を高めコストを抑えるために、プログラミングでも部品を共通化したり、部品数を削減したりするが、その設計を行うのも内部設計である。□ 内部設計書の構成・内部設計書の作成方針作成するものは何か、どのような基準、ツール、手順で作成するかを定める・モジュールを設計書機能を実現するためのモジュール構成図、各モジュールの処理手順（フローチャートなど）を設計する。・内部データ、クラス設計書内部データの形式、モジュール間データの受け渡し方法など定める・通信プロトコル設計書ネットワーク経由で端末を接続する場合、データのやりとりの決まり（プロトコル）を定める・テーブル設計書データベーステーブル設計書。データの正規化を行う・その他必要に応じてその他の設計書（セキュリティ設計書など）を作成する□ プログラミング工程の作業項目・ソースコード作成における取り決めを作成・単体テスト実施手順書の作成・ソースコード作成環境およびテスト環境の構築・バグ管理手順書や報告様式を整え、管理ツールを導入・内部設計書をもとにソースコードを作成・コンパイルエラーの除去・ソースコードレビューの実施・テストデータの作成・スタブ、ドライバーの作成・単体テストの実施と障害処理票の起票・バグ分析□ 単体テストのテスト項目の作成方法・単体テストはホワイトボックステストで行う。テスト項目は、内部設計書から作成する・作成されたモジュール（クラス）が、内部設計書で記述された機能を満たしているかをチェックする・ソースコードのすべての分岐を通るようにテスト項目を作成するかをチェックする・項目の目安は、経験的におよそソースコードの行数の５分の１程度である□ 単体テストの実施手順・ソースコードの作成・コンパイルエラーの除去・内部設計書の内容からテスト項目表を作成・スタブ、ドライバーの作成・テストの実施・障害処理表を起票・障害管理簿に追記・障害内容の原因を調査・障害処理表の対処内容を記載・障害対処（ソースコードの修正など）・障害管理簿を更新・障害管理簿の内容を分析第７章結合テスト、総合テスト、品質保証の実施方法□ 結合テストの作業項目・テスト計画書の作成テストスケジュール、テスト体制、テスト手順・テスト環境の準備テスト用マシン、実マシン、擬似呼発生装置・テスト項目の作成・スタブ、ドライバーの作成・テストの実施・バグの除去、バグの分析□ ビッグバンテストというのがありますが、これは絶対実施してはいけないテストです□ 結合テストのテスト項目作成方法・結合テストはブラックボックステストで行う・テスト項目は、外部設計書設計書から作成する・外部設計書で定義された機能を満たしているかどうかをチェックする・項目数の目安は、経済的におよそソースコードの行数の２０分の1程度である□ 結合テストの実施項目・ストレステスト過負荷状態におけるシステムのふるまいを確認・性能テスト応答時間や処理速度が規定内かどうか・回復テスト障害が発生した場合の回復機能の動作確認・操作テストオペレータの誤操作に対するふるまいや、操作マニュアルの通りに実施ができるかどうかの確認□ 品質見解の目的・品質見解の目的は、バグの傾向を分析し、構築したシステムの品質が高いことを証明することである・読者は、品質保証部門の人。品質保証部門は、出荷に向けての最終検査の際に品質見解を参照する第８章プロジェクトマネジメントについて□ PMBOKについて・スコープマネジメント・タイムマネジメント・コストマネジメント・品質マネジメント・組織マネジメント・コミュニケーションマネジメント・リスクマネジメント・調達マネジメント・統合マネジメント□ プロジェクトマネージャーのスキル・優秀なプロジェクトマネージャーは、ネゴシエーションスキル（交渉スキル）などのヒューマンスキルも高いことがわかっている・ITベンダーにおいて、トラブルプロジェクトを起こさない優秀なプロジェクトマネージャー不足が深刻な問題となっている第９章ソフトウェア産業の課題とITスキル標準□ ITスキル標準の効用・社会において、ソフトウェア業界に対する正しい認知が拡大・システム受発注でのトラブルを解消・発注者がソフトウェア会社を正しく評価・ソフトウェア業界の生産性が向上・プロフェッショナルのやる気が向上□ ITスキル標準を導入することで最も恩恵を受けるのは、プロフェッショナルな本人です。自分のスキルを棚卸しでき、自分の市場価値を知ることができるようになり、目標を明確化でき、やる気や意欲を高めることができます。□ キャリアとスキル・キャリア；成果（経験・実績）・スキル；能力（知識）・成果主義；利益率の高いお客様が獲得した社員が昇進する・能力主義；利益貢献に無関係に、能力の高い社員が昇進する

ずっと受けたかったソフトウェアエンジニアリングの授業１

ずっと受けたかったソフトウェアエンジニアリングの授業(1)ずっと受けたかったソフトウェアエンジニアリングの授業（1）著者：鶴保征城価格：2,100円（税込、送料込）楽天ブックスで詳細を見る第１章ソフトウェアとソフトウェアエンジニアリングとは□ プログラミングに必要な才能　・第一級の数学者のような理論性　・エジソンのような工学の才能　・銀行員の正確さ　・推理作家の発想力　・ビジネスマンの実務性　・共同作業をいとわず、経営的な関心も理解する性向あ第２章ソフトウェア開発におけるプロセス□ プロセスの定義　・互いに関連をもつ活動の集合で、入力を出力に変換する　・説明可能（定義）　・繰り返し可能（反復）　・測定可能（分析・評価）　・結果の把握可能□ プロセスの改善なくして結果なし□ ウオータフォールモデルの特徴と問題点　特徴　・逐次的に開発を進められ、各段階の成果はドキュメントによって段階的に引き継がれるので、進捗管理が容易　・段階ごとの作業分担がしやすい　・開発方法として定義しており、開発要員の教育がしやすい　問題点　・要求分析の結果がコンピュータ上の動作で確認されるまで長期間を要する　・作業中のある段階で遅れが生じると、それ以降の段階に遅れが普及し、次々遅れが生じる。　・作業中の段階で上流段階の不具合が見つかった場合、上流にさかのぼって修正をするのに多くの労力を要する□ アジャイル開発手法の背景と意味　背景　・ビジネス環境の変化が激しく、仕様が確定しない、カットオーバーしても仕様変更が続く。　・短期開発、低コスト化の要請が大きくなっている。　意味　・優秀な人材のみで構成した小規模のチームの生産性が最も高い。　・複数のプロセスが遂行して進めるコンカレントエンジニアが不可欠。　・お客様がフルコミットした仕様を実現したテスト済みのソースコードの生産（スループット）を最大にする。それ以外は在庫に等しい。在庫はゼロが望ましい。□ 課題とは　・何を解決したいと思っているか　・業務分析、イベント分析を行う　・業務の流れ（業務プロセスモデル）、業務の対象物（業務オブジェクトモデル）を明らかにする□ 仕様とは　・その問題を解くために何をするシステムを開発するか　・問題を解く仕掛けを明らかにする　・情報の入出力　・5W2Hを明らかにする□ 設計で決めること　・システムアーキテクチャー　　ハードウェア、デバイス、DB、ミドルウェア、ネットワーク、セキュリティ、システム信頼性　・ソフトウェアアーキテクチャー　　実装言語、コンポーネントの配置、アプリケーション、通信プロトコル、オンライン/バッチプログラム構造、共通ライブラリ、利用者インターフェース構築　・開発方法、開発ツール、開発環境第３章システム提案書、開発計画書の作成方法□ システム提案書の構成　表紙　・提案先会社名、標題、作成年月日、版番号、作成会社名　本文　・提案先企業の抱えている経営課題・利用者の不満　・経営課題を解決するための方法・システムの目的　・システム化の範囲　・機能概要、前提条件、制約事項　・情報・人・物・金の流れ　・想定する利用者　・システムのハードウェア構成・ソフトウェア構成　・システム化にかかる費用とその効果　・システム提案の独創的なところ・アピールポイント第４章外部設計の作成方法□ 外部設計工程とは　・作成しようとしているシステムがお客様のニーズを見たしているかを検証し、確認をとる工程が外部設計であり、大変重要な工程である　・外部設計工程では、ソフトウェアとしての外部インターフェースを定義し、システムを構成するサブシステムに分解する。また、サブシステムがシステム機能を満たすようにデータ構造や制御構造を設計する□ 外部設計書の構成要素　・ユーザインタフェース設計書　　画面デザイン、帳票・レポート設計、ユーザー要件（想定利用者）　・サブシステム設計　　業務とサブシステムとの関係と機能概要　　新システム導入後の業務オペレーション設計　　サブシステム間のインターフェース設計　・データテーブル設計書　　ファイル設計、データ設計、外部データとの連携方法　・ネットワーク設計書　　コンピュータや端末との接続方法　・システム移行・以降方法、障害発生時の対処方法□ レビュの種類　・要求定義レビュ　　お客様要求が漏れなく記載されているか、誤解はないか、5W2Hについて確認する　・外部設計レビュ　　お客様要求を満たす設計になっているか、画面、帳票、機能などを確認する　・内部設計レビュ　　機能やデータが適切に実現されているか、機能分類やプログラム構造やインターフェースは適切かを確認する　・内部設計レビュ　　機能やデータが適切に実現されているか、機能分割やプログラム構造インターフェースは適切かを確認する　・ソースコードレビュ　　ソースコードやアルゴリズムは適切か、プログラミング規約に準拠しているかを確認する　・テスト計画レビュ　　テスト手順、テスト内容に漏れがないかを確認する□ デザインレビュの目的　　ソフトウェアの品質確保、生産性の向上が目的である　・ソフトウェアライフサイクルの各工程のできばえ（作業結果）を確認する　・当該工程の生産物をレビュすることで進捗状況を把握し、工程完了度合いを把握するためのデータを得る　・当該工程の品質状況を評価し、不良の早期発見と対策の実施を行う　・やり直し工数、マシン工数などの削減を行う　・レビュの結果を設計や製造技術の改善に役立てる□ デザインレビュの種類　・ウオークスルー　　ドキュメントの順を追って確認し、仕様の理解と欠陥の発見を行う。制御やデータの流れのチェックに向いている　・インスペクション　　欠陥の発見を目的とした会議形式のレビュ。検討対象を限定して、短期間に集中して行う　・ラウンドロビン　　レビュ対象のドキュメントを参加者に均等に割り振り、順番に説明していく方法のこと。メンバーの参画意識を高め、教育的な効果もある。□ デザインレビュの実施方法　・デザインレビュを行う日時、場所、参加者を決める　・参加者にあらかじめドキュメントを配布しておく　・レビュ記録票を用意　・2時間以上行わない第５章　ソフトウェア開発の基本設計（分析と設計）□ 構造化設計の特徴　・全体機能をトップダウンで機能階層（モジュール）に分けていく　・モジュールはプログラムとコメントの集まり。互いに独立し小さな業務に対応　・モジュールは「プロセス」とも言う。プロセス間通信はデータフローで行う　・データは機能の中に包含されている□ オブジェクト指向の基本概念　・カプセル化　・抽象化（クラス・オブジェクト）　・階層と継承　・メッセージ　・ポルモーフィズム

鉄のあけぼの/黒木亮

鉄のあけぼの上（角川文庫） [ 黒木　亮 ]楽天で購入鉄のあけぼの下（角川文庫） [ 黒木　亮 ]楽天で購入鉄のあけぼの上□ なあ脇谷。戦局はどうなるか、我々にはわからない。もし敗れて占領されても、敵はこの優秀な工場を廃物にはすまい。いずれ誰かの手で、この機械を動かすだろう。□ おい、藤本。そんなに心配するなよ。人間の心というものはなあ、敗戦のことなどすぐ忘れてしまって、新しい考えでまた立ち上がれるものだ。いつまでもこんなことにとらわれるものじゃないんだ。□ 祖国愛だけは失ってはいかん。祖国愛のない者は、世界で馬鹿にされ、嫌われる。我々は日本という祖国をもっている。それはあくまで愛する。しかし、金儲けに徹するという意味でユダヤ人になるんだ。□ 事業は人だ。わたしは三木知事に惚れ込んだ。だから社運を賭けて、水島に踏み切った□ あなたもいつか人を使う立場になるだろう。色んな人がいるが、その人のいいところだけをみて使っていきなさい。□ 社訓　誠実をつらぬき、人から信頼されよう　現状に満足せずに、ますます努力しよう　創意工夫を心がけよう　互いにしっかりと協力しよう　常に身体の健康に努めよう　産業人として誇りをもとう□ 資源を確保するのに、何が必要かというと、まずは、人だ。どの国にどういう資源があって、どうやれば手に入れられるか、それを調査する鉱山技師、国際交渉のできる人間、そういった人材を集めなければならない。それから金だ。しかし今は千葉に金が要る。水島にも金が要る。だから国を巻き込むのだ。こういう資源は民族の資源であるのだと政府を説得して、国と協力してやっていかなくてはならない。□ 夢をなくしちゃ進歩はないよ☆彡黒木亮さんの本リストラ屋／黒木亮排出権商人/黒木亮エネルギー/黒木亮トリプルA/黒木亮獅子のごとく/黒木亮リスクは金なり/黒木亮鉄のあけぼの/黒木亮冬の喝采/黒木亮法服の大国上/黒木亮法服の大国/黒木亮(下)島のエアライン/黒木亮国家とハイエナ/黒木亮