SWEBOKで学ぶソフトウエア・エンジニアリング
ソフトウエアの開発・保守にかかわる問題が発生したとき，ITエンジニア個人の頑張りだけでは対処しきれないケースが増えている。そこで注目すべきなのが，ソフトウエア・エンジニアリング。開発・保守に必要な知識を，現場で活用することを前提に体系化する取り組みだ。「SWEBOKガイド」などの知識体系を手掛かりに，実証された理論や方法を学んで，現場での問題解決に生かして欲しい。 この講座では，ソフトウエア・エンジニアリングとは何か，そして，SWEBOK（SoftWare Engineering Body Of Knowledge）などが定めているソフトウエア・エンジニアリングの体系を学ぶ。 Part1 ソフトウエア・エンジニアリングとは Part2 ソフトウエア・エンジニアリングの体系
本当は楽しいIT業界――“重鎮”を超えて − ＠IT
2007/12/26 日本のIT業界は暗い話題に事欠かない。国内にはシステムエンジニアが31万人、プログラマが15万人いる。ユーザー企業のIT技術者やフリーのIT技術者を加えると50万人を超える人が関わっている。専門技術者では建築土木技術者に次いで多いといわれる。情報サービス業界全体の売り上げは16兆7000億円を超える（参考資料PDF）。IT業界が生まれて50年以上たち、それなりの規模に成長してきたわけだ。ただ、IT業界のイメージはここ数年で悪化してしまった。このままでいいと思っているIT業界内の人間は少ないだろう。＠ITが10月末に掲載した記事「IT業界不人気の理由は？現役学生が語るそのネガティブイメージ」が高い注目を集めたのは、IT業界の今後に対する不安が反映された結果だ。 IT業界。簡単に使ってしまっているがこの言葉が指す業界は幅広い。代表的なのはソフトウェア開発業だ。そのソフトウ
要求工学の概要（要求工学：第1回）
概 要 要求工学はソフトウェア開発における要求仕様化プロセスを工学的に定式化する技術として注目を集めている。今年は第12回の要求工学国際会議（International Conference on Requirements Engineering,ICRE）が日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催される[１]。本稿では、要求工学の概要と要求工学の本質的な要素を明らかにするとともに、要求工学の価値について述べる。最後に要求工学の課題を紹介する。 要求工学の必要性 要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている[２]。 開発したソフトウェアが納入され変更することなく使わ
間違いは上流工程にあり
機能を利用者視点でしか考えない、脆弱性対策のガイドラインに頼り切りになる──。セキュリティ設計における多くの間違いが、システムの脆弱性を作り込んでいる。逆に、セキュリティばかり重視して利便性を損なうこともある。 「このセッション管理方式だと、簡単に他人になりすませるのではないか」。電通国際情報サービス（ISID）の石井博之氏（技術統括本部 システム推進センター 基幹アプリ1グループ プロジェクトディレクター）は、あるWebシステムの再構築プロジェクトで、現行システムの機能を調査しているとき、まずいことに気付いた。 そのシステムでは、URLのパラメーターとして使っているユーザーIDだけで、利用者を識別しているようだった（図1）。ユーザーIDは連番で、他人のIDを容易に推測できる。試しにWebブラウザーでURL中のユーザーIDを変更してみると、予想通りの結果を得た。他の利用者になりすまして、利
開発支援ツールとは 「システム開発支援ツール, ソフトウェア開発支援ツール」 かいはつしえんツール： - IT用語辞典バイナリ
開発支援ツール 読み方： かいはつしえんツール 別名： システム開発支援ツール ， ソフトウェア開発支援ツール 【英】 development support tools 開発支援ツールとは、情報システムの開発の一部を自働化、効率化して、開発者の負荷を軽減するためのソフトウェアのことである。 要件定義や設計、開発、テストというシステム開発の流れ（開発プロセス）に沿って、設計ツールやプログラミング支援ツール、テスト支援ツールなど、さまざまな開発支援ツールがある。 また、CASE（Computer Aided Software Engineering）ツールと呼ばれる統合的な開発支援ツールもあり、開発プロセスの複数の段階にまたがって開発を効率化できる。
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
Part1 ソフトウエア・エンジニアリングとは
企業情報システム開発に携わるすべてのITエンジニアが，ぜひ知っておきたいのが「ソフトウエア・エンジニアリング」である。ソフトウエア・エンジニアリングとは，ソフトウエアの開発や保守に関する理論，方法，ノウハウなどを体系化し，仕事の現場で活用できるようにする取り組みだ。Part1では，ソフトウエア・エンジニアリングの定義とともに，その歴史を解説しよう。 銀行のオンライン・システムが停止，不具合の見つかった数十万台の携帯電話をメーカーが回収，航空管制システムの障害で運航がストップ――。ここ数年，ソフトウエアのバグに起因する事件の報道が目立つ。 こうした事件が多発する背景には，ソフトウエアが企業情報システムはもとより，自動車や携帯電話，家電にまで入り込み，今や社会基盤の重要な要素になったことがある。特に企業情報システムは，ソフトウエアの複雑化・巨大化が急速に進行。同時に，品質や納期，コストへの要求
人月計算とExcelとスーツの世界より
俺の住む世界はアイティーとやらに支えられているらしい。 アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。 そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。 昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。 だから自分はシステム会社に向いていると思った。 実際、資格取得を勧められて始めた勉強は楽しかった。 浮動小数点数、オートマトン、SQL、スタック、木、論理式。 パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。 楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。 研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。 現場に出て、本番機に触った。 ３０年間親会社を支え続ける偉大なシステムの中身を、わくわくし
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
ロバストネス - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "ロバストネス" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2023年3月） ロバストネス（英: robustness）とは、ある系が応力や環境の変化といった外乱の影響によって変化することを阻止する内的な仕組み、または性質のこと。頑強性（がんきょうせい）、頑健性（がんけんせい）、堅牢性（けんろうせい）、ロバスト性とも言う。 ロバストネスを持つような設計をロバスト設計、ロバストネスを最適化することをロバスト最適化という。 「頑強な」という意味の形容詞 "robust" が語源であり、他に頑強性、強靭性、堅牢性、強さなどと呼称されることもあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウルシステムズ株式会社
相次ぐシステム障害 ： ITpro
株式会社ディバータ
