ページ内コンテンツ
定義の履歴1,目的別に分けられたシステム開発作業の集まり システム開発作業の集まりとは,システム開発ライフサイクル(DEPARTMENT JUSTICE http://www.justice.gov/jmd/irm/lifecycle/ch1.htm)に含まれる全てのフェーズのこと 開発工程【Development Process】 システムを開発するために必要な業務プロセス。システム開発の業務プロセスには,①ユーザ要求分析とシステム化要件定義②システム開発の準備③システム設計(外部設計)④コンポーネント設計(内部設計)⑤詳細設計(プログラム設計)⑥プログラム実装⑦ソフトウェア導入支援,などがある。以上に挙げたプロセスの区切り方には,団体や企業によってさまざまな種類があるが,ISO/IECが検討したSLCP(Software Life Cycle Process)に基づく「システム開発取引の共通フレーム SLCP-JCF98」が現在の標準として定着しつつある。(『情報処理技術者用語辞典』 日経BP社)(11.12.05 藤田) システムやソフトウェアの開発を実行する組織のアクティビティやタスクからなる。(SLCP-JCF2007)(11.12.08 塩谷) ソフトウェアをどのように作り上げるかについて,手順や工程,要員,成果物,進め方に関する基本的な考え方を定義したもの.(2011.12.22 青田) システム開発のために、実施すべき作業の手順と作業間の関係を示したもの(12.02.21 WWS結果) システム開発のために、入力を出力に変換するための入力から出力までを含めた行為(12.02.21 WWS結果) #「開発文書」という用語は入らないか?(21.02.21 WWSコメント) 2,システム開発において,入力から出力へ変換し,相互に作用する一連の活動(12.03.02 部会ミーティング) システム開発のために,実施すべき作業の入出力と作業内容,作業間の関係を示したもの(12.02.23 石田) #プロセスは,「手順を整理して示したもの」であり,定義したり,従ったりするものだと思います.WWSの2番目の定義は「・・・行為」となっていたのがひっかかっていましたので,WWSでの2つの定義を合わせました. #定義を順に読むと,2.23の石田案で良い気がしました.プロセス,工程,作業の関係は,次で良い?プロセス={工程|工程の集合}, 工程={作業|作業の集合} (12.03.22 山本) *2,システム開発において,入力から出力へ変換し,相互に関連する又は相互に作用する一連の活動. #プロセスの定義が「入力を出力に変換する,相互に関連する又は相互に作用する一連の活動.」だから(12.04.12 石田) #2.の定義は,「システム開発におけるプロセス」となり,何も定義していないのでは?(12.05.15石田メールより) #何も定義していなくても良いのでは.基本用語の組み合わせで説明が成り立たない場合は,成り立たない理由を考えてみると「用語を定義する手法」も確立できるかもしれない.(12.05.16 塩谷さん,青田さんメールより) #「作業」となっているのには違和感があります。自動化などで「作業」ではなく「処理」になったものも「開発プロセス」ですよね。「プロセス」定義にある制約以上の制約を「開発プロセス」に付加しない方が分かり易いかもしれません。もし,作業しか問題にしないのなら「開発プロセス」という用語を使わずに「開発作業」という用語を使った方がよいかもしれません。(12.06.13 小川) #プロセスは人の活動と機械の処理の集合にしておけば整合性が取り易い。「活動」だけにしてしまうと自動化するとプロセスでなくなってしまわないか。(2012.06.15 小川清) #プロセスは人の作業と機械の処理の集合にしておけば整合性が取り易い。「作業」だけにしてしまうと自動化するとプロセスでなくなってしまわないか。(2012.06.15 小川清) ⇒*システム開発の構造を、実施する処理とその手順として示したもの。それぞれの処理は前フェーズの結果を入力として受け、それに対して何らかの作業を実施し、結果として出力する。 #うちの社員にみせたら、いわんとしていることはわかるけど漠然としていてイメージにつながらない、という意見があったので、もう少し具体化して書いてみました。>「⇒」以降。(12.08.08 青田) 上記の青田さん定義に小川さん意見を反映させ、下記の点を考慮して再定義し次の案とした(2012.9.30 塩谷) *システム開発において、実施する処理とその手順を示したもの。それぞれの処理は前の処理の結果を入力として受け、その入力に対して何らかの処理を実施し、結果として出力する。
#以下を削除 JIS規格定義に対する意見プロセス定義は規格によってそれぞれ異なる定義をしています。ステップの集合はprocedureという用語を使う場合もあり,processはそのうちの時間を捨象して抽象化したものに使っていることもあります。(2012.06.15 小川清) 用途#「①再現性を高める...」以降を追加しました。プロセスデザインを職業とされている方のブログからの(一部)引用ですが、そもそもなんのためにプロセスが必要なのか(なにを意識してプロセスをつくるべきか)という観点が良いと思ったので。「そもそもこれを(システム開発)プロセスと呼んでいいか?」と考えるときに、①~③が実現できているか、という視点が役に立つのではないか、と感じました。(2012.08.08 青田) #用途のところですが、最初、ソフトウェアに限定したような書き方になっており、システムはソフトウェアに限定しないことに矛盾している(永田) #「目的として..」以降だけでよいのではないか(2012.8.27 塩谷) #最初の行は「ソフトウェア開発プロセス」をググった結果から引用している(たしか)ので、ご指摘の通りだと思います。 「用途」を項目立てせず(2012.9.12部会ミーティングより)、定義内の<目的>とした(2012.9.30 塩谷) |