発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の（1）～（3）のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
NECは、ソフトウェア開発の品質やコスト、納期の改善を目的として、ソフトウェア生産革新活動を推進しており、「ソフトウェアファクトリ」はソフトウェア生産革新活動のプロジェクト管理と、技法・ツール等のエンジニアリング面において、中心的な役割を果たしている。 「ソフトウェアファクトリ」の使用によって、開発プロセスや方法論、ツールの標準化や、ソースコードおよび仕様書などを共有が可能になるとともに、セキュリティ脆弱性検査やバグ検出などの自動化を促進して、生産性と品質の向上を目指す。また、開発状況のリアルタイムでの「見える化」によって、マネジメント力の強化を実現する。 「ソフトウェアファクトリ」の利用が拡大した結果、拠点が国内外に分散している場合でも、開発環境や仕様書などの共有によって作業のやり直しなどが減り、製造やテスト工程のコストを10～20％削減した。また、ハードウェアの用意や、プロジェクトごと
情報システムの「アーキテクチャー」にもっと目を向けるべきではないでしょうか。部分最適の積み上げで全体として必要以上に複雑で歪なアーキテクチャーになっているケース、性能問題など保守・運用上に課題を抱えて事業の採算が合わないケース。筆者の周りでもこうしたケースを見聞きすることは少なくありません。また、ビジネス上の本質的な目的を捉え、目覚ましい進化を遂げるハードウエアを活かすのもアーキテクチャー次第だといえます。 情報システムのアーキテクチャーに責任を持つのはITアーキテクトとされています。その重要性は増していますが、人数が少ないのが実情です。どうしたらなれるのでしょうか。どのように育てたらよいのでしょうか。一つの方法は、ITアーキテクトが実施していることを真似てみることだと思います。 ITアーキテクトが何かをするのであれば、そこには「成果物」が生まれます。そして成果物には必ず目的があります。そ
毎年、梅雨明けの7月末に情報化研究会のコアなメンバーで旅行会をしている。1995年以来だから今年で16年目だ。梅雨明けの時期にしているのは天候が安定していて盛夏らしい強烈な日射しや、群青色の海を楽しむことができるからだ。烈日と呼ばれる強い陽を浴びると、体にエネルギーを注ぎ込まれるように感じる。 今年は東京、名古屋、松山から12人が参加し、2001年以来、9年ぶりに高知へ行った。もちろん大河ドラマ「龍馬伝」の影響だ。前回は桂浜の龍馬像、岩崎弥太郎の生家などを見学した。今回も高知が初めてという三菱グループの方が3人いたので、この2カ所も再訪したのだが、筆者の目当ては武市半平太と岡田以蔵の墓に参ることだった。 さて、今回は企業ネットワークの設計や試験、移行の準備がきちんと行われ、サービス開始（旧ネットワークから新ネットワークへの移行開始）が可能かどうか判断する「サービス可否判定」（以下、サービス
ここにきて、アジャイル開発手法を業務システム（アプリケーション）の開発に適用しようとする動きが本格化している。これまで小規模、Webシステムへの適用が目立ったが、最近は業務システムや大規模プロジェクトへの適用事例も出てきた。アジャイルはもはや“ブーム”ではなく、本格的な普及が始まったと見てよさそうだ。 ところが、実際にアジャイルを採用した現場に話を聞くと、何とことごとく失敗している。そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。 それでも開発現場はアジャイルに望みをかけている。刻々と変わる要求やリスクに迅速に対応する必要があるからだ。最
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
SDAS（エスダス）（注1）は、開発期間短縮を実現し、お客様のビジネスのスピードアップに貢献する為の総合システム開発体系です。 新しい「SDAS」は、「短期間・高品質」のシステム開発を実現するとともに、「オープン性・国際標準」「ライフサイクル全般でのシステム最適化」「エンジニアリングとマネジメントを両輪とするプロジェクト遂行」を特長としています。 これにより、システム開発期間を従来と比べ、概ね半減することが可能となり、ITの観点から、お客様のマーケットの動きを先取りしたビジネス展開を支援していくことで、競争優位確保に貢献します。 システム開発を「要件定義」「設計」「構築」「テスティング」の4フェーズに分け、それぞれのフェーズを最短化する開発手法、標準技術に基づくツール群およびテンプレートを適用することで、トータルの期間短縮を実現します。 注1 SDAS： System Developmen
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
