タグ

ソフトウェア開発に関するfumokmmのブックマーク (12)

  • コード・シンプリシティ

    Bugzillaプロジェクトの主任設計者の実体験に基づいた、ソフトウェアの簡潔性を保つさまざまな知見をまとめた書籍。「なぜ簡潔性が大事なのか」「変更の価値を計るための方程式」「コードの簡潔性と複雑性」といったトピックについて、事実、法則、ルール、定義などを示しながら解説します。直接的なコードの書き方だけでなく、ソフトウェアプロダクト全体にわたるコードの健全性を保つためのヒントとなるでしょう。なお書はEbookのみの販売となります。 まえがき 1章 はじめに なぜ簡潔性が大事なのか ソフトウェアデザイン 2章 なぜソフトウェアを作るのか 実際のアプリケーション 3章 未来 ソフトウェアデザインの方程式 デザインの品質 見えない結末 4章 変更 プログラム変更の実例からわかること 3つの間違い インクリメンタルな開発とデザイン 5章 不具合とデザイン 故障でなければ…… 何度も同じことを繰り

    コード・シンプリシティ
  • 作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!

    ソフトウェア開発の世界には、様々な法則があります。 遅れたプロジェクトに人数を追加しても、さらに遅らせることになるという「ブルックスの法則」は有名ですね。他にも、ソフトウェアの構造は、それを作った組織の構造が反映させるという「コンウェイの法則」などなど。(参考) 最近、ソフトウェア開発を通じて感じていることは、ソフトウェアの仕様を決める人の数は、ソフトウェアをプログラミングする人の数と同じだけ必要なのではないか、ということです。 そこで、この記事ではこれを「人数等価の法則」として考えてみることにしました。 balance / hans s これまで考えられてきた開発にかかる人数の感覚 ソフトウェア開発には、何を作るかを考えるという段階があって、どう作るかを考えてプログラミングするという段階があります。それを2人以上の人間で役割分担するとしたら、その間に入るものが「仕様」となります。 「仕様

    作る人と決める人は同じ数だけ必要な時代になった〜ソフトウェア開発における「人数等価の法則」 | Social Change!
    fumokmm
    fumokmm 2012/08/05
    仕様を決めて、設計して、実装して、テストまで同じ人がやったらいいよね。
  • エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type

    エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『@type』のコンテンツです。

    エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職@type
  • アジャイルソフトウェア開発宣言

    私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

  • Fine Software Writings

    最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か? (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか? (Nick Bostrom) 厄介な問題を解決したい? ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W

  • 工数見積もりで陥りやすい罠 - プログラマの思索

    「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記:一部修正した。 ※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索 ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索 チームは加速するのか~Velocityの使い

    工数見積もりで陥りやすい罠 - プログラマの思索
    fumokmm
    fumokmm 2011/09/28
    あとでチェック。
  • スクラム (ソフトウェア開発) - Wikipedia

    複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくア

  • IPA 独立行政法人 情報処理推進機構:超上流から攻めるIT化の事例集:INDEX

    SEC BOOKS「経営者が参画する要求品質の確保」では、情報化の現場で起こっている問題を取り上げ、それらの解決のヒントとして超上流工程における経営層のシステム開発への参画による要求品質の確保の重要性を説明しました。 ここでは、情報化に関わるユーザ企業・ベンダ企業が、心掛けるべき原理原則や取り組む上での行動規範を示しています。 また、心構えだけでは、「実際には何を行ない、どんなものを作ればよいのか」という問いに、実際の開発現場で行なっている情報化の進め方や、実際に使用している成果物を提供することにしました。 ユーザ企業とベンダ企業の間での情報化での作業や役割分担、成果物について、具体的なイメージをつかめればと思います。 ご利用条件について 当コーナーで紹介しているファイルをダウンロードすると下記の利用条件に同意したものとみなします。 利用条件は、IPAの「ご利用条件」に追加するものです。

    fumokmm
    fumokmm 2011/05/02
    上流工程で使う資料など。
  • アジャイルなソフトウェア開発とは | オブジェクトの広場

    同僚の協力もあり 2002 年にアジャイルモデリング ( AM ) 日語リソースサイト [1] を開設し, 2003 年に AM [2] を刊行して以降, 筆者にとって「 AM の適用事例を作る 」ことが大きな課題として残されていました. 幸いにも, 2003 年から社内開発でアジャイルなソフトウェア開発を適用する機会を得るとともに, 2004 年にはお客様からアジャイルなソフトウェア開発のプロジェクトのお手伝いを依頼されたり, 社内開発で AM を実践する機会を得ることができました. 読者の皆さんが AM を学ぶ際の参考となることを目指して, 今回から数回の連載で AM を実践するために筆者が勉強したり, 考えたり, 実践したことを紹介させて頂こうと考えています. とりあえず, 今回は AM の土台となるアジャイルなソフトウェア開発について説明します. 1. アジャイルなソフトウェ

    アジャイルなソフトウェア開発とは | オブジェクトの広場
  • オープンソースソフトウェアの育て方

    製作著作 © 2005-2013 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

    fumokmm
    fumokmm 2009/07/27
    なんだかしっかりまとまってそうなので、あとで読みたい
  • Musee d'Dimanche

    xdocdiff TortoiseSVNでWord、ExcelPowerPointpdfのdiffを見るツール xdocdiff WinMerge Plugin WinMergeでWord、ExcelPowerPointpdfなどを比較し、差分をを見られるようにするツール PopRss メーラーでRSSを読むためのツール DesktopHE Windowsデスクトップ検索ツール hyperqm QMAIL3をちょっぴりGmail風にするツール HtmlHE WindowsHTMLファイル検索&閲覧ツール MailScouter for 秀丸メール 秀丸メールのデータを検索するツール VisualStudio コメントマクロ 名前のまんま 日記 闘うプログラマーの、闘う日記 tDiaryにしてみました。ツッコミ上等! ゲストブック 気軽に書き込んでください。質問などは、過去ログ

  • The Seasar Foundation Project Site

    利用者向け情報 ニュース & Wiki プロダクト一覧 メーリングリスト Eclipseプラグイン Mavenリポジトリ ライセンス 各種リソース イベントサイト ファウンデーションサイト 開発者向け情報 SeasarWiki ソースコードリポジトリ 課題追跡 継続的ビルド 開発者ログイン サーバチームサイト Java プロジェクト S2Container.Java Seasar2 (S2Container) Presentation.Java Cubby Mayaa mobylet S2BlazeDS S2Flex S2JSF S2OpenAMF S2Portlet S2Struts SAStruts Teeda Ymir Persistence.Java DBFlute Doma Kuina S2Dao S2Hibernate S2JDBC S2OpenJPA S2TopLink Co

  • 1