タグ付けされた質問 「rad」

3
アジャイルはRADのバリアントですか?
ウィキペディアによると、アジャイルは「RAD」の一種であり、これは間違っていると思います。私が知っていることから、アジャイルはRAD自体が90年代に成功しなかったために開発されました(変更にはあまりにも厳格です)。それとも私は間違っていますか? (備考:どうやらアジャイルソフトウェア開発に関するWikipediaの記事は、間に改善されたが、それだけで一覧表示されますRADをないスーパーセットとして、アジャイルの前身として)。 本Radical Project Management(Thomsett)からの参照 「..RAD、アジャイル、オブジェクト指向などの新しい開発の流行...」 CISA認定情報システム監査員: ..2 つの代替ソフトウェア開発を認識しています。メソッド:アジャイルで迅速なアプリケーション開発 ソフトウェアのアジャイル管理: アジャイルメソッドは、主にRADの軽量アプローチから派生しています。 ソフトウェア推定のベストプラクティス: swの主な方法。開発者 次のように要約できます 。1.ウォーターフォール.. 4. RAD 5.アジャイル この質問のポイントは次のとおり です。アジャイル型はRADですか、それともスタンドアロン開発アプローチですか?

5
RAD環境でリリース品質を改善する簡単な方法
ここに少しの背景があります-私たちは、大規模な非ソフトウェア会社の内部ソフトウェア開発を担当するRAD開発者の小さなチーム(5人)です。「内部ソフトウェア」は、MSSQLサーバーをバックエンドとして使用するデスクトップ.N​​ETアプリケーションと、バックグラウンドで実行されるPythonスクリプトからMS Word文書やテンプレートに至るまでさまざまです-技術の動物園。 チーム全体は、ユーザーから要件を取得し、コードを作成し、テストし、運用環境に展開できるすべてのアロンダで構成されています。本番環境のソフトウェアは、別のチームによって管理されていますが、通常、何か問題が発生した場合は簡単に介入できます。 これまでのところはすべて良さそうですが、問題があります-RADチームであるため、頻繁にリリースする必要があり、1つまたは2つのアプリケーションの新しいバージョンをリリースせずに1日を過ごすことはできません(または、スクリプト、更新されたWordドキュメント、C ++コンソールアプリなど)を本番環境に追加します。開発テストを行い、エンドユーザーがUAT環境でソフトウェアを実行できるようにすることで、エンドユーザーも関与させます... ...しかし、バグはとにかく生産に忍び込んでいます。ユーザーはこれらのバグと時折の不安定性が本当に欲しいものをすぐに手に入れるために支払う価格であることを理解していますが、同時に考えさせられました-おそらく開発やリリースのプラクティスを改善して安定性を改善できるかもしれません新しい機能を追加するときに導入するバグの数を減らします。 良いこと-そもそもプロセスがあまりないので、改善を開始しやすいはずです。悪いこと-実装する時間とリソースがあまりない小さなRADチームであること大きなことですが、次のイニシアチブについて検討しており、フィードバック、ヒント、ヒント、提案を歓迎します。 現在、一部のアプリケーションは、ユーザー受け入れテストをバイパスして、開発者テストの直後に本番環境にリリースされています。その慣行は中止されるべきであり、小さな変更でさえエンドユーザーがテストする必要があります。各アプリケーションには、エンドユーザーから選択された専用のベータテスターがあります。ベータテスターが新しいリリースを承認した場合のみ、テストから実稼働環境に昇格されます。 コードレビューは実施しませんが、変更セットをチェックインする前にコードレビューを開始します。また、「ロールアウトレビュー」についても考えていました。基本的に、開発者の1人がソフトウェアロールアウト(バイナリのコピー、設定の更新、データベースへの新しいテーブルの追加など)を行う他のウォッチと一緒に隣に座っている必要があります-通常は5〜10分かかるため、「ロールアウトレビュー」の時間はあまりかかりません。 新しいリリースが、本番環境から撤退し、適切な以前のバージョンに置き換えられるほどバグが多いことが証明されている場合に、ロールバック時間を短縮する方法。すべてのリリースの履歴を(バイナリとして)保存して、1つのバージョンに簡単に戻せるようにします。また、「新しくリリースされたバイナリを以前のバージョンのバイナリで上書きする」のは簡単ですが、エラーが発生しやすい手動プロセスです。また、「ロールバックが失敗し、システムがバグの代わりに使用不能になる場合はどうするか」を時々要求します。 ここでアイデアを使い果たしました。これらについてのフィードバックを受け取りたいと思います。簡単なリリース/開発プロセスの改善アドバイスを共有できれば、それは素晴らしいことです。

3
「早期リリースが頻繁にリリースされる」環境での単体テストの関連性は何ですか?
過去1年ほどの間、私はチームをリリース-アーリー-リリース-頻繁な開発モード(別名:アジャイルではなく迅速なアプリケーション開発)に向けました。ビルドを閉じる方法の詳細については、こちらの回答を参照してください 。RAD環境でのリリース品質を向上させる簡単な方法 私たちがRADを採用したとき、人々は非常に独立していて、最初にユニットテストを行っていました。統合テストはプロセスのかなり後の方で行われました。それは、正式な強制をあまり行わなかった彼らにとって自然なプロセスでした。今の状況はかなり異なります: プラットフォーム全体は、ホットスポットがなく、クライアント側で機能する確立されたビルド/リリースとうまく統合されています。 新しい機能の要件は今後も続き、必要に応じて段階的に構築していきます。 独立した開発グループがプロセスを正しくフォローしている一方で、複雑で自明ではない状況が原因で重大な障害が発生しているため、システムの全体的なダイナミクスは非常に重要です。 システムの多くの部分には新しいアルゴリズムと研究入力が含まれるため、明確に定義されたソフトウェアでの機能テストのように、課題(およびテストのメカニズム)が常に正しく予測されるとは限りません。 最近、プロセスの改善が必要かどうかを確認するために、全体像をよりよく把握することを試みていました。チームと一緒に座ったとき、彼らの多くは「私たちはもうユニットテストをしません!」他の人たちは、効果がなくなるので今すぐ始めるべきではないと考えました。 単体テストは比較的成熟したシステムで役立ちますか?ユニットの成熟度に応じて、少なくともテストスコープの重量を量る必要がありますか?単体テストは開発のペースを遅くしますか?単体テストを別の方法で評価する必要はありますか? リリース早期リリースの環境で成熟したプラットフォームをテストするためのベストプラクティスは何ですか?
10 unit-testing  rad 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.