コンピュータ工学は、土木工学、機械工学、製造工学などに比べて非常に若い木です。多くの工学概念は自然にコンピュータ工学に移植されるでしょう。また、システム アーキテクチャと建築アーキテクチャ、システム スタイルと建築スタイル、建築設計図面とシステム設計図面、パイプライン組立ラインと生産組立ラインなどの類似点を見つけることも簡単です。
他のプロジェクトから学ぶという点で、コンピュータ エンジニアリングがわずか数十年の間に多大な努力を払ってきたことは否定できません。特に、クラウド コンピューティング、ブロックチェーン、メタバースなど、製品が登場したばかりの場合は、商業的な雰囲気が強く、人々を当惑させます。まるで自分たちの製品がすべてを表しているかのように、それがなければ世界は終わってしまう、大袈裟ですが、そんな神秘的な形而上学的な雰囲気も多くの人が追い求めています。あなたの携帯電話やコンピュータには、ほぼ蔓延しているそのようなものと、憎しみに満ちた推奨システムが埋め込まれています。
ある時点から、システム設計またはアーキテクチャが浮き沈みを始め、しばらくは理解できない隠語でいっぱいでした。統一モデリング言語の図を見てみると、見覚えのあるものがありました。実は、システム設計も建築設計と同じで、設計図や施工図を描く必要があるのですが、厄介なことに、その柵を破ろうとする人はほとんどいないのです。施工図ではなく、統一モデリング言語と呼ばれているからです 施工図と呼んでしまうと、いろいろなもので膨らんだ泡が弾けてしまいます プログラム設計は、もはやデザインとは呼ばず、コードワードと呼ばれ、プログラマはプログラマとは呼ばれません. コードファーマーと呼ばれていますが、初めて言語を学ぶときは「****プログラミング」と呼ばれ、非常に断片的に感じられます。
集積回路図: ユースケース図: コラボレーション図: 展開図:
長年にわたり、コンピュータは商用テクノロジーとして偽装され、このシステムには何も問題がないということを国民に日常生活の中で教え込まれてきました。実際、私たちはまた何をしたか、ある先生から PPT を借りました。
批判されながらも、慎重かつ恐る恐るお金を稼いだ。
茅葺き小屋を建てることは超高層ビルを建てることと同じでしょうか？Web の閲覧と 3A の傑作の再生には、別のコンピューターが必要です。。。。
多くの場合、ビジネス指向の要件からテクノロジー指向のソフトウェア システム実装、特に複雑なシステムの設計に至るまで、大きなギャップを越える必要があります。要件分析は明確でも、システムを実用化するのは大変ではないでしょうか。設計方法の選び方、デザインパターンの選び方、アーキテクチャの選び方、サーバの選び方、ストレージの選び方、ネットワークのレイアウトの仕方、そしてそれらの素材を使って情報をどう生み出すか。システムをまともな方法で開発するのは大変な作業です。
一方で、システムを設計する際、ビジネスロジックをより良く設計するべきか（縦方向）、技術ロジックをより良く設計するべきか（横方向）、一般的な機能をより良く設計するべきか（フレームワーク）というジレンマに直面することがよくあります。 ）、今後の個別設計において徐々に機能を拡張していくべきか、あるいはシステムとサブシステムの関係を全体的な視点（アーキテクチャ）から整理し、その後の開発システムやコンポーネントにおいて新たな追加を徐々に拡張していくべきである。実際、複雑なシステムを前にすると、人材、資本、技術、経営、営業などさまざまな課題に直面することになります。ソフトウェア製品は、設計、開発、適用、プロモーションに至るまで不確定要素が多すぎて、すべてをカバーするのは困難です。
一方、システムアーキテクチャは、結局のところ、システム設計の初期段階で作成されるものであり、システム設計後も、コーディング、テスト、納品が必要であり、システム開発の複雑さにより、技術コストがかかります。組織の発展、ユーザーに提供する製品の品質、ソフトウェアのアップグレードを制御できない、あるいは再生の可能性がある、製品ラインがあまりにも壮大または複雑で現実と一致しない場合、それは失敗に違いありません。ある本にはこう書かれています。
ソフトウェア アーキテクトが垂直方向 (顧客が必要とする機能) に多大なエネルギーを費やし、水平方向のテクノロジの大部分をコーダーに任せるのはよくあることです。近年の情報システムではシステム障害が多発しており（たまに「ある場所の情報システムが崩壊した」というニュースを耳にします）、アーキテクトはパフォーマンスを重視しながらも、 (システムの信頼性、サービスの安定性、機能の拡張性など) それを議題に上げ、要件などのことはプロジェクト マネージャーまたはシステム アナリストに任せてください、そうですね、プロジェクト マネージャーは (プロジェクトを引っ張るために) 飲んでいます、プロジェクト チーム私が言いませんでしたが、システムアナリストはいません。
情報システムには開発から納品までの期限があるはずですが、いつまでも先延ばしにすることはできませんし、プロジェクト期間が徐々に臨界点に近づいたとき、右往左往する場面を経験したことがある人も多いのではないでしょうか。 。採算が取れるか、プロジェクト期間はどれくらいか、技術的に実現できるか、技術的に実現するのはどのくらい複雑か、開発者の能力はレベルに合っているか、などを考慮する必要があります。慎重に検討してください。そうでないと、誰にとっても困難になるでしょう。
システムの機能（ビジネス）、構築期間、品質、メリットを同時に考える必要があり、ある業界に参入したばかりの情報開発会社などでは、ビジネス（この業界がどのようなデータを持っているか）を重視する場合があります。 、どの機能がビジネスを表現できるか、どのテクノロジーがその機能を実現できるか）。機能や工期、利益を重視するあまり、品質への配慮が軽視されるケースも少なくありません。特定の業界に進出している一部の情報開発会社にとって、システムの製品品質 (パフォーマンス、セキュリティ、使いやすさ、継続的なサービスの可用性、拡張性、相互運用性、信頼性など) が特に重要であることも事実です。堅牢性、再利用性、移植性）。後者は前者に比べて明らかに成熟しているが、その成熟度は長年にわたって一定の業界で深く培われた結果形成された習慣によるものであり、甲の父親からの数えきれないほどの叱責や苦情によっても継続的に改善できるものでもある。
システム開発テクノロジーのトレードオフと製品の費用対効果の分析は、徹底的に議論する価値のある問題です。プロジェクトは孤立して存在するわけではありません。システム設計やアーキテクチャが、より経済的であるか、より高度であるか、よりシンプルであるか、より成熟しているか、またはよりシンプルであるかを単独で議論することは無意味です。特定のシナリオや背景では、正しいものが最善である可能性があります。エンジニアリングと研究の違いは、高品質のシステムがコスト面で多大なオーバーヘッドを生成する場合は、それを楽にしましょうエンジニアと原材料、ツール、技術、製品とコストのローカルまたはグローバルの最適なソリューションが適しています。
実際、多目的問題を解決する場合、目的を 1 つずつ選択して計画や予測を行うと、線形関数を使用するか非線形関数を使用するかに関係なく、評価値は比較的信頼できます。
