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

1977年、Maurice Howard Halsteadは、ソフトウェアシステムの複雑さの尺度を導入しました。これには、プログラムの語彙、プログラムの長さ、音量、難易度、努力、モジュールの推定バグ数の測定が含まれます。ウィキペディアによると、難易度は、プログラムの読み取りまたは書き込み時のプログラムの理解の難易度に関連しており、努力は、アプリケーションのコーディングに要する時間（時間=（努力/ 18）秒）に変換できます。 データと計算がソフトウェア開発の何らかの側面に関係しない限り、測定は役に立ちません。ただし、特定の値以上の難易度が統計的に有意な欠陥の増加や、難易度とコードの読み取り時間の関係につながる傾向があることを示す作品は見つかりませんでした（Nの難易度は平均M時間を費やしますコードベースを理解する）または品質を決定するのに役立つ事実の後の時間を計算できることの分析（特に書く時間はすでに測定値として記録されているはずなので）特にHalsteadのバグ推定（Wikipediaには記載されていません）に興味があります-アプリケーションのバグの数はVolume / 3000またはEffort ^（2/3）/ 3000で推定できます。 私は2つのことを探しています： 誰もが実際のアプリケーションでHalsteadのソフトウェア複雑度測定を使用してソフトウェア品質を評価しましたか？もしそうなら、どのようにそれらを適用し、有用で、有効で、かつ/または信頼できる測定であることが判明しましたか？ ソフトウェアの品質に適用した場合のHalsteadの複雑さの測定の有効性（または無効性）を検討する調査、分析、またはケーススタディの形式で学術研究はありますか？ ソース行コード（SLOC）を使用してボリューム、難易度、努力、時間、バグのハルステッドメトリックに類似した何かを計算することを実証する調査、分析、またはケーススタディの形式の学術研究はありますか？Volumeは単にSLOCカウントに対応し、Difficultyは循環的複雑度（およびおそらく他の指標）に対応する可能性があると思われます。また、SLOCで努力、生産性、または時間を測定することは、誤解を招く可能性があることをよく知っています。

14 quality  metrics  measurement 

誰かが機能テストのために「コードレビュー」プロセスを実践していますか？便利だと思いますか？私の現在の雇用主がSCRUMを実践している方法では、特定のスプリントの「必須」の一部として機能テストを含めています。

14 scrum  code-reviews  quality 

組織内にコードレビュープロセスを導入しましたが、うまく機能しているようです。しかし、時間の経過とともにプロセスの有効性を測定できるようにしたいと思います。つまり、コードがクリーンであるためにバグを見つけられないのですか、それとも人々がバグを拾っていないのでしょうか。 現在、効果的な完全自動化されたテストプロセスはありません。私たちは主に手動テストを採用しているため、この段階で見つかった欠陥に頼ってコードレビュープロセスが機能していることを確認することはできません。 誰もこの問題に出くわしたことがありますか、コードレビューの測定で何がうまくいくのかについて考えたことはありますか？

14 code-reviews  quality  metrics  measurement 

タイトルはそれをすべて言います。当社の一部の従業員は、自動化されたテストは「簡単」であり、COMおよびUIテストのスイートを作成するには「1日かかる」と考えています。これに対抗するために何ができますか？ 注：自動化を促進する方法については質問していません。それは問題ではありません。ここでは常に自動化されたテストとプロセスが促進され、要求されています。問題は、一部の個人は、自動化が「簡単」でも「高速」でもないことを理解していないことです。

12 project-management  quality  automation 

SLIMとソフトウェアの推定に関する職場でのトレーニングマニュアルからの引用を以下に示します。 また、努力と欠陥の間には相関関係があることに注意してください。つまり、特定のサイズのプロジェクトに割り当てられる人が多いほど、欠陥が多くなります。 労力は、プロジェクトの人時間（人年、人月）です。欠陥は、ライフサイクルの任意の時点で検出された欠陥の数です。サイズは、プロジェクトを構成するユースケース、機能ポイント、またはSLOCとして定義されます。 優れたプロセスと有能なエンジニアを想定すると、これは直感に反するように思われます。たとえば、より多くの人がいるということは、すべての成果物（要件の仕様、設計、コード、テスト）に注目することを意味します。より多くの目を持っていることは別として、私の直感は、適切な品質技術を利用するプロジェクトの努力と欠陥の間にはほとんど関係がないことを示唆しています。 欠陥と労力または欠陥とプロジェクトの人数との間の既知の関係を示唆する、Putnam Model（SLIMで使用される）に関するドキュメントを除いて、ドキュメントを見つけることができませんでした。これは既知の関係であり、「より多くの人=より多くの欠陥」という主張は有効ですか？

12 estimation  quality  metrics  measurement 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 ソフトウェア製品で測定できる品質には、目的への適合性（最終用途など）、保守性、効率など、さまざまな種類があります。これらのいくつかはやや主観的またはドメイン固有です（たとえば、優れたGUI設計原則は文化によって異なる場合や、使用状況に応じて、軍事的使用と消費者使用を考えます）。 私が興味を持っているのは、タイプのネットワーク（またはグラフ）に関連するより深い形式の品質とそれらの相互関係、つまり、各タイプが参照するタイプ、適切に関連する相互接続性の明確に識別可能なクラスターがあることです階層型アーキテクチャ、または逆に、型参照（「モノリシック」コード）の大きな「ボール」があります。また、各タイプおよび/またはメソッドのサイズ（たとえば、Javaバイトコードまたは.Net ILの量で測定）は、より複雑で管理しやすいものに分解される代わりに、大きな複雑なアルゴリズムがコードのモノリシックブロックとして実装されている場所を示す必要がありますチャンク。 このような考えに基づいた分析は、少なくとも品質の代用となる指標を計算できる可能性があります。高品質と低品質の間の正確なしきい値/決定点は主観的であると思われます。たとえば、保守性とは人間のプログラマーによる保守性を意味するため、機能の分解は人間の心の働きと互換性がなければなりません。そのため、考えられるすべてのシナリオで考えられるすべてのソフトウェアを超越する、数学的に純粋なソフトウェア品質の定義があるのではないかと思います。 また、品質の客観的なプロキシが普及すると、ビジネス上のプレッシャーにより、開発者は全体的な品質（プロキシで測定されない品質の側面）を犠牲にしてこれらのメトリックを追求することになるので、これは危険な考えかと思います。 品質に関する別の考え方は、エントロピーの観点からです。エントロピーは、システムが秩序状態から無秩序状態に戻る傾向です。中規模から大規模の実際のソフトウェアプロジェクトに携わったことのある人なら誰でも、コードベースの品質が時間とともに低下する傾向があることを理解するでしょう。一般に、ビジネス上のプレッシャーは、新しい機能に焦点を当てた変更（品質自体がアビオニクスソフトウェアなどの主なセールスポイントである場合を除く）、および回帰の問題と「適合」が合わない「シューホーン」機能性による品質の低下をもたらします品質とメンテナンスの観点。それでは、ソフトウェアのエントロピーを測定できますか？もしそうなら、どのように？

12 quality  metrics  measurement 

コード生成を主張して、コード品質を向上させる方法の例を探しています。コード生成の意味を明確にするために、私のプロジェクトについてのみ説明します。 XMLファイルを使用してデータベーススキーマ内のエンティティの関係を記述するため、エンティティの追加、削除、変更に使用できるORMフレームワークとHTMLフォームの生成に役立ちます。 私の考えでは、人的エラーが減るため、コードの品質が向上します。何かが正しく実装されていない場合、モデル内で破損します。これは、より多くの生成コードが破損するため、エラーがより早く表示される可能性があるためです。 コード品質の定義を求められたので、これを明確にしましょう。つまり、ソフトウェア品質です。 ソフトウェア品質：相互に影響するのは、1つの属性ではなく、効率、変更可能性、読みやすさ、正確さ、堅牢性、理解可能性、使いやすさ、移植性などの多くです。

12 development-process  code-quality  quality 

私の会社（3年前のWeb業界の新興企業）では、製品チームに「これは危機的なパッチになりました！」と頻繁に問題があります。（皆ではありませんか？） これは、自己完結したエンジニアリングスタッフの生産性（および士気）に影響を与えます。経営陣は、これらの同日リクエストの頻度を減らす方法について考えることに時間を費やし、毎週リリースするソリューションを考え出しました。（以前は2週間に1回行っていましたが、通常は数日ほどずれていました。） 13人の開発者と6人のローカル/ 9人のオフショアテスターがいます。理論的には、他の開発者のいずれかから特定の専門知識を実際に必要とする作業が発生しない限り、4人の開発者（およびすべてのテスター）だけが偶数番号のリリースで作業します。各サイクルには、2日間の開発作業と2日間のQA作業が含まれます（さらに1日間のスコーピング/トリアージ/ ...）。 私の質問は： （a）このリリース期間の長さを経験した人はいますか？ （b）このようなリリースサイクルが試みられていることを誰かが聞いたことがありますか？ （c）（a）または（b）の場合、地球上でどのように機能させますか？（避けるべき落とし穴なども歓迎します。） （d）この取り組みが失敗した場合、どのように損害を最小限に抑えることができますか？

12 agile  quality  release-management 

レガシーコードベースを改善するためのツールとテクニックについては多くの情報がありますが、実際に成功したケーススタディはありません。ほとんどのアドバイスはミクロレベルであり、マクロレベルで役立つ証拠が不足しているため、役立つものの、多くの人々を納得させるものではありません。 大規模なレガシーコードベースを更新して今日の品質基準を満たすようにし、完全に書き直すのではなく、実際に成功することが証明されている段階的な改善を具体的に探しています。 前： 大：1MLOCより大きい レガシー：自動テストなし 品質が悪い：複雑度が高く、カップリングが高く、回避された欠陥が多い 後 自動テスト より簡単なアップデート/メンテナンス 高品質：複雑さの軽減、コードの分離、少数の回避された欠陥 大規模なレガシーコードベースを完全に書き換えずに、上記の品質基準を満たすように正常に更新するために、実際にどのような段階的な手順が証明されていますか？ 可能であれば、バックアップの回答に「成功した」品質改善プロセスを経た大規模なレガシープロジェクトの会社または事例の例を含めてください。

10 quality  legacy  large-scale-project 

現在、中規模/大規模のPHP / MySQLプロジェクトに取り組んでいます。私たちはPHPUnitとQUnitでユニットテストを行っており、アプリケーションを手動でテストしている2人のフルタイムテスターがいます。テスト（モック）データは現在、SQLスクリプトで作成されています。 テストデータ用のスクリプトの管理に問題があります。ビジネスロジックはかなり複雑で、テストデータの1つの「単純な」変更によって、アプリケーションにいくつかのバグが発生することがよくあります（実際のバグではなく、無効なデータの産物です）。テーブルの作成と変更は常に行われているため、これはチーム全体にとって大きな負担になっています。 UIを使用して約5分ですべてをアプリケーションに手動で追加できるため、スクリプトでテストデータを維持する意味は本当にわかりません。私たちのPMはこれに同意せず、テストデータで展開できないプロジェクトがあることは悪い習慣だと言います。 テストデータを含むスクリプトのメンテナンスを中止し、テスターがデータなしでアプリケーションをテストできるようにする必要がありますか？ベストプラクティスは何ですか？

10 testing  unit-testing  quality  manual-testing 

静的コード分析とコードレビューの違いを知りたかっただけです。これら2つはそれぞれどのように行われますか？より具体的には、PHPのコードレビュー/静的分析に現在利用できるツールは何ですか？また、あらゆる言語のコードレビューに適したツールについても知りたいです。

9 code-quality  terminology  code-reviews  quality 

議論：リファクタリング作業を含むすべての開発には追跡の問題を伴うべきですか？（この場合、Jira） 共通点：私たちの主な目標は品質です。機能する製品、すべてのリリースは、何よりも重要です。私たちのコードベースは古く、自動テストが欠けています。私たちはこれに取り組んでいますが、それは長期的なプロジェクトであり、暫定的なプロセスが必要です。 ポジション1：リファクタリング作業はJiraで追跡する必要があります。変更と明らかに関係がない場合は、別の問題を提起する必要があります。そうしないと、レビューとテストが省略され、私たちの主な目標にリスクが生じます。PCIコンプライアンス（ビジネスの近い将来の目標）ではこのレベルの追跡が必要であるという議論が行われました。私はそれがどんなレベルの確実性でも真実か偽りであると言う立場にはありません。 ポジション2：コードの品質は非常に重要です。それが良くなればなるほど（ある程度、私たちがどこにも近くないほど）、機能する製品をリリースし続ける可能性が高くなります。どんなに小さくても、リファクタリングの方法で障害となるものはすべて、私たちの主な目標に対するリスクです。多くの場合、IDEが自動的に機能します。そのため、とにかく問題が発生することはほとんどありません。 次のケースが行われました： 開発者がカードに「リファクタリング」と関連するリビジョン番号を書き込んだ場合、それは両方の立場を満たしますか？正直なところ、これは皆を等しく不幸にしてしまうような気がします。それでも、リファクタリングの実行にはある程度の抵抗はありますが、十分な追跡機能はありません。 イテレーションのリファクタリング作業を網羅する、すべてを網羅するJiraの問題についてはどうですか？はい、これにより開発者の抵抗層が削除されますが、Jiraの問題があることによる追跡の利点も削除されると思います。QAは何をテストすべきかを明確に理解する方法を教えてください。これは政治的な解決策のようであり、軽量だが最終的には無意味なプロセスを追加することで誰もが落ち着くようにしています。 議論の双方が最終的に同じことを望んでいることを考えると、誰もが本当に幸せになる解決策があるはずだと私には思えます。私たちはこの質問をする最初の人ではあり得なかったので、同様の状況で他の人はどのような経験をしましたか？

9 refactoring  issue-tracking  quality 

このトピックについて多くを読んだ後--- 検証と検証、ソフトウェアテストと品質保証に関するこのSoftware Testing Fundamentalsサイトなど --- NaikとTripathyによる理論と実践 ---まだわかりません。検証では、製品を適切に構築していることを証明し、検証では、適切な製品を構築していることを証明します。しかし、検証手法として言及されているのは静的手法（コードレビュー、要件チェックなど）だけです。あなたがそれをテストしない場合、それが正しく実装されているかどうかはどのように言えますか？検証は、製品が指定された要件を満たしていることを保証すると言われています。繰り返しになりますが、機能が何らかの形で機能するように指定されている場合、テストすることによってのみ機能すると言えます。 誰か私にこれを説明してもらえますか？

8 testing  quality  validation  verification 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 この質問は同じラインに沿っているこのいずれかが、代わりにコードの品質について話を、私は、ユーザーの視点から、最終製品について話しています。時間と予算が限られていて、まともなソフトウェアから良質のソフトウェアに移行するためのソフトウェアの1つの属性（基本的な要件以外）しか保証できない場合、最も重要だと思うものは何ですか。 バグはできるだけ少ないですか？直感的なインターフェース？役に立つエラーメッセージ？優れた技術サポートとドキュメント？ソフトウェアをユーザーに安っぽく見せたくない場合は、常に何を含める必要がありますか？

8 product-features  quality 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックとなるようにします。 3年前休業。 定義されているが使用されていない関数があるように見えるいくつかのC / C ++コードを見ています。これは、コードをトレースして確認するのにかなり退屈なプロセスです。私はいくつかの調査を行ったが、このタイプの分析を行うことができるツールはたくさんある。 このコードが実際に使用されていないことを確認するための最良のツールまたは代替の方法に関する経験やヒントを誰かと共有できますか？

8 quality  software