タグ

developmentに関するKOZIのブックマーク (5)

  • ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ

    実際に動的なウェブサイトを作ってしまう前に、紙上でデザインや部品の配置、画面遷移などを確認するペーパープロトタイピングという設計技法があります。書籍もありますね。 ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする そのペーパープロトタイピングの事例を集めたページというのがありました。たとえば次のこれは、2000年5月31日にスケッチされたtwitterのプロトタイプです。当時はstat.usという仮名で、これによるとtwitterはLiveJounal(ブログサービス)とAIM(インスタントメッセンジャー)から最初の着想を得てから実装まで5年以上の間があったことになりますね。 FlickrのPlacesページやVimeoなどのペーパープロトタイプの写真も紹介されています。 こちらは韓国のポータルサイトDaumのAjaxウェブメール開発時に行なわれた、ペーパープロト

    ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ
  • 開発者と利用者では「継続」の意味が違う - ただのにっき (2008-05-16)

    ■ 開発者と利用者では「継続」の意味が違う tDiaryのリポジトリを、CVSからSubversionに移行中だ(hsbtが)。SourceForge.netがsvnをサポートしたのはずいぶん前だから、とっと移行しちゃえば良かったんだけど、「2.2を出すまで待とう」と思っていたらいつまでたっても出せなかったので(笑)、こんな時期になってしまった。もたもたしている間に巷ではgitやらMercurialのような分散VCSが流行し始めてしまい、いまさらsvnかよ的な状況。でもまぁ、これくらいがちょうどいいんじゃないかね。 いまのところ、tDiaryプロジェクトのミッションは「プロジェクトを25年間存続させる」である(参考:「継続」という目標)。人生の記録をつける日記システムが、たかだか数年で消えうせるようでは困る。せめて四半世紀は安心して日記をつけ続けられるようにしたい。バグ修正だけでなく、時流

  • 極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ

    今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる

    極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
  • プログラミングファースト開発 - ひがやすを技術ブログ

    プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

    プログラミングファースト開発 - ひがやすを技術ブログ
  • 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
  • 1