人気ブログランキング | 話題のタグを見る

備忘録&状況報告


by rhizomesara
カレンダー
S M T W T F S
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

久々のエキサイトブログ

すっかり忘れていた。。。。
# by rhizomesara | 2012-07-29 06:04 | other

平成20年(2008)

7月 クリアファイル製作開始 http://cf.jiin.com
# by rhizomesara | 2008-07-20 02:33 | RZ年表

EPM(日立)

※日立システムからの引用です。

EPM(Enterprise Performance Management/企業パフォーマンス管理)は、経営情報をビジュアル化し、分析機能を提供することで、経営の迅速化を図る問題発見および解決を支援する・・・らしい。

日立システムの EPM ソリューションは、経営の可視化を実現するための
KPI(Key Performance Indicator:主要業績評価指標)や、経営情報を分析するためデータウエアハウス化を行なうBI(Business Intelligence)などのテクノロジーを活用。

リアルタイムなビジネス判断および分析機能を提供し、経営における意思決定を迅速に支援するということらしい。

フェーズ1
経営課題の分析と経営指標(KPI)導出

フェーズ2
経営指標(KPI)のビジュアル化
BIツールを用いてKPIのモニタリング環境を構築

フェーズ3
経営課題を解決するための業務システムの改善
当社が培った多種多様な業務システム開発技術を用いて、経営課題を具体的にシステム改善につなげます。。。。



とのことですが、
こういうのはどんな会社が導入するのだろうか・・・・ちょっと不思議。
コンサルの会社向け?
# by rhizomesara | 2007-09-10 14:49
アジャイルソフトウェア開発(agile software development)は、迅速かつ適応的にソフトウェアを開発する軽量な開発手法群の総称である。

XPはその中の一つ。

XPには、開発チームが行うべきいくつかのプラクティス(習慣、実践)が定められている。これらのプラクティスを実行することが、XPを実行することと言える。

初期では12のプラクティスがあったが、数度の改定を得て数が増え、対象者の立場ごとに4種類に分類されるようになった。しかし本質的には変化することなく、その内容をより理解しやすくするための改定となっている。

■■■共同のプラクティス■■■
[反復]
開発を反復から構成する(⇒反復型開発)。全体の開発期間はイテレーションと呼ぶ1~2週間の短い期間に区切り、イテレーションごとに部分的な設計・実装・テストを行い、半完成品システムのリリースを繰り返す。またより小さな単位の単体機能の実装も、コード修正とテストの繰り返しによって進める。このように反復によって、徐々に完全なシステムを構築していく手法を取る。このことで、リスクを最小限に抑えつつ、イレギュラーな変更に対応した開発が可能になる。

[共通の用語]
用語集を作成し、チーム全員(開発者・管理者・顧客)の使用する用語とその概念の不一致を解消する。

[開けた作業空間]
会話しやすく、作業に打ち込める雰囲気を作る。

[回顧(頻繁な振り返り) ]
現在の状態を明確に把握しつつ、過去のフィードバックを迅速に反映させるよう心がけ、そのための環境、体制を構築しておく。

■■■開発のプラクティス■■■
[テスト駆動開発 ]
実装を行うより先に、自動化されたテストないしは手順の明確化されたテストを作成する。実装はそのテストをパスすることを目標に行う。テストを先に作成することで、求める機能が明確化され、シンプルな設計が可能になる。

[ペアプログラミング ]
二人一組で実装を行い、一人が実際のコードを書き、もう一人はそれをチェックしながらナビゲートする。この役割を随時交代しながら作業を進める。これによって、細々した問題解決に要する時間が短かくなる、常にコードレビューを行うことができる、集中力が持続する、コードの詳細を理解したメンバーが常に2人以上いることで後々のコード共有に役立つ、などの多彩な効果が得られる。

[リファクタリング]
完成済みのコードでも、随時、改善処置を行う。この際、外部から見た動作は変更させずに、内部構造がより見通し良く優れたものになるようにする。テストが作成されていることが前提になる。

[ソースコードの共同所有]
誰が作ったソースコードであっても、開発チーム全員が断り無く修正を行うことができる。ただし、全てのコードに対する責任を、全員が担う。

[継続した結合]
単体テストをパスするコードが完成するたび、すぐに結合テストを行い、問題点や改善点を探す。少なくとも一日に一回は、結合テストを行う。

[YAGNI]
You Aren't Going to Need It(今必要なことだけ行う)。先の事を考えて、前払い的に機能を増やし、実装を複雑化させる事は避ける。むしろ無駄な機能があれば削りとり、今必要な機能だけのシンプルな実装に留めておく。このことで後のイレギュラーな変更に対応しやすいようにする。

■■■管理者のプラクティス ■■■
[責任の受け入れ]

[援護]

[四半期毎の見直し]

[ミラー]

[今どういう状態かをチームに知らせる。]

[最適なペースの仕事 ]
知的作業には週40時間の労働時間が最適である。特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さない。そのため、計画的に開発スピードの調整を行う。

■■■顧客のプラクティス■■■
[ストーリーの作成 ]
求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い、詳細を決定する。

[リリース計画 ]
どのストーリーをどのイテレーションの対象とするか、チームミーティングで主体となって提案し、合意の上で最終的な承認を行う。

[受け入れテスト ]
イテレーションごとに顧客の立場からテストを行い、ストーリーが実現できているか、望むシステムになっているか確認する。もし満足できない場合は、それを指摘する。

[短期リリース]
これらの個々のプラクティスが、お互いを補いあい補強しあう事で、XPという一つの方法論を成り立たせている。

しかし、ソフトウェア業界の現状においては、この全てのプラクティスを同時に実行することは非常に困難であるため、テスト駆動開発やリファクタリングなど、単独でもある程度有効なプラクティスだけが、一部導入されているケースが多い。
# by rhizomesara | 2007-08-19 04:06
ソフトウェア開発方法論の1つで、最も基本的、一般的な開発モデル。プロジェクト全体をいくつかの工程に分割し、各工程での成果物(仕様書や設計書などのドキュメント)を明確に定義し、その成果物に基づいて後工程の作業を順次行っていく開発モデル。

 ウォーターフォール・モデルでは、開発プロセスをソフトウェア開発ライフサイクル(SDLC:software development lifecycle)などに沿って、「要求」「仕様」「分析」「設計」「プログラミング」「検査」「運用」といった形に分割する。そして例えば設計工程で設計書を作成し、その設計書に基づいてプログラミングを行うといった手順でプロジェクトを推進していく。成果物は各工程ごとに検証され、所定の手続きで承認されたものだけが次の工程へ進む。原則的にこの順序を飛び越したり、逆戻りしたりすることを許さないため、滝の水が流れ落ちる様子にたとえて、ウォーターフォール・モデルと呼ばれる。

結局、途中での仕様変更をするのに手間がかかり、効率もイマイチなので、RZは採用していない。
やはり使いながら柔軟に仕様変更する反復型プロセスでないといけません。
# by rhizomesara | 2007-08-19 03:51