正式には、 「ソフトウェア構成管理」 (Software Configuration Management: SCM) と言います。 「ラショナル統一プロセス」 (Rational Unified Process: RUP) では、 「構成および変更管理」 (Configuration and Change Management: CCM) などとも呼ばれます。 では「構成」とはなんでしょう？
Pearson and Google Jump Into Learning Management With a New, Free System One of the world’s biggest education publishers has joined with one of the most dominant and iconic software companies on the planet to bring colleges a new—and free—learning-management system with the hopes of upending services that affect just about every instructor, student, and college in the country. We’re sorry. Somethi
新人エンジニアとその先輩たちへ、OJTの前にこの本「ずっと受けたかったソフトウェアエンジニアリングの授業」を 4月に新入社員として入社した新人エンジニアの方々は、早ければそろそろOJTという形で現場にやってきて、若手の先輩社員が新人の教育担当、あるいはOJTリーダーに任命される時期。 そんな新人エンジニアと教育担当におすすめしたい本を今回は紹介します。 プログラミングテクニックの解説は一切なし 一般にソフトウェアの開発は、顧客と相談して仕様を考え、それを外部仕様書、内部仕様書といったドキュメントに落とし込み、プログラミングを行い、ソースコードレビューやインスペクションを行い、単体テスト、結合テスト、運用テストといった工程を経て完成します。いわゆる「Vモデル」と呼ばれるものです。そしてこれらは1つのプロジェクトとしてマネジメントされます。 こうしてみると、ソフトウェア開発の中でプログラミング
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
下記Blogで、これがやりたいことなんだ！と思ったのでメモ書き。 【元ネタ】 実践バグ管理―プロジェクトを成功に導くための (単行本) - watawata日記 まあ要するに僕が読みたいのはバグ管理も含めた構成管理とか開発プロセスの本なんだｗ。 僕が考えるプロジェクト管理サーバーのイメージは下記の通り。 RedmineやTracのようなプロジェクト管理機能を持つBTSをチケット駆動でタスク管理する。 Subversionで、ソースコードだけでなく、WordやExcelの仕様書もバージョン管理する。 更に、trunkとブランチを上手に使い分けて、メインラインモデルとしてコードラインを並行開発する。 Hudsonで、継続的インテグレーションを実現するだけでなく、並行に走らせて、ビルドや自動テストの工数を短縮する。 TestLinkで受入テストを効率化する。 VMWareでテスト環境、本番環境を
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
■ [git] WEB+DB PRESS Vol50の「はじめてのGit」が神記事 読み終わった。 477413838X なんといってもメンテナ自らが書いてるということで、言ってみれば世界一Gitに詳しい人(の一人)による入門記事なわけですよ。 紹介されているコマンドは以下の通り。 git add : ファイル・変更の追加 git commit : コミット git diff : 差分 (git diff, git diff --cached, git diff HEADの違いも！) git status : ワークツリーの状態を表示 git show : あるコミットの情報を表示 git log : コミット履歴 git blame : gitk : GUIツール git revert : コミットの取り消し(あるコミットを打ち消すコミットを行う) git checkout : ファイル
複数のプロジェクトを並行して進めた経験のあるプロマネやデベロッパなら、「どうプロジェクトの進捗を管理・共有していくか」に一度は頭を抱えたことがあるはずだ。日々発生する要望・バグ・修正の作業に追われるだけになってしまい、プロジェクトが混乱・迷走することもよくある話。「管理さえしておけば」と後悔する前に、プロジェクト管理の手法を確立しておきたいものだ。 そこで、本稿では、プロジェクト管理に特化したWebアプリ「Redmine」について、インストールの手間から運用面までふくめて紹介しよう。 複数プロジェクト対応、Webブラウザで完了、日本語もOK プロジェクト管理Webアプリケーションの筆頭といえばtracが挙げられるが、ここ数年の間でRedmineが注目されつつある。 RedmineはJean-Philippe Lang氏が中心となり開発・リリースしている、プロジェクト管理に特化したWebアプ
僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。 【プロジェクト管理サーバーのイメージ】 そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。 基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。 タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。 RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。 つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。 バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。 バージョン管
「優秀な若手が一生懸命に働く。しかしプロジェクトは成功を収めることができず，若手は結果的に燃え尽きてしまう。その責任はプログラマやエンジニアよりもマネジメント側にある。長い間，マネジメントを何とか変えようと考えてきたのは，能力の高いエンジニアを失うのが大きな問題だったからだ」。 ゆっくり，力強く語るのはジョー・マラスコ氏（写真）。長年ソフト開発の現場を経験し，米ラショナル・ソフトウェア（IBMに買収）の幹部を16年以上務めた。IT業界に35年以上在籍し，ソフトウエア開発プロセスやプロジェクトマネジメントについて思考と実践を重ねてきた同氏の言葉を紹介したい。 10年から20年前と比べて，優秀な人がこの業界に来なくなっている。この問題は日本と米国で共通している。この業界こそ，どの業界よりも優秀な人に来てほしいと望んでいるにもかかわらずだ。なぜ若い人が来ないかを問う必要がある。 日本では「IT業
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門：ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践：ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次：ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次：ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス － ＠IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine：コーナー：実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
Copyright (C) 1995-2008 Nikkei Business Publications, Inc. All rights reserved. このページに掲載されている記事・写真・図表などの無断転載を禁じます。著作権は日経BP社，またはその情報提供者に帰属します。 掲載している情報は，記事執筆時点のものです。
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
前の記事、「The Uniform Serverを使ってUSBメモリでタスク管理サーバを持ち歩く方法」では「The Uniform Server」をUSBメモリにインストールして使えるようにするところまでを解説しましたが、今度は実際にオープンソースのプロジェクト管理ツール「activeCollab」をUSBメモリで動かすことになります。 手順は以下の通り。簡単に「activeCollab」の動作画面も掲載しておきます。 ◆「activeCollab」のインストール まずは公式サイトにアクセスしてダウンロード activeCollab - open source project management and collaboration tool. http://www.activecollab.com/ ダウンロードしたら解凍し、wwwフォルダの中にまるごと移動 それから以下のアドレスにアク
ITプロジェクトのマネジメントにおいて、本書はまさに宝の山といえる。 一回の探索では持ちきれないほどのアイディアがザクザクと手に入る。しかも、ひとつひとつの宝が、著者の経験に裏打ちされ、考え抜かれているため、一回読みでは消化不良を起こす。それぞれのフェーズで読み返すことで、順番にモノにしていくやり方が良いかと。 このエントリでは、自分の振り返り読みのために、読書感想文エントリの目次と、次に読むべき本・サイトのをまとめた。わたしだけでなく、誰かの参考にもなればイイナ！ その1 ・オーバービュー その2 1章「プロジェクトマネジメントの簡単な歴史」からの考察 ・PMにとっての最重要ツール ・アート ―― 技芸と呼ぶ理由 ・ホワイトボード地獄 その3 2章「スケジュールの真実」および、 3章「やるべきことを洗い出す」からの考察 ・何のための開発プロセスか? ・見積もり確度を上げる2つの質問
This shop will be powered by Are you the store owner? Log in here
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
