ITの分野で仕事をしていると、知らず知らずのうちに、さまざまなソフトウェアの膨大な数のエラーに気づきます。 Microsoftのグローバルベンダーが1Cのビジネスソリューションを適用した場合でも、1970年1月1日の幼年期の致命的エラーを伴うAppleの称賛されたソリューションの場合でも、それは間違いです。 プログラマーのスタッフが少ない中小企業については何と言えますか？
ソフトウェアのエラーは自然なプロセスですか？ それを理解しましょう。 以下はすべて、分類、有限オートマトンの理論を適用する可能性、観察など、著者の意見のみです。
少し前まで、SamsungはSamsung Payサービスの開始を発表しました。SamsungGear 3時計の存在は、端末の時計に触れることで購入代金を支払うという新しい楽しみをもたらしました。 製品の製造中にどのような問題が発生したのかはわかりませんが、プログラムの最初のバージョンでは調整できませんでした。 いくつかのリリースのリリースでのみ、サービスを使用できました。
すべてのメーカーは、規模や認定にかかわらず、ソフトウェアのミスを犯します。
プログラマーのメンタルワークには、常に革新が必要です。 彼らは、投資家や夢想家にビジネスのアイデアを提供するために、現代の技術を適用しなければなりません。 情報と技術は急速に陳腐化するため、プログラマーは開拓者の研究者のように、タイガ、乾燥した砂漠、氷のハンモックの茂みを克服するために最前線に立つ必要があります。
G.セドフ、R。スコット、V。ベーリングなど、困難なルートを通過しようとして何人の研究者が亡くなりましたか？
プログラマーは、ミスを容易にする新しい未訓練のテクノロジーを使用します。 外部開発者が提供するモジュールと、独自のソフトウェアのアプリケーションの両方にバグがあります。
エラーと有限状態理論
有限状態機械の理論を見てみましょう。 かつて、研究所はコントローラーのプログラミングと制御システムの構築の両方にこの手法を適用しなければなりませんでした。
しかし、理論に基づいて、ソフトウェア開発の複雑さとエラーのしやすさが示されたらどうでしょう。 たとえば、適用された問題のステートメントは、顧客の注文のステータスへの自動移行を実現することです。
次の状態を持つ製造企業の有限状態マシンの標準グラフを想像してください。
ステートマシンイベント：
- a-バイヤーによる確認後にマネージャーが設定します。
- b-生産責任者によって設立され、生産能力と実行能力を評価します。
- c-倉庫での受領時に倉庫の従業員によって確立されます。
- d-お金の受け取りと貨物の転送時に管理者によって設定されます。
- e-マネージャーが手動で設定します。
簡単なプロセスが説明されています。 競争では、最新のすべての機能を使用する必要があります。もちろん、SMSを顧客に送信することはプラスであり、おそらく義務です。 覚えているように、最初のタスクはプロセスを自動化することです。 たとえば、ローダーはバーコードスキャナーを使用して商品を受け取り、システムはSMSを購入者に送信します：「完了しました。」
これは一般的な作業ですが、デザイナーにとっては多くのニュアンスが隠されています。 たとえば、彼らは製品を生産し、一部は欠陥品であることが判明しました。 どのような状態にすべきですか？ 考慮に入れますか？ 顧客は買いに来ましたが、検査中に製品の一部を放棄することに決めました-完了またはキャンセルしましたか？ 誤って注文がキャンセルされましたが、生産に戻す必要があります。
グループ、多数の保管場所、および多数の条件が存在する可能性がある場合、複雑な例を考慮しませんが、この単純なタスクでは、多くのソフトウェア設計者がミスを犯します。 自動化には分析的なアプローチが必要です-問題ディレクターが気付いていない遷移を解決するために。 上記のプロセスに対する企業の実生活では、移行の数ははるかに多くなります。
ソフトウェアが機能するほど、エラーが増えます。 テスターは役立ちますが、常にではありません-彼はデザイナーとして主題分野に精通していません。私は、有限状態マシンの理論に基づいたステータスグラフの構築により、解決されている問題を詳しく調べることができると判断しました。
私は、最高財務責任者から従業員の剥奪制度の開発を要請されたことを覚えています。 すべての従業員の指示の会計処理は1C：文書管理（DO）で実行され、作業時間の会計処理は1C：生産企業管理（SCP）で実行されました。 従業員が重要な仕事を延滞している場合、その従業員はプレミアムをX％奪われました。 これを行うには、DOでタスクの完了時間を確認し、SCPからその期間のタイムシートで従業員のデータを取得し、「execute can be perdoned」のコンマの場所を決定します。しかし、状態間の遷移の数（システム制限の理論による）は非常に大きくなったため、うつ病システムが機能しなくなる予定のない多数のシナリオに答えなければなりませんでした。 例：
そのようなシステムを導入する誘惑は素晴らしかった。なぜなら、従業員からの給料を絞るほど、年末の結果に応じて年末年始に車をより良く買うからだ。 したがって、このタスクを実装するために、すべての移行を考慮して、1Cの改善が多数行われました。ソフトウェアのテスト手順は長い間デバッグされ、標準化されています。 しかし、マスプロダクトはまだバグ修正を絶えずリリースしています。 例：
エラーなしで機能ソフトウェアをリリースすることは可能ですか？ いいえ、そのようなケースは観察されませんでした。エラーの分野における経済学と技術知識の関係
エラーを最小化できますか？ 間違いなく。 それらの数は、検索と削除に費やされた時間に従って非線形に減少します。 時間はコストを意味します。 エラーの検索を減らす理由は2つあります。それ以上の検索に対する経済効果の損失と、エラーを排除するための技術知識の損失です。
理想的には、「必要なリソース」の軸上に並んでいる場合。 これは、ビジネスの経済モデルとソフトウェアの品質の調和を意味します。
たとえば、新しい航空機のオンボードコンピューター用のソフトウェアを開発することがタスクです。 飛行物理学の膨大な数のパラメーターと機能を考えると、資金の損失のためにソフトウェアのデバッグを停止することはできません。 結果は悲しいでしょう。
「技術的知識の喪失」のポイントがはるかに早く来る場合、開発者の品質基準とプロ意識を高める必要があります。
そのすべてに対して、すべてのテストから隠され、ユーザーによってのみ検出される「忍者エラー」が残ります。エラーの重み
各エラーの重みは異なります。 一般的に、私はそれらを4つのタイプに分けます。
重大なエラー。 業務（会計システム用）、機器、サービスを停止します。 そのようなエラーはすべきではありません。 このような「バグ」の存在は、開発者の技術面が弱いことを示しています（テスト方法を含む）。
たとえば、Google Playストアで積極的に宣伝されているプログラムをダウンロードしました。 起動直後にエラーが発生しました。
重要なマイルストーンこれは操作を停止しませんが、ユーザーが手動で修正できない不正確な結果につながります。
ポドルスク市へのルートを舗装しました。 あるセクションでは、ナビゲーターは非常に奇妙なルートを敷きました（彼は交通渋滞を迂回せず、道路の修理やブロックはありません）。 このエラーは重大ではなく、プログラムを引き続き使用できますが、変更はありません。
重要な克服可能な間違いたとえば、ビジネスコストの計算は非常に重要ですが、多くの未知数を含む多次元方程式系の解のために困難です。 上記のように、提供されたベンダーモジュールでエラーが発生します。
コスト計算は、以前の一連の計算に基づいた最終結果のみを提供し、ある反復でエラーが発生した場合、結果は不正確になります。
プログラム1Cでは、このようなコスト計算のエラーが表示されていました。 ユーザーは（もちろん、実験によって）それを削除することができます-ドキュメントをリダイレクトします。 RAUZメソッドの宣言された機能では、これは実行されるべきではありませんが、実際には実行されるべきではありません。
備考これですべてです。 たとえば、メッセージはVirtueから送信され、リンクが壊れています。 テストが実施されなかったことはすぐに明らかです。
履歴書としての間違いの分析
プログラマーおよびプロジェクトマネージャーとしての私のすべての間違いを思い出して、私はそれらの出現の次の理由を強調することができます。
- 言われ、聞かれたことの問題。 円柱の投影を覚えているように、一方の円ともう一方の円は長方形です。 その結果、1つの要件について話していますが、異なる方法で理解しています。
- 思考の深さを制限する。 各人には独自のレベルがあり、さらに深化を正式に行わない場合（紙片やプログラムコードにメモを取らないでください）、機能的なギャップが生じます。
- コード要素を重要視していない。 彼は書いており、それが間違っていたことを疑うことさえしませんでした。 最良の場合、これは最適でないコードに変換されます。
- 機能開発ツールの不完全な知識。 エンジニアの仕事はリファレンスドキュメントを扱うことであると教えられましたが、経験は本とのコミュニケーションを最小限に抑えるのに役立ちます。