ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(2) ―― 狙いを定めて投資を回収，ガイドライン策定は必須
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(2) ―― 狙いを定めて投資を回収，ガイドライン策定は必須 大塚 潤 新しい開発手法を取り入れても，定量的な成果が出てこないと推進が難しくなってくる．富士通九州ネットワークテクノロジーズのソフトウェア・プロダクト・ライン開発適用も壁に突き当たりつつあった．そのような中で，比較的規模の大きなプロジェクトにおいて成功事例が生まれた．第2回は，成功事例に至ったファームウェア開発について，プロジェクト・リーダの立場から解説する．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回 管理者は「石の上にも3世代目」 経営層の協力を取り付け，プロダクト・ライン開発手法を推進してきた筆者たちでしたが，定量的な成果に結びつくプロジェクトがなかなか現れず，手法の有効性には手ごたえを感じつつも，開
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(4) ―― 社内・社外から見た導入のかぎ
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(4) ―― 社内・社外から見た導入のかぎ 岩崎 孝司，内場 誠，中西 恒夫 筆者らが取り組んできたソフトウェア・プロダクト・ライン開発手法の導入事例を3回にわたって紹介してきた．各プロジェクトでの効果はさまざまだったが，いくつかのプロジェクトで具体的かつ定量的な成果が見え始めたことにより，その結果に触発された複数の部門が自ら進んでプロダクト・ライン開発に取り組み始めるという好循環が生まれた．最終回となる今回は，プロダクト・ライン開発手法の導入に成功するためのかぎを，社内および社外の視点から紹介する．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回 管理者は「石の上にも3世代目」 第2回 狙いを定めて投資を回収，ガイドライン策定は必須 第3回 導入方法と効果は開発タイプごと
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(3) ―― 導入方法と効果は開発タイプごとに異なる 内場 誠，佃 紀昭 前回は，ソフトウェア・プロダクト・ライン開発手法の適用で大きな成果を挙げた大規模なファームウェア開発の事例について紹介した．なお筆者らの会社では，ファームウェア開発のみならず，ハードウェア開発を含むさまざまな開発にもソフトウェア・プロダクト・ライン開発手法の導入を試みた．今回は，これらの開発に対するソフトウェア・プロダクト・ラインの導入事例を紹介する．また，いずれのプロジェクトにも共通の悩みとなった，フィーチャ・モデルと実装構造の対応付けについて，分析した結果を示す．（編集部） 技術解説・連載「ソフトウェア・プロダクト・ライン開発手法の実践的導入事例」 バック・ナンバ 第1回 管理者は「石の上にも3世代目」 第2回 狙いを定めて投資を回収，ガイドライン策定は必須
ソフトウェア・プロダクト・ライン開発手法の実践的導入事例(1) ―― 管理者は「石の上にも3世代目」
ソフトウェアの「部品化・再利用」は，多くの企業にとって長年の課題になっている．近年，ソフトウェアの部品化・再利用化を加速する開発手法として，ソフトウェア・プロダクト・ラインが注目を集めている．本連載では，富士通九州ネットワークテクノロジーズのソフトウェア・プロダクト・ライン適用事例を紹介する．第1回は，ソフトウェア・プロダクト・ラインの導入の経緯や，ソフトウェア・プロダクト・ラインが定着するまでに解決しなければならなかったさまざまな課題や困難について，導入を推進した管理者の視点から紹介する．（筆者） ●通信システムは派生開発が多く開発期間が長い 筆者が所属する富士通九州ネットワークテクノロジーズ（以下，富士通QNET）は，富士通の出資によって設立された，通信機器やネットワーク・システムのハードウェア，ソフトウェアを開発する設計開発専門会社です．通信機器は，通信の標準規格に準拠して仕様決定
ソフトウェアプロダクトラインが組込み企業の技術力を左右する - プログラマの思索
チケット駆動開発でアジャイル開発を運用すると必ず並行開発が現れる。 並行開発、ソフトウェアプロダクトラインの関係について連想した事をメモ。 【元ネタ】 ソフトウェアプロダクトラインを考えるセミナーに参加 - Basic CACM の特集記事：ソフトウェアプロダクトライン工学(1) - IT、アイスホッケーそしてヒップホップのある日常 衛星標準プロセス展開支援 成果報告 【1】Redmineでチケット駆動開発をアジャイル開発っぽく運用すると、必ず2個のコードラインを保守するようになり、自然に並行開発になる。 つまり、リリースした本番システムはリリースブランチ、裏で機能改善中のシステムはtrunkの2本を常時保守しなくてはならない。 特にアジャイル開発を実践すると、2～4週間のサイクルで小刻みにリリースしていく為、リリースしたコードラインと次のイテレーションのコードラインの2本を並行で作業しな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
状態遷移設計におけるＳＰＬＥ実践ガイド
コラム｜コラム