見出し画像

夢を叶えている人を観ても嫉妬しなくなった私は大人になったんだなあってことにしときましょ!

秋晴れの市内をITパスポートの問題をブツブツつぶやきながら徘徊する
鍼灸師 伊藤です。

今日はウォークラリーに参加しましたが、見事にビリでした。
優勝したチームに話を聞いたところ、綿密な計画を立ててたとのこと。
いやいや、秋を感じるために私は参加したので、段取り決めてなかったとか別に後悔なんかしてませんよ。
へのつっぱりはいらんですよ。
しかし、システム開発は段取りを決めておく方がよさそうです。
ハイ、問題

問題

ソフトウェア開発モデルの一つであるウォーターフォールモデルの記述として適切なものはどれか。

ア オブジェクト指向開発において、設計とプログラミングを何度か行き来し、トライアンドエラーで改良していく手法である。

イ サブシステムごとに開発プロセスを繰り返し、利用者の要求に対応しながら改良していく手法である。

ウ システム開発の工程を段階的に分割し、全行程の成果物に基づいて後工程の作業を順次進めていく手法である。

エ システム開発の早い段階で試作品を作成し、利用者の意見を取り入れながら要求や仕様を確定する手法である。

開発手法

システム開発は規模や種類によって開発手法も変わります。
ここでは代表的な3つを解説。

【ウォーターフォールモデル】
要件定義 → システム設計 → プログラミング → テスト
水が高いところから低いところへ流れるように各工程を順番に進めていく手法。
大規模開発向き。
デメリットは、開発最終段階にならないと利用者はシステムを確認できないこと。しかも前工程に戻って作業すること(手戻り)を想定していないという・・・
「仕様が違う」とか言われた日には・・・詰みデス。

【プロトタイピングモデル】
要件定義 → [ プロトタイプ作成 → プロトタイプ確認 ]✕∞ → システム設計 → プログラミング → テスト
試作品を作って利用者に確認してもらうことで、制作側との意識のズレを防ぐ手法。
大規模にはムリッス。
デメリットは、試作作るのも手間なんですね。
しかも利用者のインスピレーションを刺激しようものなら、エンドレスなやり直しが待っている。

【スパイラルモデル】
サブシステム① : 設計 → プログラミング → テスト
サブシステム② : 設計 → プログラミング → テスト
サブシステム③ : 設計 → プログラミング → テスト
・・・・・・・・・
サブシステム① → サブシステム② → サブシステム③ → ・・・・・・・・・
システムを分割してそれぞれ作っていく手法。
割と万能。

完成したサブシステム毎に利用者に確認してもらえるため、思い違い対策になる。

治療前の診断ってやっぱりこういうことですよね。

患者さんの困ってることを聞いて(問診)、ある程度問題の方向性を絞った上で視覚的に(視診)手の感覚(触診)や様々なテスト法で原因を断定して、治療方針を複数想定し、治療経過と予後まで想像した上で、患者さんに診察結果とそれぞれの治療のメリット・デメリットを説明した上で、治療方法を決めます。

やっぱり患者さんに信頼もしてもらいたいし、お金ももらわなきゃないとかも考えるから結構いっぱいいっぱいだったりして、ついつい「あなたの問題はこれです!」
って言ってしまいがちです。

確かに、スパって言い切って治療もハマれば患者さんも私も万々歳ですけど、当然治療効果が思ったように出ない、見落としていた要素があったとか、新たな問題が起きてきたとかってやっぱりあります。

私も人だから勘違いや間違いはあるし、患者さんも人だから機械のように一辺倒じゃないので変化も激しい。
患者さんの環境因子が取り除けないことも多いし。

そりゃあ、大体の人が「先生」みたいな立場であろうとするし、そうすべき意味があることも分かるけど、私的にはもっと患者さんのパートナー的な立場での治療体制を求めちゃいます。

治らないものは治らないから診ない方針の治療院もあるし、リスク管理の面では当然だけど私が目指すのは患者さんの人生に足りないものを足したり引いたりして、バランスを整えてあげて、少しでも充実した人生のお助けをすることなので、同じ目線でありたいし、悩みは一緒に悩んであげたいんですよね。

でも、こういうのってお金にならないんだよなー
しかも少人数しか対応できないし。
そういうのウザいって人もいるだろうし。
結局やりたいことをやるしかないんですけどね。
コンビニ以上に治療院ってあるから、患者さんも治療院選ぶのって今大変だと思います。
私を求めてくれる患者さんも多少はいるし、そういう人たちのためにこれからも頑張るだけ。
必要なくなった時は淘汰されていく、それが自然なんだと思う伊藤でした。

毎回忘れそうになる回答

ウ システム開発の工程を段階的に分割し、全行程の成果物に基づいて後工程の作業を順次進めていく手法である。

これが前工程の成果物に基づいて後工程に流れていく、後戻りを想定しないウォーターフォールモデルの特徴をよく現しています!!
ということで答えは ウ です

ITパスポートまで

残り4日。
もう〜い〜くつね〜る〜と〜♪
明日が来るのがだんだん怖くなってきました、伊藤です。
おやすみなさい。

この記事が気に入ったらサポートをしてみませんか?