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

無駄のないソフトウェア開発とISO 9001の対象となる慣行との関係を扱った学術論文はほとんどありません。ほとんどの記事は、これらのアプローチの相違は大きいと述べていますが、アプローチします。 学問的にはとても美しいですが、実際にはとにかくですか？ 質問は次のとおりです。ISO9001としてアジャイルの両方を適用している会社で働いていますか、または働いていましたか？あなたの認識は何ですか？本当に良いものと不適切なものは何ですか？

28 agile  lean  iso 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私がよく遭遇することの1つは、ISO標準に準拠していないプログラムによって引き起こされる問題です。 1つの例は、ISO国テーブルを使用せず、独自の短縮形を作成することです。これは、米国（米国）またはオランダ（NL）には問題ありませんが、英国（GBではなく英国）またはスペインには見事に間違っています。 （ESではなく、SP）および他の多くの国。 別の例として、内部日付表記。なぜ誰もが日付を2014年1月2日として保存するのでしょうか？それが2月1日であるか1月2日であるかは完全に不明ですが、ISO標準を使用する場合は2014-02-01 *のみを保存し、2月1日であることは明白です。 私の質問：ISO規格が利用可能な場合、プログラマーはいつ、なぜ独自の構成を作成する必要がありますか？ * 2014-02-01を保存し、エンドユーザーに表示するときに日付を適宜フォーマットします。

18 standards  iso  interoperability 

私はeXtremeプログラミングチームで働いており、Windows環境で7年以上ペアプログラミングを行っています。私たちが最初にそれを始めたとき、誰かがWindowsの資格情報でログインするため、ドメインリソースへのすべてのアクセス、より具体的にはバージョン管理はそのWindowsユーザーに説明責任があります。最終的に、特定のペアリングステーション（ペアA、ペアB、ペアCなど）のWindowsペアリングアカウントを持つように進化しました。すべての開発者は、これらのアカウントのパスワードを知っています。コミット（チェックイン）の説明責任は、コミット中にプログラマーのイニシャルをコメントに入れることで実現されます。 これまではこれでうまくいきましたが、私の会社は現在ISO 27001監査を受けており、監査人によってリスクとしてフラグが立てられています。ペアの組み合わせごとにペアリングアカウントを作成するなど、可能な解決策がいくつかありますが、この問題に他の誰かが遭遇したかどうか、どのように解決したかを知りたいのですが。 審査員はどのような解決策を受け入れましたか？

16 pair-programming  iso 

ISO / ANSIがC ++をバイナリレベルで標準化していないのはなぜですか？C ++には多くの移植性の問題がありますが、これはバイナリレベルでの標準化の欠如によるものです。 Don Boxが書いています（彼の本Essential COMの章COM As A Better C ++から引用） C ++と移植性 C ++クラスをDLLとして配布することを決定すると、C ++ の基本的な弱点の 1つ、つまりバイナリレベルでの標準化の欠如に直面します。ISO / ANSI C ++ドラフトワーキングペーパーは、どのプログラムをコンパイルし、それらを実行することのセマンティック効果をコード化しようとしますが、C ++のバイナリランタイムモデルの標準化は試みません。この問題が初めて明らかになるのは、クライアントがFastString DLLのビルドに使用した環境以外の C ++開発環境からFastString DLLのインポートライブラリにリンクしようとしたときです。 このようなバイナリ標準化の欠如により多くの利点または損失がありますか？

14 c++  dll  ansi  iso 

現在、「ソフトウェア開発」の研究のために卒業に取り組んでおり、外部企業で複雑なソフトウェアを個別に開発する必要があります。これはすべて、構造化された方法で行われ、対応するすべてのドキュメントを作成する必要があります。 このプロジェクトでは、IEEE要件文書（ソフトウェア要件文書（SRS）、ソフトウェアアーキテクチャ文書（SAD）、ソフトウェア設計文書（SDD））を使用することにしました。別の方法で学校で教えられましたが、このプロジェクトでは、開発前に（代わりに）開発後にSDDを作成することにしました。私の推論は： 私がインターンシップを行っている会社は、実験的な方法で、特定の要件を満たす複雑なソフトウェアを作成するよう指示をくれました。プロジェクトの定義で彼らが私に与えた自由の量のために、事前にほとんど何も確実ではなく、開発プロセスの実験中に最もよく遭遇することができます。さらに、私はソフトウェアを個別に作成していますが、このソフトウェア設計を事前に行うことは、社内の他の誰にとってもメリットがありません。プロジェクトの不確実性により、事前に作成したデザインを大幅に変更する必要があることを確信できるため、事前にそれを行うと、後で変更するのにかなりの時間がかかります。これは逆効果だと感じています。 これは、開発後にSDDを作成する正当な理由ですか？そうでない場合、そのための正当な理由はありますか？ 編集：SDDを後で作成する理由は、将来の開発者がプロ​​ジェクトを継続するためです。私は卒業期間中にプロジェクト全体を終了することはできませんので、他の開発者は現在のコードベースを継続する必要があります。

11 design  documentation  software  iso