品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ - 現場のためのソフトウェア開発プロセス - たかのり日記
以前に、以下の記事を書きました。 進捗管理は「遅れ」か「残り」か これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。 ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。 今回は、まず、レビューについて。 レビューは、大抵のベンダー／SIerでは実施されていると思います。 レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか？ レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。 そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。 これは、 要件は十分に
setunai.net - setunai リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
第3回設計勉強会をやりました - Do You PHP はてブロ
無事、第3回設計勉強会が終了しました。会場を提供して頂いたアイティメディア株式会社さん、ありがとうございました。今回も、id:NEKOGETさんのご協力で、Ustreamでの配信も行えたようです。毎度ありがとうございます！アーカイブがUPされるのは時間の問題かとｗ 今回は「ustもあるし、誰かメモをガガッとblogに上げるだろう」という予想の元、メモはほぼ取っていません。すみません。 発表資料は、handsout.jpにUPしてあります。 http://handsout.jp/slide/1635 「頑張ってテスト書いたよ」的な内容っぽく見えますが、実はもう1つプレゼンを作ってあって、そちら側は「ガッツリ書いたけど、どうだったの」的な話にしてました。ついでにUPしておきました。 http://handsout.jp/slide/1636 結論としては、「バランス重要」ということで。まあ、「
実践ロバストネス分析 第2回 ロバストネス分析の適用 | オブジェクトの広場
本稿は、2003年11月号に掲載した「ロバストネス分析実践 第一回」の続編になります。前回の記事を掲載した後に、読者の方々から様々なご意見、ご感想を頂いていたにもかかわらず、今回の第二回掲載までに、1年3ヶ月もの空白期間を作ってしまいました。本稿の掲載を心待ちにしていた読者の方々にお詫びいたします。 はじめに 前回の記事の訂正 前回の記事ではロバストネス分析を適用したソフトウェア開発の流れ、ロバストネス分析の方法を説明しました。 しかし、前回の記事を掲載してから今回の記事までの 1年3ヶ月の期間で、よりよいロバストネス分析について考えた結果、前回の記事で紹介した内容についていくつか訂正を加えようと思います。いずれ、下記の訂正を前回の記事に反映する予定です。 ロバストネス分析の範囲からユーザーインターフェースの定義を除く 前回の記事では、ロバストネス分析の「バウンダリを識別する」作業でバウン
MVC 構造を実現する "ASP.NET MVC" リリース | スラド デベロッパー
ストーリー by reo 2009年04月07日 10時30分 オープンソースですよ、オープンソース ! 部門より Microsoft が ASP.NET MVC 1.0 を、OSI 準拠のオープンソースライセンス Microsoft Public License (MS-PL) でリリースしました (Microsoft の開発者である Scott Guthrie 氏の blog 記事, japan.ineternet.com の記事より) 。 ASP.NET MVC は ASP.NET フレームワーク上で Model View Controller 構造を実現するもの。また、オープンソース化により ASP.NET MVC は .NET 互換環境である Mono でも利用できるようになり、早速 Mono 向けの開発環境である MonoDevelop 上で ASP.NET MVC を利用する
エンジニアにもわかる「ユーザーインターフェース設計」
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに 島津悠樹と申します。Yahoo! JAPANのソーシャルメディア系サービスの開発・ユーザーインターフェース（以下UI）設計を担当しています。私からは「エンジニアにもわかる『ユーザーインターフェース設計』」と題し、エンジニアのみなさまに考え方のヒントとなるようなネタをお届けします。 エンジニアの方々にとって、UI設計は、おもしろそう、けれど、どこかとっつきにくい......、そんな印象を持っておられるのではないかと思います。 私も以前はそう思っていました。ですが、とっつきにくさを理由にUI設計をやらないのはもったいない、という思いで試行錯誤した結果、なんとか、UI設計のお仕事をいろいろ担当させていただくことができるようにな
第35回 画面設計書はどう作られるべきか
Webサイトを構築する場合，通常は「設計書」を作成します。サイト全体の設計書であったり，ページ単体の設計書であったりするわけですが，今回は後者である「画面設計書」について考えてみましょう。 画面設計書を読むのは誰か Webサイトの構築では，対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に，画面設計書にも「対象読者」を見定める必要があります。結論から言えば，かなり属性の異なる二種類の読者が存在します。 まず，発注者である「クライアント」です。クライアントは，技術的な難易度ではなく，自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発（プロジェクト）のゴールや，プロジェクトのメリット/デメリット，リリース後の顧客満足の予想などを，その設計書から読み取ろうとします。したがって，できる限り具体的なイメージが伝わるものが要求されます。
開発現場のUIトラブルを解決!? 画面プロトタイプ入門
開発現場のUIトラブルを解決!? 画面プロトタイプ入門：いまさら聞けないリッチクライアント技術（16）（1/3 ページ） UIを取り巻く開発現場の問題点って何？ システム開発におけるUI（ユーザーインターフェイス。本稿では、画面系の話題をすべてUIといいます）には、大きく2つの問題があります。 ■ユーザーいわく「使いにくい、分かりにくい」 1つは、システムの使いやすさについての問題です。システムをリリースしても、エンドユーザーから「使いにくい、分かりにくい」などのクレームが発生し、システム導入後の運用コストが低減できなくなるなどの問題が発生します。 ■ユーザーいわく「やっぱり画面にアレが欲しいな」 もう1つは、製造工程以降で、動くシステムが出来上がったときに、顧客から追加の要件が頻発する問題です。これは、システム開発共通の大きな問題ですが、特に顧客の目に付きやすいUIの部分は、その指摘が多
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
