システム屋日誌

情報システム構築、開発手法を中心に気が付いたことを書き留めます。ちいさなことから、おおきなことまで。もちろん、どうでもいいことも。。。
<< October 2017 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
 
RECENT COMMENT
RECENT TRACKBACK
れいねっとHP
http://www.rey-net.com
MOBILE
qrcode
PROFILE
無料ブログ作成サービス JUGEM
 
企業とIT活用
12月は忘年会の季節。1年間お世話になった人々と一堂に会する機会がたくさんありました。 今年は色々な事件がありました。 そんなわけで、これからどうする?日本はどうなる?ということを真剣に語り合う場が多かったです。 希望が持てたのは、前を向いて具体策を考えている人が予想以上に多かったこと。 私より年下の層の方がその傾向が強いです。 来年の年末はどんな話をしているか、楽しみになりました。
JUGEMテーマ:インターネット
要求工学入門
久々に、ブログ復帰。

最近暖めている企画の中で、どうしても勉強しておきたいことができました。それは「要求工学」。

数年前から、少しかじっていたけれど。
目的ができたので、ちゃんと学んでみることにしました。
以前読んだのは、「ソフトウェア要求」という本。

この本のゴールは、顧客の要求にマッチした情報システムを作ること。
私の、現在の目標は、顧客の要求にマッチした、システムを作ること。何がなんでも、情報システムを開発するというものではない。

・あるものは利用する
・不要なものは作らない
・業務が今より大変になるなら、変えない

そんな視点で書かれた文献を探してみよう。
「ソフトウェア要求」の訳者である渡部 洋子さんが書いたITプロの記事によると。
http://itpro.nikkeibp.co.jp/article/COLUMN/20051020/223121/
---------------------
 「要求工学」注1)は,このソフトウエア工学を構成する重要な領域の1つだ。

注1 要求工学
要求工学を「要求定義工学」と呼ぶこともあるが,英語はRequirements Engineeringでどちらも同じ意味だ。また,要求を「要件」と呼ぶ場合もあるが,これも英語で言えばどちらもRequirementsである。本記事では,Requirements Engineeringは要求工学,Requirementsは要求と呼ぶ
---------------------
と、書いてあります。というとこは。

ソフトウエア工学>要求工学
という関係であり、私が考える、

要求>ソフトウエア

という関係ではないので、要求工学には私の求める情報がないのかな。
まぁ、とにかく調べてみよう。

補足:「ソフトウェア要求」は、いい本ですよ!
システム屋として、読んでとっても勉強になりました。
システム開発のためのモデル その4 システム開発技法 スパイラルモデル
スパイラル・モデルを一言でいうと、ウォーターフォール+プロトタイピング。

【いいとこ取り】
大規模な開発に向いているのが、ウォーターフォール・モデル。小規模な開発に向いているのが、プロトタイピング・モデル。
その2モデルのいいところを取ったのが、スパイラル・モデルといわれています。

【事例】
ウォーターフォール・モデルで工程を分割します。基本計画->外部設計まで一貫して行います。それ以降の工程は、独立したサブシステム毎に「設計」「プロトタイプモデル作成」「検証」を繰り返して、徐々に開発規模を大きくしていきます。

    (1)基本計画−>(2)外部設計−−−>
                    ↑ ↑ (3)内部設計1
                    | |     ↓
                    | | (4)プロトタイプ1作成 ※
                 フィードバック    ↓
                    ↑ | (5)テスト1(検証)
                    | +−−−−−+
                    |
                    ↑   (6)内部設計2
                    |       ↓
                    |   (7)プロトタイプ2作成 ※
                 フィードバック    ↓
                    |   (8)テスト2(検証)
                    +−−−−−−−+

【良いところ】
一歩ずつ、仕様を確認しながら進められるところ。
このモデルは、各工程の直前の工程での検証結果を、次の工程に「フィードバック」がある。
フィードバックの前に必ずユーザの承認が必要なので、仕様との相違がないかどうか、
小さな単位で確認しながら前に進めるので、大きな手戻りが発生しないというわけです。
また、仕様変更にも柔軟に対応できます。

【欠点】
毎回プロトタイプを作るので、時間がかかります。全体でみると、開発効率は低くなる可能性があります。
では、どんなときに開発効率は低くなるのか。単純に考えると。

 最初の要件〜完成まで全く変更なしの場合、開発効率は。
  ウォーターフォール > スパイラル

 最初の要件が完成前までにずれが生じた場合、開発効率は。
   スパイラル > ウォーターフォール
 
要件のズレの頻度が高いほど、スパイラルの特性が生きて、開発効率が良くなります。


参考文献:情報処理技術者テキスト 基本情報技術者プラスアルファ〈4〉システム開発とその運用

デジタル用語辞典 2002−2003版
システム開発のためのモデル その3 システム開発技法 プロトタイプモデル
 ウォーターフォールモデルの「最後まで完成形が見えない」という欠点を補うために考えられたモデル。
プロトタイプとは、試作品を意味します。本格的な開発に入る前に、要求仕様からプロトタイプを作り、
ユーザに確認してもらいます。要求仕様とと完成した情報システムのズレを早期の段階でなくせば、
下流の段階での手戻りを防ぐことができます。

-------------------------------------------------
プロトタイプモデルを使った開発の流れ

 [システム化要件定義]
   ↓
 [プロトタイプ作成]  
   ↓           
 [ユーザレビュー(評価)] 
   ↓           
 <プロトタイプの判断>→不可なら「プロトタイプ作成」へ戻る
   ↓           
 [外部設計] (ここから下は、ウォーターフォールモデル)
   ↓           
 [内部設計]        
   ↓           
 [プログラム設計]     
   ↓           
 [プログラム実装]     
   ↓           
 [ソフトウェア導入支援]  

参考文献:情報処理技術者テキスト 基本情報技術者プラスアルファ〈4〉システム開発とその運用
システム開発のためのモデル その2 システム開発技法 ウォーターフォールモデル
情報システムを作るとき、何でもかんでもコンピュータ化すればいいものではなく、最初に情報システムの全体像を作り、どこを人に任せるか、どこをコンピュータに任せるかを考える必要があります。

この後、どのようなシステム開発技法を使うかを決めて、開発に着手します。

システム開発技法は、色々なモデルがあります。ウォーターフォールモデルはそのひとつ。

【ウォーターフォールモデル】
上流工程から、下流工程に向けて、作業を順番にこなします。
各工程が終る前、作業結果が完全かどうか、チェックします。間違いや欠落を見つけ、修正してから
次の工程に移るので、工程間の手戻りが少ないというのが、ウォータフォールの最も良い点です。
ただし、開発が並列ではないので、ユーザ部門はかなり後ろの工程に来ないと成果が見えない。
また、後から発生した仕様変更に対応しにくいという欠点をもっています。

設計図通りにきちんとプラモデル組み立てて、色を塗ってから、エンジンを乗せ変えたくなった。
無理やり接着剤はがして乗せ変えて組み立て直すと・・・なんかコ汚くなっちゃった・・・みたいな感じ。

ウォーターフォールモデルの特徴
(1)上流工程から下流工程の向けてトップダウン方式でシステムを開発する。逆流は、原則なし。
(2)開発の各工程の成果物が明確
(3)工程管理が楽。大きなプロジェクトに向く
(4)上流工程にミスがあると、下流工程への影響が大きい
(5)開発工程はV字型の関係を持つ

     \                     /
 [システム化要件定義] ←チェック      [ユーザテスト]
      \                  /
    [外部設計]   ←チェック   [システムテスト]
       \               /
     [内部設計]  ←チェック  [結合テスト]
        \            /
         \          /
          \        /
       [プログラミング][単体テスト]

参考文献:
情報処理技術者テキスト 基本情報技術者プラスアルファ〈4〉システム開発とその運用
システム開発のためのモデル
情報システムを開発するためには、設計や計画が必要です。無計画にバラバラとプログラムだけ組んでも、きちんとした情報システムは作れません。

【テキトウでもうまくいく事例】
設計や計画がなくても、開発がうまくいく事例はあります。
私の思いつく限りでは、ある程度ツールを使いこなしている人が
自分で作ったホームページ。

エンドユーザ=自分。

(1)要件定義を出すのは、自分。情報システムを実装するのも、自分
  -->したがって、要件定義と実装のずれはなし

(2)スケジュール・品質・予算、すべて自分の中で折り合いがつく

【一般的な事例】
一般的な情報システムは、そうはいきません。

エンドユーザ≠自分。

(1)要件定義を出す人と実装する人は違う
  -->したがって、要件定義と実装のずれが出る可能性がある

(2)スケジュール・品質・予算、すべて合意をとる必要があり

つまり、一般的な開発では要件定義と実装の調整および、スケジュール・品質・予算の調整が必要になってきます。

技術的な問題を解決してモノを作るだけでは、成り立たなくなってきます。
情報システムの設計や計画を難しくしている最大の要因は、完成品が最後の最後まで「見えない」こと。

見えないことは、トラブルを生みます。
スケジュールや開発費用などの見積の誤算。
開発過程で、技術者が針路を見誤ってしまい、要件と違うものができるなど。あげればきりがないです。

それらを解決するために、さまざまな手法が考えられています。
デッサンと情報システムの設計
考えてみたら、私は特技らしい特技というものがない。あえて言えば。コンピュータとデッサンと心肺蘇生。コンピュータは、これでごはん食べてるから・・・特技は残りの2つかな。

デッサンは、小さい頃からアトリエに通って、身に付けたもの。今は・・・全然練習してないからダメダメですが。でもしかし。デッサン力を身に付ける過程で、情報システムの設計に役立つスキルがついたように思います。

それは「全体を見る習慣」。

デッサンは、次のようなプロセスで描いていたと記憶しています。
1.対象を観察し、どこからどこまでを描くか決める
2.輪郭を薄く書いて、バランスを見る
3.全体のバランスにをとりながら、面を書き足していく

デッサンの練習の目的は、写実。対象物を忠実に紙の上に再現するための訓練でした。気の向くまま、一部分を描き込んでしまうと、うまくいかない。
常に客観的な視線で全体を見て、まんべんなく面を描きこんでいくと・・・ちゃんと写実できます。

情報システムも初期段階で全体を見抜き、バランスをとりながらプロジェクトを進めていくことが必要です。デッサンを描くプロセスと同じように並べると。

1.要件を把握し、システム規模、範囲をつかむ
2.決まったことをドキュメントにして、全員で共有
3.進捗管理や要件と成果物の整合を取りながらプロジェクトを進める

わかっていることから先に手をつけてしまうと、大抵の場合、後から見えていなかった部分が出てきて、時間が足りなくて火を噴きます。大規模な情報システムになるほど、後が大変。

設計の段階で全体を抜けなく把握して、決まった内容を「見える化」する。また、プロジェクトを進めていく上で、常に全体のバランス意識することも大事なんです。
考えながら仕事する人と、しない人
風呂に入りながら、時々小説を読みます。そうやって読んだ小説はたいていブックオッフ行きなのですが・・・時々捨てられない小説があります。伊集院静の短編集「冬のはなびら」。これ、小説自体に名残はないのですが、解説がすごくいい。清水良典という文芸評論家が書いてあるのですが、時々読み返しています。

解説は、現代社会に潜む問題と、主人公たちを対比させながら書かれています。仕事を覚えるのが遅いけれど、着実に技を身に付けていく表具師をはじめとする主人公たち。彼らの生き方は、効率重視の現代社会で歓迎されない。しかし、要領をつかんで早く結果を出すことを繰り返すうちに、失ってしまうことがある。清水さんは不器用な表具師を「生来不器用だったことが幸いして道を誤らずに済んだ」と表現しています。

じっくりものに向かいあう人が減る。
真の仕事人が減ってしまう・・・判断力、問題解決能力、コミュニケーション能力。。。普段から準備していないと、いざというとき出てこない力たち。直接作業をヒョイヒョイこなすだけでは、到底身に付かない。でも、身に付けてしまえば、仕事が変わっても、役に立つはず。

もっとコワイことを言えば。
ルーチンワークを効率的にこなす仕事は、ロボットの方が得意。考えないで仕事していれば、どんな業務でも、いずれはロボットに負けます。人が生き残るためには、考えながら仕事する時間が必要なんだと思います。
ソースコードが語る、もの作りの文化
そろそろスノーボードに行きたいと思う今日この頃。
私のスノーボード仲間は皆、SE(システムエンジニア)。
集まって話していると、自然と開発の話題になります。

ある人は、今、とんでもないプログラムを解析中。
1つのソースファイルは数百行でも多い方。
でも、そのファイルは1万行。
人間でいえば、メタボリック症候群です。
でも、表面上はちゃんと動いている。

なぜ、1ファイルの行数を少なくするか。
それには、いくつかのわけがあります。
・シンプルにプログラムを書くと、間違いが少ない
・1つの処理を分割し、構造化することでプログラムを部品化。
 組み合わせることで、別の処理系に再利用できる。
・設計書とすり合わせがしやすくなるので、設計とのズレが少なくなる
・読みやすければ、開発メンバー全員が理解できる(相互チェック可能)

などなど。

で、この1万行を機能そのままでシンプルな形にするのがその人の仕事。
まるで、ジェンガ、はたまた将棋崩し。
真ん中をそーっと、、、1本抜くと、、、ばらんばらん。

「この変数使ってないよね。えいっ削除!」→画面真っ白
「この関数はどこからも呼ばれていない。消しちまえ!」→画面フリーズ

そんな日々を送っているそうです。
これは、先月私も体験したこと。

「それ、もしかして・・・日本人以外が作ったプログラムでは?」
「そうだよ、何で分かるの??」

1枚板で、内容が複雑に絡み合ったプログラムは、
昔からザルそば、スパゲティと表現されています。
比較的、天才肌の人や個人で短期集中して仕事するのが好きな人が作った
プログラムに多いです。
そして、日本人でこの手のプログラムを書く「プロ」に会ったことはないのです。

単品で動かすツールやデモ用の
短期利用、使い捨てソフトウェアなら問題ないのですが。
複数で開発するシステムの一部や、
再利用の可能性が高いソースならこれはまずい。
もっとも、最近のオーサリングツールや
UMLのコード自動生成ツールなどはザルそばを生成しないと思いますが。

ところが、日本人の「プロフェッショナル」が作ったソースコードは
まったく別の会社の業務であっても、申し合わせたように
キチンと構造化されています。

まだ歴史の浅いITの世界にも、日本のもの作りの文化は形成されつつあるんですね。