スポンサーサイト

 --------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

スポンサーサイト の続きを読む


カテゴリ :スポンサー広告 トラックバック(-) コメント(-)

wikiを使ってシステム開発を効率化できるのか検証する ~第1回~

 2009-01-27
要件変更、仕様変更、連絡事項、情報共有、、etc
システム開発には様々な情報が飛び交っています。

それをコミュニケーションツールであるwikiを使う事で
効率化(コスト削減)できるのか?

直に答えは出ないので、
これからココで順次報告して行きたいと思います。

まずは環境構築。
使いやすさから、xamppとpukiwikiで構築。
以下参考URL
http://www.apachefriends.org/jp/xampp-windows.html
http://pukiwiki.sourceforge.jp/

便利なもんで、30分位でできます。

次に、
出始めのコンテンツとして、
会議のたたき台となる、前回の打合せ議事録をアップ。
QAで使う為の掲示板も作成。

一旦これでお客さんにwikiを使った進め方を提案予定。


次の課題
・wikiの表記ルールをお客さんが面倒と思わないか?
・RSSリーダでの発信トリガーを上手く周知できるか?

皆様からも有用な情報を教えて頂けると助かります。

wikiを使ってシステム開発を効率化できるのか検証する ~第1回~ の続きを読む


システム開発に困ったら、、、

 2008-03-20
どうも開発が上手く進まないとか、
何から手をつけていいか解らないってなったときに
これはいかがでしょうか?

ジョエルテスト

詳しくはリンク先を読んで頂いたほうが理解しやすいと思うのですが
概要は以下です。

1. ソース管理システムを使っているか?
2. 1オペレーションでビルドを行えるか?
3. 毎日ビルドを行うか?
4. 障害票データベースを持っているか?
5. 新しいコードを書くまえにバグを修正するか?
6. 更新可能なスケジュール表を持っているか?
7. 仕様書を持っているか?
8. プログラマは静かな労働環境にあるか?
9. 買える範囲で一番良い開発ツールを使っているか?
10. テスト担当者はいるか?
11. プログラマを採用するときにコードを書かせるか?
12. 「廊下での使い勝手テスト」を行っているか?


私的には、、
1. ソース管理システムを使っているか?
これは開発規模に関係なく必須、
ぜひ導入しましょう、CVSならフリーで、windowsでも簡単です。

2. 1オペレーションでビルドを行えるか?
これはスクリプト言語なら無視ですかね。
要は、「決まった手順は自動化しましょう」と置き換えていいかも

3. 毎日ビルドを行うか?
毎日結合テスト。
誰かが触った箇所が他に影響を及ぼしてないか?
2と近い感じ。
ユニットテストとかを自動化できれば言うこと無し

4. 障害票データベースを持っているか?
これは当然。
記載する内容は同サイトより
* バグを再現する完全な手順
* 正しい動作
* バグの現象
* 誰が直すべきものか
* バグが修正されたかどうか
を書くとの事。

5. 新しいコードを書くまえにバグを修正するか?
6. 更新可能なスケジュール表を持っているか?
7. 仕様書を持っているか?
これらも当然といえばそうなるでしょう、
こういう事を後回しにしていくとどんどんデスマへ突入です。
最近はちゃんとしているプロジェクト増えてきた気がします。

8. プログラマは静かな労働環境にあるか?
9. 買える範囲で一番良い開発ツールを使っているか?
これは本当に頼みますって感じ。

10. テスト担当者はいるか?
11. プログラマを採用するときにコードを書かせるか?
12. 「廊下での使い勝手テスト」を行っているか?
文化の違いを感じました。
ここまでできたら良いですよねー

という見解です。

早速次の4月の案件から試して見ます。
結果はまたブログで、、


システム開発に困ったら、、、 の続きを読む


今日のブックマーク ~性能品質~

 2008-03-07
参考記事

@ITより 保存版 性能品質の作り方

今までなんとなくで行ってた性能品質
「動けばいいや」を目標に完成したシステムで
思った以上に性能が出なくて、
もう手を打てません状態にならない為のヒントが、
工程ごとに解り易く説明されています。

自分なりに気付かされた事は、、

要件として、、
■モニタリングできる仕組みを要件定義の段階で考慮しておく
 超簡単に言うと、想定閾値でのレスポンスタイムとそれを計る為の手段(ログ等)
■性能の有効期間も考慮する
 例えば有効期間を5年として、1年目のデータが1万件、2年目が2万件と
 増えていった時に有効期間である5年後のデータ量でも性能要件を
 満たしているかという事


要件が出揃った所で、実際のアーキテクチャ構築に入ります。

これは色々なパターンがあるので適時考える必要があるのですが、
(SEの一番の腕の見せ所かもしれません)
まぁ、この処理は重そうなのでバッチにしようとかここはSQL一発でとか
そういう所をよく考えてねって事です。

さらにプログラミングにはいって、
無駄なループや不要な条件分岐、メモリ食いすぎ見たいな点をチェックしつつ、


テストに突入、
単体テストで思ってる性能がでないと、
当然のごとくそれ以後では性能は確保できないので
ますは単体レベルで整えていきます。


そしてめでたく完成!!

と思う前に、

運用レベルので性能監視と診断レベルを決定
このあたりは最初の要件定義の品質が効いてきます
実際の運用ルールまで要件定義の段階から頭に入ってないと
保守の名目でとんでもない事になってしまいます。。

上流工程恐ろしや、頼むから変なモノ作り逃げしないでね。


よろしければポチっとお願いします。(変な所には飛びません(^^))

今日のブックマーク ~性能品質~ の続きを読む


障害対応と原因究明

 2008-02-05
プログラムバグがあったので修正しました、
もうリリースしたので問題ありません。」

これは障害対応であって、原因究明ではない。

不具合報告書にこういう事が書かれて終わっているのを
たまに見る事があります。

僕も昔はこれで何か問題でも?って思っていたのですが、
これは対応が終わっているだけで、原因を解決していません。

いわゆる対処療法みたいなものです。

「カゼひいたので風邪薬飲みましたー。
もうひきません!」

そんな事は無いはず、
薬をのんでもまたカゼひきます。

何でカゼ引いたのか?
・1日中寒い中で外にいてたから
・周りにカゼひいてるひとがいてたから
・仕事が忙しくて疲れていたから
これらが原因のハズ。

これをシステムに置き換えると

なぜバグが出たか?
例えばこういうのは原因となる。
・開発者の技術不足
・仕様認識不足
・単純ミス

ここからさらに「なぜ」とか掘り下げて行けばいい。
この場合だと原因究明の行き着く先は、

原因】 → 【対策案】
技術不足 →  教育実施
単純ミス →  レビュー体制見青し
とかになって、障害が減少していくって言うシナリオは立てれる。

最初に戻って、
不具合報告書に原因はプログラムミスでした。。
それを集計したところで一番の原因はプログラムミスでした。
で?

よろしければポチっとお願いします。(変な所には飛びません(^^))

障害対応と原因究明 の続きを読む


CMMIとアジャイル開発

 2008-01-09
最近CMMIの話題が身近に近づいてきてる。
うちの会社でもレベル3の取得を目指しているみたい。

個人的にはアジャイルのような、開発スタイルが好みなんですが、
なかなか理解し合える人とは出くわさないので実施する機会は少ないです。

要件変更が頻発するのが目に見えてるときなんかは
有効なんだけどなぁ。。

CMMIですか。。

定義されてるドキュメントを全てそろえるのだけでも
かなり大変そう、、
そりゃ正論では必要かもしれないけど、
それはそれで手間と技術が必要だし、
維持も難しいんではないだろうか。

大規模ではCMMI準拠でウォーターフォール
小規模ではアジャイルXP、反復開発
大規模でも細分化してXP、反復開発!

結局どっちが正しいもないので
どういう手法をとるかも腕次第なんだよね。

やっぱり上流(当事者)で全てが決まる。

よろしければポチっとお願いします。(変な所には飛びません(^^))

CMMIとアジャイル開発 の続きを読む


≪ トップページへこのページの先頭へ  ≫ 次ページへ ≫
halken800 Twitter
最近の記事
カテゴリー
タグリスト
最近のコメント
最近のトラックバック
広告



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。