2011年02月の記事
全9件 (9件中 1-9件目)
1
-
クラウドHACKS!/小山龍介
クラウドＨＡＣＫＳ！ ―同期と共有でラクチン・ノマドワークスタイルクラウドHA...著者：小山龍介価格：1,575円（税込、送料込）楽天ブックスで詳細を見るクラウドHACKS!はじめに □ 理爪で相手を納得させる議論ではなく、共通認識井を確認しあう対話。そして、メンバーを同期してプロジェクトを進めるためのリアルタイムコミュニケーションが重要となるのです。 □ 宇宙に衝撃を与えてやるんだCAPTER１ データハック □ ローカルPCからクラウドへの引っ越し □ ドキュメントスキャナで紙のしょりぃをデジタル化する。 大量にスキャンするのであれば、ScanSnap S1500、それほど多くなければ小型のCanon DR-150 □ クラウド時代には、本の付き合い方も大きく変化していきます。本は１冊１冊を完結して読むよりも、キーワードのリンクをたどって見ていく横断的読書へと変化していくのではないかと思います。 □ 入門書の読書 １）読みやすくわかりやすいこと ２）その世界の全体像が的確に伝えられること ３）基礎概念、基礎的方法論などがきちんとセイルされていること ４）さらに中級、上級に進むためには、どう学んでいけばよいか、何を読めばよいかが示されていること □ 蔵書リストはクラウド管理する。メディアマーカーはMYバインダーへ登録するという仕組み。アカウントを登録すれば、あとは書名や著者名などから書籍を検索、登録していくだけです。 □ 多くメッセージを詰め込むことはせず、１スライド１メッセージのみ。スライドはポンポン変えていくのではなく、３～５分に１枚、じっくりと伝える。スライドは文字だけでなく、できるだけビジュアルを使って感情豊かに伝える。 □ クオリティ高い写真はフォトストックサービスを利用する。 □ 写真はクラウドに一元管理する。Picasa Web Albumがおすすめです。CAPTER2 情報収集ハック □ 重要なウェブページはPDFで保存する。ウェブページのPDF化には、PDF Downloadなどを使います。 □ RSSはGoogle Readerでクラウド管理する。 □ Xmarksでブックマークとパスワードを同期させる。 □ Tumblrでクリッピングブログを作る。 □ インターネット上の情報はそのままでは単なる「データ」でしかありません。しかしそれを日本語入力の辞書として活用することで、今度はそれが「情報」となり、さらに「知識」へ、そしてさらに「知恵」へと変化していくのです。それがクラウドへと集められることによって「集合知」として利用できる。 □ iTunes-Uでは、さまざまな大学が提供する動画や音声コースをダウンロードできるようになっています。Capter-3 ノマドワークハック □ 充電可能な電源カフェはGoogleマップで見つける。 □ Awesome NoteでGoogle Docsを編集する。 □ Google Readerを使って文書を閲覧する。 □ iPhoneのカメラを使って書類を取り込む。 □ WorldCard MobileというiPhoneアプリを使えば、名刺を読み取り、しかもOCRまでしてくれます。 □ ノマドワーカーのためのリラックスハック ・ピースオブマインド ・アロマパルス・」リラクセーション □ 最近、地域活性の運動が盛んに行われていますが、その際に必要な人材として、３つの人材があげられています。 １）ワカモノ・・・行動力のある人 ２）ヨソモノ・・・しがらみのない人 ３）バカモノ・・・ゼロベースで考えられる人Capter-4 クラウドタイムハック □ Google Calenderで業務データベースを構築する。過去はアーカイブして頭の中から消し、未来はデザインした上でスケジュールに記入して忘れる。 □ 過去のメールをテンプレート化して再利用する。 ・Gmail Tempate Switcher3 □ OhLifeで非公開日記をつけるCapter-5 クラウドチームハック □ 各自の裁量で働く時間を決めていくよう、自主性を重んじることが重要です。 □ モチベーションを高める自律性に４つの基本要素、課題（Task）、時間（Time）、手法（Tecqnic）、チーム（Team） □ Google Calenderで共有 □ CCですべてのコミュニケーションを共有する □ Skypeを使ってチームミーティングを開く □ 「伝助」で簡単スケジュール調整 □ Teamboxでプロジェクトを管理する □ クラウドによるプロセス管理を導入することによって、透明性の高い人事考課の可能性も見えてくる。Capter-6 アウトプットハック □ 自分では「分かっていない」と思っていることにあえて取り組む □ わからないからこそ、自分のテーマにする □ ロジカルに考えず、全体像をイメージする。 □ 無意識の領域から意外なアイディアをアウトプットしようとする場合には、ロジックは邪魔になるのです。 □ 異なるように見えたものの中に共通性を見つけ、つなげていく思考 □ プライベートライティングによるアウトプットトレーニング ・原則：自分の書いたものを誰にも見せない。 １）自分のくだらない考えや、下手な書き方を許容すること ２）手を止めずに書き続けること ３）時間を決めて取り組むこと ４）ウソのない素直な考えを引き出すこと □ アウエイに身を置く □ アウトプットした後に「編集者の目」で再構成するCapter-X クラウド手帳ハック □ 点を線へとつないでいくことは、僕たちの人生の本質にも関わる大きなコンセプトです。
2011/02/26
コメント(0)
-
EVERNOTE「超」仕事術/倉下忠憲
EVERNOTE「超」仕事術EVERNOTE「...著者：倉下忠憲価格：1,470円（税込、送料込）楽天ブックスで詳細を見るCHAPTER-2 「知のデータベース」になんでも詰め込もう□ Evernoteを使えば、ソーシャルブックマークとは別の機能が実現できますそれは、次のような点です。１）他人と共有されない２）保存範囲の選択ができる３）コピーを保存する４）加工性が高い□ アドオンやエクステンションでウェブクリップを効率化する□ EvernoteのOCR機能□ 「フォルダーのインポート機能」を利用すると、指定したフォルダーに追加されたファイルが自動的にEvernoteの特定のノートブックに取り込まれます。設定するフォルダは複数指定できるほか、連動するノートブック、連動した後にフォルダーのデータを削除することが指定できます。□ デジカメを使う場合は撮影したファイルを一度パソコンに移動させてその後Evernoteに取り込む作業が必要です。これが面倒な方にはEye-Fiカードというものがあります。□ メモをさっと記入する「FastEver」□ Evernoteには大きく分けて3つの要素があります。データを保存してある「ノート」、そのノートを入れておく「ノートブック」、そしてノートにさまざまな情報を付け加える「タグ」。□ クラウドベースのスキャンソフト「ScanDrop」CAPTER－３ 「知のデータベース」から縦横無尽に情報を引き出そう□ 思いついた着想はすべて書き留める□ それらを見直して、脈がありそうなものは移動させる□ 移動させたものを見直して、まだ脈がありそうな物はもう一度いどうさせる。□ Evernoteに集約する事で、情報に関する制約はかなり解消されるはずです。Evrenoteに集約・蓄積しておけば、それらの制約から解放され情報が持つ力を最大限に発揮することができるでしょう。CAPTER－４ ストレスフリーのタスク管理□ GTDの基本的な流れと考え方１）収集ステップ２）処理ステップ３）整理ステップ４）レビューステップ５）実行ステップ□ GTDの要点とは１）頭の中の「気になる事」を「すべて」頭の外に追い出す２）そのすべての「気になる事」について、求めるべき結果と次にとる行動をきめよう３）決めた「とるべき行動」を信頼できるシステムで管理し、定期的に見直すCAPTER-5 「自分専用データベース」で人脈管理□ わたしはGMAILの「フィルター」機能を使って特定の人から来たメールは自動的にEvernoteへ転送されるように設定しています。CAPTER-6 「共有ノートブック」でコラボレーション
2011/02/25
コメント(0)
-
グーグルで必要なことは、みんなソニーが教えてくれた/辻野晃一郎
グーグルで必要なことは、みんなソニーが教えてくれた【送料無料】グーグルで必要なことは、みん...価格：1,575円（税込、送料別）□ ソニーの双方での「さん」付けのコミュニケーションスタイルは、何でもないことのようであるが、当時の日本企業では珍しく、なかなか画期的なものであった。□ 「初めて日産を見たときには、とにかく問題だらけなので、大きなPotential of Progress（改善の余地）を感じた。」ということがあった。そのようなポジティブ思考そのものが彼の真髄なのだろう。□ 社内改革において抵抗勢力にどう対応すべきか、というテーマについては、Just ignore them（ただ無視するのみ）という答えであったのを痛快に思った。□ グーグルではすべてがハンズオン（自ら動く）であった。□ グーグルが見つけた１０の真実 １）ユーザーに焦点を絞れば、他のものはみな後からついてくる。 Focus on the user and all eles will follow. ２）ひとつのことをとことんきわめてうまくやるのが一番 It's best to do one thing really,really well. ３）遅いより速い方がいい Fast is better than slow. ４）ウエブでも民主主義は機能する Democracy on the web works. ５）情報を探したくなるのはパソコンの前にいるときだけではない You don't read to be at your desk to need an answer. ６）悪事を働かなくてもお金は稼げる You can make money without doing evil. ７）外にはいつも情報がもっとある there's always more infomation out there. ８）情報ニーズはすべての国境を超える The need for information crosses all borders. ９）スーツがなくても真剣に仕事はできる You can be serious without a suit.１０）すばらしいでは足りない Great just isn't good enough. □ 人間はあまりに忙しすぎると、自分のやっている仕事の本質的な意味を忘れてしまう傾向がある。 □ 能率の追及が有効性の考察を排除する。 □ 自分より優秀な人材を採用せよ。 □ crowdは「群衆の英知（wisdom of crowd）」や「クラウドソーシング（crowd sourcing）」など不特定多数の人達がネット上でその英知を結集することを表現する場合などによく使われる。 □ 2009年1月の社長就任時には、あまるグーグルらしいアプローチではないことを意識しながら、あえて、「Change ＆ Charenge（変革と挑戦）」というスローガンを掲げ、５つのキーワードを社員全員共有した １）Solidarity（連携/団結） ２）Accountability（説明責任） ３）Commitment（約束） ４）Conribution（貢献） ５）Motivation（やる気/意欲） □ 変化の時代には変化に逆らっても自分が淘汰されるだけである。 □ 何かを得るためには何かを代償にしなければならない。失うものがあれば必ず得るものがある。 □ 人生はたった1度しかない。自分の人生は、人に縛られるよりも、できるだけ自分でコントロールした方がいいに決まっている。 □ 私には夢がある。全く新しい会社を作る その会社は井深さんがソニーを作ったときの精神を共有し、「真面目なエンジニアやデザイナーが、その才能を最高度に発揮できる自由闊達な」会社である。 □ その会社の社員は、「少数精鋭を前提に厳選したメンバー」で構成し「無意味な階層を持たず、すべての秩序は実力本位、人格主義基に構築して、個人の能力を最大限に引き出す」徹底的にフラットで人間尊重のカルチャーをどこまでも貫く会社である。
2011/02/20
コメント(1)
-
ピアレビュー/Karl E.Wiegers （５）
ピアレビュー―高品質ソフトウェア開発のためにピアレビ...著者：カール・E．ウィーガーズ価格：3,045円（税込、送料込）楽天ブックスで詳細を見る付録 □ ソフトウェアCMMの構造 １ 初期 （なし） ２ 反復できる ・要求管理 ・ソフトウェアプロジェクト計画 ・ソフトウェアプロジェクト進捗管理 ・ソフトウェア外注管理 ・ソフトウェア品質保証 ・ソフトウェア構成管理 ３ 定義された ・ピアレビュー ・グループ間調整 ・ソフトウェアプロダクトエンジニアリング ・ソフトウェア統合管理 ・トレーニングプログラム ・組織プロセス重視 ・組織プロセス定義 ４ 管理された ・ソフトウェア品質管理 ・定量的プロセス管理 ５ 最適化する ・欠陥予防 ・プロセス変更管理 ・技術変更管理 □ システムエンジニアリングCMM ・解決法の候補を分析する ・要求事項を派生・配分する ・システムアーキテクチャを案出する ・領域を適合する ・システムを統合する ・顧客ニーズと期待を理解する ・システムを検証および妥当性を確認する ・品質を確保する ・構成管理する ・プロジェクト・リスクを管理する ・技術開発を監視・管理する ・技術開発計画を作成する ・組織におけるシステムエンジニアリングプロセスを定義する ・組織におけるシステムエンジニアリングプロセスを改善する ・生産物ラインの進化を管理する ・システムエンジニアリング支援環境を管理する ・最新のスキル・知識を提供する ・供給者と調整する □ CMMI-SE/SW １ 初期 （なし） ２ 管理された ・要求管理 ・プロジェクト計画策定 ・プロジェクトの監視と制御 ・供給者合意管理 ・測定と分析 ・プロセスと成果物の品質保証 ・構成管理 ３ 定義された ・決定分析と解決 ・リスク管理 ・統合プロジェクト管理 ・組織トレーニング ・組織プロセス定義 ・組織プロセス重視 ・妥当性確認 ・検証 ・成果物統合 ・技術解決 ・要求開発 ４ 定量的に管理された ・組織プロセス実績 ・定量的プロジェクト管理 ５ 最適化する ・組織改革と展開 ・原因分析と解決
2011/02/19
コメント(0)
-
ピアレビュー/Karl E.Wiegers （４）
ピアレビュー―高品質ソフトウェア開発のためにピアレビ...著者：カール・E．ウィーガーズ価格：3,045円（税込、送料込）楽天ブックスで詳細を見る第９章 インスペクションデータを分析する □ 測定アクティビティ １）生データの項目を集める ２）メトリクスを計算する ３）平均値をとる ４）傾向を見る ５）相関を見る ６）欠陥要因分析を見る ７）統計的プロセス管理を行う □ 手戻りコストを減らす １）各プロジェクトにおいて開発工数の何％が手戻りに費やされているか ２）インスペクションで費やされた工数はどれくらいか。インスペクションによって節約された工数はどれくらいか ３）インスペクションで発見された欠陥はいくつか。それらの種類は何か。それらの重大性はどれくらいか。ライフサイクルのどのフェーズか。 ４）作業成果物の欠陥のうち何％をインスペクションで除去できるか ５）インスペクションを実施した作業成果物は、実施しなかった作業成果物に比べて、テスト、デバッグ、保守に費やした時間は少なくなっているか。 □ 基本的なインスペクションデータ項目の例 １）サイズ ・予定サイズ ・実績サイズ ２）時間 ・ミーティング時間 ３）工数 ・計画工数 ・概要説明工数 ・準備工数 ・ミーティング工数 ・修正工数 ４）欠陥 ・大きい欠陥発見数 ・小さな欠陥発見数 ・大きい欠陥修正数 ・小さい欠陥修正数 ５）その他 ・インスペクタ人数 ・成果物評価 ・欠陥密度：総欠陥発見数/実績サイズ ・総欠陥修正数：大きい欠陥修正数/小さい欠陥修正数 ・インスペクション数：計画工数＋概要説明工数＋準備工数＋ミーティング工数＋修正工数 ・欠陥当たり工数：（計画工数＋概要説明工数＋準備工数＋ミーティング工数）/総欠陥発見数 ・単位サイズ当たり工数：インスペクション工数/実績サイズ ・インスペクション実施比率：１００×実績サイズ/予定サイズ ・大きい欠陥の比率：１００×大きい欠陥発見数/総欠陥発見数 ・インスペクション速度：実績サイズ/ミーティング時間 ・準備速度：予定サイズ/（準備工数/インスペクタ人数） ・欠陥当たり修正工数：修正工数/総欠陥修正数 □ 散布図を使ってメトリクス間の相関を見ることができます。 □ インスペクションの有効性はタイムラグのある指標です。インスペクションで見つかった欠陥と、開発の後工程またはテストで発見された欠陥、および顧客により発見された欠陥を数える必要があります。 □ インスペクションの効率が上がれば上がるほど、工数１時間当たりに発見する欠陥の数は増えます。欠陥一つを見つける平均コストを下げるようにして下さい。 □ 費用対効果は正味節約コスト÷検出コスト □ 一般的な知見ではインスペクションで見つからなかった大きい欠陥を後工程で修正するのに必要なコストは平均９～１０時間です。 □ ROIが１．０をわずかに上回りさえすれば、インスペクションは実施する価値があるといえるでしょう。第１０章 ピアレビュープログラムを導入する □ プアレビュープロセスオーナーの責任 １）さまざまの種類のピアレビューについて、また所属する組織のレビュープロセス詳細について専門知識を維持する。 ２）レビュー方針を確立し周知徹底する。 ３）ピアレビュープログラムを確立し、ビジョン、スコープ、戦略を定義する。 ４）ピアレビュー作業班を招集し、そのアクティビティを調整する。 ５）レビュープロセスの定義と導入のアクションプランの作成作業を指導する。 ６）必要に応じてレビューのトレーニングを手配する。 ７）レビュープログラムの初期採用者にどのような形で報酬を与えるかを決め、レビュー参加者の望ましい行動を奨励、強化する。他の管理者に、報酬を与えるべく推薦する。 ８）プロジェクトにおけるピアレビューの実施を監視し、その有効性を評価する。 ９）レビュープログラムの実装成功例を組織全体に宣伝する。 １０）必要なピアレビューデータ項目とメトリクスを定義し、これらのメトリクスの収集と活用に対する期待を設定する。 １１）メトリクスデータを使用し、レビュープロセスをはじめ、他のエンジニアリングプロセス及び品質プロセスで改善すべき事項を特定する。 １２）プロセス変更依頼をレビューし、承認された依頼内容を実装する。 １３）組織のプロセス資産ライブラリーに、ベースライン化されたピアレビュープロセス説明書、プロセス資産、トレーニング教材を確実に保持する。 １４）ピアレビュープロセスをサポートするツールの一覧表を保守する。 □ 避けられない学習曲線。新しいプラクティスを実装する際は、誰でもこれを登らないといけません。 □ レビューに力を尽くしても、チームが十分なリソースとトレーニングを手にしない限り成功しません。最も重要なのは割り当てられたスタッフの時間です。 □ 文書化されたプロセス説明書と作業支援文書（合わせてプロセス資産と呼ぶ）がない限り、チームメンバーが有効にレビューを実施することは期待しないでください。 □ ピアレビュープロセス １）プロセス概要 ・レビュー書式 誤字誤植一覧表 インスペクションサマリレポート 課題ログ 反省アンケート ２）レビュー手順 ・作業支援レポート インスペクションモデレータのチェックリスト 欠陥チェックリスト ルールセット ３）リスク評価の手引き ・測定 データ項目 計算によるメトリクス データ格納 データ報告第１１章 ピアレビューの効果を上げる □ 必須の成功要因 １）顧客でなく同僚に欠陥を見つけてもらう ２）マネジメントのコミットメントを勝ち取る ３）レビューアーとレビューのリーダーをトレーニングする ４）プロジェクト計画にレビューの時間を割り当てる ５）レビューの擁護者を特定する ６）早期に頻繁に、公式および非公式のレビューをする ７）初期のレビューを分析する □ インスペクションのベストプラクティスの例 １）プロジェクトとインスペクションの目標を達成するようにインスペクションを計画する。 ２）厳格で定量的な開始基準と終了基準を用いる。 ３）最初に上流工程の文書インスペクションを実施する。 ４）作成初期のうちに文書のインスペクションを開始する。 ５）ソース文書と関連文書に照らしてチェックする。 ６）組織の最適速度で準備およびインスペクションを実施する。 ７）大きい欠陥に焦点を当てる。 ８）インスペクションによる利益を測定する。 ９）欠陥予防とプロセス改善に注力する。第１２章 さまざまな状況でのピアレビュー □ 大きい作業成果物を部分的にサンプリングすると、全体の品質に対するヒントが得られます。 □ 生成コードと非手続き型言語のコード １）クエリーは正しいか。 ２）リレーショナル結合は効率が最大になるように定義されているか。 ３）テーブルインデックスは適切に使われているか。 ４）SQLクエリーの中でGROUP BY、UNION、DISTINCTなどが使われたときなど、検索するデータのグループ化、ソート、結合に対して正しいロジックが使われているか。
2011/02/19
コメント(0)
-
ピアレビュー/Karl E.Wiegers （３）
ピアレビュー―高品質ソフトウェア開発のためにピアレビ...著者：カール・E．ウィーガーズ価格：3,045円（税込、送料込）楽天ブックスで詳細を見る第７章 顔を突き合わせる □ モデレーターがインスペクションサマリーレポートに記録するデータ項目にはつぎのようなものがあります。 １）予定および実績のインスペクション対象物の量（ページ数またはコード行数） ２）インスペクションミーティング時間 ３）モデレーターと作成者がインスペクションパッケージの作成およびその他の計画アクティビティの実施に費やした合計工数 ４）概要説明を実施した場合の合計概要ミーティング工数（ミーティング時間×参加人数） ５）各インスペクターが準備に費やした時間とチーム合計準備工数 ６）実績修正工数（フォローアップ段階まで未定） □ モデレーターがミーティングの始めに各インスペクタに良い点を言ってもらうことで、建設的な雰囲気を作り出すことができます。 □ 次に初期成果物について全般的なコメントを出してもらってください。 □ ミーティングの最中は、既に挙がった課題に繰り返し言及したり、成果物全体に繰り返される欠陥を蒸し返すのは避けましょう。 □ 読み手はあまりに多くのものをまとめて単一の「かたまり」とすべきではありません。そうでないと、成果物のかなりのセッションがごまかされてしまいます。 □ 効果的な傾聴を促進するためのガイドライン １）気が散る物をミーティングから排除する。 ２）精神的かつ感情的に気を散らさない。これによりミーティングに集中でき、開けた建設的な態度が取れるようになる。 ３）リラックスする。これにより話を注意深く良く聞けるようになる。 ４）自分にとって気分を害する言葉は何かわきまえ、逆に他人を傷つけないよう、しゃべる前に考えて感情を制御する。 ５）明確にするために質問する ６）読み手が作業成果物のセクションについてキーポイントを説明し終わるまで、判断は差し控える。 ７）話題を変えたり自分自身の次の課題に移ったりせず、現在議論されている話題に集中する。 □ 作成者を責めるようなコメントは避けてください。 □ プロジェクト支援文書をインスペクションする場合であれば、情報の欠落、あいまいな書き方、仮定の誤り、非現実的なコミットメント、タスクの見落としなど重要な問題を探してください。 □ 課題ログを使用して各欠陥と課題を記録し分類します。 １）発生源は欠陥がライフサイクルアクティビティのどこで最初に作業成果物に作りこまれたかを示します。 要求、設計、実装、テストから選択するようになっています。 ２）種類は各事項がどんな種類の課題や欠陥であるかを示します。 ■欠陥に分類される項目 ・初期成果物からの欠落 ・ロジックの間違い、計算式の間違い、要求の不整合んどの誤り ・過剰（または不要）な要素 ・使用性や性能に悪影響を及ぼす因子 ■課題に分類される項目 ・疑問 ・基準違反（これは欠落）以外の様式に対する提案 ・明確化する必要のある場所 ３）重要度 ・１：アプリケーション全体が障害 ・２：大きい機能障害 ・３：小さい問題 ・４：操作には影響しない見栄えの問題 □ 問題行動を監視する １）ミーティングに遅れてきたり、途中で退席する人々 ２）主要な課題を記録し先に進めるよりも、論点を議論する参加者達 ３）作成者による保身、言い訳、必要以上の説明 ４）インスペクション対象物を不適切な大きさのかたまりで説明する読み手 ５）作成者または他の参加者に向けられた皮肉で挑発的で個人的なコメント ６）本筋の議論の障害となる脇の方の会話 ７）オブザーバからの気が散るコメント ８）時間を無駄にする過剰な悪乗り ９）長々と様式を議論すること １０）議論を支配し、他の人たちに貢献させない人々 １１）小さい、表面的な、見栄えの欠落と様式の課題しか見つけられないこと □ 人々はときに、無知を悟られまいとして、自分の意見を公に言いたがらないことがあります。 □ 成果物の評価 １）このまま合格 ２）検証で条件付き合格 ３）修正後再インスペクション ４）インスペクション未完了 □ インスペクション反省アンケート １）インスペクションは作成者とチームの目標を満たしましたか。満たせなかった場合、なぜでしょうか。 ２）チームはインスペクションにより作業成果物の品質を大いに改善できたと感じていますか。 ３）各自の準備のための時間はありましたか。なたった場合、インスペクションミーティングまでにどのくらい時間が必要でしょうか。 ４）準備の時、今回の種類の作業成果物のための欠陥チェックリストかルールセットを利用しましたか。それは欠陥を発見するために役立ちましたか。役立たなかった場合、なぜでしょうか。欠陥チェックリストないしルールセットに改善の余地はあるでしょうか。 ５）参加者は適正でしたか。そうでない場合、参加すべきだった人、逆に参加する必要のなかった人を挙げてください。 ６）インスペクション開始および終了基準は正しく運用されていましたか。 ７）ミーティングをより効果的に実施するにはどうすればよいでしょうか。 ８）インスペクションに有効に参加できるようにするために助力を必要としましたか ９）その他、インスペクションプロセスを改善するための提案はありましたら教えてください。第８章 終了する □ 改善を実装するかどうかは、作成者の判断によります。 □ どのようなプロセスのおいても、プロセスステップが正しく実施されたかどうかの検証は、実行の重要な一部になります。 □ フォローアップからの成果物は、ベースライン化された作業成果物で、オリジナルの成果物から相当に改善されており、次の開発作業の強固な基盤となります。 □ フォローアップの目的 １）インスペクションミーティングで挙がった課題を作成者がすべて適切に解決したかどうか、および欠陥が指摘された場合、そのうちどれを修正せずにおくか妥当な決定を行ったかどうか、という検証です。 ２）初期成果物の修正が２次欠陥を生じることなく正しく行われたかどうかを判断することです。 □ 原因分析の４つのプロセス １）発見した欠陥の原因を見極め、欠陥を修正する。 ２）欠陥が作りこまれる原因となった開発プロセスの側面を是正し、将来同じような誤りを犯す確立を少なくする。 ３）欠陥を見逃した品質プロセスを見直し、ライフサイクルの早い時期に欠陥を捕獲できるようにチームの能力を向上させる。対策としては、テスト方法の改善、インスペクションプロセスの改善、分析技法の改善などが考えられる。 ４）同じような欠陥が気づかれずに残っていないか、製品全体を調べる。 □ インスペクションの終了基準 １）作成者またはチームのインスペクション目標を達成した。 ２）課題はすべてクローズした。 ３）大きい欠陥はすべて修正した。 ４）修正を実施しなかった小さい欠陥はすべて、検証者の同意を得た上で、プロジェクトの欠陥追跡システムに記録した。 ５）前回完了したコンポーネントに変更を加えた場合、そのコンポーネントはすべての回帰テストに合格した。
2011/02/13
コメント(0)
-
ピアレビュー/Karl E.Wiegers （２）
ピアレビュー―高品質ソフトウェア開発のためにピアレビ...著者：カール・E．ウィーガーズ価格：3,045円（税込、送料込）楽天ブックスで詳細を見る第４章 インスペクションプロセス □ インスペクションによってチームは次のことを行えます。 １）プログラムが移植性、保守性、再利用性など、所期の属性を備えていことを検証する。 ２）ステークホルダーが作業成果物の技術的側面について確実に合意する。 ３）作業成果物の技術的側面についてのデータを収集する。 ４）チームメンバーの技術力を向上させる。 ５）作業成果物に残存する欠陥の数を推定する。 □ 読み手を置く理由は、こうすることで作成者以外の人が作業成果物の理解性をチェックできるからです。読み手が解釈を示すと、あいまいさ、隠れた仮定、不十分な文書化、コミュニケーションを妨げる様式の問題、明白なエラーなどがしばしば明らかになります。 □ インスペクションチームの大きさは小さめに、参加者を３～７人にすることをお勧めします。 □ 複数の小さいチームでインスペクションを並行して実施（N重インスペクション）する方が、一つの大きなチームでするよりコスト効率が良い。第５章 インスペクションを計画する □ 最良のモデレータには次のような共通の特徴があります。 １）計画も事後処理も両方得意である ２）ミーティングを円滑に進める技術に秀でている。期待通りに開始/終了し、積極的な雰囲気を作り直し、積極的な雰囲気を作り出し、ミーティング横道にそらさず進め、参加者全員の貢献を促進する。 ３）自分自身のコメントによってミーティングを支配しない。 ４）不適切な行いは遠慮せずに正す。 ５）他の参加者から、尊敬されており、参加者彼（彼女）がミーティングを管理するのを安じて受け入れる。 ６）中立であり、公正であり、断定的ではない。 ７）インスペクションに貢献できるに足る技術と領域に関する知識を有している。 □ インスペクションの開始基準 １）成果物のソース文書、仕様、選考作業成果物はそれ自体インスペクションに合格していてベースライン化されていること。 ２）テキスト文書はスペルチェック済みで校正済みであること ３）初期作業成果物は一意のバージョン識別子を持っているもと。 ４）モデレーターがざっと見た限りでは甚だしい品質問題やレイアウトの誤りがないこと ５）初期作業成果物は関連する標準、テンプレート、書式の要求に適合すること ６）未解決の問題については、ＴＢＤ（To Be Determinded：未解決）と記されていること ７）文書またはコードには行番号が印刷されていること第６章 作業成果物を調べる □ プロジェクト計画のインスペクションの欠陥チェックリスト １）明確さ ・プロジェクト計画の構成は適切か。詳細さのレベルは適切か。 ・各計画要素の意味は明確で曖昧ではないか。 ・計画要素の関係は明確か。 ・計画の構成は論理的かつ明確か。規定のテンプレートと整合性がとれているか。 ２）完全性 ・見積値は計算方法とともにすべて文書化されているか。 ・プロジェクト計画は関係企画、手順、テンプレートが要求する項目をすべて含んでいるか。 ・計画要素から関係のある詳細設計が欠落していないか ・計画要素に関係のない詳細情報が付加されていないか ・不必要な計画要素はないか。 ・計画に冗長な情報はないか。 ・関連または参考文献はすべてを記載しているか ３）整合性 ・計画の中で計画要素は互いに整合性がるか ・計画の内容はすべての関連文書の内容と整合性があるか ・プロジェクトの内容はプロジェクトのスコープおよび目標と整合性があるか ・文書における詳細さのレベル、語彙、シンクタンクは、想定される読者および利用方法と整合性があるか ４）正確性 ・ＷＢＳから欠落しているタスクはないか。 ・見積書がすべて現実的で達成可能か ・プロジェクト計画に織り込んだ仮定はすべて記載され、正確か □ 要求仕様書の技法 １）特定されたすべてのユーザー層から要求を受け取ったかどうかを確認する。 ２）同種の製品および競合製品を調べ、追跡すべき機能はないかチェックする。 ３）品質属性、性能目標、制約条件、外部インターフェース要求などの非機能要求が仕様化されているかチェックする。 ４）仕様が関連するすべての業務ルールに適合していることを確認する。 ５）構造化したテキストや図形による分析モデルなど、複数の方法で要求情報を表現する。分析と設計モデルの表記方法は、DFD、ER図、状態遷移図、クラス図、その他UMLで定義されるオブジェクト指向モデルなどがある。 ６）すべてのデータ項目について、ソース（発生源）と利用先を記述する。 □ 多くの製品で重要な品質属性には次のようなものがあります １）保守性（maintainability）：別のプログラマにとってコードがどれほど理解しやすく変更しやすいか、よく構造化され、十分コメントがついているか。 ２）堅牢性（robustness）：予想外の稼働条件の下で製品がどう応答するのか。不正な入力がない場合に備えて、デフォルトが指定されているか。 ３）信頼性（reliability）：フォールトトレラント（耐障害性）か。効果的な例外処理とエラー回復の仕組みを有しているか。 ４）効率性（efficiency）：プログラムがメモリ容量またはプロセッサをどのくらい使うか。アルゴリズムは最適化され、不必要な演算は回避されている。 ５）再利用性（reusability）：コンポーネントは他のアプリケーションに再利用できるか。プログラムは分解され、モジュール化された設計で凝集度は強く、結合度は緩くなっているか。 ６）完全性（integrity）：ソフトウェアやデータが許可されていないアクセス、情報損失、変更、ウイルス感染から守られているか。 ７）拡張性（scalability）：システムはより多くのユーザー、サーバー、データ、その他のコンポーネントに、許容できる性能とコストで適応できるか。
2011/02/12
コメント(0)
-
ピアレビュー/Karl E.Wiegers （１）
ピアレビュー―高品質ソフトウェア開発のためにピアレビ...著者：カール・E．ウィーガーズ価格：3,045円（税込、送料込）楽天ブックスで詳細を見る第１章 品質の課題に挑む □ 品質はタダではない 品質コストとは、次の各項目にかかった時間とお金です。 １）外部製品不良 ２）内部製品不良 ３）品質評価 ４）欠陥予防 □ 欠陥は、実装完了後や製品出荷後に除去されるよりは、予防する方がずっと安くすむのです。 □ ピアレビューの費用対効果は、バグがどれだけ見つかったかではなく、プロジェクトチームの作業時間がどれだけ節約できたかで判断すべきです。 □ 要求はプロジェクトで行われるほかの全作業の基礎になるものですから、すべての要求文書に対して公式なインスペクションを実施することが、おそらくもっとも重要なソフトウェア品質プラクティスとなるでしょう。第２章 友だちのささやかな助け □ レビューアーたちが共有されたプロジェクトビジョンを確認できるように、各プロジェクトのビジネスゴールを定義し伝達すること。 □ 達成可能な品質目標が設定できるように、製品品質に対する顧客の期待を定義すること。 □ ピアレビューおよびその他の品質プラクティスが、チームの品質目標達成にどのように貢献するのかを理解すること。 □ ピアレビューとは何か、なぜやる価値があるのか、誰が参加すべきか、どう実施するかについて、開発組織内のステークホルダーに教育すること。 □ 組織のレビュープロセスの定義と管理、参加者のトレーニング、レビューの実施、レビューデータの収集と評価などのスタッフ業務に必要な時間を確保すること。 □ ピアレビューへのマネジメントのコミットメントを示す11の行動 １）効果的なレビュープロセスの開発、実施、維持のためにリソースと時間を提供すること。 ２）レビュープラクティスについての方針、期待、目標を設定すること ３）プロジェクトが時間的プレッシャーの下にある場合でも、レビューのプラクティスを堅持すること。 ４）プロジェクトスケジュールに、確実にレビュー時間を含めること ５）関係者がトレーニングに参加できるようにすること、および自身もトレーニングに参加すること ６）レビュー結果を決して個人の業績の評価に使わないこと ７）レビューに参加することおおびそれらを建設的に貢献することについて、人々に責任を持たせること ８）望ましい行動を強化するため、レビューの初期採用者に公的に褒美をあたえること ９）レビューの必要性に異議を唱えるほかの管理者と顧客を阻止すること １０）ドキュメントの品質に対するレビューチームの評価を尊重すること １１）レビュープログラムがうまくいっているか、コストはどのくらいか、そしてチームがレビューから享受している利益について、状況報告を要求すること □ ピアレビュー洗練度の尺度 ０：レビューが実施されていない １：アドホックなレビューが実施されている ２：非公式なレビューが実施されている ３：インスペクションが計画されている ピアレビュープロセスが採用されている ４：インスペクションプログラムが定義され、かつ管理されている インスペクターはトレーニングを受けている プロジェクトの成功はにはインスペクションが必須と認識されている プロセス改善の目的でインスペクションのデータが分析されている □ レビューの原則 １）始める前に自身のエゴをチェックせよ ２）レビューチームは小さくせよ ３）レビューでは問題の発見に努め、会計つを試みるな ４）レビューミーティングは約2時間に限定せよ ５）事前準備を要求する第３章 公式なピアレビュー、非公式なピアレビュー □ ピアレビューの公式度の分布 １）インスペクション ２）チームレビュー ３）ウオークスルー ４）ペア・プログラミング ５）ピアデスクチェック、パスアラウンド ６）アドホックレビュー □ インスペクションの特徴 １）定義された目標 ２）トレーニングを受けたチームの参加 ３）トレーニングを受けたモデレーターのリーダーシップ ４）特定の役割と責任 ５）文書化されたレビュー手順 ６）マネジメントへの結果報告 ７）明確な開始および終了基準 ８）完了（クローズ）までの欠陥追跡 ９）プロセス品質と品質データの記録 □ インスペクションのプロセス １）計画 ２）概要説明 ３）準備 ４）ミーティング ５）修正 ６）フォローアップ ７）原因分析 □ チームレビュー チームレビューは、適格と認められた人々が製品は使用に適しているかを判断し、製品がどの点で仕様を満足していないかを識別します。 □ ウオークスルー ウオークスルーは非公式レビューです。 作成者が作業成果物をグループの同僚たちに説明し、コメントを求めます。 □ ペアプログラミング 二人の開発者が1台のパソコンを共有し、一つのプログラムを一緒に作成します。 □ ピアデスクチェック ソースリストを丹念に調べる。 □ パスアラウンド 多重かつ同時進行のピアデスクチェックです。 □ 与えられた条件の下で最適なレビュー方法を選択する方法の一つは、リスクを考慮することです。
2011/02/10
コメント(0)
-
新・青年社長/高杉良
新・青年社長 上新・青年社長...著者：高杉良楽天ブックスで詳細を見る新・青年社長...著者：高杉良価格：1,785円（税込、送料込）楽天ブックスで詳細を見る□ 話しながら、この交渉は不調に終わるだろうが、プライドは保つことはできた。□ 東京ディズニーランドのキャストがあれほどフレンドリーになれるのは、あの設備とプライドにあると思う。□ 外食産業で生き残るためには、手作りで、そこでしか食べられない商品を、低価格で提供しなければならない。□ 謙虚にひたすら努力を続けることの大切さを心で学ぶ。□ どこかひとつ我慢をすることが、我慢していることが次のステップを生むと感覚的に入院時に感ずる。□ コミュニケーションをしっかりととること、「大いに発言し」「他人の意見を聞く」こと□ てんかんは薬で管理できる。怖い病気ではない。当人にとって宿命であるのだから、克服しなければならない。生徒の将来を考えたら、追い返してしまうことは挫折を与え、自分はみんなと同じには生きていけないのだと思い込んでしまいかねません。□ 開発とは開発者自身の心が豊かでないと真の豊かさは得られないということです。
2011/02/05
コメント(0)
全9件 (9件中 1-9件目)
1
