第10回 ソースコードのロジックを見える化したい！
「全ソースコードを対象にした個別調査では，時間がいくらあっても足りない」──。昨年，改修に伴う影響分析で，500万ステップに及ぶソースコード（COBOL）の内部仕様を，わずか1カ月，それも1人で見える化した野村総合研究所の藤田由起氏（情報技術本部 生産技術部 副主任テクニカルエンジニア）はこう強調する。藤田氏は「複雑な内部仕様は全体の一部。それを全体の傾向から探り当てることが時間をかけない秘訣」と明かす。 内部仕様の中心は，処理ロジックである。この処理ロジックは，一部の言語を除いて，リバース機能を持つツールを使えば見える化できる。ただし，ソースコードが複雑に絡み合うスパゲッティ状態にあると，リバースしても内容が複雑すぎて解釈できない。その問題を回避するには，スパゲッティ状態のソースコードを，あらかじめ解きほぐす必要がある。 そこで藤田氏は，スパゲッティ状態にあるソースコードの全体傾向を「規
あなたの知らない超高速開発
あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「利用者にすぐに使ってもらえたり早く帰れたりするので、嬉しい」と思うか、「人月で見積もっているので売り上げが減ったりこれまでのマネジメントの方法が変ったりするので、嬉しくない」と思うか。 いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企業が登場している。 記者は今年の1月と2月、日本と韓国で25社以上のユーザー企業を訪ねた。日経コンピュータの3月15日号に掲載した特集「『超高速開発』が日本を救う ～サムスンは既に始めている～」の取材のためだ。その中で、スクラッチ開発と比べて「10倍以上に開発効率が高まった」という声を、いくつも聞くことができた。三井住友海上火災保険や朝日生命保険、東京都足立区役所などである。 これは簡易的なシステ
サーバーの障害対策、サービスに影響させず自動切り替え
図3-1は負荷分散装置を用いた冗長化の概要だ。ポイントは負荷分散装置が持つ仮想IPアドレス。これが同一のサービスを提供するWebサーバー（サーバーA、B、C）を代表するIPアドレスだ。クライアントパソコンは仮想IPアドレスに対し、サーバーへのアクセス要求のフレームを送る。負荷分散装置は受け取ったフレームを、サーバーA～Cのどれかに割り振って処理をさせる。その際にあて先IPアドレスを、仮想IPアドレスからサーバーの実IPアドレスにして送り出す。 では、負荷分散装置は何を判断基準にしてサーバーに処理を振り分けるのか（図3-2上）。処理を振り分けるルールを「負荷分散のアルゴリズム」という。このアルゴリズムはTCPのコネクションなどもかかわるため、ネットワーク管理者は知っておくべきことである。アルゴリズムは三つの手法に大別できる。 (1)「順番に分散」は代表的な手法で、よく使われるのが「ラウンドロ
SWEBOKで学ぶソフトウエア・エンジニアリング
ソフトウエアの開発・保守にかかわる問題が発生したとき，ITエンジニア個人の頑張りだけでは対処しきれないケースが増えている。そこで注目すべきなのが，ソフトウエア・エンジニアリング。開発・保守に必要な知識を，現場で活用することを前提に体系化する取り組みだ。「SWEBOKガイド」などの知識体系を手掛かりに，実証された理論や方法を学んで，現場での問題解決に生かして欲しい。 この講座では，ソフトウエア・エンジニアリングとは何か，そして，SWEBOK（SoftWare Engineering Body Of Knowledge）などが定めているソフトウエア・エンジニアリングの体系を学ぶ。 Part1 ソフトウエア・エンジニアリングとは Part2 ソフトウエア・エンジニアリングの体系
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
第1回 ユーザーと意思疎通が図れない外部設計書は危ない
みなさんは，外部設計書を誰に読んでもらい，理解してもらおうとして思って作成していますか？レビューしてもらう開発プロジェクトのリーダー向けですか，後工程でプログラミングを担当してもらう技術者向けですか，それとも自分のためですか？ もちろん外部設計書は，リーダーも読みますし，プログラミングを担当する技術者も見ます。しかし最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。上の質問に対して，「お客様」と自信を持って回答できることが，今の技術者に求められているのです。 外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。 とはいえこれまでは，「発注者に理解してもらう」という観点での外部設計の体系的なノウハウはほ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
