GOSサイトでのGOSTについて
今日、彼のブログでセルゲイ・ナザロクは、政府機関のウェブサイトが開発されるべきであるという標準からの抜粋を発表しました 。 興味深いドキュメント。
すぐに、 Habréで議論の波が起こりました。 そこでは、とりわけ、スクープの復活についての声明があります。 このドキュメントは非常に必要で便利だと思います。
なぜ標準が必要なのですか？ いくつかの決定を下すときに考えることを少なくします。 同時に、標準で蓄積および収集された知識を通じて、これらのソリューションの品質を向上させます。 例を挙げましょう。 80年代、米軍はソフトウェアの開発と供給のベンダーを選択する手順に困惑していました。 請負業者の選び方 ランダムに働く人々から確実に働く人々を分離するために、企業のいくつかの指標レベルを導入する必要がありました。 理想的には、このインジケーターは1、2、3、4、5の1つの数字のみです。レベル5の会社はレベル3の会社よりも優れているため、レベル5の会社と協力します。 そこで、 CMMI （Capability Maturity Model Integration）標準が登場しました。 EPAMには4つ目のレベル（5つのうち）があるため、市場では2つ目または3つ目のレベルよりも魅力的に見えます。
どういうわけか、政府機関向けのインターネットプロジェクトの開発に対処する必要がありました。 この職業は容易ではなく、多くのリスクを伴います。 結果はしばしば、特定の役人との確立された関係の質にのみ依存していました。 しかし、もし彼らがそれを変えたら-書かれた製品をゴミ箱に捨てることができた-彼の副官は再び奇妙なものを要求した。 唯一の解決策は、プロジェクトの要件と各動きを明確に修正することです。 それでも、私はGOSTに従ってTKを書きました。
では、なぜこのような標準が必要なのでしょうか？
現在、政府機関や政府機関の多くのインターネットプロジェクトの品質は台座よりも低くなっています。 これらのサイトが本来あるべきように開発されたこと、それらを更新するための手順が存在しないこと、そして情報保護について話す価値はありません。 時々、仕事は貧しいシステム管理者に委ねられます。
このドキュメントは、多くのユーザビリティ標準だけでなく、Web標準を大きく満足させるはずのW3C標準にも適用されます。
ポジティブなことは、標準レベルで多くの要件がすでに形成されていることです。 これは、参照条件を作成するときに、この標準の規定を参照できることを直接意味します。 ベラルーシのプロジェクトの分析に従事していたとき、私は本当にそのような標準を持っていませんでした。
政府の顧客のために働くときの仕事の受け入れが常に問題であることは秘密ではありません。 これには2つの理由があります。
実際、非機能要件がTORで明確に記述されていない場合、顧客は業界標準に訴えることができます。 EUに住んでいる場合、ISO規格に対する訴えになります。 そして、ここでは少しは思えないでしょう。
一般に、要するに、そのような標準は多くの質問を取り除き、役人による意思決定の基礎を設定します。 また、標準が十分に高い品質の出力で取得される場合、商用サイトを開発するときに参照することは理にかなっています。
このような標準の導入に伴い、Web開発者は厳しい状況に陥ることになります。 :)まず、ラベル全体を閉じることができます。私たちが言うことは、標準に従っているということです。 第二に、この問題の調和のとれた開発プロセスを構築するために-それは標準で簡単です。
同時に、この文書は美しく、優れており、変更せずに受け入れなければならないとは言いたくありません。 私は文書全体を読んだのではなく、セルゲイがレイアウトしたものだけを読みました。 私が読んだことから-多くのことが非常に当てはまります。 彼には生命権があります。
悪い点：
通常の方法論者が文書を入手した場合、これらのニュアンスを修正します。 一般的に、方向は正です。
すぐに、 Habréで議論の波が起こりました。 そこでは、とりわけ、スクープの復活についての声明があります。 このドキュメントは非常に必要で便利だと思います。
なぜ標準が必要なのですか？ いくつかの決定を下すときに考えることを少なくします。 同時に、標準で蓄積および収集された知識を通じて、これらのソリューションの品質を向上させます。 例を挙げましょう。 80年代、米軍はソフトウェアの開発と供給のベンダーを選択する手順に困惑していました。 請負業者の選び方 ランダムに働く人々から確実に働く人々を分離するために、企業のいくつかの指標レベルを導入する必要がありました。 理想的には、このインジケーターは1、2、3、4、5の1つの数字のみです。レベル5の会社はレベル3の会社よりも優れているため、レベル5の会社と協力します。 そこで、 CMMI （Capability Maturity Model Integration）標準が登場しました。 EPAMには4つ目のレベル（5つのうち）があるため、市場では2つ目または3つ目のレベルよりも魅力的に見えます。
どういうわけか、政府機関向けのインターネットプロジェクトの開発に対処する必要がありました。 この職業は容易ではなく、多くのリスクを伴います。 結果はしばしば、特定の役人との確立された関係の質にのみ依存していました。 しかし、もし彼らがそれを変えたら-書かれた製品をゴミ箱に捨てることができた-彼の副官は再び奇妙なものを要求した。 唯一の解決策は、プロジェクトの要件と各動きを明確に修正することです。 それでも、私はGOSTに従ってTKを書きました。
では、なぜこのような標準が必要なのでしょうか？
品質バー
現在、政府機関や政府機関の多くのインターネットプロジェクトの品質は台座よりも低くなっています。 これらのサイトが本来あるべきように開発されたこと、それらを更新するための手順が存在しないこと、そして情報保護について話す価値はありません。 時々、仕事は貧しいシステム管理者に委ねられます。
このドキュメントは、多くのユーザビリティ標準だけでなく、Web標準を大きく満足させるはずのW3C標準にも適用されます。
要件のステートメント
ポジティブなことは、標準レベルで多くの要件がすでに形成されていることです。 これは、参照条件を作成するときに、この標準の規定を参照できることを直接意味します。 ベラルーシのプロジェクトの分析に従事していたとき、私は本当にそのような標準を持っていませんでした。
仕事の受け入れ
政府の顧客のために働くときの仕事の受け入れが常に問題であることは秘密ではありません。 これには2つの理由があります。
- 多くの場合、仕事の受け入れを行うのに十分な資格のある専門家がいません。 あなたが正しいことを証明することは非常に困難です。 その結果、TKで非常に詳細な品質要件を規定する必要があります。
- スプロール要件。 承諾後、契約が終了することに気付き、顧客は新しい要件を押し進めようとしている。
実際、非機能要件がTORで明確に記述されていない場合、顧客は業界標準に訴えることができます。 EUに住んでいる場合、ISO規格に対する訴えになります。 そして、ここでは少しは思えないでしょう。
一般に、要するに、そのような標準は多くの質問を取り除き、役人による意思決定の基礎を設定します。 また、標準が十分に高い品質の出力で取得される場合、商用サイトを開発するときに参照することは理にかなっています。
このような標準の導入に伴い、Web開発者は厳しい状況に陥ることになります。 :)まず、ラベル全体を閉じることができます。私たちが言うことは、標準に従っているということです。 第二に、この問題の調和のとれた開発プロセスを構築するために-それは標準で簡単です。
同時に、この文書は美しく、優れており、変更せずに受け入れなければならないとは言いたくありません。 私は文書全体を読んだのではなく、セルゲイがレイアウトしたものだけを読みました。 私が読んだことから-多くのことが非常に当てはまります。 彼には生命権があります。
悪い点：
- 品質定義の使用。 「ページ要素は簡単に識別できるようにする必要があります」-簡単に何を意味するのか明確ではありませんか？ このような言語は、標準と要件で避ける必要があります。
- ファジー構造。 たとえば、「設計」セクションのセキュリティについて。 :)
通常の方法論者が文書を入手した場合、これらのニュアンスを修正します。 一般的に、方向は正です。
All Articles