アーキテクチャ設計のプロセスを改善するために参照した論文・資料・記事 - Qiita
はじめに 組込みソフトウェア開発において、アーキテクチャ設計のプロセスを改善をするために（アーキテクチャの評価方法の考案などをするために）、参照した論文や資料や記事をまめておきます。 以下で分類して、論文や資料や記事を整理します。 設計者 設計原則 設計事例 設計プロセス 設計評価 設計改善（リファクタリング） 1. 設計者 山田大介，「連載コラム アーキテクトへの道」 「ソフトウェアアーキテクトが知るべき97のこと」 2. 設計原則 @hirokidaichi，「技術選定/アーキテクチャ設計で後悔しないためのガイドライン」 @hirokidaichi，「なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか」 「The #1 bug predictor is not technical, it's organizational complexity」，2019 @MinoDriv
マネージャー・リーダーの私にとって有益な知見が得られた書籍 - Qiita
はじめに マネージャー・リーダーの私にとって有益な知見が得られた書籍を、簡単な所感とともに、まとめておきます。 随時、更新していく予定です。 ここに示した書籍は、マネージャー・リーダーの経験を得た後に、自分の経験を頭に置きながら、読んでみたほうがよいと思います。 経験がない状態で、ここに示した書籍を読んでも、得られる気づきなどは少ないと思います。 書籍は、「以下の順で読むとよいかもしれない」という順に並べてみます。 また、おまけとして、以下の情報もまとめてみました。 マネージャーとして意識的に実行していること マネージャーの立場で工夫してみたこと 書籍ではなくメンバから学んだこと 書籍一覧 「先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明」，金子 龍三 金子龍三さんの講演は楽しい、刺激がある。経営者やPMは、是非一度話を聞いてみるみよい。トラブル
ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果 - Qiita
ワークショップ「ソフトウェア開発におけるHAZOP入門」を3回開催した。 その結果（参加者の所感）を記録する。 開催シンポジウム ソフトウェアテストシンポジウム（JaSST ： Japan Symposium on Software Testing）でワークショップを開催させていただいた。 http://www.jasst.jp/ JaSST'18 Tokai（参加者：13名） JaSST'19 Tokai（参加者：8名） JaSST'19 Shikoku（参加者：19名） 参考文献 [1]小川清, 「一人HAZOPを組み合わせた効率的な分析作業」, WOCS2011, JAXA/IPA, 2011 [2]日高隆博, 山崎二三雄, 中本幸一, 本田晋也, 高田広章, 「HAZOP分析によるソフトウェア異常動作検出条件の導出手法の提案と実装」, 組込みシステム(EMB) Vol.2009-E
「規模あたりのテストケース数はもはや意味をなさない」という問いに対する考え - Qiita
背景 にしさんの以下のツイートをきっかけに、「規模あたりのテストケース数」というメトリクスについて考えてみた。 https://mobile.twitter.com/YasuharuNishi/status/1203344174864453634 規模あたりのテストケース数はもはや意味をなさないという意見に賛成する人は、その理由を最低2つと、じゃあ何をするかを答えられるようにしておくこと。ここ試験に出すからな。 — Yasuharu NISHI (@YasuharuNishi) December 7, 2019 (注意) 規模はソースコードの規模であることを前提とする。 "もはや"ではなく、"以前から"意味をなさない理由とした。 問いに対する考え 「規模あたりのテストケース数」が意味をなさない理由 その1：有効なアクションを起こしにくい 前提：しっかりテスト設計をしている テスト観点ツリー
ソフトウェアテストに関して、個人的に有益な論文・資料 - Qiita
個人的にソフトウェアテストに関して有益（後から見返したい）と思った論文・資料を列挙しておく。 随時、追加・更新していく。 [1]秋山浩一,「テスト技法の位置づけとテストの十分性」，JaSST'09 Tokai，2009 http://jasst.jp/archives/jasst09n/pdf/S2.pdf この講演で初めて「品質コスト分析」を知った。テスト技法の全体象を教えていただいた。 [2]鈴木誠,「品質判定マップによる人員配置とテストマネジメント」，JaSST'09 Tokai，2009 http://jasst.jp/archives/jasst09n/pdf/S3-2.pdf 「品質判定マップ」という仕組みは、すごく面白い。活用できそうと感じた。その後、活用する場面に出くわしてはいない。 [3]松尾谷徹,「テストから観た実体のモデリングと実装構造の評価～ 検証指向設計の実現に向
プロセス改善に関して、個人的に有益な情報 - Qiita
個人的にプロセス改善に関して有益（後から見返したい）と思った論文・資料等を列挙しておく。 随時、追加・更新していく。 論文・資料 清水吉男，「硬派のホームページ」 清水吉男，「Index of "Software Process について"」，2006 https://affordd.jp/koha_hp/process/Proc.Index.html 清水さんがSoftware ProcessとCMMについて語られている。 清水吉男，「これまでの「標準化」の間違い」，2003 https://affordd.jp/koha_hp/process/Proc.WhyStd.html 「プロセスを設計する能力」の必要性について述べられている。 清水吉男，「ＰＦＤ（Process Flow Diagram）の書き方」，2009 https://affordd.jp/koha_hp/process
見積りに関する情報と知見 - Qiita
見積りツールが以下のサイトにある。 http://itref.fc2web.com/management/cocomo.html CoBRA見積りモデル[5] 独フラウンホーファー財団実験的ソフトウェア工学研究所協会（IESE）から発表された。 考え方 規模がほぼ同じでも、かかる工数に違いがある。 見積り式 実績データに照らして、変動要因とその定量化を検証し、αを計算。 コスト変動要因のオーバーヘッドを考慮。経験豊富なPL等の熟練者の知見を基に、変動要因とその影響を定量化。 見積り手順 規模の推定 変動要因の影響度の評価 見積りの実行 CoBRAモデルの構築手順 変動要因の抽出・定義 実績データの収集 モデルの構築・改善 規模の計測補法 ファンクションポイント[6] 概要と特徴 ファンクションポイントは、ソフトウェアの機能の大きさを表す指標で、誰が計測しても同じ値になるという特徴があります
新人の方によく展開している有益な情報 - Qiita
新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム，「派生開発におけるスペックアウト手法の提案」，派生開発カンファレンス2015，2015 http
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
