協力会社とのつきあいかた

投稿者

投稿内容

まる: 常連さん; 会議室デビュー日: 2005/08/09; 投稿数: 21

投稿日時: 2005-08-18 01:11

引用:
Jittaさんの書き込み（2005-08-17）より：１．　これって、「機能仕様定義からテストまでお願いします」とか、「機能仕様はこれなので、詳細仕様定義以降をお願いします」って、発注するんですか？

顧客とのヒアリングから(要求仕様定義)参加してもらう場合もありますし、
要求仕様書を作成後の仕様を考える段階から(機能仕様定義)参加してもらう場合や、
機能仕様書を作成後の仕様を詳細化してコードに落とし込む段階から(詳細仕様定義)参加してもらう場合もあります。
デスマーチとなってテスト工程から参加してもらう場合もあります。

「マトモでない」パターンはたくさんあるのでキリがないといえばないのですが、
基本的には期日に予定通りに検収できないことを「マトモでない」と判断しています。

一番多いパターンは期日にはなんとかプログラムはあるけど、
受け入れテストを行うと不良が多発して使い物にならないというパターンです。
事前に進捗と不良の摘出率を見てれば検収時に受け取れないのは予想できますが、
相手が期日どおりにできると主張しているものを当方で否定するのも難しいので。

次に多いパターンが要求仕様・機能仕様の考慮漏れでしょうか。
レビューで見つかれば問題ないですが、テスト工程で発覚した場合は納期遅れにつながります。
レビューで発見すれば手戻りは少ないですが、
気合を入れてチェックしなければならないのでこっちが疲れます。

プログラムに問題がなかったとしてもいろいろ問題があります。
SE個人の問題と会社の問題が混じってます。

■技術
・ソースの抽象化不足(1000行中20行しか違わないソースが複数箇所に散在)
・車輪の再発明(ライブラリ使えば1行なのに1000行くらい書く)
・遅いアルゴリズムの選択(性能問題)
・コメントがない、コメントが間違っている

■倫理
・SE単価の捏造(初級SEを中級SEにみせかける)
・進捗度合いの捏造
・無断で仕様改変
・顧客への暴言メール
・他社のソースの無断借用
・常駐・専任のはずが他社作業をする。しかも他社作業分の時間まで請求
・会社に出社しない
・寝る
・業務中に2ch等を閲覧

許せる要素もなくもないのですが、ハズレの場合はたいてい複数の要素を兼ね備えています。

引用:
Jittaさんの書き込み（2005-08-17）より：２．　最近思うのですが、テスト工程って、コーディングの後ろにあるのでしょうか？言い直すと、「テストする項目／内容を決める」ことを、コーディングの後ろに行うのでしょうか？

Jittaさんのおっしゃる手法が大変有効であることも理解しています。
V字モデルどおりに機能仕様書や要求仕様書に対応するテスト項目を作成することでプログラマの思い込みを修正できるので。

ただ、ウチではテスト項目の作成はコーディングの後ろです。
理由は3点あります。
・ライブラリに依存する等の理由でソースコードを書き終わるまで(最悪の場合は実行するまで)仕様が決定しない場合があります。
・カバレージを意識してホワイトボックステストを行うため、単体テストは必ずコーディング終了後としています。
・ソースコードと仕様書をつき合わせながらテスト項目を作成することで、テスト前に不良を発見できる場合があります。

参考：
「Ｖ字モデル」http://msugai.fc2web.com/pgm/test.html
「カバレージ」http://www.jfits.co.jp/it_frontline/2003/1027.html
「ホワイトボックステスト」http://e-words.jp/w/E3839BE383AFE382A4E38388E3839CE38383E382AFE382B9E38386E382B9E38388.html

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2005-08-18 08:48

引用:

まるさんの書き込み (2005-08-18 01:11) より:

プログラムに問題がなかったとしてもいろいろ問題があります。
SE個人の問題と会社の問題が混じってます。

■技術
・ソースの抽象化不足(1000行中20行しか違わないソースが複数箇所に散在)
・車輪の再発明(ライブラリ使えば1行なのに1000行くらい書く)
・遅いアルゴリズムの選択(性能問題)
・コメントがない、コメントが間違っている

ん？これってSEじゃなくてプログラマーの問題では？

引用:
ただ、ウチではテスト項目の作成はコーディングの後ろです。

テストとひとことで言っても単体や結合、システムといろいろあり、またテスト計画
作成段階や、テスト項目等を出したり、テスト仕様やテストツール作成段階、テスト
の実施とテストの中でもフェーズがいろいろあるので、ひとことでどこという訳には
行かないと思いますよ。
便宜的にマスタスケジュール等大まかなスケジュールではテストは後ろの方に引かれ
ていることが多いですがね。
これはある程度、修正作業のバッファという部分も含まれますから、調整用という
感じですかねぇ。

でも、詳細に落とし込むスケジュールでは各所にテストというフェーズありませんか？
単体の単体テスト（って意味不明か？）なんて実際にはプログラミングの中に入って
たりしますよね。

で、チャチャ入れですが、

引用:
理由は3点あります。・ライブラリに依存する等の理由でソースコードを書き終わるまで(最悪の場合は実行するまで)仕様が決定しない場合があります。

実装仕様が変わろうと要件が変わらなければ、総合テスト等の項目は変わりませんよね？

引用:
・ソースコードと仕様書をつき合わせながらテスト項目を作成することで、テスト前に不良を発見できる場合があります。

まぁ、完璧な仕様書というのは無いに等しいですが、ソースコード見ながら項目を
作成するというのは、個人的には好きでは無いですね。
思い込みというのがあって、CASEの抜けが発生しやすくなってしまうように思うからで
す。項目をあげた後、テスト実施前にソースレベルでチェックするというのは時間さえ
許せばＯＫですが。

Jitta: ぬし; 会議室デビュー日: 2002/07/05; 投稿数: 6267; お住まい・勤務地: 兵庫県・海手

投稿日時: 2005-08-19 05:20

さるさん：
> 要求定義がそこできちっと終わるような事があれば可能なんですけど
わははは！！痛いところをつかれました(^-^;

　まぁ、そうなんですけど、「要求事項」が変わるなら、「見積もり」も変わってしまいますよね。まぁ、「機能丸ごと追加！」なんてことは…官公庁相手の場合、「その他、必要な一切を含む」の言葉を楯に、ねじ込まれることがあります(-.-;

　いや、ほんと、難しいと思います。規模が見えないとお金の計算が出来ないし、ざっくりやると後から「取りすぎだ」とか言われたり。。。「取りすぎだ」は簡単に言われますが、反対はないのよね。。。

　なんていうんでしょう？その辺は「変更管理」かな、と。で、
「変更した仕様」と、「変更しなければならないテスト項目」がつながっているか？
「変更した仕様」によって影響する「仕様」は把握されているか？
「変更した仕様」によって変更される、「下位の仕様」は連携しているか？
というところが問題になってくると思います。
　スレのお題から外れるのでこれくらいにしておきますが、この連携が、今の私の課題です。

まるさん：
> 基本的には期日に予定通りに検収できないことを「マトモでない」と判断しています。
　なるほど。。。確かに、それにつきますね。

　ところで、ここで言う協力会社さんは、

持ち帰り型請け負い
常駐型請け負い
派遣

のうち、「派遣」にあたるのでしょうか。

引用:
根拠：１．SE単価の捏造(初級SEを中級SEにみせかける) ２．顧客への暴言メール３．常駐・専任のはずが他社作業をする。しかも他社作業分の時間まで請求４．会社に出社しない請負であれば１は関係ないし、常駐しているから３，４が問題になってくるのかな、と。

　しかし、「期日通りに検収できない」というのは、請負のようです。
派遣だとすると、管理責任はプロパー側にあるように思うのですが？？？

«前のページへ 1|2|3|4|5|6|7|8|9

協力会社とのつきあいかた

スキルアップ／キャリアアップ（JOB@IT）