開発プロセスは終わらない - rabbit2goのブログ
ソフトウェア開発のプロジェクト開始時には「キックオフ」、完了時には「ふり返り」などと称して、プロジェクトとしてのけじめを付けたりすることが有る。開発契約などの実務上の作業は別として、プロジェクトの現場としては一区切りを付ける意味で必要だし悪くないと思う でも、継続的にソフトウェア開発に関わる立場として言えば、プロジェクト毎に開発対象は異なるにせよ「開発プロセスは終わらない」のが実状だろう。一つの開発作業が終わったら、プラス面として開発メンバーのスキル向上や技術的蓄積の増加などが上げられるし、マイナス面としては積み残し課題や技術的負債が上げられるはずだ。だから、次に行う開発プロジェクトではこの様々な蓄積と負債を共に抱えつつ作業することになり、前回の開発では実施出来なかった上手い対応が出来るはずだし、不可欠のはずだ。 言ってみれば、保守開発とか派生開発で得られた知見は次の開発へフィードバックさ
インフルエンザ診断ゲームで学ぶ検査閾値と治療閾値 - NATROMのブログ
簡易検査はするべきではない？ 北秋田市の病院でインフルエンザの集団感染があった。簡易検査では陰性だったが死亡した患者もいたと報道された*1。インフルエンザ迅速診断キットの感度は高くない、つまり、インフルエンザに感染していても検査結果で陰性と出やすいことはよく知られている。あらゆる検査と同様に、インフルエンザの簡易検査は感度・特異度を理解の上に使うべきである*2。当たり前の話。しかし、まれに、インフルエンザの患者に対して、簡易検査をするべきではない、簡易検査をする意味は何もないと誤解している人もいる。 ■Open ブログ: ◆ 簡易検査による死者増加*3 要するに、簡易検査をする意味は、何もない。 ・ 検査で陽性ならば → 抗インフルエンザ薬の投与 ・ 検査で陰性ならば → 抗インフルエンザ薬の投与 （様子見、は間違い。） つまり、どっちみち、「抗インフルエンザ薬の投与」である。投与するか否
asahi.com（朝日新聞社）：かかと踏みにくい上履きヒット 樹脂の出っ張りつけ開発 - ビジネス・経済
突起があり、かかとが踏みにくい上履き＝福岡県久留米市のムーンスター本社突起の付いた上履き（左）と体育館シューズ（右）＝福岡県久留米市のムーンスター本社 かかとを踏みにくい学校用の靴がヒットしている。「いくら注意しても、かかとを踏むのをやめない」という先生たちの悩みを受け、靴メーカーのムーンスター（福岡県久留米市）が開発。樹脂の出っ張りをつけ、かかとを踏んだままだと違和感があるようにした。 かかとを踏んで靴を履くと十分な機能を発揮できないため、ムーンスターは「メーカーとしても正しく履いてほしい」と開発に取り組んだ。 かかと部分全体を硬くする案もあったが、柔軟性がなくなって歩きにくいため出っ張りを付けることに。とがりすぎず、丸すぎず、５分程度踏み続けると痛くなる形と硬さにした。 ２００４年に体育館用を発売した後、学校側の求めで上履きを売り出すなど今では４種類に増えた。一般の店での販売は
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
頻繁なVerUpがソフトウェア開発の本質 - プログラマの思索
WF型開発とAgile開発の本質的な違いはどこにあるのか？ プロセスや技術の観点から見れば、WF型開発は本番リリースが1回しかないのに対し、Agile開発は定期的なリリースを基本とする特徴がある。 その観点をもう少し深めて考えてみた。 ラフなメモ書き。 【1】WF型開発は、シーケンシャルに工程単位に開発を行い、フィードバックプロセスをできるだけ排除するプロセス。 半年～1年に1回だけ本番リリースするのが普通だろう。 特に日本のSIは製造業から派生した会社が多いから、ソフトウェア工場の発想に影響を受けている。 つまり、前工程の品質をできるだけ確保するために、レビューやテストを事前にしっかり行い、仕様漏れや検証漏れを前工程で十分に行って、後工程のフィードバックや突然割り込んだ変更要求をできるだけ排除するやり方。 たいていは、スコープは長期間固定化するのが普通で、最後の1回の本番リリースを成功さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルのまずい考え方