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

私は、クライアントにとって有効で目的に合った製品に取り組んでいます。 LAMPスタック（PHP / Cake）上に構築されているため、GPL、MIT、PHP、APACHEライセンスがあります。 「現状有姿」、いかなる種類の保証または条件もなしに、明示、黙示を問わず、タイトル、非侵害、商品性、または特定目的への適合性の保証または条件を含むがこれらに限定されない。お客様は、作品の使用または再配布の適切性を判断する責任を単独で負い、本ライセンスに基づく許可の行使に関連するリスクを負います。 私の製品は有効であり、目的に合っているという理論的根拠： 署名されたUAT文書は、妥当性と目的への適合性を証明します。 スタックは、開発者、業界、およびエンドユーザー（netcraft、gartnerなどの統計情報）で広く使用されているため、目的に合っているというコンセンサスが得られています。（つまり、保証免責事項の目的適合性ステートメントをある程度無視することができます） これは有効なポイントですか？自分のソフトウェアが目的に合っていると主張できますか？

15 licensing  documentation  specifications 

多くの場合、文字通り何百もの不要な機能を備えたアプリケーションを使用して新しいクライアントが来るという状況に直面しますが、プロジェクトを成功させるには物事を大幅に簡素化する必要があることは明らかです。どのようにして、クライアントに、より多くのMinimum Viable Product（MVP）アプローチを取り、簡素化するよう説得しますか？ 編集： したがって、現在の一番の答えは、クライアントに巨大なアプリケーションの時間/コストの見積もりを提供することです。この状況の本当の問題に対処していないので、私はこの答えがあまり好きではありません。そして、それは大規模なアプリケーションを特定し、それを始めから構築しようとするのは悪い習慣です。最初は小規模でシンプルなMVP基盤を構築する方がはるかに快適です。そして、その基盤に小さな機能を一つずつ追加します。それでは、クライアントにこの方法でソフトウェアを構築する方法を説得するにはどうすればよいですか？

15 client-relations  specifications 

ここで他の質問で書いたように、現在取り組んでいるプロジェクトにはソフトウェアプロセスがありません。意味することに何の（ハードコピー要件や仕様を含む）のドキュメント、無ソースコントロール、無バグデータベース（たぶん）、「固定」されているバグや新しいコードは、同じ時間、および正式なテスターで追加されていない-私たちは失敗するだろうジョエルテストひどく、面白くないです。 昨日、私のマネージャーは、これらの欠点を修正し始める方法についての文書を書くように私に頼みました。ここで6か月間、私は単なるインターンです。私は学校に戻るために11月に感謝祭の周りを離れます。ただし、このプロジェクトを正しい方向に進めることはできると思いますが、どこから始めればよいのかわかりません。私は現在、CiteSeerとWikipediaを使用して、ソフトウェアプロセスを説明し、それらを実装するいくつかの論文を見つけようと試みていますが、アドバイス、個人的な経験、またはブログ、論文、wiki記事などへのリンクは大歓迎です。

13 development-process  specifications 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 仕様の修正を顧客と交渉し、顧客が望んだことではなく、顧客が望んだことを行うように仕様を修正する最適な状況を知っています。それは交渉で、説明しています。 時には、クライアントを納得させることができません。設計どおりに壊れたものを生産せざるを得ません。これは魔術師と悪魔が彼らの願いを文字通りに満たして魔術師の終miseをもたらす魔術師の功績によって「悪魔学」と呼ばれ、顧客が彼らのエラーに気づいたら非常に不満を残す別のアプローチであり、もちろん開発者に責任があります。 今、私は非常に異なるアプローチに直面しました：顧客はいくつかの重要な警告を説明できない単純な仕様を作成し、それらを修正することを完全に嫌がり、明白なエラーを認め、提案された修正を受け入れます。これらの仕様に合わせて作られた製品は非常に壊れており、人命を犠牲にする可能性があります。それでも、契約を完全に解除するには遅すぎます。契約には、そのための罰則条項があり、実際に受け入れることはできません。 上司の決断？私たちは仕様通りにそれを行ったことを正しく行い、顧客に嘘をつきます。問題のアルゴリズムは表面下に十分に隠されているため、製品は問題なく動作し、警告の状況で失敗することはありません。誰かが深く掘り下げない限り、要求どおりに壊れていないことを発見することはありません。 この仕様実行の戦術には、一般的な名前がありますか？

12 design  specifications 

プロトタイピングのさまざまな方法についてのメモがあり、インターネットでいくつかの定義を見つけましたが、学んだことを確認したいと思います。 使い捨てプロトタイピングは仕様の概要から開発され、クライアントがその機能に満足するまでさまざまなプロトタイプが提供および変更されることを理解しています。 一方、進化的なプロトタイプは、エンドユーザーから集められた基本的な要件から構築されます。最初のプロトタイプがユーザーに提示され、評価されます。プロトタイプは、クライアントが満足するまでフィードバックに基づいて修正されます。 これは正しいです？使い捨てと進化的プロトタイピングのより良い定義はありますか？

12 prototyping  specifications 

反復的な開発を理解していないシニアディレクターに問題があります（アジャイルの方がずっと少ないです）。彼は、コードの行が書かれる前に、ソフトウェア設計仕様（SDS）が完全であることを主張します。彼にとって完了とは、すべての機能の詳細がそこにあることを意味します。また、元Cobolプログラマーである彼は、「モジュール」とフローチャートを見たいと考えています。これは大声で叫ぶためのJava Webアプリです！ とにかく、コーディングを開始する前にSDSを100％完全にする必要はないことを示すために、彼を優しく指す簡単な場所を見つけようとしています。助言がありますか？ ありがとう！

12 design  agile  specifications 

私はC＃仕様を読んでいます。セグメントで説明を使用できます： C＃には統一型システムがあります。intやdoubleなどのプリミティブ型を含むすべてのC＃型は、単一のルートオブジェクト型を継承します。したがって、すべてのタイプは一連の共通操作を共有し、任意のタイプの値を一貫した方法で格納、転送、および操作できます。さらに、C＃はユーザー定義の参照型と値型の両方をサポートしているため、オブジェクトの動的な割り当てと軽量構造のインラインストレージが可能です。 この文脈で「軽量構造のインラインストレージ」とはどういう意味ですか？

11 c#  specifications 

今日、同僚の1人と「SVNなどのソース管理システムに仕様書を入れるべきか」について議論しています。私の意見では、そうあるべきです。プロジェクトの開発に関連するすべてのものは、ソース管理システムで慎重に管理する必要があります。ソフトウェア開発プロセスの概念は間違っていますか？

11 version-control  specifications 

開発期間中に仕様を変更してはいけない理由を企画部新入社員に説明したい。

11 requirements  specifications  requirements-management 

自然言語の形式張らない性質のために、曖昧さのない完全なソフトウェア仕様を英語で書くことはおそらく不可能だと私には思えます。したがって、本当に明確な仕様には、正式に指定された言語で書かれたコードを含める必要があります。 これは既知の結果ですか、それとも何か不足していますか？

10 documentation  specifications 

Acceptクライアントからのヘッダーの目的は、サーバーが要求への応答として受け入れるデータの種類を通知することです。このヘッダーは、JavaScriptの非同期HTTP呼び出しで設定できますが、HTMLでは設定できません。 たとえば、のようなリンクを考えてみましょう<a href="https://softwareengineering.stackexchange.com/some/resource">Get as CSV</a>。のような属性accept="text/csv"が許可されていて、ブラウザAccept: text/csvがそのリクエストと共にヘッダーを送信すると解釈した場合、サーバーはリクエストのセマンティクスに応答できます。それがなければ、などのリンクを作成する可能性が<a href="https://softwareengineering.stackexchange.com/some/resource?format=csv">Get as CSV</a>あり、サーバーは代わりに任意のクエリ文字列パラメーターに応答する必要があります。 Acceptマークアップによるヘッダーの設定を許可しないHTML \ DOM仕様の背後にある技術的および歴史的な理由は何ですか？

10 history  http  specifications 

以前は専門のコンサルティング会社で働いていましたが、さまざまな契約条件で働いていました。時間と材料のプロジェクトを取得できたら、SCRUMで実行し、課題追跡システムでバックログを追跡しました。 ただし、ほとんどの場合、固定価格契約の下で納品する必要がありました。これには、契約の付録として仕様書が必要でした。そのため、仕様から作業項目をバッチインポート（さらには手動で入力）することになりました。変更注文は、特にプロジェクトの終わりに向かって、すべてが同期していることを確認するのに長い時間がかかりました。 このプロセス全体をDRYに保つ方法論またはソフトウェアツールはありますか？私はいくつかの検索を行ったが、どうやら正しい用語を使用していない。私の専門ネットワークのほとんどは固定価格の仕事をしていません。 私は次のことを受け入れます： バグトラッカーの切り替えまたはプラグインの購入（現在はFogBugzを使用）。 別の開発方法論に従う 仕様を管理し、バグトラッカーと仕様ドキュメントを更新するソフトウェアを作成する（ただし、これは、疑わしい利益のために多くの作業が必要と思われます） 最後に、これは本当に解決する価値がありますか？一部のプロジェクトではかなりの費用がかかりましたが、他のプロジェクトでは影響はありませんでした。

9 issue-tracking  specifications  methodology 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 ソフトウェアプロジェクトの仕様とドキュメントを作成および管理するためのwikiまたはwikiのようなシステムを探しています。 利用可能なwiki実装がたくさんあることは知っていますが、この種のタスクに特に適しているものはありますか？ 実際、それはwikiである必要はなく、仕様とドキュメントを簡単に記述してナビゲートし、変更の追跡をサポートするシステムにすぎません。

9 specifications  wiki 

2人の開発チームのために、完全な機能仕様を作成します。私たちはプロのテスターはおりませんが、利用可能なヘルプデスク担当者の助けを借りて「QAテスト」を実行するためにドラフトを作成しました。 これまでに、機能の完全なチャンクが機能しない、またはコードが配信されないという仕様に問題があるという問題がありました。 私の質問は次のとおりです。開発者はQAチームに手渡しているコーディングをどの段階で停止する必要がありますか？QAチームに引き渡す前に、仕様に照らしてコードをレビューするよう開発者に依頼するのは多すぎますか？

9 testing  qa  specifications 

仕様なしでソフトウェアを書くことは想像できません。それがどんなに大雑把であろうと高レベルであろうと、スペックはプログラムの機能が何であるかについて無知なプログラマーに説明することが重要です。 しかし、スペックの問題は、ソフトウェア開発サイクル全体でいくらか2番目の市民であることです。開発がスチームを拾うとき、それは無視されます。しかし、論争が発生すると、開発者、テスター、および販売担当者は、彼らの根拠を正当化するための仕様を見つけるために争います。 1つ以上のシナリオが発生します。 仕様を復元できません。仕様がどこにあるか誰にもわかりません 仕様の異なるバージョンは異なるソースから出てきます。どのバージョンが最新バージョンであるか、または利用可能な最新バージョンがあるかどうかを見つけるのは非常に困難です。 仕様は不完全であり、参照するドキュメントの一部が欠落しています。 したがって、スペック管理は重要であり、誰もが単一のスペックのソースしか持っていないことも同様に重要です。 スペックをどのように管理しますか？私は誰もがGoogleドキュメントを使用できるようにしようとしましたが、誰もが反対しました。誰もがあまりにも愛着があり、Microsoft Wordに夢中です。MicrosoftWordは、非常に使いやすく、画像を挿入しやすく、数式を入力するのも簡単です。 MS Wordが共有するのがひどいことを彼らに納得させるには？

9 specifications