約 1,247,444 件
https://w.atwiki.jp/iconix/pages/17.html
ICONIXプロセスの流れ 1.ドメイン分析プロジェクトの用語を洗い出し、用語を統一します。（同じものを表す用語が2つあったりしないように） クラス図をとても単純にしたものを使って、用語同士の関係を見やすく図で表します。 予備設計過程で更新するので最初は2時間以内に作成します。 2.ユースケース記述要求を満たすための振る舞いを具体的に記述します。（AがBを要求するとCはDする、等） 晴れの日のシナリオ（正常系）と雨の日のシナリオ（異常系）を全て見つけ出すように書きます。 図を使ってユースケース同士の関係を明確にします。 3.ロバストネス分析3つのオブジェクトを使って簡単に図を描きます。 ユースケース1つにつきロバストネス図を1つ描きます。 図を描く過程で、見落としていた振る舞い、データ、インターフェイスなどを見つけ出します。 見つかったものは1のドメイン分析、2のユースケース記述に随時追加していきます。 ロバストネス図をレビューし、要求→ユースケース記述→ロバストネス図の対応が取れていることを確認したら予備設計完了です。 4.シーケンス図1つのロバストネス図に対して1つのシーケンス図を描きます。 ロバストネス図で見つけ出したオブジェクト（バウンダリ、エンティティ）をシーケンス図のオブジェクトにします。 シーケンス図を描く過程で、どのオブジェクトにどの操作を割り振るのか決定します。 5.クラス図ドメイン図に属性と操作を付加し、名前を付けて作成します。 詳細設計のアウトプットとなります。 6.コーディング 7.テストロバストネス図のコントロールオブジェクトをそのままテストケースとすることが出来ます。
https://w.atwiki.jp/iconix/pages/12.html
ICONIXプロセスとは何か 機能要求から ①簡単な図で ②他人がトレースできる形で ③漏れ、抜けのないように 詳細設計を導くやり方。
https://w.atwiki.jp/bplib/pages/897.html
このページについて このページは、ビジネスプロセスライブラリの主旨について記述するページです。 また、それらに関連するトピックの要約を兼ねていて、各トピックに対する参照元でもあります。 ページをご覧になられた方のコメントを反映して、随時更新していきます。 論として不十分な点として、個人の感覚に頼った記述をしており、ベースになる事実情報の紹介をほとんどしておりません。トピックに関連する情報ソースをご存知の方、ご紹介いただけると幸いです。 要約 ビジネスプロセスライブラリは、Wikiのような、だれでも執筆が可能なツールでビジネスプロセスモデルを公開・共有し、共同編集によってプロセスモデルを拡張し、大規模で、実態に即し、整合の取れたモデルの複数のセットを構築することと、それを通して ビジネスプロセスモデルを介した効果的なコミュニケーションと、コミュニケーションによる高品質なビジネスプロセスモデルの構築のサイクルによるメタプロセスを提案することを目的としています。 詳細 ビジネスプロセスモデルの構築は、ブラックボックスになりがちな（工事中）ビジネスにプロセス設計という概念を導入し、様々な改革の第一歩としてビジネスをレベルアップさせる多くの可能性を秘めています。そして、ツールの進歩によって可能になった、 グレードの高いモデリングは、コスト削減やリードタイム短縮などの一般的に言われるメリットを越えた革命的な変化を生み出す可能性があります。（工事中） しかし、情報システム構築の最初のステップととして定着はしましたが、現在の一般的なやり方では、実現にかかる時間とコストに見合った結果を得るレベルまで企業が地道に継続することは今までも困難でしたし、ビジネスのスピードが加速するなかで、今後はさらに困難になるでしょう（工事中）。これは、情報システムの導入によっても改善されなかった問題（工事中）です。 単体の企業では実現しきれない問題解決をパッケージ化して、ソリューションとして販売してきたのがIT関連企業です。上記の領域に彼らが提唱したソリューションは、「BPM」というものでした。しかし、ビジネスプロセスのITによる実装までの一環した実施を求めるあまり、かえって需要側のニーズに即さないものになっている（工事中）と私は感じています。重ねて、最近のIT関のバズワードを見ると、彼ら自身がそれに継ぐ新しいソリューションをあきらめているのではないかという印象さえ受けます。 一方、賃金格差を利用したコストダウンや、企業の統合によるビジネスの大規模化は、手っ取り早く確実で、ビジネスのパフォーマンス向上の方法としてますます主流になっていく傾向があります。 しかし私は、それだけではつまらないと感じます。卓越した品質、徹底的な効率化、画期的な価値の創出がそれらに比肩する競争力を持ち続けて欲しいと願っています。多くの人もそのように思うのではないでしょうか。 私は、ビジネスには、今後もそれらを生み続ける「余地」は十分にあると思っています。そして、モデリングを活用したビジネスプロセス設計の向上はその産出に大きく寄与する（工事中）ことにも確信を持っています。しかし、現実はこの領域の進歩は停滞していおり、イノベーションが生まれていません。 私は、停滞を打破する鍵の一つはコンテンツであると考えています。コンテンツとして、モデリングによるプロセス設計を正しく体現したビジネスプロセスモデルのセットがあれば、プロセス設計の向上を希望する利用者は、その期間とコストを大幅に削減できるでしょう。そして、それによるビジネスのパフォーマンス向上の実例も増え、需給双方が活気づき、イノベーションを生み出すよいサイクルが生まれます。 もう一つの鍵は、プロセスモデルを効果的に構築・維持・拡張するプロセス（「プロセスモデル作成のプロセス」というややこしい表現なので、ここからは区別がつくように、メタプロセスと呼びます。）です。現在一般的なメタプロセスは、時間とコストがかかりすぎます。それらを解消するメタプロセスモデルが提供されれば、ビジネスプロセスモデリングは一過性のものではなくなります。 問題は、ビジネスの世界のプレイヤーが、誰もその鍵を提供しないということです。もしかすると、ビジネスの世界だけではビジネス上の問題解決ができない時代が来ているのかもしれません。 私は、そのコンテンツをオープンなコミュニケーションを通して作成すること、その過程を通して、全員参加のビジネスプロセスモデル構築というメタプロセスモデルを提案することはできないかと考えました。 それが、ビジネスプロセスライブラリです。 これは、Wikiのような、だれでも執筆が可能なツールでビジネスプロセスモデルを公開・共有し、オープンな議論と参加者全員の共同編集によってプロセスモデルを拡張し、結果として大規模で、実態に即し、整合の取れたモデルの複数のセットを構築することを目標にしています。また、もしそれが実現できるなら、実現に至るまでのプロセスそのものが、クローズドな世界でも利用できるメタプロセスモデルにもなると考えております。 ただ、それは簡単なことではないし、足りないものも沢山あります。 そもそも、オープンソースソフトウェアの如き考えがビジネスプロセスモデルに成立するのか、効果的なメタプロセスの模索（工事中）、企業機密の漏洩のリスクがない進め方、二次利用を制限しない上手な権利の設定方法（工事中）など、課題は数多くあります。 ただ、まずは何より、それからビジネスプロセスモデリングの楽しさ、有益性について多くの人に実感を持っていただくことが最初かなと考えております。 本サイトは、ビジネスプロセスライブラリのモックアップとして、イメージを人に伝え、意見をいただくためのために作成しました。 是非この文章に関し、コメントやトラックバックでご意見ください。 コメント -- (コメントテスター) 2009-05-11 00 55 46 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/bplib/pages/1299.html
このページについて このページは、ビジネスプロセスモデリングの意義について記述しています。ビジネスプロセスモデリングの定義や手法については、他の様々なサイトで述べられているので、概念的な部分に絞って記述しています。 本文 ビジネスプロセスモデリングは、ブラックボックスになりがちな ビジネスのメカニズムを明らかにする（ホワイトボックスにする）ための方法の一つです。 目に見えない概念を明らかにするための基本的な手段は、文書化です。文書という目に見えない形にすることによって、目に見えない概念について具体的に検討することが可能になります。 ビジネスのメカニズムの構成要素であるプロセスも、文書化が可能です。業務マニュアルはその一例といってよいでしょう。 ビジネスプロセスモデリングは、このプロセスの文書化の一形態として、プロセスを図形や表などで抽象化して表現することです。なお、モデルというのは、一般的には対象となる物事を表現するための模型のことです。 しかし、近年のモデリング環境の充実により、二次元の限界を超えた情報についての取り扱いも可能になってきましたので、ビジネスプロセスモデリングの定義は、拡張されつつあります。 今は、「図形や表のような抽象化された表現を中心とした構造化された形式で業務を記述すること」であり、文書化の一形態から文書を包括するものとなったと言ってよいでしょう。 ビジネスプロセスモデリングの特長 ビジネスプロセスモデリングは、プロセスを単に文章として表現することに比べて、以下のような特長を持ちます。 分かりやすい：図形や表を用いるため、直感的にプロセスの内容が見て分かりやすい 論理的に正しい：図形を用いるため、表現における依存関係や前後関係、条件分岐の関係に、矛盾が発生しない。 必要十分な情報量：記号による略記が可能なため、適切な情報量をすっきりと伝達できる。 また、これらの特徴から、業務情報システムの開発の最初の工程として、ビジネスプロセスモデリングが実施されることが一般的です。 むしろ、近年におけるビジネスプロセスモデリングの多くは、業務の情報システム化を契機として実施されていると言えるでしょう。 方法論等について モデリングの方法論は様々にあります。IDEF、BPMNといった標準がありますし、標準に則らない形でもビジネスプロセスモデリングは業務フロー、フローチャートといった呼称で昔から実施されています。また、そのためのツールも数多く発売されています。記述の効率もずいぶん向上しているし、シミュレーションなど優れた機能を持っている製品も出てきました。モデリングのツールや手法について書かれた文献や情報はインターネット上にも数多くあるため、ここでその詳細について記述はいたしません。今後このページを拡張する際に、参考情報に対するリンクを追記していきます。 ビジネスプロセスモデリングの二つの側面 ビジネスプロセスモデリングには、方法論にかかわらず、２つの側面があることを述べておきます。一つの側面は現状のプロセス（AS-ISモデル）記述、もう一つは新しいプロセス（TO-BEモデル）の記述です。大抵のビジネスプロセスモデリングは、まったくゼロから新しいビジネスプロセス設計するのでない限り、AS-ISモデルの記述の次にTO-BEモデルを記述するというステップを経る必要があります。 AS-ISモデルの記述では、業務の調査を行い、現状の業務をビジネスプロセスモデルとして書き出します。この時点ではビジネスプロセスの設計が行われるわけではなく、現状を書き出すことが主眼となります。 TO-BEモデルの記述では、多くはAS-ISモデルを参考に、新しいビジネスプロセスを設計し、その内容を書き出します。
https://w.atwiki.jp/asaikenji/pages/11.html
プロセス一覧を取得する。 プロセス一覧を取得する。 プロセス一覧を取得するには、System.Diagnostics.ProcessクラスのGetProcessesメソッドを使用する。 サンプルコード // プロセス一覧を取得する。 System.Diagnostics.Process[] hProcesses = System.Diagnostics.Process.GetProcesses(); // 取得したプロセス一覧を表示する。 for ( int i = 0; i hProcesses.Length; i++ ) { System.Diagnostics.Process hProcess = hProcesses[ i ]; System.Console.WriteLine( hProcess.Id + " " + hProcess.ProcessName ); } 実行結果 ……… 824 sqlservr 2004 k7tsmngr 624 lsm 3972 SPMgr 3380 IMJPCMNT 1208 SLsvc 616 lsass 1400 VESMgr 3264 conime 1200 VCSW ………
https://w.atwiki.jp/bplib/pages/1302.html
5ビジネスプロセスモデリングが進んでいない現状 私がシステムエンジニアの業界で働くようになって10年以上経ちます。 10年の間に、インターネットおよび携帯ネットワークの普及と活用については、大きな進化が見られました。しかし、ビジネスが誰にとってもブラックボックスであるという面には変化が見られないようです。 私は、業務のシステム化や業務分析の過程で様々なお客様とお話しましたが、その中で、ビジネスのメカニズムを、その全体の概要を大きなレベルで把握している人、自分の関連する仕事を詳細に把握している人にはお会いしたことがあります。しかし、全体をある程度詳細に把握している人、となると、まったくお会いしたことがありません。最近になってそういう人に会うことが増えたということもありません。 また、業務の中で、ビジネスプロセスモデリングを行うことが多かったのですが、そのたびに、現場のお客様からも、「なるほど、うちの業務はこうなっていたのか、いままでさっぱりわからなかったよ」という声をいただきます。最初のうちは、お客様からの感謝の言葉をいただくのがただ嬉しかったのですが、10年間ずっと同じ状況が続くので、別の感想を持つに至りました。 プロセスの文書化、ビジネスプロセスモデリングに関して、大方の企業の現状は以下のようではないかと私は考えています。私の手元に統計情報等があるわけではないので、是非皆さんの意見を伺いたいと考えています。 5.1現状のビジネスプロセスモデルによくある課題 共有がされていない。 情報システムの導入等の際に作成されたビジネスプロセスモデルはあるものの、現場で業務を行う人の目の届かない場所にある。 外部のコンサルが作成した業務フローが、誰の目にも届かないところにひっそりと死蔵されている。 断片的な資料が散在している。 関連のはっきりしない狭い範囲のビジネスプロセスモデルが散乱している。 同じ業務領域に対し、内部統制用、ISO用などで重複する複数のドキュメントが存在し、それぞれ書いてある内容がずれていて、どれが正しい情報なのかよく分からない。 内容の品質が低い。 不正確で現状と乖離している。 内容が古く、現状をキャッチアップしていない。 それを見ても仕事の手順は分からない。 5.2まとめ この10年で企業のIT化は進み、相当量のビジネスプロセスが情報システム化されました。次に述べますが、ビジネスを情報システム上で実施するためには、ビジネスプロセスモデリングによるホワイトボックス化は必須の作業であるため、少なくとも情報システム化する間に、大量のビジネスプロセスモデリングがなされたはずです。そのための手法や、専用のツールもあります。にもかかわらず、なぜこれほど状況に変化がないのでしょうか。 ここで、私の頭に浮かんだ考えは、ブラックボックス化するのがビジネスのメカニズムの基本的な性質であり、それはホワイトボックス化する手法が紹介されたとしても、よほどのことがない限り変化しないのではないかということです。
https://w.atwiki.jp/freememo/pages/92.html
概要 プロセス生成関数CreateProcess() コメント 概要 OSからメモリ領域などの割り当てを受けて処理を実行しているプログラム。 TOP プロセス生成関数 CreateProcess() 例）メモ帳起動する場合 TCHAR cmdline[] = _T("notepad.exe"); STARTUPINFO si; ZeroMemory( si, sizeof(si)); si.cb = sizeof(si); PROCESS_INFORMATION pi; ZeroMemory( pi, sizeof(pi)); if ( CreateProcess(NULL, cmdline, NULL, NULL, FALSE, 0, NULL, NULL, si, pi)) { // メモリリークの原因になるので、不要ならば、すぐクローズする。 CloseHandle(pi.hProcess); CloseHandle(pi.hThread); } TOP コメント 名前 コメント TOP
https://w.atwiki.jp/takayuki_yano/pages/14.html
プロセス OSからメモリ領域などの割り当てを受けて処理を実行するプログラム
https://w.atwiki.jp/sevenlives/pages/1386.html
スレッド プロセスID? IPC?共有メモリ? セマフォ? ファイル メッセージ・パッシング? シグナル? パイプ
https://w.atwiki.jp/rffbl22/pages/90.html
プロセス管理 バックグラウンドでのプロセス実行 通常、プロセス実行中にsshを切断すると、実行中のプロセスはkillされてしまう。 バックグラウンドで実行数には、 をつけてコマンドを実行する。 (例) ./hoge.out [1] 10220 ここで、10220とあるのはプロセス番号が表示される。なお、topもしくはpsコマンドでもプロセス番号を確認することができる。 この状態なら、sshを切断してもプロセスは終了しない。 実行後にプロセスをバックグラウンドに変更する キーボードで Ctrl + Z するとプロセスが停止される。その後 bg コマンドを実行 bg バックグラウンドプロセスの終了 topもしくはpsコマンドでプロセス番号を確認して kill -9 プロセス番号