「ソフトウェア工学入門、第6版」-ZhangHaifanとMouYongminの授業後の回答と詳細な説明第2章実現可能性調査

記事のディレクトリ

質問1

1.ソフトウェア開発の初期段階で実現可能性調査を実施するのはなぜですか?ターゲットシステムの実現可能性をどのような側面から調査する必要がありますか?
回答:(1)ソフトウェアを開発する際には、元のシステムモデルと目標が現実的であるかどうか、システム完成後のメリットがシステム開発に投資する価値があるかどうかを判断する必要があります。これは不可能であり、コストこれらのプロジェクトに費やされる時間、人的資源、ソフトウェアおよびハードウェアのリソースと資金は、不必要な無駄です。フィージビリティスタディの本質は、大幅に圧縮され簡素化されたシステム分析および設計プロセスを実行することです。これは、より高いレベルでより抽象的な方法で実行されるシステム分析および設計のプロセスです。フィージビリティスタディの目的は、最小のコストで可能な限り短い時間で問題を解決できるかどうかを判断することです。

(2)一般的に、各ソリューションの実現可能性は、少なくとも次の3つの側面から検討する必要があります
。a。技術的な実現可能性。開発するプロジェクトの機能、パフォーマンス、制限を分析し、既存のリソース条件下での技術的リスクの大きさを判断し、プロジェクトを実現できるかどうかを判断します。これらは技術的実現可能性調査の内容です。ここでのリソースには、既存または利用可能なハードウェアおよびソフトウェアリソース、既存の技術者の技術レベル、および既存の作業基盤が含まれます。
b。経済的実現可能性。開発コストを見積もり、開発するプロジェクトに投資して開発する価値があるかどうかを判断するために得られるメリットを理解します。これらは経済的実現可能性調査の内容です。ほとんどのシステムでは、一般に、経済的にコストがかかるかどうかの尺度です。効果的。「収益」を考慮する必要があります。経済的実現可能性調査は、費用対効果分析、長期的な企業管理戦略、開発コストとリソース、および潜在的な市場の見通しを含む幅広い範囲をカバーします。
c。運用の実現可能性。社会的実現可能性の問題を研究し、開発されるプロジェクトに侵害、妨害、その他の責任の問題があるかどうかを研究する必要がある場合があります。社会的実現可能性の範囲も比較的広く、契約、責任、不法行為、および技術担当者が理解できないことが多いその他の罠が含まれます。
必要に応じて、各ソリューションの実現可能性は、法律と社会的利益のより広い側面から研究する必要があります。

質問2

2.預金者の便宜のために、銀行はコンピューター預金システムの開発を計画しています。預金者が記入した預金伝票または引き出し伝票は、店員がシステムに入力し、預金の場合は、預金者の氏名、住所、預金の種類、預金日、金利などの情報を記録し、預金者への預金伝票;それが引き出しである場合、システムは利息を計算し、預金者への利息のリストを印刷します。問題の定義を書き留めて、このシステムの実現可能性を分析してください。
回答:預金の場合、預金者は預金フォームに記入し、それを店員に渡してシステムに入力します。同時に、システムは預金者の名前、住所(または電話番号)、ID番号も記録します。 、預金の種類、預金日、金利、その他の情報、完了システムは、預金伝票を預金者に印刷します。
出金の場合、入金者は出金フォームに記入し、事務員に渡します。出金金額をシステムに入力し、入金者にパスワードの入力を求めて本人確認を行います。パスワードが正しいことを確認した後、 、システムは利息を計算し、利息リストを預金者に印刷します。
預金者のニーズに応えるため、システムはユーザーの要求に迅速に対応し、ユーザーが入力した情報を可能な限り迅速に処理する必要があるため、大容量のメインメモリと強力なデータベースサポートが必要です。ターゲットユーザーは幅広い貯蓄ユーザーのグループであるため、システムには強力なセキュリティサポートが必要です。実現可能性調査方法
条件、仮定、および制限
推奨される開発ソフトウェア操作の最短寿命:5年
システムスキームの選択と比較の期限:2か月
資金源と使用制限:カスタマイズされた銀行
ハードウェアの条件と条件ソフトウェア、動作環境、開発環境制約事項:
銀行センターにはメインフレームとサポートデータベースがあり、各銀行支店には
Windows2000以降のオペレーティングシステムがインストールされた設備の整ったPCがあります。
ソフトウェアの開発を開始する最新の時期は、開発完了後1か月にすることをお勧めします。
フィージビリティスタディ手法
熟練した銀行員との綿密な話し合いを通じて、ユーザーや銀行員の実際のニーズを真に理解するための詳細なユーザーアンケートを作成し、店員から提供された情報と問題の定義に基づいて、アンケートは改善のために統合されました。プロジェクトが解決する必要のある問題を確定し、問題を解決できるかどうかを判断します。
実現可能性を決定する主な要因
1)プロジェクト開発コスト
2)必要な機器取得コスト
3)技術が需要を満たすことができるかどうか
4)オペレーターの熟練度
5)リソースの有効性

既存システムの分析
ここに画像の説明を挿入します

1処理フローとデータフロー
預金フローチャート:
ここに画像の説明を挿入します
引き出しフローチャート:
ここに画像の説明を挿入します
データフローチャート:
ここに画像の説明を挿入します
2ワークロード
現在、ほとんどの銀行で使用されている銀行貯蓄システムは、業務処理の手続きが面倒で、手作業が多すぎます。顧客のビジネスを処理するために必要です。時間がかかり、他の顧客は待たなければなりません。これには時間がかかりすぎ、顧客のビジネスを処理するために多数の営業担当者が必要になります。特に休日の人の流れのピーク時には、作業効率が非常に低く、エラー率が高いため、お客様は手続きを待つのが待ちきれず、銀行の効率が低下します。これはまた、銀行スタッフに非常に大きな負担と追加の作業負荷を追加しました。同時に、営業スタッフの増加と銀行経費の高額な支出は、銀行会社の発展に深刻な制約と圧力をもたらしました。

3経費
既存のシステム運用するために必要な経費には、銀行員やその他のスタッフの給与、およびシステムの保守に必要な資金が含まれます。

4人スタッフ
多数のセールスマン、カスタマーサービススタッフ、システムメンテナンススタッフ、その他のスタッフが必要です。

5機器
既存のシステムに必要な機器には、プリンター、PC、コンピューターが含まれます。

6制限事項
作業効率は、多くの人々のタイムリーなニーズを満たすことができず、人々の生活に不便をもたらします。これは、既存のシステムのビジネスプロセスに現れる深刻な問題です。この問題を解決し、人々が銀行業務をより便利かつ迅速に行えるようにするために、貯蓄業務が列に並ぶ必要がないように、より効率的な銀行のコンピューター貯蓄システムを早急に開発する必要があります。
(1)現在の銀行の貯金制度は、手作業のみで業務を行っており、手作業がすべてを占めているため、銀行員は、丁寧で忍耐強く、数字に敏感で、高い算術のレベル。これは作業効率に深刻な影響を及ぼし、エラー率が高くなります。預金者は取引を処理するのに時間がかかりすぎ、預金と引き出しの需要の高まりに対応するために多数の銀行家を必要とします。
(2)紙の記録を使用してユーザーの預金記録を保存することは、面倒で、時間がかかり、不便であり、紛失しやすい。さらに、手動記録は絶対確実であるとは保証できず、データ入力エラーが発生する傾向があります。ユーザー数が増えると、この欠陥はより顕著になります。
(3)預託記録の機密性が低く、営業担当者なら誰でも自由にユーザーデータを変更・閲覧でき、ユーザー情報が漏洩しやすく、セキュリティ上のリスクがあります。
(4)営業担当者のサービス時間は限られており、24時間営業ができず、緊急対応もありませんので、大衆のニーズを十分に満たすことができません。
(5)お客様の業務はすべて営業担当者が手作業で行っており、人的資源を浪費しています。いくつかの簡単な操作は、手動で行うことなく、改善後に機械で完了することができるため、人件費が節約され、効率が向上します。
(6)既存のシステムの改善と維持は、営業担当者の数を増やし、銀行の支店の数を増やし、営業担当者の専門的な品質を向上させることによってのみ達成できます。営業担当者の増加は銀行の人件費の大幅な増加につながると同時に、支店を建設したり支店の規模を拡大したりするために複数の場所を選択する必要があり、コストがかかります。営業担当者のプロとしての資質を養う必要があり、短期間で成果が出せず、新入社員の育成にも一定の時間がかかり、資金や人材の浪費になります。現在のシステムの改善されたメンテナンスは、もは​​や、ますます多くの預金者の問題を解決することはできず、預金者にとってますます長い時間になる。

質問3

3.航空会社は、乗客の便宜のために、チケット予約システムの開発を計画しています。旅行代理店は、予約したチケットの乗客情報(名前、性別、作業単位、ID番号、旅行時間、旅行先など)をシステムに入力します。システムは、乗客のフライトを手配し、チケット収集通知を印刷します。と請求書を発行し、乗客は飛行機で離陸します。前日、チケットはチケット収集通知と請求書の支払いで収集され、システムは確認されるとすぐに乗客にチケットを印刷します。
問題の定義を書き留め、システムの実現可能性を分析します。
回答:
1>目標:1ヶ月以内に効率的でエラーのない航空券予約システムを確立する
2>主な問題:労力の管理が容易でなく、手続きが面倒である
3>新しいシステムを確立する
①経済的実現可能性、費用対効果分析、
費用見積もり:1台のプリンター(2000元)+開発費用(3500元)= 5500元。
推定手頃な利益:このシステムは、優れた社会的利益を持ち、航空券の発券効率を改善し、乗客にとって便利であり、より便利で科学的な発券
②技術的実現可能性
調査と分析の後、現在の航空券予約システムのフローチャートは次のとおりです。
ここに画像の説明を挿入します
ここに画像の説明を挿入します

質問4

4.現在、入院患者は主に看護師による看護を行っており、多数の看護師が必要となるだけでなく、重症患者の状態の変化をいつでも観察できないため、救助の機会が遅れる可能性があります。病院は、コンピューター中心の患者監視システムを開発し、問題の定義を書いて、このシステムの開発の実現可能性を分析しようとしています。
患者モニタリングシステムに対する病院の基本的な要件は、各患者の生理学的信号(脈拍、体温、血圧、心電図など)をいつでも受信し、患者の状態を定期的に記録して患者ログを作成することです。 。患者の生理学的信号が医師によって指定された安全範囲を超えた場合警告メッセージが勤務中の看護師にいつでも送信されます。さらに、看護師はシステムに指定された患者の医療レポートを印刷するように依頼することもできます。必要に応じて。
実現可能性分析-元のシステム分析:
ここに画像の説明を挿入します
実現可能性分析-論理図:

ここに画像の説明を挿入します

ここに画像の説明を挿入します

ここに画像の説明を挿入します
技術的実現可能性:生理学的データの収集には多くの専門的な精密機器が必要であり、ソフトウェアエンジニアは熟練していませんが、専門家の助けを借りて完了することができます。

経済的実現可能性:支出は病院が負担し、実現可能かどうかは病院が必要な費用を支払うことができるかどうかに依存します。

運用の実現可能性:医師にはソフトウェアを保守する能力がありません。専門家がデータベースを保守する必要があります。患者数が多すぎないため、データベースを定期的に管理および保守する必要があるのは1人または数人だけです。アップ。

質問5

5.北京の大学で利用できる電話番号は、次のカテゴリに分類されます。キャンパスの電話番号は4桁で、最初の桁は0ではありません。キャンパス外の通話は、市内通話と海外通話に分けられます。学外の電話をダイヤルするには、最初に0をダイヤルする必要があります。ローカル電話の場合は、次に8桁の番号(最初の桁は0ではありません)をダイヤルします。非ローカル電話の場合は、3をダイヤルします。 -数字の市外局番と8桁の電話番号(最初の数字は0ではありません)。
上記の電話番号を定義するには、セクション2.5.2で説明されているデータを定義する方法を使用します。
回答:
電話番号= [学内電話番号‹学外電話番号]
学内電話番号=ゼロ以外の数字+3桁
の学外電話番号= [市内番号|外国番号]地方
都市番号=番号ゼロ+8桁の非
ローカル番号=番号ゼロ+3桁+8桁の
非ゼロ番号= [1 {2} 2 !! 3 !! 4 !! 5 !! 6 ++ 7 !! 8 !! 9]
番号ゼロ=
03桁= 3 {数値}
38桁=ゼロ以外の数値+7桁
7桁= 7 {デジタル} 7
デジタル= [0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9]
ここで、[]はまたは学校の電話番号または外部の電話番号から1つを選択します。{}は繰り返しを意味し、両側の数字は繰り返し回数の下限と上限を示します。=は次のように定義されます。+は合計を意味し、2つのコンポーネントを接続します。

おすすめ

転載: blog.csdn.net/hypertext123/article/details/109536106