2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ソフトウェア開発プロセスのメタ・プログラミングは可能か?

1 :デフォルトの名無しさん:02/12/02 21:43
ソフトウェア開発プロセスの流れを大まかに分類すると、
御存知のように{ウォーターフォール手法、スパイラル手法、ラピッド・プロトタイピング、イテレーション}等ありますよね?

各手法は、開発対象や開発主体への適合性(目的や優先項目)が異なり、その結果各工程で完了すべき事項や手順も異なり、それが各手法の存在意義となっています。

それでは、上記の各手法をカバーする、汎用の開発プロセスを表現する事は可能でしょうか?
そしてその汎用開発プロセスを、オブジェクト・モデリングして、開発プロセス支援ツールをプログラミングする事は可能なのでしょうか?

Rational RUP が何か言っていた気がします…


2 :デフォルトの名無しさん:02/12/02 21:44
2



3 :デフォルトの名無しさん:02/12/02 21:44






「今すぐKISS ME」「Dream On抱きしめて」「恋をしようよYeah Yeah!」「胸騒ぎのAfter school」「だってそうじゃない?」「every little thing every precious thing」等16曲収録。三方背ボックス仕様です。ボックス,ディスク等なかなか綺麗だと思います。



4 :デフォルトの名無しさん:02/12/02 21:49
要するに、ウォーターフォールでキッチリ計画立てて分割再統治する方法しか知らないレガシー野郎に、RUP や Agile を理解させるのが目的なんですけど。

5 :デフォルトの名無しさん:02/12/02 21:57
意図がよくわからん

6 :デフォルトの名無しさん:02/12/02 21:58
理論でプログラム組めたら苦労せんわと。

また目的と手段を勘違いしているバカがスレ立てた。

7 :デフォルトの名無しさん:02/12/02 22:01
>>6
「目的と手段を勘違い」意味が良くわかりません。
よろしかったら、ご高説をお聞かせ下さいませ。

>>1の文章、今読み返すとかなりわかりにくい(汗


8 :デフォルトの名無しさん:02/12/02 22:01
井の頭線を下北沢で降りると学生の集団が線路に降りていく。
すわ落下事故かと注目していると彼らはそのまま線路脇のフェンスを越えていった。
どうやら無賃乗車らしい。
私がパリで書生をしていた頃、友人となったパリジャン達がよく改札を飛び越えていたのを思い出す。
東京も都市としてパリ並に成熟してきたのかもしれない。

9 :デフォルトの名無しさん:02/12/02 22:05
>>6
じゃあ、1を否定してやれば?

10 :デフォルトの名無しさん:02/12/02 22:06
>>6
「今日を一生懸命生きる」っぽい感じで、毎日の仕事をこなすのが精一杯で、
仕事の勘所を抽出して理論化できないレベルの方でしょうか?

11 :デフォルトの名無しさん:02/12/02 22:12
「私」が意識する「現実」と、「彼」が意識する「現実」とが違うものかもしれない、
むしろ絶対に違うと断定できる。それどころか「私」の[現実」への「認識」が、
「私」の「現実」だけでなく、「彼」の「現実」にまで影響を及ぼしているという考え
に取り付かれたのは、目の前のちっぽけな緑色の物体
   アストラクァンタムクリノメーター
―――多重宇宙量子測量器
を手に入れてからのことだった。今から二日前の話しである。

12 :デフォルトの名無しさん:02/12/02 22:12
>>1
ツールを作るのが目的なのか?
開発プロセスを改善する手がかり/足場を用意するのが目的なのか?
はっきりしる!

13 :デフォルトの名無しさん:02/12/02 22:13
>>3, >>8, >>11
デムーパ発信するのはやめれ。このkitty電波野郎

14 :1:02/12/02 22:14
大見得切った>>6はどこに雲隠れした?

15 :デフォルトの名無しさん:02/12/02 22:15
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行
htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行htmlを実行

16 :デフォルトの名無しさん:02/12/02 22:16
>>1は「バカ」に過剰な反応を示しています。何か思い当たるところがあるのでしょう。

17 :デフォルトの名無しさん:02/12/02 22:17
性格最悪の1だな。そりゃ荒らしも来るわ。
↓1の数倍のセンスと経験のある人の話
http://pc3.2ch.net/test/read.cgi/tech/1036148120/l50

18 :デフォルトの名無しさん:02/12/02 22:24
マ板逝け

19 :1:02/12/02 22:27
>>12
とりあえず「プロセス改善」が目的です。

巷の品質屋さん、プロセス改善屋さんは、
組織内責任体系やら、トレース可能な文書体系整備やらに注力してしまうタイプが多いのですが、
私は、プログラミングの現場で発生する問題の解決や改善に主眼を置いとりまして、
具体的には現場の凄腕プログラマに、自らの開発プロセスをプログラミングさせる事を通じて、問題を解決できないものか?と考えております。

関連スレ:■プロジェクト管理 で欲しいツール■
http://science.2ch.net/test/read.cgi/infosys/1009417487/

>>18
そのスレの何割かは、俺のレスだよ(藁

20 :17:02/12/02 22:29
俺が悪かった(泣

21 :デフォルトの名無しさん:02/12/02 22:30
1ってほんとにバカだね。

22 :1:02/12/02 22:33
わかれば結構。

で、現場の凄腕プログラマというのは、得てしてプロジェクト管理は嫌い or 向いてない事が多いわけですが、果たして彼らに自らの「開発プロセス」をプログラミングし、改善させる事は、可能なのでしょうか?

私の理解では、凄腕プログラマの力量が問われるチャレンジャブルなテーマだと思うのですが。

23 :デフォルトの名無しさん:02/12/02 22:34
21 名前:デフォルトの名無しさん 投稿日:2002/12/02(月) 22:30
1ってほんとにバカだね。


22 名前:1 投稿日:2002/12/02(月) 22:33
わかれば結構。



爆笑。

24 :デフォルトの名無しさん:02/12/02 22:38
>>23
あんたの指摘で爆笑。

25 :デフォルトの名無しさん:02/12/02 22:38
while ( test() ) {
writeTest();
}

26 :デフォルトの名無しさん:02/12/02 22:40
要するに、AgileとかRUPとか、借り物の方法論を騙る事しかできない
>>17 リンク先の>>1 に爆笑

27 :デフォルトの名無しさん:02/12/02 22:45
>>1
開発プロセスのプログラミングって、具体的にはどーするの?


28 :デフォルトの名無しさん:02/12/02 22:47
>>27
・答えられない
・奇天烈発言

の馬連で。


29 :デフォルトの名無しさん:02/12/02 22:55
>>28
・東京kittyのデムーパ嵐
の単勝に、1テスラ

30 :デフォルトの名無しさん:02/12/02 23:29
>>27
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。

31 :デフォルトの名無しさん:02/12/02 23:34
結局さ、50%の人間は「3角形を塗りつぶす」 って所まで分解するのは出来るのよ
でもさ、「3角形を塗りつぶす」がライブラリにないと、どう実現するかって部分で詰まる奴が8割なのさ
さらに、水平線に分解して描画ルーチンを組める奴は1割しかいないのさ。

32 :デフォルトの名無しさん:02/12/02 23:39
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。




33 :デフォルトの名無しさん:02/12/02 23:39
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。




34 :デフォルトの名無しさん:02/12/02 23:39
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


  

35 :デフォルトの名無しさん:02/12/02 23:39
ウゼェきえろ・・・
      ∧_∧          _ _     .'  , .. .∧_∧
     ( ´_ゝ`)   _ .- ― .= ̄  ̄`:, .∴ '     ( >>1
    /     '' ̄      __――=', ・,‘ r⌒> _/ /
   / /\   / ̄\-―  ̄ ̄   ̄"'" .   ’ | y'⌒  ⌒i
 _| ̄ ̄ \ /  ヽ \_              |  /  ノ |
 \ ̄ ̄ ̄ ̄ ̄ ̄ \__)              , ー'  /´ヾ_ノ
  ||\            \          / ,  ノ
  ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄          / / /
  ||  || ̄ ̄ ̄ ̄ ̄ ̄ ̄||          / / ,'
  ||  ||           ||       /  /|  |
                       !、_/ /

36 :デフォルトの名無しさん:02/12/02 23:39
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


   

37 :デフォルトの名無しさん:02/12/02 23:40
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


     

38 :デフォルトの名無しさん:02/12/02 23:40
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


          

39 :デフォルトの名無しさん:02/12/02 23:40
よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


                      

40 :デフォルトの名無しさん:02/12/02 23:40
>>30
それはどの本の何ページ?是非読んでみたいんだが。

41 :デフォルトの名無しさん:02/12/02 23:44
ハァ
    ∧_∧            ((
   ( ´Д`)            ) )
  /    \          ノ
  | |     | \        ((  ((
  | | /⌒|⌒|ヽ二二つ    )    ) 丿パチパチ
  ヽ二二Ο./      \ (( (   ノノ
  (_| |_| |_       \ ∴λ∵ ←>>1
    .(__)__)       //》||ヾミ\

42 :デフォルトの名無しさん:02/12/02 23:55
何でこんなに荒れてるの?


43 :デフォルトの名無しさん:02/12/02 23:58
>>31
「部品化&再利用至上主義」ですか?
グラフィクス・プリミティブのコーディングでしたら、
アルゴリズム本&ライブラリを探せばすぐに対応できますが、
「何が再利用に値する共通構造か?」
「いかにして再利用可能なフレームワークを構築するか?」
「時代の変遷と共に変わりうるアーキテクチャから、
 その上に実装する業務ドメインのオブジェクトを、
 いかに分離し再利用可能にするか?」(MDAとかRASとか出てますが)
てな感じで、まだまだ同意がとれていない問題が、多数あると思います。


44 :デフォルトの名無しさん:02/12/03 00:00
>>42
kittyちゃんが、その恵まれない己の人生の憂さ晴らしをしているから。

45 :デフォルトの名無しさん:02/12/03 00:04
test

46 :デフォルトの名無しさん:02/12/03 00:05
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う

47 :デフォルトの名無しさん:02/12/03 00:06
>>1
とりあえず、荒らしのレス削除依頼だしてきて。

48 :デフォルトの名無しさん:02/12/03 00:11
ちゃんとした議論をしてれば荒らしはいなくなることが多いよ。
>>43=>>1なんだろうが、用語ばっか出してピントはずれのような……
>>31は「できる人できない人」の話でしょ。

49 :デフォルトの名無しさん:02/12/03 00:12
>>40
どの分野で仕事してる方ですか?(w
最近本を読んだのは何時で、何の本ですか?(f

例えば、ユースケース駆動とか、テスト駆動は、
それぞれ、顧客要求の実現とか、コーディング対象の仕様化と検証、
に関して明確な方向付けをしており、
「顧客要求の実現度」とか、「ソフトウェア構成要素の仕様の明確さ」
といった内部指標が存在する事を示していると思います。

50 :デフォルトの名無しさん:02/12/03 00:13
>>48
 >>43 は、話がずれずれですね

51 :50:02/12/03 00:19
つーか。
>>43 は、できる人:できない人 の比率こそが、
プログラム開発の成功に関する指標、と言いたいんだろうが。

グラフィクス・プリミティブのコーディングで、
素朴にアルゴリズムを思いつく人、あるいはアルゴリズムを暗記している人、
なんてのは、かなり勉強の足りない部類だと、私は感じますが…

そんなテーマ以外に、考えるべき事柄は、たくさんある。

52 :デフォルトの名無しさん:02/12/03 00:34
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う

53 :デフォルトの名無しさん:02/12/03 00:34
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う

54 :デフォルトの名無しさん:02/12/03 00:34
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う

55 :デフォルトの名無しさん:02/12/03 00:34
「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う「おえらさんがた」は可視化なんかするよりも、
分かりやすい文書にしたほうがよっぽど喜ぶと思う

56 :デフォルトの名無しさん:02/12/03 00:40
>>46
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。

57 :デフォルトの名無しさん:02/12/03 00:51
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。


58 :デフォルトの名無しさん:02/12/03 00:52
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。


59 :デフォルトの名無しさん:02/12/03 00:52
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。


60 :デフォルトの名無しさん:02/12/03 00:52
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。


61 :デフォルトの名無しさん:02/12/03 00:52
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。
分かりやすい文書を出すと、
開発方法も仕事の進むべき方向も良く知らないアフォーが、
内容と適用範囲を良く知らない言葉を振り回したりして、
被害甚大になりますので…

可視化して、自分の頭で考えさせて、アフォーを排除するっつうポリシーですが。


62 :デフォルトの名無しさん:02/12/03 00:58
<閑話休題>

開発プロセスのプログラミングする前に、
嵐の人格矯正プログラミングを議論した方がよさそうだな(藁

</閑話休題>


63 :ジョソ ◆WQidKPmoYU :02/12/03 00:58
そんな事書いてると、また嵐が来るぞ

64 :デフォルトの名無しさん:02/12/03 01:00
>>62
っていうか>>1がしゃべらないと言うのも手だと思うぞ。

65 :デフォルトの名無しさん:02/12/03 01:02
荒らしにレスするとスレ汚しになるだけ。あぼんされるわけだし。
放置しる!

66 :デフォルトの名無しさん:02/12/03 01:02
【隔離】煽り厨に告ぐ!【座敷牢】
http://pc3.2ch.net/test/read.cgi/tech/1038844519/l50

妙なスレまでたったな・・・。>>1の仕事だろうか?

67 :デフォルトの名無しさん:02/12/03 01:12
/|         |  |_____
  |         |  | ̄ ̄ ̄ /|
  |         |  |   / /
  |        /\ |  /|/|/|                           ド
  |      /  / |// / /|  12月3日だ                 ド
  |   /  / |_|/|/|/|/|   \ │ /                ド
  |  /  /  |文|/ // /    / ̄\                ド
  |/  /.  _.| ̄|/|/|/.    ─(゚ ∀ ゚ )─   (´⌒;;       ド
/|\/  / /  |/ / 秩    . \_/ (´⌒;´⌒;;(´⌒;;    ド
/|    / /  /ヽ         / │ \(´⌒(´⌒;;// 今 (´ド
  |   | ̄|  | |ヽ/l  父         ∩ ∧ ∧∩//( 日 ;(´⌒ド
  |   |  |/| |__|/     ∩ ∧ ∧∩\(゚∀゚ ) /(´⌒も (´⌒ド(´⌒;;
  |   |/|  |/   夜    \(゚∀゚ )/ |    /   さ ⌒;;(´ド;;
  |   |  |/           |    〈 |   |/ い ⌒(´ド⌒;;(´⌒;;
  |   |/     祭      / /\_」 / /\」 た (´;;ド(´⌒;;
  |  /                ̄     / / (´⌒;ま  ド
  |/       /                ̄   /   ド


68 :デフォルトの名無しさん:02/12/03 01:49
つか、可視化と文書化の違いに必死になってる人がいて、笑えた。



69 :デフォルトの名無しさん:02/12/03 12:40
 


70 :デフォルトの名無しさん:02/12/03 16:05
>>6
また目的と手段厨ハケーン。

71 :デフォルトの名無しさん:02/12/03 16:08
RUPは分る人には分る。とにかく一度教科書読んでみれ。

72 :デフォルトの名無しさん:02/12/03 17:44
>>71
このスレの趣旨と、どう関係があるのか教えてくれ。

RUPの開発プロセスってこんな感じでしょ。

 顧客要求をユースケースで表現
 ↓
 概念モデル作成(分析)
 ↓
 実装モデル作成(設計)←
 ↓↑            |Iteration
 実装モデルを実装   |
 ↓↑            |
 テスト−−−−−−−→

これって、手続き的なプログラムみたいだよね?

RUPに限らず、
開発プロセスをカスタマイズしたり、
開発プロセスの実行を支援/モニタリングするための、
汎用の方法論とかフレームワークって、
ないんでしょうかねぇ?

73 :デフォルトの名無しさん:02/12/03 17:47
結局、よくあるパターンとしては、
・「成果物主義」:ある「工程」でやるべき作業と成果物を定義し、
        成果物の提出を持って工程完了とするやり方
・「計画至上主義」:スケジュールでも生産性でも品質でも、あらかじめ計画を立てさせて、
        計画値と実績値のズレに焦点を当て、プロセスを予測可能なものにしようと
        強烈なフィードバック(!)をかけるやり方。不確定要因の徹底的な排除。
        (結果として臨機応変な対応能力/柔軟性の軽視に繋がる)
・「プロセス・モニタリング+人手による方向修正」:
        開発プロセスのメトリクス(コスト、スケジュール遅延、品質、生産性)を測定し、
        内容を自動もしくは人手でチェックして、問題の兆候を検出し、
        お偉いさん方の会議で、方向修正を図るやり方
等があると思います。

でも、これらの方法は、間接的であり、問題伝達のロス、問題解決の時間的遅延が烈しいようです。
もっと直接的な指標を探し、その指標値を、開発コミュニティが自律的に制御するやり方がないものか、と思っております。

XPやアジャイル手法には、より良い指標のヒントや、その指標の自律的な改善方法が示されていると思います。
それらを可視化して、お偉いさんの見当違いな方向修正を改善できれば、良いのですが…まだイメージが明確になっていない、というのが実情です。


  



74 :デフォルトの名無しさん:02/12/03 20:55
「成果物主義」ISO9000でやりがちな、作業をトレース可能な文書体系の構築なんてのは、
       品質保証活動の成果物を「品質の向上」でなく審査に通る「文書」に設定
       した事で、落とし穴に嵌ってるよね。
       つう意味で、不適切な成果物主義は×。

       #最近は、捏造可能な「品質指標」を報告させるんじゃなく、
       #ソフトウェア成果物を個別に識別・構成管理して、それぞれの品質を測定
       #するっつう当たり前の事を、ようやく重視しだしたみたいだけど。
       #また実際のソフトウェア開発活動とは無縁の袋小路に嵌らなけりゃいーけど。

「計画至上主義」:「スケジュールは絶対変えるな。代りに目標を下げろ」ってな話もあるらしいけど…
       なんか、曲解してとんでもない方向に引きずり込まれそうなやり方って気はする。

       #確か、計画経済って、破綻したんだよね?

「プロセス・モニタリングと人手による修正」:
       主旨はわかるんだけど、理解力が低いをっさんが決定権を振り回す
       修羅場しか想像できない…
       
       
       

75 :デフォルトの名無しさん:02/12/03 21:05
>>70
ん?
ツール作るときは、開発方法論なり開発プロセスとの関係が重要だと思うけど。
君の「目的」とやらは何なの?

76 :デフォルトの名無しさん:02/12/03 21:13
>>1
> ソフトウェア開発プロセスの流れを大まかに分類すると、
> 御存知のように{ウォーターフォール手法、スパイラル手法、ラピッド・
> プロトタイピング、イテレーション}等ありますよね?
あれ、まだこんな詐欺方法論に騙される馬鹿が存在したんだ。

現実を見ろよ。特にデマルコの本はお薦めだ。

77 :デフォルトの名無しさん:02/12/03 21:14
>>76







                 ま た 本 厨 か 










78 :デフォルトの名無しさん:02/12/03 21:25
>>76
詐欺って、、、君はデムーパか?
>>1は、プロセスの「流れ」だけに着目しても、
上に挙げたような分類ができるって話だよ。

閑話休題
最近、構造化以降を知らない、知恵遅れな化石人種の話しを多少は理解してやるために、
トム・デマルコの「構造化分析とシステム仕様―目指すシステムを明確にするモデル化技法」
  http://www.amazon.co.jp/exec/obidos/ASIN/4822710041/qid=1038917896/sr=1-1/ref=sr_1_2_1/249-8443964-6033134
なんて買って、たまーにちらちら見てるけど、
DOAとかOOAとの連続性が感じられて、古代の文献としてはなかなかいい線逝ってると感じましたです。

79 :78:02/12/03 21:30
知恵遅れは、言い過ぎたかもしれん。

計画経済と関連付けて言えば、
「計画至上主義で、経済原理と技術革新を無視して、
 予測可能な強制労働をやらされて、
 すっかり時代から取り残されてしまった囚人連中」
くらいが妥当かもしれん

80 :デフォルトの名無しさん:02/12/03 21:35
1は人と対話する器が無いみたいだね

81 :デフォルトの名無しさん:02/12/03 21:35
「開発プロセスのオブジェクト・モデリング」までたどり着くには、
まだだいぶ時間がかかりそうだな(w

82 ::02/12/03 21:36
>>80
ん?どうゆう事?
ジサクジエンしまくってるから、
第三者が読んだらそう見えるかも(爆

83 :デフォルトの名無しさん:02/12/03 21:38
>>82
「1は人と対話する器が無いみたいだね」
『ジサクジエンしまくってるから、第三者が読んだらそう見えるかも(爆』

確かに会話が成立していない。

84 :デフォルトの名無しさん:02/12/03 21:41
じゃぁ、>>1の線に沿って、
君が寝た出ししてくれ。

しばらく付き合ってやるから

85 :デフォルトの名無しさん:02/12/03 21:46
>>83
寝た振りまだぁ〜?眠いよぉ〜

86 :デフォルトの名無しさん:02/12/03 21:48
>>83
やっぱり常駐煽りかよ。相手して損した

87 :デフォルトの名無しさん:02/12/03 21:50
2分で物事を放り投げる素敵な方ですね。

88 :デフォルトの名無しさん:02/12/03 21:51
素敵だなんて、、、ずばり的中ですよ

89 :デフォルトの名無しさん:02/12/03 21:54
で、寝た振りまだぁ〜?


90 :デフォルトの名無しさん:02/12/03 22:06
>>81
どうだろうね

91 :デフォルトの名無しさん:02/12/03 22:15
RUPで全て上手くいくと考えるやしは隠れヘーゲリアン。
あんなもので現実的な問題が全て片付くと考えるなら
結果はソ連のようになるでしょう。

個々の問題に大して柔軟に対処しろっていう当たり前の主張に、
Agileとかいう名前がついているのかな?おれはよく知らんけど。

92 :デフォルトの名無しさん:02/12/03 22:18
ふーん

#ごめん、よく判りもせずに、言葉を振り回すタイプなんだ…

93 :デフォルトの名無しさん:02/12/03 22:19
ふーん

#よく判りもしない言葉を振り回すタイプですか。ご免仕ります

94 :デフォルトの名無しさん:02/12/03 23:10
>隠れヘーゲリアン
禿げ藁

95 :デフォルトの名無しさん:02/12/03 23:46
正直開発プロセスのメタプログラミングってなんのことか良くわからんが、
開発プロセスのメタモデルならあるよ。

http://www.omg.org/cgi-bin/doc?ptc/2002-05-04


96 :デフォルトの名無しさん:02/12/04 00:03
開発プロセスってすごく興味のあるテーマではあるんだが、
1の言いたいことがよく分からないので、
何を話せばいいのかよく分からない。
というわけで、1はまず、自分の意図するところを正確に伝えるべし。

とりあえず、>>19がよくわからん。
開発プロセスを、「プログラミングする」って、どういう意味で言っているの?
まさか、開発プロセスの流れを擬似コードで書くとかじゃあるまい。


97 :デフォルトの名無しさん:02/12/04 00:25
RUPにおいて開発プロセスというのは、ツールにおいて具現化する
ということになっているのだっけ。
1が言いたいのはRationalなんかが現状のソフトウェア開発状況などを
リサーチして、それをツールに落とし込むまでの作業を「手作業」で
やっているようなところ、もう少し自動化させたいということでしょうか。

まあこういったでかい風呂敷広げてる暇があるならもっと実用的な
アプリケーションを作ろうぜって俺は思うけどね。

98 :デフォルトの名無しさん:02/12/04 07:09
>>97
>>75


99 :98:02/12/04 07:40
>>97
 つか、解釈どうもありがとう

>自動化
っつうよりも、
誰もが再利用可能な開発プロセスのメタ・モデルを探すor作って、
手作業でツールに落とし込めれば充分です、はい。

>こういったでかい風呂敷広げてる暇があるなら
2ちゃんでそーゆー真面目な反応されても、困るのだが…
つうことで、>>75 に書いてあるように、ツール作る/改造するのが主目的です



100 :デフォルトの名無しさん:02/12/04 07:59
100ずさー

101 :デフォルトの名無しさん:02/12/04 14:43
>>75
いみふめ

102 :75:02/12/04 18:13
誤爆ですた。>>6の間違い

103 :1:02/12/04 21:40
>>95
SPEMっすか、ありがd。
早速読んでみます

104 :デフォルトの名無しさん:02/12/12 22:58
あげてみよう

105 :デフォルトの名無しさん:02/12/13 00:06
橋やダムを作るときは、事前にコンピュータでシミュレーションしてから本物を作る。

大規模システムを作るときは、、、、

106 :デフォルトの名無しさん:02/12/13 00:07

http://petitmomo.com/mm/

ここがちょっぴりエッチ系のめぐが運営している出会いサイトです。
もしよかったら使ってみて、、、
ヨロシクです。

めぐ(^o^)-☆

107 :デフォルトの名無しさん:02/12/13 18:31
>>105
>大規模システムを作るときは、、、、
 どうなんでしょ?
 小規模システムやプロトタイプ・システムで検証する、
 くらいしか思いつかん。

本当は、小規模システムをベースにして、
いい意味で雪ダルマ式に大規模システムへと拡張?
できればよいのかな?

>>106
事前にコンピュータ上でシミュレーションしてから本番に移れ。

108 :デフォルトの名無しさん:02/12/14 16:09
で?

109 :デフォルトの名無しさん:02/12/14 23:34
開発プロセスって、汎用的になればなるほど、
現場の作業とは乖離してくるもんだと思うんだが、1はその辺のこと
どう考えているんだ?
現場のプログラマがやっている自動化作業と、
開発プロセスの汎用的なメタモデルを作ることに、
どういうつながりがあるのかイマイチ見えてこない。


110 :1:02/12/15 08:47
>>109
おっしゃる意味がイマイチよく見えません。
できれば、具体例を挙げて、もっとー具体的に説明して下さい。

特に、
>開発プロセスって、汎用的になればなるほど、
>現場の作業とは乖離してくるもんだと思うんだが、
てあたり。
汎用モデルと、具体的手法とのマッピングを考慮すべきなのは、
ツール製作者と、追加で現場の一握りの凄腕プログラマでよろしいのではないか?


111 :1:02/12/15 08:48
あと、
>現場のプログラマがやっている自動化作業
ってあたり、できれば詳しくお教え願えないでしょうか?



112 :1:02/12/15 09:04
連続レスすんずれぃ。

>>109
私が考えるには、以下の人々は、レガシー開発と現代的な開発手法との
橋渡し、ないしは、統一モデル、を必要としているように思えます。
・品質保証グループの人達
・プロセス改善グループの人達
・レガシー手法(ウォーターフォール+構造化+COBOL)どっぷりからの離脱を志している現場マネージャ
・可能であれば、レガシー手法と現代的手法両方に通用する
 「プロジェクト管理ツール」を供給しようとしている、
 社内「プロジェクト管理ツール」供給者



113 :デフォルトの名無しさん:02/12/15 23:56
>>110
>汎用モデルと、具体的手法とのマッピングを考慮すべきなのは、
>ツール製作者と、追加で現場の一握りの凄腕プログラマでよろしいのではないか?
それより先にプロジェクトマネージャ。

114 :デフォルトの名無しさん:02/12/17 02:06
次は何?他は?

115 :デフォルトの名無しさん:03/01/09 01:45
RUPは分る人には分る。とにかく一度教科書読んでみれ。

116 :デフォルトの名無しさん:03/01/09 02:52
>>102
なんで?

117 :デフォルトの名無しさん:03/01/09 03:07
↑誤爆大魔王

118 :デフォルトの名無しさん:03/01/09 18:25
======2==C==H======================================================

         2ちゃんねるのお勧めな話題と
     ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数: 138720人 発行日:2003/1/9

年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。

そんなわけで、年末に予告したIP記録ですが実験を開始しています。

「2ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。

んじゃ!

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

119 :デフォルトの名無しさん:03/01/10 00:13
>>800
別に名無しは名無しですが
名無しデフォがフシアナになるわけでもあるまいし

120 :デフォルトの名無しさん:03/01/10 09:00
普通の2ちゃん利用者なら、IPログ取られても困らん罠

121 :デフォルトの名無しさん:03/01/10 10:22
>>152
http://www.shitaraba.com/cgi-bin/read.cgi?key=991158920_1&bbs=robi&res=121

122 :デフォルトの名無しさん:03/01/10 10:59
実際 TELは無理でしょうね。
気遣いやけん制、色々多彩にあるでしょうし。要因が。

 何でもいいですが
 頭の悪くない方であると祈って

助けてくれるとありがたいです。

123 :デフォルトの名無しさん:03/01/10 11:30
書けるかな

124 :デフォルトの名無しさん:03/01/10 12:17
SETTINGがBBS_SLIP=
って
書き込みのIPが、保存はされてるってこと???






125 :デフォルトの名無しさん:03/01/10 13:42
ウルトラマンコスモス

126 :デフォルトの名無しさん:03/01/10 15:38
マ板逝け

127 :デフォルトの名無しさん:03/01/10 15:58
さん
スイマセン 移動しました。
http://qb.2ch.net/test/read.cgi/sakud/1028262850/405-407n

以降 このスレでは この件は放置をお願いします。m(_ _)m。

128 :デフォルトの名無しさん:03/01/10 16:20
今までの暗黙の了解が公になっただけの話では。

129 :デフォルトの名無しさん:03/01/10 22:46
 
 せめて照会があってから通知しなさいよ、ログは。
 >西村

130 :デフォルトの名無しさん:03/01/10 22:52

記録してもいいけどIP抹消のセキュリティを激甘にして毎日ハッカーに消してもらおう
パスワード・HIROYUKI とか
 

131 :デフォルトの名無しさん:03/01/11 00:10
そういやこの頃激しく忍者さんを見かけてないな

132 :デフォルトの名無しさん:03/01/11 00:17
さん
ついていきますわ!

133 :デフォルトの名無しさん:03/01/11 10:15
======2==C==H======================================================

         2ちゃんねるのお勧めな話題と
     ネットでの面白い出来事を配送したいと思ってます。。。

===============================読者数: 139038人 発行日:2003/1/10

なにやら、連日メルマガだしてるひろゆきです。

そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。

重くなって落ちたりしてもご愛嬌ってことで。。。

んじゃ!

────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────

134 :デフォルトの名無しさん:03/01/11 11:08
これで荒らしや犯罪予告が減ってくれると助かるんだが。

135 :デフォルトの名無しさん:03/01/11 11:38
ちょっとした疑問

P2P 掲示板って昔の(今もあるけど)NetNews とどう違うの?

 

136 :デフォルトの名無しさん:03/01/11 12:41
じゃ、俺も串で

137 :デフォルトの名無しさん:03/01/11 16:00
前スレは、強い電波が検出されちゃったからじゃないかな。。。

138 :デフォルトの名無しさん:03/01/11 16:04
匿名性に絡む問題なので反対 27% 381 票
サイトのためになるから賛成 54% 744 票
利用しないから関係ない 9% 132 票
2ちゃんねるってなに? 4% 64 票
アクセスログってなに? 3% 53 票



139 :デフォルトの名無しさん:03/01/12 00:07
2chが2chでは無くなるときが来ましたね。
遊び方の解らない馬鹿が増えたから、しかたないのかもしれません。
もう転載しませんので、以後は該当のスレ追っかけてください



27 名前:心得をよく読みましょう 投稿日:03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か?

38 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:22 ID:rLfxQ17l
鋭いです。

73 名前:ひろゆき ◆3SHRUNYAXA 投稿日:03/01/08 17:27 ID:rLfxQ17l
>ところで、IPが抜かれて何か今までと変わることってあるのでしょうか?
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

こんなところでしょうか。

140 :デフォルトの名無しさん:03/01/12 00:16
ここで3人くらいが「大丈夫だよ」と言ったら、それを信用して
そういう書き込みを続けるんですか?
まあご自由にとしか言いようがありませんね。
どうせなら「授業料」を支払うことになる限界がどこにあるか見つけてください。

141 :デフォルトの名無しさん:03/01/12 02:54
プレゼント

142 :デフォルトの名無しさん:03/01/12 02:58
2002年2ちゃんねるアニメランキング1位のアニメに・・・・

モナーが出演決定!!!!!!!!!!!!!!!!!!!!!

<<放送時間>>
1/12
大阪 テレビ大阪 (日)9:30〜10:00
東京 テレビ東京 (日)9:30〜10:00
名古屋 テレビ愛知 (日)9:30〜10:00
福岡 TVQ九州放送 (日)9:30〜10:00
札幌 テレビ北海道 (日)9:30〜10:00
岡山・高松 テレビせとうち (日)9:30〜10:00 

143 :デフォルトの名無しさん:03/01/12 10:27
リア厨が捕まるんだろうな。

144 :デフォルトの名無しさん:03/01/12 10:29
はいはい能書きはいいから
実際問題、仮に削除された奴が
削除されたことに対して文句を言っても無駄でしょ
大袈裟に語らんでよ

145 :デフォルトの名無しさん:03/01/12 21:07
荒らしキタ━━━━(゚∀゚)━━━━!!!!!!

146 :デフォルトの名無しさん:03/01/12 21:09
>しかし その反証の場が 2ch でなくてはならないというのは ? です。

書き込んだ人間に通知することが合理的に可能な方法としては、
2ch上(削除依頼対象のスレ)でやる以外にないでしょう。

後段はいまいち意味不明。発信者の特定は第三者機関からの要請があってから行えば十分な筈ですが?

147 :デフォルトの名無しさん:03/01/12 21:21
なんで書けないのかわからないの!

148 :山崎渉:03/01/13 18:51
(^^)

149 :デフォルトの名無しさん:03/01/13 23:03
DHCぐらいしか知らん

150 :山崎渉:03/01/15 18:06
(^^)

151 :山崎渉:03/01/23 22:15
(^^)

152 :デフォルトの名無しさん:03/01/28 12:02
素敵だなんて、、、ずばり的中ですよ

58 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)