アジャイルは大学や企業の偉い人に、どう見られているのか？

こんなTweetがあるみたい・・


Yoshihito Kuranuki‏@kuranuki
「例えば、アジャイル開発では設計書は更新しない」・・・えっと、これはエイプリルフールなのかな。。。 Link: 誤発注裁判が改めて問う「バグは重過失か」 http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465906/ … via @nikkeibpITpro

https://twitter.com/kuranuki/status/318535749920247810


誰が、

「例えば、アジャイル開発では設計書は更新しない」

と思ったかが問題ですよね。
東証の人が思った、弁護士が思った・・・というより、
意見書を書いた専門家が思ったと考えたほうが素直ですよね。
（すくなくとも、専門家は、その考えを否定しなかった）

そして、相手方の専門家も、それを否定しなかった。
（否定するなら、相手の言っていることに根拠はないと、
　すかさず反論するはず）。

つまり、専門家の方々は、

「例えば、アジャイル開発では設計書は更新しない」

と思っていると推察される。

---

　ソフトウェア工学の専門家のかたとは、

　　大学や企業の研究室、開発の偉い人のはず。。。

　　あんまり、新入社員が、意見書とか、書きませんよね、当然

　そういう人たちに、

　　「例えば、アジャイル開発では設計書は更新しない」

　と見られていると考えて、まず、まちがいない。

---

　ここから浮かび上がってくる、

　アジャイルは大学や企業の偉い人に、どう見られているのか？

　っていうことは、実は重要。

　アジャイルに否定的な見方を、
　　大学の先生にされると、大学生は、否定的な感情でフォーマットされるし、
　　企業の偉い人にされると、会社で導入しにくい。

　ただし、企業に関しては、日経ほにゃららで、「アジャイルでこれだけ生産性向上」
　とか、ビッグデータばりにやれば、ＯＫかもしれない・・

昨今の開発スタイルの流れを、ＭＶＣでまとめてみる

最近の開発スタイルは、Ｍ，Ｖ，Ｃに対する力点の置き方の違いで、
いろいろと分かれている気がする。

---

■モデル（Ｍ）に力点を置いたもの
　モデルに力点を置き、モデル、さらにＤＢの内容に基づき
画面自動生成などを行う。

　たとえば、cakeだと
　Ｖｉｅｗに対するコントローラーが必要で
　コントローラーに対するモデルがあることが期待され
　ってなってくると、

　モデルがあることが必要になってくる。
　この場合、Viewのつくりは固定的な場合が多い。

　Rails系、ＳｕｇｅｒＣＲＭ５．０のモジュールビルダー
　たぶん、GeneXusなどもこの流れ

　ＵＩを重視する場合などは、この手法だと、自動化しても、
効果があまりなく、逆に混乱する。

---

■コントローラー（Ｃ）に力点がおかれたもの

　そのため、モデルとビューを分離する。
　　　モデルは、サービスとして存在し、
　　　ビューはユーザーインターフェースとして存在する。

　モデルとビューは違うものだから、コントローラーで、
　　　モデルからデータを収集し、
　　　ビューで使うデータに詰め替える

　こうすると、
　　　モデルは、モデルだけで完結するため、モデルのみでテストでき、
　　　ビューは、ＨＴＭＬで作成したあと、
　　　　　　　　コントローラーでダミーの値を入れて確認、
　　　そののち、モデルからデータを取ってきてビューの変数にいれる。

　ビューから飛んできたデータは、
　　　コントローラーでチェックしたあとに、
　　　保存などモデル処理し、次画面にとび、
　　　次画面でははじめ、画面表示データを取得し、表示する。

　データは、モデルに存在しても、画面(View)に存在しても、セッションに存在しても
　　　すべてコントローラーでアクセスできるので、
　　　コントローラーでデータを操作するなら、すべてアクセスできる
　この際、モデルに存在するデータは隠蔽されるので、ＤＢでもメモリ上でもかまわない

　このようなＭとＶを分離する考え方は、長く続いた。
　ＭとＶを分離した場合、Ｖのみをつくる、Ｍのみをつくる、糊付けするという分業が
やりやすい上、属人性を排除しやすい。そこで、人を追加することに意味があった。

---

■ビュー(view)＝画面に力点を置くもの


この後、ＵＩに力がいれられるようになり、ＵＸでは、

　　Viewの内容をもとに、クエリを作り、それに対応したモデルを作成する

という方針になってきた。

　特に、ＮｏＳＱＬが「ネット上の」主流の論調になると、
　　（実際に稼動している主流というわけではない）
　ＮｏＳＱＬは正規化すると、やりにくいので
　　（トランザクションの問題とかあるから）、
　正規化を否定する方向になってきた
　　（実は、ＲＤＢ否定よりも、正規化の否定のほうが、開発上、影響が大きい）


　そして、cakeもzendもそうだけど、
（１画面１コントローラーに、「わざわざする」ことをしない場合）、
１コントローラーに各画面の処理をてんこ盛りすることになり、
コントローラーが、肥大化する。

　なにより、１コントローラーが１ソースになるため、
　　画面ごとに担当者がばらばらで、
　　コントローラーで処理をいっぱい書こうとすると、
　　ソースをマージするのが大変になる。

　じゃあ、１画面１コントローラーにすればいいじゃない
　と思うかもしれないが、世の中は、そう進まなかった。

　Javaの世界ではstrutsは、画面初期設定(reset)で、
　画面表示内容のような大きな処理をすることを
　好んでいない（と確か思った）

　また、ＰＨＰの世界では


CakePHP コントローラに処理を書かずにモデルにメソッドを追加しよう！
http://blog.syuhari.jp/archives/172


にあるように、コントローラーに処理を書かずにモデルに処理を書き、
画面の内容をダイレクトにモデルにつなげるようになった。

このため、ＭとＶが分離せず、モデルを修正すると画面がエラーになったり、
画面を修正しても、モデルを修正しないと確認できなかったりすることも
起こる。

で、そうなってくると、モデルとビュー作成者は、同じ人のほうがやりやすい
別の人だと、モデルの出来をまって、ビューの出来を待ってとか、待ちが発生する。
さらに、同じ人がやった場合、どこまでモデルでやるか、どこからビューでやるかが
自由に選択できるから。

ただ、ここまでの自由度を与えると、属人性が出てくるので
他の人が手伝いにくい。

結果として、おひとりさま開発のほうが、やりやすいことになる。

ChromeのWebkitに代わる新しいレンダリングエンジンBlink

まず、そのニュースは、


Google、WebKitに代わる新レンダリングエンジン「Blink」を発表
http://www.itmedia.co.jp/news/articles/1304/04/news037.html


にあって、その話は

Blink: A rendering engine for the Chromium project
http://google-opensource.blogspot.jp/2013/04/blink-rendering-engine-for-chromium.html

に書いてある。

そのBlinkプロジェクトは、

こちら
http://www.chromium.org/blink

Gooにつづき、Ｙａｈｏｏも、不正アクセスらしい・・

昨日、

gooの「不正ログイン被害のご報告とパスワード再設定のお願い」
http://blog.goo.ne.jp/xmldtp/e/49fc3da5f8ce743fbfc7e3c1ffda6508

というエントリを書いたけど、ＹＡＨＯＯも・・


ヤフーに不正アクセス　１２７万件の情報持ち出そうとするプログラム
http://news.goo.ne.jp/article/sankei/nation/snk20130404568.html


とのこと・・・

最近、流行ってる？

PressmanのSoftware Engineeringを超訳ななめ読み その６－要求の理解

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

前回までで、第一部の第１～３章をやった。

今日から「第二部　モデリング」
この部は、４章～１３章まで。
４章は、実践ガイドとしての法則ということで、法則というか都市伝説というかが、
いっぱい並んでいるけど・・・まあ、省略！
ということで、今日は５章

---

■第５章　要求の理解

「５．１　要求工学」
　以下のタスクが並行して起こる
　　　はじめに（インセプション）
　　　抽出する
　　　詳述する
　　　交渉
　　　仕様化
　　　妥当性の評価（バリデーション）
　　　要求のマネジメント

　で、コラムに「ソフトウェアの要求仕様のテンプレート」がある
　以下のカタチ

　　　目次
　　　変更履歴

　　　１．はじめに
　　　　１．１　目的
　　　　１．２　表記法
　　　　１．３　対象者
　　　　１．４　プロジェクトのスコープ
　　　　１．５　参照文献

　　　２．概要
　　　　２．１　製品概要
　　　　２．２　製品機能
　　　　２．３　利用者の特性
　　　　２．４　操作環境
　　　　２．５　設計と実装上の制約
　　　　２．６　ユーザーのドキュメント
　　　　２．７　仮定と依存性

　　　３．システムの機能
　　　　３．１　システム機能１
　　　　３．２　システム機能２
　　　　　　　　：（などなど）

　　　４．外部インターフェース要求
　　　　４．１　ＵＩ
　　　　４．２　ハードウェアインターフェース
　　　　４．３　ソフトウェアインターフェース
　　　　４．４　通信インターフェース

　　　５．その他の非機能要件
　　　　５．１　性能要件
　　　　５．２　安全性要件
　　　　５．３　セキュリティ要件
　　　　５．４　ソフトウェアの品質属性

　　　６．その他の要求
　　　　付録１：用語集
　　　　付録２：分析モデル
　　　　付録３：問題点リスト

まあ、IEEE std-830見たいな内容が載っている。

---

■５．２　基礎の確立
　要求を獲得するまでの手順が書いてある

　　５．２．１　ステークホルダーの識別
　　５．２．２　複数の観点の認識
　　５．２．３　コラボレーションに向けて作業する
　　５．２．４　はじめの質問を尋ねる
　　　　インセプションデッキみたいな話
　　　　(インセプションデッキは出てこないけど）

---

■５．３　要求抽出
　　５．３．１　共同で出した要求を集める
　　５．３．２　品質機能展開（ＱＦＤ）
　　５．３．３　シナリオを使う
　　５．３．４　抽出作業の成果物

---

■５．４　ユースケース開発
　　ユースケース記述が載っています。

　　ユースケース
　　主なアクター
　　ゴール
　　事前条件
　　トリガー
　　シナリオ
　　例外
　　優先順位
　　いつ使えるか
　　使用頻度
　　アクターに対するチャネル
　　二次的なアクター
　　二次的なアクターに対するチャネル
　　問題点

　などなどを挙げる。
　また、ＵＭＬのユースケース図が載っている

---

■５．５　要求のモデルを構築する

　　５．５．１　要求のモデルの要素
　　　・シナリオに基づいた要素
　　　・クラスに基づいた要素
　　　・振る舞いの要素

　　　アクティビティ図やクラス図が載っています

　　５．５．２　アナリシスパターン

---

■５．６　要求の交渉
　５．７　要求の妥当性確認
　５．８　まとめ
　　　そのほかつづく

---

こんなかんじ