アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - stefafafan の fa は3つです
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
ソフトウエア工学と方法論の再建を目指す「SEMAT」の日本コミュニティが活動開始
ソフトウエア工学と方法論の再建を目指す「SEMAT（Software Engineering Method and Theory、シーマット）」の日本におけるコミュニティ「SEMAT Japan Chapter」が2013年4月28日、Webサイトを公開し活動を開始した。早稲田大学グローバルソフトウェアエンジニアリング研究所 所長の鷲崎弘宜氏が代表を務め、チェンジビジョンの平鍋健児氏らがメンバーとして参加している。 SEMATは、UMLの開発で知られるIvar Jacobson氏、オブジェクト指向プログラミング言語Eiffelを開発したBertrand Meyer氏、Object Management Group(OMG)会長のRichard Soley氏らが推進しているソフトウエア工学と開発方法論の再建運動。 SEMATでは、今日のソフトウエア工学は流行に左右され、方法論が乱立、確たる理
ソフトウェア工学は失敗している - きしだのHatena
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
永遠なるソフトウェア工学の諸問題 - 勘と経験と読経
マイケル.A.クスマノの「ソフトウエア企業の競争戦略」という本の中で紹介されている、1968年(!)に発表された「ソフトウェア工学の諸問題に関するNATO報告書」の内容を知って絶望したことについて。 ちなみに、「ソフトウェア工学」という言葉そのものも、ほぼこのあたりが発祥らしい。つまり、これから紹介する諸問題は「ソフトウェア工学」のはじめからあったということ。 たぶん原典はhttp://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDFだけどちゃんと読んではいない。 ソフトウェア工学の諸問題に関するNATO報告書（１９６８年） 顧客と設計者側のシステム要件に対する理解の欠如 見積もり技術の未熟さが原因の、経費および時間に関する大きな予実差異、要件変更に対応する期間延長の不履行、および作業分割の内容が十分に理解されないうちに実施され、
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」（Empirical Software Engineering、実証的ソフトウェア工学）です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は？ マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
モデル駆動エンジニアリングのために汎用言語とDSLを組み合わせる - Johan den Haan - Digital Romanticism
この記事はJohan den Haan氏のブログ記事「http://www.theenterprisearchitect.eu/archive/2008/04/15/combining_general_purpose_lang」を、氏の許可を得て翻訳したものです。（原文公開日：2008年4月15日） モデル駆動エンジニアリングに関する以前の記事で、私はMDEの基本的な原則は「全てがモデルである」ということだと述べた。モデルとその要素にはファーストクラスの地位が与えられている。本質的な違いは、モデルがもはやプログラマのための単なるドキュメントとして使用されるだけではなく、ソフトウェア開発を駆動させるために直接利用できるということだ。モデルは、実装、変換、ソフトウェア成果物の諸相、システムに関する視点などを定義するのに用いられる。この記事で、私はモデルとは何なのか（モデルに関する様々な利用シナ
CMMIって何だろう
CMMI(Capability Maturity Model Integration，能力成熟度モデル統合)は，能力成熟度モデルの一つであり，システム開発を行う組織がプロセス改善を行うためのガイドラインです。この講座では，CMMIの歴史や概要，CMMIを利用したプロセス改善のポイントなどを解説します。 CMMI(Capability Maturity Model Integration，能力成熟度モデル統合)は，能力成熟度モデルの一つであり，システム開発を行う組織がプロセス改善を行うためのガイドラインとなるものです。米国国防総省（Department of Defense）が米国カーネギーメロン大学(CMU)に設置した，ソフトウェア工学研究所(SEI)で考案されました。CMMIでは，組織の製品，サービスの開発，調達能力などを5または6段階のレベルで評価します（後述する「段階表現」では5段階
Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。：An Agile Way：オルタナティブ・ブログ
先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。 slideshare で見る PDFをダウンロード 原文を見る ヨードン博士の動機は、 不況時代に突入し、今後デスマーチが一気に増えるであろう。でも、ソフトウェア工学の大切な考え方は、そんなに昔から変わっていないんだ。新しい世代は、すごいよ、学生はみんなIMで会話して、Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。ここで１０個上げて、フリー文書にしておくので、共有
ソフトウェア工学というバズワード - プログラマーの脳みそ
ソフトウェア工学というのはなかなか曖昧なもので、wikipediaのソフトウェア工学の項が、いの一番に「分野の曖昧性と論争」という章から始まっているあたりなんか象徴的だと思う。 大雑把には「コンピュータのソフトウェアの開発方法を研究対象とする情報工学の一分野」となるようだけど、構造化プログラミングとかの技法から、今では開発者の憎悪を一身に受けている感のあるウォーターフォール・モデルまで幅広いジャンルに及ぶ。 ニュートン力学が相対性理論や量子力学の範疇の事項を説明できないからといって、力学なんて間違いだらけで使い物にならないとか言う人はいない。それは物理の発展の歴史の一歩だし、不足分を補う理論が出てきて矛盾点をどんどん解消してきたわけだ。 具体的な例もあげずに「従来のソフトウェア工学なんて間違いだらけ」とかdisってるのを見ると、それって単なるルサンチマンなんじゃないのと言いたくもなる。過去
ソフトウェア工学とか - プログラマーの脳みそ
流れに乗り損ねたけども。 ソフトウェア工学は単一の方向を向いているものではない。というか、多様なジャンルがあるなかで「属人性を排除して開発者の能力を均一化しようとしている」なんて統一の目的感があるわけがない。 より高度なソフトウェア製品を作るには、ソフトウェア工学の成果を持って当たることになる。データマイニングの技術は属人性の排除か？まったくそんなことはない。ひとまとめに「ソフトウェア工学」と言ってしまうのはあまり本質的ではないと思う。 SI業務のふたつの仕事 さて、ソフトウェア工学のなかでも話のターゲットになっているであろうオブジェクト指向技術だとかの話。近年広く普及したオブジェクト指向だとかは、僕は高度技術を振るう作業と単純作業の間を分かつモノとして働いていると分析している。*1そして、単純作業をするのには特別の才能を必要とせず、SI業務はこうした頭数でこなされる部分が多い。ボリューム
従来のソフトウェアエンジニア人事工学が決定的に間違っている点 : 404 Blog Not Found
2009年02月06日05:30 カテゴリArt 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 ここまでは、誰もが同意するだろう。 従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 にも関わらず、 ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。 とならないのはなぜか。
従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記
従来のソフトウェア工学は、属人性を排除して開発者の能力を均一化しようとしている。この点に置いて、従来のソフトウェア工学は決定的に間違っている。 ソフトウェア開発では、個人の生産性は上と下とで 30 倍違うと言われる。これが本当だと仮定したら、これだけ差がでるものを均一化なんてできるわけない (したところで間違った結論しかでない) んだから、属人性を排除することは大きな誤りである。 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 よく、ソフトウェア開発を工場での作業に例える人がいるけど、これも「属人性を排除できる」という勘違いからもた
アラン・ケイ - 「ソフトウェア工学」は矛盾語法か？ [邦訳]
アラン・ケイ Is “Software Engineering” an Oxymoron? By Alan Kay (訳注: 以下の文章は、http://d.hatena.ne.jp/sumim/20080806/p1 に紹介されていたアラン・ケイの文章 -- Is “Software Engineering” an Oxymoron? -- を訳したものです。原文もsumim さんのサイトからダウンロードしました。最初に書かれたのは 1999年から2000年ごろと少し古いので注意してください。日本語で矛盾語法(oxymoron)とは聞き慣れない言葉ですが、ジーニアス英和大辞典によると an open secret (公然の秘密) や、living death (生き地獄) のような矛盾する二つの単語を組み合わせた熟語の事を言うらしいです。) 真のソフトウェア工学はまだ未来のものだ。一年と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
