CALENDAR
            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
<<Back 2020年02月 Next>>
LOGIN
現在のモード: ゲストモード
USER ID:
PASSWORD:
NEW ENTRIES
RECENT COMMENTS
■ 奥脇という名前の由来
└ s.okuaki(02/27)
└ hide okuwaki(11/23)
■ ブログを引越しします。
└ okugaku(03/07)
└ yurika(03/05)
└ OFFICE DOYU (03/03)
RECENT TRACKBACK
■ 岸和田観光農園(いちご狩り)
└ 現役栄養士のお仕事日記(04/25)
■ やっと終わった
└ MY Favorite Things(03/19)
■ PDA版にのりかえ
└ 大阪でWEBサイトをプロデュースするということ(01/06)
CATEGORIES
ARCHIVES
LINK
PROFILE
■ okugaku(2088)
POWERED BY
script by Blogn+
skin by vivid*face
OTHER
■ RSS 1.0
■ 処理時間 6.511145秒
SEARCH
体重計

機能見積り
システムのお見積りって人月というのが、ほぼ常識。

でも私は人月で計算するのが大嫌い。作業効率とかが全く考慮されないうちに出てくる人月って大嫌い。

基本的には、作成する機能、その難易度などで細かく計算すべき。

最近はその様な見積り手法を取入れようとしている流れが有るようです。ファンクションポイント法とか
でもそれで成功した事例を少なくとも私はしらない。

なかなか難しいんでしょうねそれらへんを基準的に数字化するのが。

| テーマ::システムネタ | 11:39 PM | comments (0) | trackback (x) |
品質保証
システム開発で留意しなければ行けないのが、品質保証。

システムの品質保証は世界中の中で日本が世界一といわれている。

しかし、それは大企業だけの話で中小企業では品質保証をきちんとしているかどうか疑わしいもの。

かくいう私も、必要最低限という感じでやっている部分が多いので多いに反省すべき所。

実はシステム開発では開発の工数より、テスト工数の方が多い事が多々有る。

テストの方法もさまざま。最近ではテストをするプログラムを書いて行くうちにシステムが自然と出来上がるのが理想ともいわれている。

そんなレベルまでできるような体制をつくりたいです。

| テーマ::システムネタ | 11:43 PM | comments (0) | trackback (x) |
プロジェクト管理
前回は開発手法のことのさわりを書いたので、今回はプロジェクト管理のさわり。

プロジェクト管理ってなにをするものか。それはプロジェクトの計画、定義、進捗管理、品質管理、リスク管理等をするもの。

これも勉強しだすときりがない。最近はPMBOKが注目されているが、これは結構大変。

PMBOKとはなにか。それはプロジェクト管理をするうえで、どのような事を考えて遂行すれば良いかといったような知識を体系立てて書いているもの。

ざっとこんな感じのことを書いています。ここのページのものから抜粋しました。

(1)総合マネジメント
プロジェクト計画の策定、プロジェクト計画の実施、変更管理
(2)スコープマネジメント
プロジェクトの立ち上げ、スコープ計画、スコープ定義、プロジェクト成果物の検収、スコープ変更管理
(3)タイムマネジメント
作業定義、作業順序設定、作業所要時間の見積、スケジュール作成、スケジュール管理
(4)コストマネジメント
資源計画、コスト見積、予算設定、コスト管理
(5)品質マネジメント
品質計画、品質保証、品質管理
(6)組織マネジメント
プロジェクトの組織計画、要員の調達、チームの育成
(7)コミュニケーションマネジメント
コミュニケーション計画、情報の配布、進捗報告、プロジェクト完了手続
(8)リスクマネジメント
リスクの特定、リスクの定量化、対応策の策定、リスク管理
(9)調達マネジメント
調達計画、引合計画、発注先選定、契約管理

いろんな本を読んで勉強はするけど、たかだか2,3人規模のプロジェクトで使用できるもんではないなという実感がします。

そんなことをすると「管理工数」だけで「製作工数」を上回ってしまう・・・

着目点だけはもらっておきます。

| テーマ::システムネタ | 11:20 PM | comments (0) | trackback (x) |
アジャイル開発
ソフトウエアの開発手法は数あれど、私が理想的に考えている手法はアジャイル開発プロセス。

アジャイル開発とは変化に対して機敏な対応ができる開発手法のこと。

手法に関しては、いろいろ乱立していて、それぞれ毎に利点欠点がある。
システム会社もよく適用しようとするけど、失敗するケースが後をたたない。

全員がきちんと手法と目的を理解しない限りはすぐに失敗するだろう。

今日は手法の紹介をするのではなく、アジャイルの基本的な考え方を紹介しましょう。

アジャイル提唱者達のが考えた「アジャイルソフトウエア開発宣言」

・プロセスやツールより「人と人同士の相互作用を重視」する。
・包括的なドキュメントより「動作するソフトウェアを重視」する。
・契約上の交渉よりも「顧客との協調を重視」する。
・計画に従うことよりも「変化に対応することを重視」する。

アジャイルソフトウエア開発の原則

1. ソフトウェアの早期,継続的な納品により, 顧客の満足を達成することが第1優先である.
2. 開発の終盤であろうとも、要求内容の変更を歓迎する. アジャイルなプロセスは, 顧客の競争上の優位性のため, 変化を制する.
3. 数週間から数ヶ月間のサイクルで動作するソフトウェアを納品する. サイクルは短い方が良い.
4. ビジネス側の人間と開発者がプロジェクトを通じて日々協力をしなければならない.
5. 志の高い開発者を中心にプロジェクトを編成する.必要な環境や支援を与え, 任務をやり遂げることを信じなさい.
6. 開発チームの内外でもっとも効率的で、効果的な情報伝達を行う手段は, 顔をつき合わせて話し合うことである.
7. 動作するソフトウェアが, 主たる進捗の確認手段である.
8. アジャイルなソフトウェア開発は、持続的な開発を促す. 開発資金の提供者、開発者、ユーザは、必ず一定のペースを守れるべきである.
9. 技術力と良い設計に絶えず気を配ることで、機敏さは向上する.
10. 不必要なことを行わない技能である簡潔さは、本質的である.
11. 自己組織化されたチームから最善のアーキテクチャ, 要求, 設計が生まれる.
12. 定期的に、チームはもっと効果的になる道を考え、開発の進め方を調和させ, 調整する.

| テーマ::システムネタ | 11:58 PM | comments (0) | trackback (x) |

  PAGETOP