Home > ソフトウェア工学 Archive

ソフトウェア工学 Archive

学生症候群

 学生症候群(Student Syndrome)とは、期限が近づいてから慌てて宿題に着手する学生のように、期限があればあるほど作業の開始を遅らせてしまうことを指す。学生症候群によって、プロジェクトの各作業に用意されていたバッファが使い切られてしまう。突発的なトラブルが発生すると、プロジェクトに致命的な被害を与える可能性が高い。

試験工程の研修を受けてきた

 100802(月)~100805(木)までの4日間、会社で必修となっている試験工程に関する研修を受けてきた。会社の研修なんてあんま意味なんいじゃね・・・?っても思うこともやまやま。が、結局人の捕らえ方次第、機会を生かすも殺すも自分次第。思うことがあったので、忘れないようにするためにココに記す。

研修の目的

  • 試験(テスト)に関係した尺度の意味を理解する。
  • 試験(テスト)を行うための基本的な技法を身につける。
 試験工程に関する最低限の知識を手に入れて、仕事で生かしましょうね、ということだと理解。

研修内容

 試験の目的に触れ、試験の基礎知識、試験のプロセスについて、演習を交えながら進めていく。演習では単体試験デシジョンテーブルや結合試験項目表の作成、相手の結合試験項目表に沿って実際に試験を行い、故障処理票を起票する、といったことを行う。講義60%、演習40%といったところ。

思ったこと

 SEとして実際に職場に配属されてから1年経った。試験工程も経験済みだ。試験工程でよく思っていたのが、「バグは見つからなければ良い」ということ。バグが見つかれば、解析・修正に時間がかかる。何より面倒くさいし。そんな中受けたこの研修。
 
 『そもそも試験工程の目的って「バグを見つける」ことですからね』

 1日目の講義開始から10分後に講師が述べた。試験工程を教える講師として当たり前の、いや、SEとして至極当たり前のこの言葉にハッとなった。

 ――俺は今まで、この基本をすっかり抜けたまま試験をしていた。

 上記でも述べたように、バグを見つけたときの面倒くささといったら半端ではない。原因の特定、故障処理票起票、お客様への事象説明、再発防止策の説明、試験環境への再リリース、試験の再実施・・・と簡単に思いつくだけでもたんまりある。
 俺がバグを見つければ、もちろんこの手順を踏むが、積極的にバグを探そうと躍起になっていたかというと、そんなことはしてない。試験項目に沿って、ただ淡々と試験項目を消化して、エビデンスを確認して、どうせ大丈夫でしょ・・・という気持ちでやっていた。

 反省。

ずっと受けたかったソフトウェアエンジニアリングの授業(1)
鶴保 征城 駒谷 昇一
翔泳社
売り上げランキング: 61285
おすすめ度の平均: 3.5
3 講義で使いました。
3 初級の本
3 SEの入門書としてはいいかも
4 エンジニアリングとしてのソフトウェア工学を学べる
3 充実しています


ずっと受けたかったソフトウェアエンジニアリングの授業(2)
鶴保 征城 駒谷 昇一
翔泳社
売り上げランキング: 64224
おすすめ度の平均: 4.0
4 工学としてのソフトウェア開発を学ぶ

 今、ちょうど試験工程に関する改善をテーマにQCストーリーを作って、稼動と品質をよりよくしようとしているところ。システム開発(試験)では、お客様に要求されるレベルの品質を確実に、かつ効率的に確保することが求められている。牛丼じゃないけども、はやい、やすい、うまい、を求められている。それに貢献してやろう。うん。考えて、実行する。

ダストトレイル

 「ダストトレイル」という言葉を初めて知った。流星群の流星物質の集団の名称として使われる言葉らしい。塵で出来た道。「塵も積もれば山となる」、ならぬ、「塵も積もれば道となる」か。塵と思っているようなことでも積もりに積もれば、きれいな道となるのか?

 友達のC言語・構造体の課題を手伝った。結構簡単だったけど、C自体久しぶりで、人に教えながらだったので、なかなか進まず3時間かかった。最終的にうまくいったのでよし。教えるのは、こっちも勉強になるな、と再確認。すぐにその後の研究に生かせるプログラミング記法を身につけることができた。

 研究の行き詰まり。SCORMの限界を知る。完全に個人的なメモだが、cmi.suspend_dataというSCORMデータモデル要素には、

1.データはASCIIフォーマットで転送されなければならない。その後、SCOは要求された形式に変換する。

2.LMSの過度の負荷を避けるために、この要素は4096バイトのデータ(量)に制限されるべきである。

という制限があるらしい。駄目じゃん。4キロバイトって全然データ送れないじゃん!ASCIIだから日本語そのままじゃ送れないじゃん!まぁそれでも戦うがね!

 ビーグルクルーがいいけん!聞けば聞くほど深みが出るです。必殺ウラオモテの音源もGETしたので、聴きこんでいこーと思います。

<追記>
パンヤを再インスコしたw

3時間に及ぶゼミで感じたこと、学んだこと

<先生たちからのお言葉>
・できて当然のとこ・・・そこで詰まってたらむなしいだけや
・すぐできるよ!
・わかってないでしょ?

うー悔しいす!ちくしょう、勉強不足や。

<決意表明>
・研究時間=平日は1日最低5時間
・今持っている本を読む
・1日50~100ワード検索する

自力で卒業論文に必要と言われている時間、350時間をクリアしたい。
現在170時間ぐらい?

<プログラミング(コーディング)・デバックの基本>
・まずは簡単な例から始める!
   → 簡単なものから着実に進めていく
・STEP BY STEPで!
   → 最初は、一気に同時処理せず、1つ1つ進める
・いきなり本番データを使用しない!
   → テストファイルを作り、何個かクリアした上で、最後に本番のデータにあてる。
・楽な方法、できる方法でやる!
   → まずは動かすことが大事
・利用できるものは利用する!
   → リユース、リユース!

毎度勉強になります。ちくしょー!
使える知識がんがん増やすぞ!

神を見た昼下がり

昨日のゼミで、見事に准教授に粉砕される。
今後の方針が見えてこない恐怖に、教授のもとへ。

不安を述べると、教授は笑顔で
「まぁだいじょーぶですよ、あはは」
肩の荷がおりた。

オブジェクト指向や研究(ツール開発)の進め方について講義を受け、今日の空いている時間に一緒にソースコードを見ましょうということに。

そして、今日・・・
神を見た。

一ヶ月近くやっていたところが2時間でほぼ終わった。
全体の進捗状況ではまだまだ半分もいっていない気がするが、
それでもかなり進捗した(と思われる)。

教授の言った事をメモ。

<デバック・プログラミング手法>

・ソースコードを一行一行追うことはやめろ
   → パニックになるらしい。めどをつけて、そこを攻める!
・手を動かす!トライ&エラー!
   → 頭で考えすぎずに、とりあえず、試してみる!
・アラートとコメントアウトでわからないところをつぶす
   → デバック時。他のウィンドウにコメントを出せるようにするとなお良い。一つ一つの挙動を追う。


よし。もっといいものにできるようにする!
んで、わからなくなったら、また行こう!
相談する人がうまく生きれる!

Home > ソフトウェア工学 Archive

Calendar
« 2020 年 10月 »
Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Twitter
InBook.jp
 

携帯百景
携帯百景 - konpan
影響を受けた本


Return to page top