雇用主の声に耳を傾け、CASEツールを使用する必要がありますか？

私の雇用主（開発者ではない）は、CASEツールが開発プロセスとドキュメントの改善に役立つと考えています。それについては定かではありませんが、私たちはローカルクライアント向けのモバイルバンキングソリューションを構築する5人の開発者から成る小さなチームです。CASEツールは購入する必要があるため時間とお金の無駄になり、慣れるまで時間がかかり、モデリングや作業のために効率的に作業する必要があると思います。コード生成は別の問題です。CASEで生成されたコードは、優秀な開発者が作成したコードほど優れていないと思います。

アジャイルの原則を守り、パターンを設計し、TDDを使用し、コードをクリーンに保つと思います。私たちは良いはずです。そして、分析と設計に関しては、ホワイトボード上の単純なUMLダイアグラムがトリックを行うはずだと思います。ドキュメントは適切で重要ですが、できる限り少なくする必要があります。ドキュメントに集中してコードを忘れてはなりません。これは私が思うことです。

私は正しいですか？または、雇用主の声に耳を傾け、適切なCASEツールの調査を開始する必要がありますか？

状況は、決定に対する分析的アプローチを保証します。結論は、「CASEツールはビジネスに価値を提供しますか？」です。多くの場合、管理者は、組織の現在のプロセスや文化にどれだけうまく適合しているかに関係なく、開発者が方法論やツールについて良いことを聞いているため、開発者にそれを採用することを望みます。

ChrisFが指摘しているように、雇用主からCASEツールの調査を依頼された場合は、義務を負う必要があります（これはプログラミングではなく職場の問題です）。CASEツールの採用に影響するいくつかの要因には次のものがあります。

• どのプロセスでCASEツールが利用可能か、
• 新しいツールを採用するために必要な人時間の推定、
• 新しいツールの採用によりプロセスはどのように変わりますか？
• または、新しいツールを採用することでどのようなプラス（またはマイナス）の影響を測定できるか

これは、開発環境とプロセスをアップグレードする機会と考えてください。現在のプロセスは組織の文化に完全に一致している可能性がありますが、適切な調査を行うのは雇用主とチームの義務です。

はい、CASEツールの調査を開始する必要があります。

1. 助けにはならないという主張を裏付ける証拠が必要だからです。あなたは決して知らない、あなたは彼らが助けることを見つけるかもしれない。
2. 雇用主があなたに言ったからです。

David Kaczynskiが優れた答えで示したポイントは、あなたが従うべきステップであるため、繰り返しません。

実際、コード生成を伴うアジャイルからCASE / MDA指向の開発への大きなパラダイムシフトのようです。プロジェクト管理の観点からは必ずしもそうではありません（CASEアプローチは、反復、ユーザーストーリー、迅速なフィードバック、継続的な改善の概念と競合しません）。生成され、生成されたコードは、おそらく読みにくく、厳密で、テストが難しく、モデルと常に同期する必要があります。

あなたの説明から、あなたの雇用主が必要とするものは容易に理解できます：

• 開発者がチームを去る場合に知識の損失を避けるためのより良いドキュメント。
• より速い開発プロセス。

ソフトウェアの専門家として、CASEアプローチがこれらの期待に応えることができるかどうかについての疑念について、彼に間違いなく伝えることができます（またそうすべきです）。また、CASEツールが必要な場合は、CASEツールの検討を開始することも義務です。そのうちの1つを試しても、結果が満足できることを意味するわけではありません（特に、開発を高速化する必要性と競合する潜在的に大きなコード生成のオーバーヘッドについて考えています）。既存のアジャイルコンテキストを維持しながら、CASEツールの一部の機能（図、ドキュメント生成）を使用する妥協案を見つけます。

アジャイル環境でのCASEツールとその利点/欠点に関する興味深い記事は次のとおりです：http : //www.agilemodeling.com/essays/simpleTools.htm

私の雇用主（開発者ではない）は、CASEツールが開発プロセスとドキュメントの改善に役立つと考えています。」

私があなたの雇用主のコンサルタントとして行動しようとするなら、私は彼らをこの種のものから思いとどまらせることを試みる義務があります。まず、仕事に関係のない人々が開発者向けのツールを選択することは、大きな管理エラーです。これはほとんどうまくいきません。選択をする人々が強力な技術的背景を持っていないとき、それは少なくとも2倍悪いです。そして、彼らがプッシュしているツールの経験がない場合、これは完全に大失敗になりそうです。

この種のことが非技術的な管理によって提案されている最も可能性の高い理由は、誰かが何かを売ろうとしているからです。これらの種類のものを販売している大手企業の1つは、希薄な空気の中の鉛ツェッペリンのように落ち込んでいる収入を持っています。他のことに移動していない営業担当者（別名、再販業者、コンサルタント）は、新しいマークを見つけようとしているのか、顧客を探しているのです。これらの企業が苦労している主な理由の1つは、これらの種類のツールに対する需要がなくなっていることです。「これらの種類のツール」とは、「コードの記述を排除する」ことを約束するツールを意味します。言語に応じて、コードに問題はありません。記述されたコードには、これらのツールが提供するものよりもはるかに強力な抽象化があります。

これが開発を管理する上でこのように貧弱な方法である主な理由の1つは、チームのスタッフに引き込むために利用できる人材のプールを大幅に減らすことです。1つは、これらの一般的でないツールを学ぶ必要があり、2つ目は、経験豊富な開発者のほとんどがこれらのツールを使用したくないことです。多くの場合、これらの種類のツールに関するピッチは、これらのツールがほとんどの面倒な作業を行うため、優秀な開発者を本当に必要としないということです。これは完全に間違っています。それは逆です。彼らは些細なことをすべて行い、多くの場合、重要な部分をより難しくします。また、コードを記述する必要性を完全に排除することもありません。

特にCASEツールを使用して、これらのパッケージを所有する3つの異なる場所で働いてきました。ひとつひとつ、次のようになりました：

1. モデルは、ツールで入念に設計されました。それは通常よりもはるかに長くかかり、作業の非常に遅いまで使用可能な成果物は作成されませんでした。
2. モデルにはビジネスロジックを追加する必要がありました。モデルは間違っていて、プロジェクトの後半の段階で手作業で微調整する必要がありました。
3. モデルとコードの再同期は非常にコストがかかるため、CASEツールは棚上げされ、二度と使用できなくなりました。

一言で言えば、それはそれぞれのケースで100％の失敗とお金の無駄でした。他の組織でCASEツールを使用した他の人と話をしたとき、話はいつも同じです。私はこれらのツールのすべてを使用したわけではなく、一部の人々がそれらをうまく利用した可能性がありますが、それらを使用したほとんどのチームはずっと前にそれらの使用を停止しました。

CASEツールの調査/実装から得られる利点の1つは、将来の雇用のために、より市場性の高いスキルセットを取得できることです。あなたの懸念の多くは注目に値すると思いますが、David Kaczynskiが指摘したように、これは雇用主と従業員の関係の質問であるので、プログラミングの質問ではありません。CASEツールのもう1つの利点は、一度習得すると、より複雑なプロジェクトを幅広く取り扱えるようになることです。雇用主が取得しようとしている契約が必要であるか、CASEツールの使用を優先している可能性があります。

あなたは問題と解決策を混ぜており、あなたの上司は多かれ少なかれ成功して助けようとしています。上司に挑戦するには、組織での自分の役割を明確にする必要があります。彼がCEOであり、あなたがCTOである場合、決定はあなた次第であり、CEOは文書の欠如によってどのビジネス側面が影響を受けるかを指摘するだけです。その場合、CASEツールまたは他のソリューションを使用して、ビジネス上の問題を解決することがお客様の義務となります。

CASEツールの使用に関する具体的な提案については、チームに余分な作業を与えずに目標を達成できるように、適切に選択する必要があると思います。ドキュメントを改善したい場合は、グラフィカルなダイアグラムからコードを生成する必要はなく、コードからダイアグラムを生成できるツールで十分です。そのようなツールの例はCodelogicです。数年前、私たちのデザインがきれいでわかりやすく、非常に使いやすいことを確認するために使用しました。お金を表明する際に別の懸念がある場合は、おそらくオープンソースを調べることができます（ここでは仕方がありませんが、研究の結果に興味があります）。

CASEツールの代替も役立ちます。サイクロマティックまたはその他の複雑さの尺度のようなものを測定することで、設計を適切に構造化し、開発者がコードに集中できるようにします。Javacodeのようなコードに対するコメントの改善も、ドキュメントの改善に役立ちます。

正直なところ、CASEツールは上司がそれを知る必要があるのに役立たないと考えているなら、私は思う。彼が上司であれば、あなたの意見を大切にします。私は、批判的な分析なしに彼が言われたことをするだけの従業員が好きではありませんでした。しかし、もちろん、デビッドが示唆しているように、議論は強力で客観的な議論に基づいて行われるべきです。

私はあなたの雇用主に、彼/彼女が物事を後戻りさせたことに気付かせようとします。ソフトウェアチームに投資の余地がある場合は、ボトルネックや品質の問題を特定する必要があります。IFそれはあなたがドキュメントや開発プロセス分野の改善のための最も部屋を持っていることが判明し、あなたはこれらの分野の改善に関しての最大のROIを持って変更内容を識別すべきです。それはCASEツールの使用を開始していることが判明する場合もあれば、そうでない場合もあります。

あなたの上司を助け、自分を助けてください

このリクエストに対応するか、行動することができます。

「富士山を移動」の質問をすべて覚えていますか？あなたが本当に望んでいる仕事の面接にいたら、あなたは質問がどれほど愚かであるかをインタビュアーに伝えることはせず、質問をし続け、それを解決するためのあなたの最高のアイデアを表明し続けるでしょう。一部の文化では、実際に富士山を移動するように頼んだ上司にノーと言うことはありませんが、あなたが両方の顔を救う方法を見つけるでしょう。

質問の再構成

質問を次のように再構成する場合、

「ソフトウェアに関連する生産性の低いタスクを可能な限り自動化する一連のツールを購入または入手できますか？」

この割り当ては、はるかに口当たりが良くなります。CASEへの明確なトレーサビリティを備えたオプションと、1つまたは2つのアジャイル/オープンソース/クラウドベースのオプションを上司に提供することで、上司（および自分）を支援します。

ケース再訪

90年代には、CASEツールは、Requisite Pro、Rational Rose、Clear Case、Rational Robot（テストランナー）、Purify、Pure Coverage、Quantify、およびその他のいくつかのツールを含むRationalのツールスイートの形をとることがありました。一緒に統合されました。MADショップ（Medical、Avionics、Defense）である場合、これらのツールの更新バージョンを使用して、これらの市場の顧客が必要とすることがある広範囲で追跡可能なドキュメントとアーティファクトを作成できます。

IBMに連絡して、セールスマンに連絡して、5つのライセンス（または1つのフローティングライセンス）の見積もりを依頼してください。トレーニングも追加してください。この見積もりを上司と共有すると、CASEツールに関する話が終わるかもしれません。しかし、誤解しないでください。Rational、彼らの主任科学者、および彼らの製品は好きですが、私が働いた会社にとって価格が高すぎるため、主に大学のサイトライセンスを通じてそれらにアクセスしました。少なくとも私の経験からあなたが承認されれば、彼らは良いサポートと質の高いトレーニングであなたの権利を扱います（通常は最高の食事を提供するトップリゾートで）。

販売用ツール

あなたはまだツールの買い物に行く絶好の機会を持っています。アジャイル開発者にもツールが必要です。オンラインストーリーカード、ユースケース、ユースケース、その他のUMLダイアグラムタイプのドキュメントサポートを提供するスイートを購入できます。Atlassianには、タスクとバグの追跡用のJira、アジャイルプロジェクト管理と呼ばれるもののGreen Hopper、イントラネットWiki用のConfluence、オンラインコードレビュー用のCrucible、継続的統合サーバー用のBambooという素晴らしいツールスイートがあります。あなたがアジャイルである場合、これらとあなたのニーズにターゲットを絞った他のツールスイートのサービスとしてのソフトウェアライセンスがあります。

IDEインテグレーションは、2012年のCASEと同等になるもう1つの手段です。Microsoft開発会社の場合、Visual Team Studioには、Rationalが作成したものと同様の範囲のツールがあります。いくつかのラウンドトリップソフトウェアエンジニアリング、クラスからの単体テストスタブの生成、ソース管理システムとの統合、およびチームコラボレーションのための多数のツールがあります。

オープンソースツール

オープンソース側では、Eclipseとその多くのプラグインは、多くのオープンソースツールを統合しようとします。Eclipse Modeling Frameworkが成熟しているかどうか、または効果的な往復ソフトウェアエンジニアを提供する他のツールがあるかどうかはわかりませんが、前回見てみると、簡単に達成できるとは思えませんでした。Qt Creator環境はソース管理と統合されており、エディターでの変更のコードカバレッジからのスポットチェックを支援するいくつかの機能を備えています。

反復的な増分ツールの採用

ツールの選択に対する反復/増分アプローチも非常に効果的です。多くの場合、オープンソースプロジェクトは単一または複数の環境をサポートしています。ツールの選択は、使用するスタックの影響を受ける場合があります。開発を完全に停止する良い時期は決してないので、四半期ごとにいくつかの小さなツールでチームを追加してトレーニングすることは、すべてを一度に変更するビッグバンアプローチよりも良いかもしれません。

クラウドツールソリューション

リストされているソリューションの多くは、サーバーと比較的複雑なセットアップを必要とする場合があります。クラウドベースであり、月額料金でプロバイダーがホストするサービスとしてソフトウェアを提供する多くのオプションが市場に出回っています。これは、短期的または長期的にあなたのチームにとって意味があるかもしれません。すぐに使用できるホスト型ソリューションがあり、後でライセンスを購入するオプションもあります。

これらの提案はどれも、すぐに生産性を向上させるための安価で簡単な方法ではありませんが、試してみると、いくつかのツールが不可欠であると感じる場合があります。

ここでの優れた答えに加えたいことの1つは、「開発プロセスを改善する」方法を理解することでメリットが得られることです。

過去20年間の圧倒的なトレンドは、市場投入までの時間のソフトウェア開発を最適化することでした。「アジャイル」、「リーン」、DevOps、TDD、BDD-これらはすべて、可能な限り迅速に高品質のソフトウェアを公開することです。

CASEツールは、市場投入までの時間ではありません。これらはトレーサビリティ、設計の一貫性、モデルの完全性などに焦点を当てています。これらはすべて、特に銀行システムで価値のある側面ですが、市場投入までの時間を犠牲にします。

ですから、上司に最適化しようとしているものを正確に聞いてください。

経験から、CASEツールでの作業はコードでの作業よりも急速に難しくなります。特に、平均的に複雑な問題領域で作業する場合はそうです。このプロジェクトは、「銀行」プロジェクトではなくなり、代わりに「CASE-tool-hereの挿入名」プロジェクトになります。