InfoQ ホームページ ウォーターフォール に関するすべてのコンテンツ
ニュース
RSSフィード-
”2019 State of Testing”調査
"2019 State of Testing"調査は，テスト専門職の発展に関する洞察の提供を目的とする調査である。調査に回答すると，State of Testing 2019レポートの無償コピーを公開時に受け取ることができる。
-
どうアジャイルとアーキテクチャは袂を分かち、最後に友好関係を築いたか
人々はアーキテクチャを定義すること、もしくはソフトウェア設計を行うことの必要性をアジャイル宣言の不正確な解釈のために止めてしまったと、Software Architecture for Developersの著者であるSimon Brown氏は主張した。多くのソフトウェア開発者はプラクティスの十分な工具箱を持っていると思っておらず、ソフトウェア業界にはソフトウェアアーキテクチャに対する十分な共通言語が欠落している。良いアーキテクチャはアジリティを高める。方向性を設定するための強固な基盤を構築するのに必要十分な事前設計が必要である。
-
-
企業のマインドフルネスと状況把握
プロセスから無駄を排除するには、ジャストインタイムで提供できる流れが必要だ。そして、人間の知性によって構築されたプロセスの問題に対処するための、企業でのマインドフルネスや状況把握が必要になる。ますます多くの企業が流通の概念を導入して必要なときに必要なものを開発し、在庫を抱えるのを回避しようとしている。このような企業に必要なのは“自動化”、つまりマインドフルネスと状況把握だ。
-
自動車システムのためのアジャイルテスティング
アジャイルテスティング(Agile Testing)は，自動車システムのソフトウェア開発に応用することができる。アジャイル手法を自動車に適用するには，Automotive SPICE-Vモデルをアジャイルに適用することが必要だ。アジャイルとSPICEを組み合わせた成果として，Xavier Martin氏は，QA&Test 2014カンファレンスでのプレゼンテーションで，"集中的な自動テストとクライアントのデモンストレーションが，よりよい製品を生み出し，顧客満足を向上するのに役立っています"，と述べている。
-
コードの品質のためにアジャイルとウォーターフォールを組み合わせる
2014年のCAST Research on Application Software Health (CRASH)のレポートは、アジャイルとウォーターフォールを混ぜた手法で開発した企業向けソフトウエアはどちらか一方の手法だけで開発されたものよりも強靭で安全であると報告している。InfoQはBill Curtis氏に今回の調査について、また構造的品質要因について、アジャイルとウォーターフォールを混ぜることについて話を聞いた。
-
アジャイルにおける計画作りの死
企業がアジャイルを導入して、自己組織的なチームが生まれ始めると、マネジメントは制御を失ったと感じる可能性がある。アジャイルに移行すると、手続きやレビュー委員会、コンサルテーション委員会などが無駄になってしまう可能性がある。しかし、そのような立場になる人は無駄になってしまうことに気づかない、とMarcel Heijmans氏は言う。再び、制御を取り戻そうとすると、問題はもっと厄介になり、"プランニングの死"へと到る。
-
必要十分な事前設計を行うには
今回この記事で紹介するのは，プロジェクト開始に必要なシステム構造情報を提供し，アーキテクトのビジョンにチームを統一して，想定されるリスクを評価するためには，十分な事前設計を行うべきだ，とするアドバイスだ。
-
ウォーターフォールからアジャイルへの移行によるムダの削減
組織がアジャイルを採用するのは，変化への対処を可能にするためだ。アジャイルは開発チームにとって，顧客ニーズを満足する製品を提供する上で有効な手段であると同時に，必要のない(使用されない)機能を含まない製品を提供する手段でもある。リーンソフトウェア開発は言う：ユーザに価値を提供しないものは，すべてムダとみなされると。ならばウォーターフォールからアジャイルへのソフトウェア開発の移行は，開発組織のムダ削減に役に立つのだろうか？
-
組織にアジャイルを広めるのは挑戦だと調査が示す
「調査結果:あなたの会社はどのくらいアジャイルを取り入れているか?」と題された2011年11月グローバルアジャイルソフトウェアアプリケーション開発オンライン調査の結果を、最近、Forresterが発表した。この調査には、アジャイルを導入した企業がどのように実施しているかという興味深い調査結果が数多く含まれている。
-
-
-
2011年のITプロジェクトの成功の実態
Scott Ambler氏は、氏が毎年行なっているITプロジェクトの成功に関する調査の結果を公開し、プロジェクトの結果に対する方法論の影響を分析した。Ambler氏は5つの異なる"開発パラダイム" - アドホック、イテレーティブ、伝統的方法／ウォーターフォール、アジャイル、リーン - がプロジェクトの結果にどのような影響を与えるのかを考察した。 Ambler氏の成功の定義は、あえて主観的なもの - 結果について顧客がどのように感じたか - を使っている。
-
アジャイルと緊縮財政
西欧各国政府が対GDP比で返済困難な負債に苦しむなか、英国はもっと効率よくリスクのないITプロジェクト納入フレームワークを作るためのイノベーションとアジャイルプラクティスに取り組み始めている。
-
デマルコ、ソフトウエアエンジニアリングの40年間を振り返る
NATOのソフトウエアエンジニアリング会議から40年経ち、トム・デマルコはソフトウエアエンジニアリングの信念の進化において、自身が支持したメトリクス指向の方法論が、"変革を起こすこと。世界を変えるソフトウエアを作ること。"を目的にする現実の開発現場では、本当は邪魔になっていたのではないかと、振り返った。それとも、彼の当初の助言はやはり有効なのだろうか。彼自身は、"有効ではなかった"と、Software Engineering誌の"時代はやって来て、そして過ぎ去ってしまったのか"と題した記事で書いている。