つい最近ですが、私情で参加する予定だったコンテストへの作品も完成して
何しようかな~とだらだら2,3日過ごしていたので
ちょうど発売日が近かったドラゴンクエストビルダーズを購入してみました。
今はYoutubeでライブ配信したりして楽しんでいるのですが、ドラクエなので
やはりマルチプレイがないんだな~と思いながらやってますぜ
(マルチプレイがあったらもっとよかったんだけどな~
今のところフリービルダー?自由に建築したりという感じのことは
あまりやっていなくて、ストーリー重視のプレイスタイルを楽しんでいるところですね
これからストーリーがひと段落したら今度はマイクラみたいな感じに
なにか作ってみたいものを作っていこうかと考えています。
2016年2月1日月曜日
2015年12月10日木曜日
自分の知識定着のための投稿#5
☆テストから本番稼働へ1
・業務手順書と運用マニュアルの完成
・業務手順書:利用部門のためのドキュメント・運用マニュアル:システムを運用する部門のためのドキュメント
・テストの結果を生かして、問い合わせ、トラブル、対応策のFAQ
・開発チームから運用・保守チームへの引継ぎ
・運用・保守チームへの引継ぎ、教育計画・設計、製造段階に運用担当者の参画
・運用担当者の中に開発経験者が加わる
☆運用マニュアルの内容例
項目 | 内容
システムの構成 |【システム・ハードウェア一覧】
|・サーバ機器構成
|・クライアント端末一覧
|【システム・ソフトウェア一覧】
|・OS,ミドルウェア、各種ツールの名前,バージョン
システムの運用 |【運用体制】
|・担当者と役割
|・障害児の連絡体制、連絡先
|【運用内容・運用手順】
|・システムの起動、終了、リブート
|・データのバックアップ
|・プログラムの変更の手続き,実施方法
|・障害の監視、トラブルへの対応
システム障害と対策 |【想定される巣ステム障害の一覧】
|・影響の度合い、検出方法
|・対応手順
☆テストから本番稼働へ2
・本番稼働後の対応
・本番直後はユーザの不慣れやバグで、問い合わせ、トラブルが多発
・サポート体制の整備
-運用テスト部隊をサポート要員として配置
-ヘルプデスク
・追加機能の開発に備えて、システムのテスト環境をしばらく残す
☆本番稼働直後のユーザ対応が肝心!
システムを狙い通りにユーザに活用してもらえるか!最初の印象がユーザのシステム評価を左右する!
☆稼働後は顧客の所有物
検収が済んで本番稼働
システム: 開発企業の所有物 → 顧客企業の所有物・プログラムやデータの変更
開発時のように勝手に実施してはいけない
顧客の所有物であり、顧客の管理責任下にあるもの
・変更の必要性、影響度を開発側が勝手に判断してはいけない
・顧客の定めた運用方法に従って、正式な申請・認証手続きを得る
・変更管理、バージョン管理は顧客企業の責任で実施する
・運用マニュアルは、開発側、顧客側がお互い協力して作成する
☆設計の仮設を確認
・本番稼働したら、設計上の仮設の確認が必要
・稼働すると実績データが集まる
見積もり、設計時の仮設が検証できる
・実績に応じて仮設条件の修正
・今後の対策の検証
ハードウェアの増強は必要か
ソフトウェアの修正、改善は必要か
・発生可能性の高いトラブルを未然に防ぐ
☆設計上の仮設:稼働後の確認項目の例
項目 | 確認内容
トランザクション量 |・トランザクションによるシステムやネットワークへの負荷
|・ピーク時のトランザクションの負荷見積り
レスポンスタイム |・オペレーション別のレスポンスタイム
|・時間帯など条件によるレスポンスタイムのバラツキとその原因
|・プリンタ印刷などのレスポンスタイム
サーバへの負荷 |・CPU使用率
|・IO使用率
データ量 |・ネットワーク間の通信量
|・データベース容量
データベースへの負荷 |・データベースへのアクセス頻度
|・DBMSによるパフォーマンス解析
☆運用管理しやすいソフトウェア
・本番稼働後の運用管理部門の仕事
-インストール作業、バージョンアップ作業
-ユーザに対する支援業務
-ユーザの誤操作対応
端末がフリーズ
-ユーザが勝手に使用ソフトをインストールしないよう管理方針の周知
システムの動作不調,セキュリティの問題
-企業の組織変更、人事変動対応
システム再設定、インストール、利用検収の実施
-サーバ、端末のハードウェア対応
-ネットワーク、回線対応
-障害発生時の原因切り分け、回復企業
☆ソフトウェア開発者は
・運用しやすいソフトウェアを意識した設計・運用に対するアドバイスや提案などの支援が必要
☆保守の分類1
修正のための保守
☆テストで検出できなかった欠陥が発覚したときの対応
・ふつうは、開発側の責任となる
・顧客の立場を考えて、トラブル、バグに対応する
・修正保守による二次トラブルを避ける
慌てず確実に
・プログラムの修正に加えてドキュメントの修正も確実に行う
・大幅な修正、変更はユーザが戸惑う恐れがある
リリースの範囲、タイミングを考える
☆保守の分類2
改正のための保守
☆外部環境や顧客要求の変化に対応し、ソフトうゎの改正を行う
・変更に対し、適切な対応ができない → 開発失敗とみなされる
・システムへの要求木のは変わるのが当たり前と考える
・変更しやすいソフトの開発を心がける
・「保守性」は品質特性にも含まれる
・「保守性」は設計工程で、作りこまれる
☆保守の分類3
防止のための保守
☆近いうちに発生しうるトラブルを察知し、事前に対応をしておく
・予想される障害
ハードウェア障害、データベース障害・・・
・運用管理者は全部を見る必要がある
・迅速に対応できるように、運用管理者向けの「障害対処マニュアル」を準備する
・障害原因の切り分けが一番重要
・運用管理できるように教育・訓練を実施する
2015年11月27日金曜日
BO3が面白くてやばいw
2015年11月5日木曜日
自分の知識定着のための投稿#4
先週やろうとしてたの忘れてた~
管理の考え方
管理とは
ある基準から離れないよう、全体を統制すること
プロジェクト管理
-プロジェクトとは、独自の製品、サービス、所産を創造するために実施される
有機性の業務
プロジェクトの要件明確な目標
-映画の完成や建築物の完成など具体的な目標明確な期限
-完成予定日、作業完了期限、納品日といった具体的な締切限定された資源
-使える資源の能力と人数、資産、原材料といった人・モノ・かね・情報などの目標のために使えるソース進め方の枠組み
計画:PLAN
-企画を制約条件(目標,期限,資源)に沿うように基本計画(BLP:Base line plan)として具体化する
実施及び追跡:DO
-計画を実施し、状況が計画に沿っているかを追跡確認する管理:SEE
-実績値と計画値を比較し、必要に応じて手当(措置)をするしかし、これは実際の仕事では実現的ではなく計画が無理だったら新しい計画を常に更新をしていきその最終目標が達成できる計画を立てて行くことが実際の現場では大事なことらしい
計画策定
いつ、何を、だれが行うか、いくらお金がかかるかを明示する作業内容・要因稼働・予算 ← 明確化する
↓
いずれかを基準にして計画を策定する
例
作業内容基準 = 作業に必要な要因と稼働日数 × 一人当たりの費用
要因稼働基準 = 業務に動員可能な要因と稼働日数 × 一人当たりの予算
予算 = 予算で確保できる要因と稼働日数 × 一人当たりの予算
主要となる要因に基づいて計画をする
予算計画
事業の分解と作業定義
-事業を作業に分解し、各作業を定義する。作業の細分化と順序によってこれを定義する
作業の見積もり
-定義された作業に必要となる作業日数および稼働量(必要人数等)を見積もる
経理の見積もり
-作業の見積もりから、その作業の経費(人材費、管理費、諸費用等)を算出する
費用の考え方
人月
一人が一ヶ月で行うことのできる作業量(工数)を表す単位
見積もりとしては、あるプロジェクトにかかる経費は4人月(4人であれば一ヶ月,一人であれば4ヶ月かかる作業量)と定義したりする(他にも人日,人週とかもある)
2015年11月1日日曜日
WOT WN8レーティング吟味報告
WOT WN8レーティング報告
今回の議題は上のとおりにWN8レーティングをみようということで
最初に見てみましょう
最近の調子はこんな感じとなっています。
今日の成績がすごく悪かったのですが
1000戦の成績は順調に上がっているといっていいでしょう~(うれしいぜ
ティア帯でいうとこのところ7,8を中心として活動していますね
T43 , T20 , 50t
とこのあたりを使っているのですが
まあ、中戦車にはまってしまったというあたりですねw
T43をT20が来るまで使っていたので、使い心地はT43がいいのですが
戦車別のレーティングでいうとT20のほうがいいという感じで
まだまだ分からないというところですね
あとは、勝率が悪くなってきているのでなんとか
盛り上げたいところです
登録:
投稿 (Atom)