タグ

開発に関するholyppのブックマーク (20)

  • ソフトウェア開発に本当に必要なものは人手か? | Social Change!

    当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち

    ソフトウェア開発に本当に必要なものは人手か? | Social Change!
    holypp
    holypp 2011/07/08
    ソフトウェア開発という仕事は、対象のドメインを理解したり、プログラミングの技術を磨いたり、本来は「学び」の多い仕事。プログラマの稼働を100%にしなくても成立するビジネスモデル。
  • 「契約もアジャイルに」、中堅SIerの新たな挑戦 - @IT

    2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方

  • オブジェクト指向開発を理解した開発者に、設計書は不要:アジアのソフトウェア開発現場にて:エンジニアライフ

    シンガポールでアジアのエンジニアと一緒にソフトウエア開発をして日々感じること、アジャイル開発、.NET、SaaS、 Cloud computing について書きます。 わたしのソフトウェア開発者としての経歴は10年程度。10年間、いろいろなものを作ったが、「設計書」と言えるもの、つまり「基設計書」「詳細設計書」がある形でプログラム開発したことは一度もない。たぶん、これからもないかと思う。 「大したものを作っていないのでは」と、わたしのソフト開発者としての能力を疑う人が出てくるかもしれない。しかし、大企業で大勢の人に使われるようなシステム――規模にして数十年月のしっかりしたシステムを作ってきたことは事実である。ということで今回は、「設計書なしでかなりの規模のシステムを作る」ことに関するわたしなりの方法論を少し書いてみる。 オブジェクト指向は必須である。「設計書なしである程度の大きさのソフト

    オブジェクト指向開発を理解した開発者に、設計書は不要:アジアのソフトウェア開発現場にて:エンジニアライフ
    holypp
    holypp 2010/07/05
    良いこと書いてる。DB修正は工数が増える(場合によるけど)とか。あとはリファクタリングはもう基本で、客側がそれを理解しない場合が今後一番辛いところではないかな。
  • 要件定義の勘どころ

    はじめに 役に立つシステムを構築するための要件定義書とは、いったいどういうものなのでしょうか。 「何でこの機能が必要なんですか?」「理由は分からないけどXXX機能があるのでこの機能が必要なんです。これがないとつじつまが合わなくなるんです」もしくは「要件定義書にこの機能が載っているので必要なんです」など、要件定義書の役割を理解しないまま、システムの開発に着手していることなどがないでしょうか。 稿では、要件定義書の役割や重視すべき点、要件定義書に盛り込むべき情報について解説します。 何をやるのか、そしてなぜそうするのか 要件定義書はジグソーパズル? システム開発を受託した会社にコンサルテーションしたときのことです。機能とデータがある程度記述された要件定義書を受け取ったその会社では、要件定義書を読み解き、システムの全体像を掴むためにおのおのの機能の関係を整理し、その役割を把握しようとしていまし

    要件定義の勘どころ
    holypp
    holypp 2010/06/15
    マーチンファウラーのUML本を思い出した。そちらがオススメです。
  • いまさら聞けないiPhone/iPadアプリの作り方の基礎

    いまさら聞けないiPhone/iPadアプリの作り方の基礎:SDKで始めるiPad/iPhoneアプリ開発の勘所(1)(1/4 ページ) 初めてiPhone/iPadアプリ開発に挑戦する人が、迷わず短時間でアプリを作れるように、数多くの情報の中から要点をグっと絞った開発の勘所を紹介する入門連載です 迷わず短時間でiPhone/iPadアプリを作れるように 皆さんのお気に入りのiPhone/iPadアプリは何でしょうか。筆者は、Googleカレンダーと同期してくれるスケジュール管理アプリがお気に入りです。いまでは目的のアプリを探すのも大変なほど、日々多くのiPhone/iPadアプリが登場しています。 6月8日にはiPhone 4の発表があり、マルチタスクやモバイル広告ネットワーク、ゲーム開発など、iPhone OS改め、iOS 4で実現できる機能がたくさん追加され、さらに魅力的になりました

    いまさら聞けないiPhone/iPadアプリの作り方の基礎
  • マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey

    マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech

    マイクロソフトにおけるアジャイル開発はこんな風に進められている - Publickey
  • 第34回 Redmineプラグイン開発(1) | gihyo.jp

    はじめに RedmineRuby on Railsで実装されたプロジェクト管理ツールです。競合のツールとしてTracが有名ですが、Tracと比較して開発速度が早く、ここ数年で急激にユーザを増やしています。Tracには標準で用意されていない機能として、ガントチャートの表示や複数プロジェクトの管理、チケットの種別ごとのワークフローのカスタマイズ機能に加え、最新の0.9系ではTracに比べて唯一貧弱だったチケットのレポーティング機能がほぼ同等レベルまで強化されました。 これにより今年から格的にRedmineへの移行が始まっていくと思われます。既に2009年の9月にはオープンソースのSNSエンジンであるOpenPNEの開発チームがTracからRedmineに移行したことや、Googleトレンドの検索数でRedmineがTracを追い抜いたというニュースもあります。 今回は、Redmineのプラ

    第34回 Redmineプラグイン開発(1) | gihyo.jp
  • ユメのチカラ: 開発工程を別々に担当してはいけない

    古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更

    holypp
    holypp 2010/05/11
    キーワードだけ。心に刻んでいつか壊す。>上流、人月単価、ドキュメントは冗長に、製造の責任ではない、ゼネコン、実力より所属、業界にとってエンジニアの使い捨ては百害、工程の分離は悪。
  • 角谷信太郎——「スーパーマンである必要はない」 − @IT自分戦略研究所

    第9回 角谷信太郎――「スーパーマンである必要はない」 岑康貴(@IT自分戦略研究所) 赤司聡(撮影) 2009/3/30 角谷信太郎(かくたにしんたろう) 永和システムマネジメント サービスプロバイディング事業部 チーフプログラマ 1975年2月19日、大阪府出身。1998年 立命館大学法学部卒業。「『楽しさ』がシステム開発の生産性を左右する」と信じて、アジャイル開発を現場で実践するテスト駆動開発者。日Rubyの会の理事を務め、日最大級のRubyカンファレンス「RubyKaigi」の運営に携わっている。 ■うまく回るように、全体を見る 「Rubyを使って、お客さまにとって価値のあるシステムを届けたい」と以前から考えていました。2年ほど前から実際にRuby開発チームのチーフプログラマとして働いています。わたしの任務は「プロジェクトが失敗しないようにすること」。お客さまに対するヒアリング

    holypp
    holypp 2010/04/20
    ビジネスで成り立つのは恐ろしい。いつかやりたい。>Rubyだとこの規模でも、1~2週間のサイクルでお客さまに対して、目に見える形で成果を出せます。コミュニケーションの面でこれはとても強力です。
  • 詳細設計書に何を書くべきか? - Sacrificed & Exploited

    詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと1対1に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容(内部の処理の実装方法)の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、

    詳細設計書に何を書くべきか? - Sacrificed & Exploited
    holypp
    holypp 2010/01/08
    同意。 ~具体的には、TDDやBDDの考え方みたいに、どういう入力に対して、どういう結果になるかというブラックボックステスト的な振る舞いのみを記述する必要があると考えている。~
  • Windowsでスクリプト言語“Ruby”を導入するための和製インストーラー「Rumix」NOT SUPPORTED

  • Cookieセッション、BASIC認証マジパネー - komagataのブログ

    Rails検証報告書: プログラマの思索 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsの後から付いた機能で一番素敵だと思うのがこの機能です。 「Cookieなんて仕様上は4KBしか保存出来ないんだから寧ろ弱体化してね?」 とか認識されることが多い気がしてならない。 コレ、導入時にも度肝を抜かれて、以降常に、 「ハンパねー、マジCookieセッションハンパねー!」 と脳内のアフロの人が言ってるんですが、大した利点に感じる人は少ないのか、他の言語やWAFで全面採用している例を見たことが無い。 そもそもセッションという言葉自体が複数の処理をまとめた単位という広義の意味とWebアプリケーションで複数リクエストにまたがってサーバー側に保存されるデータという狭義の意味が混在して使われているという事情があってWeb上

    holypp
    holypp 2010/01/05
    内容とはズレるが、理にかなっていることと風習が戦うんだなと思った。
  • 「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために

    最近こんなやりとりがあった。 「Cって標準のコンテナ(双方向リストや可変長配列など)がなくて不便。 Cのプロジェクトってコンテナ自体ないこともあるし、コンテナがないとプログラムって書きにくいよね。 その点C++はSTLが(ry」 ... 「コンテナ? STL“も”いいけど、自分で書きたい」 正直、自分は「え? 何を言っているんだ?」と思った。 STL“も”いいけど、“自分で書きたい”だって? その人はプログラマとしては十年選手だが、C++に関して、特にテンプレートに関しては稚児に等しいレベル。 で、どうして「自分で書きたい」ということになるんだろう? それを使わされる人の苦労はどうなる? それともプロジェクトに同一の事をするための複数のコンテナが存在するのか? 俺俺コンテナを書きたい理由はなんだ? 要するにここにおいて「自分で書きたい」はSTLがよく解らないので、 機能や動きを隅々まで把握

    「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために
    holypp
    holypp 2009/12/30
     ~多くの場合、全ての言語機能には「理由」があるのだが、それに対して「なぜ」ではなく「糞」と片付けてしまう。~ あるある。
  • アンチパターン - Wikipedia

    ソフトウェア開発におけるアンチパターン (英: anti-pattern) とは、必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う[1]。その内容は、基的には、否定的な開発方式の一般的な形、主原因、症状、重症化した時の結果、そしてその対策の記述からなる[2]。 デザインパターンを補完・拡張する関係にあるもので、多くの開発者が繰り返すソフトウェア開発の錯誤を明確に定義することにより、開発や導入を阻害する一般的で再発性の高い障害要因の検知と克服を支援することが目的である[3][4]。 概要[編集] ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う[5][6]。 アンチパターンという呼び方は、アンドリュー・ケーニッヒ(英語版)が1995年に作り出したもので[7]、後に書籍The patterns handbook[8]で再掲された。 ギャン

    holypp
    holypp 2009/12/25
     復習するしかない。これは何度も読むに値する。
  • Amazon.co.jp: システム統合の「正攻法」: 大和田尚孝: 本

    Amazon.co.jp: システム統合の「正攻法」: 大和田尚孝: 本
  • 6000人が作ったシステムは必ず動く:ITpro

    最盛期の開発要員6000人,開発工数11万人月,投資額2500億円,取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ,勘定系システム一プロジェクトの成果物である。6000人のシステムズエンジニア(SE)が作り上げた巨大システムは,2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが,6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間,記者を続けるのか分からないが,今回の三菱東京UFJ銀行を除けば,6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって,「6000人月」ではない。開発工数は先に書いた通り,11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開

    6000人が作ったシステムは必ず動く:ITpro
  • eclipse入れたら入れるもの - nazokingのブログ

    プラグイン S2JUnit4 plugin http://s2junit4plugin.sandbox.seasar.org/ ctrl+9 とかで テストケース←→体の切り替え(無ければ作成)ctrl+0でテスト実行 http://eclipse.seasar.org/updates/3.3/ テストケース作成が簡単になる。Quick JUnitプラグインはなんかうまく動かない(test作るソースフォルダの指定が出来ないなど)のでseasarの奴を使う EclEmma http://www.eclemma.org/ カバレッジ表示。djUnitだとプロジェクト全体のJunitRunができない? http://update.eclemma.org/ GrepConsole コンソールを正規表現で色分け http://marian.musgit.com/projects_grepconso

    eclipse入れたら入れるもの - nazokingのブログ
  • アナログ新人社員の「ホームページ制作会社サバイバル」企画終了

    陰ながら見守っていた京都のSEOコンサルタントM氏の企画、『アナログ新人社員の「ホームページ制作会社サバイバル」』が終了した模様です。 アナログ新人社員の「ホームページ制作会社サバイバル」より企画内容を引用します。 1ヶ月以内にホームページを1つ立ち上げる1ヶ月以内に広告収入で自分の歓迎費の3000円を稼ぐホームページを作るまでの過程をブログで毎日更新という事で、新入社員のミホミホさん(あだ名)が新規に立ち上げたWebサイトでアフィリエイトで3000円の広告収入を得られなければ正式に入社出来ない、というサバイバル企画です。え?この企画は釣り?でももう僕は釣られてしまったのでこのまま進めたいと思います。強行突破っす。 HTMLも分からない人が得られるアフィリエイト収入は・・使っているツールは僕も大好きなWordPressでテンプレートはSEOに特化した賢威ですね。 彼女はおそらくHTMLどこ

    アナログ新人社員の「ホームページ制作会社サバイバル」企画終了
  • プログラマーのジレンマ 夢と現実の狭間

    プログラマーのジレンマ 夢と現実の狭間 伊豆原 弓 日経BP社 2009-05-21 売り上げランキング : 29765 おすすめ平均 Amazonで詳しく見る by G-Tools 読み終わってから結構日が立ってしまったが、なかなかよいだと思ったので紹介しておく。 書は、「Chandler」というOSSプロジェクトを1人のジャーナリストが3年間に渡って追い続けたドキュメンタリーだ。Chandlerプロジェクトは、優秀なメンバー(名前や、名前がわからなくとも参加したプロジェクト、製品なら大抵の人が知ってるであろう人々)、潤沢な資金、OSSの為リリース日を自分達で調整できるなど開発者からしたら理想とも言える環境で開発が進められた。しかし、結果としてプロジェクトは迷走に迷走を重ね、書の中でバージョン1.0がリリースされることはなかった。 正直、あまりにプロジェクトが進まないので中盤あたり

  • 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey

    での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数%程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日SIerに務めています。日では、設計書をエクセルを使って画面や処理などの書類を作成しています。海

    「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey
  • 1