タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

devとdesignとprojectに関するMakotsのブックマーク (5)

  • 技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所

    私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既にニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ

    技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
  • だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba

    先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第2ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1買えること」 最初に「100円を入れてボタンを押すとコーラが1買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速! 「200円を入れてボタンを押すとオレンジジュースが1買えること」 次に「200円を入れてボタ

    だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう? - Mitsuyuki.Shiiba
    Makots
    Makots 2017/06/01
    示唆に富む話
  • 高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!

    どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP

    高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
  • 第65回 [図解]Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング:ITpro

    今回は,Webサイト構築プロジェクトのワークフローを俯瞰してみたいと思います。実際にクライアントから声がかかる場面から納品,つまり開発案件の完了までを12の「ステージ」に分けて図解してみました。思考のプロセス/人的配置/タスク/ツールなども一緒に記しています。少し大きな図になってしまいましたが,ご参考になれば。 図は,一番上は「4つのステップ/3つのタスク/12の要素(第62回 持続可能なWebサイト開発を支える12の要素)」。その下は,人的配置をロール(役割)ごとに記述しています。その下は,大まかなタスクのレベルです。それぞれの期間内に処理すべき項目を列挙しています。その下が,「ステージ」。プロジェクト全体を12のステージに分類して作業内容を整理しています。基的には,その流れの順で進んでいきます。その下は,それぞれのステージのアウトプットのイメージで,更にその下にはよく使うファイルアイ

    第65回 [図解]Webサイト構築プロジェクト・ワークフロー - Webデザイン エンジニアリング:ITpro
  • 連載:アプリケーション・アーキテクチャ設計入門 第5回(最終回) 物理配置および運用上の要求(1/4) - @IT

    はじめに さて、今回は連載の最後を締めくくる、Application Architecture for .NET(以下AAfN)の最終章(APPENDIXを除く)となる「物理配置および運用上の要求」を解説する。 ここまでの章では、アプリケーション・アーキテクチャを論理階層(レイヤ)の面から取り上げてきた。この論理階層(レイヤ)は、アプリケーションの中に含まれるさまざまな機能について語るには都合がいいが、分散アプリケーションとして複数台のコンピュータに配置する際には必ずしも論理階層(レイヤ)のとおりに分割されるわけではない。 どうして、論理階層(レイヤ)と物理階層(ティア)との間に違いがでるのだろうか。それは、論理階層(レイヤ)への分割と物理階層(ティア)への分割では、目的が異なるからである。論理階層(レイヤ)への分割は、カプセル化や抽象化といったテクニックで複雑なアプリケーション・システム

  • 1