ドメイン駆動設計に出てくる概念モデルと分析モデルの違い - プログラマの思索
ドメイン駆動設計に出てくる概念モデルと分析モデルの違いについて、良い記事があったのでメモ。 【元ネタ】 ドメイン・フレームワークのススメ(第1回) ドメイン・フレームワークのススメ(第2回) 【1】概念モデル、分析モデル、設計モデルを以下で定義している。 これは分かりやすい。 (引用開始) 概念モデル：問題領域に対する「理解のしやすさ」を重視したモデル。 実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。 分析モデル：概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。 設計モデル：分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。 (引用終了) ドメイン・フレームワークのススメ(第1回)では、G
Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索
Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。 以下、ラフなメモ書き。 【参考】 Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索 ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索 チケット管理システムは作業の構成管理と同じ: プログラマの思索 【1】以前、下記のツイートがあった。 最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。 【1-1】 akipiiさんのツイート: "ガントチャートは
Redmineの最新機能でサポートデスク管理をより効率よく使う運用方法のアイデア - プログラマの思索
前回のRedmine大阪で、前田剛さん、須藤さんの話を聞きながら、Redmineの最新機能でサポートデスクをより効率よく使う運用方法について、考えたことをメモ。 ラフなメモ書き。 【参考】 第17回Redmine大阪の感想 #redmineosaka: プログラマの思索 Redmine大阪 第17回勉強会 - 全文検索でRedmineをさらに活用！ #RedmineOsaka - ククログ(2017-08-27) 【１】サポートデスクやITILによるソフトウェア保守の運用作業で、従来のExcelでやっていた頃はいろんな問題が噴出していた。 その内容は、4年前の下記のスライドで既に述べた。 「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」 その問題点は下記に集約されるだろう。 【１－１】突発的な問合せ、障害が発生すると、作業が混乱する 【１－２】問合せから、暫定対応や根
WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる - プログラマの思索
WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。 【参考】 ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から ＷＢＳはコスト見積の基準を規定する : タイム・コンサルタントの日誌から 【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか？それとも機能単位に作った方がいいですか？」だ。 話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。 WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか？ (引用開始) さて、３つの機能モジュール×３段階の作業プロセスだから、合計９個のアクティビティからなるプロジェクトである。 これをＷＢＳに構成するとき、二種類の表現が考えられる（ＩＴ系の仕事になじみのない人は、「シス
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
Sonarでソースの品質をチェックする - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
オフショアプロジェクトマネジメント - プログラマの思索
「標準テキスト オフショアプロジェクトマネジメント 【PM編】」を読んだ。 こまごまとした文章よりも、コラムや経験に基づく具体例の方が面白い。 オフショア開発に携わった経験がある人ならば、うんうんあるよ、と頷く箇所が多いのではないだろうか？ 一部のコラムを抜き出して、感想をラフなメモ書き。 【1】自社のオフショア子会社よりも外部の協力会社の方が安いとしたら、どちらを選択するか あなたはオフショアPMOで海外発注数量の数値目標を持つ責任者とする。 ある日、顔なじみの協力会社の営業マンがやってきて、自社の３年前に設立したオフショア会社よりもはるかに安い人月単価を提案してきた。 そもそも、あなたの会社のオフショア社内単価は随分高めに設定されている。 あなたは、勝手を知る協力会社の提案を受け入れるか？ それとも、オフショア発注数量を数値目標を達成するために、赤字覚悟で自社のオフショア会社を社内プロ
TestLinkに似た機能を持つRedmineプラグインImpasse - プログラマの思索
TestLinkに似た機能を持つRedmineプラグインImpasseが公開されていたのでメモ。 まだインストールしていないが、とても気になる。 【元ネタ】 Twitter / kawasima: Redmineで出来るソフトウェアテストマネジメント。もうすぐ他のプロジェクトで使い始めるので、v1.0.0のリリースしました。Redmine2.xには今のところ非対応です。 https://github.com/kawasima/redmi … redmine_impasse/README.ja.rdoc at master ・ kawasima/redmine_impasse (引用開始) インパスはRedmineのプラグインとして動作するテストマネジメントツールです。 テストケースの管理 テスト計画の管理 テスターのアサイン テスト予定日の登録 テストの実行管理 バグ票の起票 テスト進捗・
分散バージョン管理の可能性 - プログラマの思索
InfoQに分散バージョン管理の可能性の記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 InfoQ: エンタープライズ分野での分散バージョン管理システム (引用開始) DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30
チケットファーストからビルドファースト、Gitoriousへ - プログラマの思索
Gitoriousやゼロ機能リリース(Zero Feature Release)に関するラフなメモ書き。 【元ネタ1】 Gitを使った開発・運用フローの紹介 | FIRN.JP Gitという優れた分散バージョン管理をソフトウェア開発の中心の配置して、チケットやビルド管理ツールを連携する方法が書かれている。 GitoriousとRedmineを使った開発 - ひかえめプロジェクト (引用開始) ポイントは，フィーチャーブランチ，リリースブランチ，ホットフィックスブランチをそれぞれRedmineのチケットに対応付ける点です． これらのブランチの名前をすべて id/xx （xxはチケットナンバー）にすることで，自動的にブランチ上のコミットがRedmineのチケットに対応付けられます． (引用終了) ブランチはRedmineプロジェクトだけでなく、チケット単位に作ってもいい。 分散バージョン管理を
プログラマの思索
astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
