今日はSEF-2009の2日目でした。 
      
        
        
        
      
    
      
        
        
        
      
     私が最初に参加したレポートは、 agile.byコミュニティの代表であるPavel Gabrielによる「TDDの最初のステップ」でした。 
      
        
        
        
      
    
      
        
        
        
      
     たとえば、アラビア数字をローマ字に変換する最も単純なマクロExcelは、 
      
        
        
        
      
      TDDの基本原則が実証されました。 
      
        
        
        
      
     最初にテストが開発され、次にその実装-徐々に、 
      
        
        
        
      
     非常に小さな連続したコード変更を行うことにより。 もちろん、各変更の後、 
      
        
        
        
      
     すべてのテストが実行されました。 
      
        
        
        
      
    
      
        
        
        
      
      「偽造」と「明白な実装」という2つのデザインパターンが命名され、TDDでよく使用されます。 
      
        
        
        
      
    
      
        
        
        
      
     その後、「ソフトウェアエンジニアのトレーニング(ウクライナの経験)」というレポートがありました。 
      
        
        
        
      
     報告書は、教育のカリキュラムと構造の変更を保証するために設計されていることについて話しました 
      
        
        
        
      
     ウクライナのITに必要な専門家。 私はそれが非常に合理的に聞こえると言う必要がありますが、 
      
        
        
        
      
     懐疑論者もいました。 
      
        
        
        
      
    
      
        
        
        
      
     専門家のトレーニングにおける次の弱点が指摘されました。 
      
        
        
        
      
      1.グループダイナミクスとコミュニケーション、プロジェクトでの役割 
      
        
        
        
      
      2.ソフトウェアエンジニアリングプロセス 
      
        
        
        
      
      3.品質保証 
      
        
        
        
      
      4.ソフトウェアエンジニアリングシステムとツール 
      
        
        
        
      
    
      
        
        
        
      
      n4以外はすべてIT教育に起因すると考えます。  P4私はそれが単に必要ではないと思う-手段 
      
        
        
        
      
     理論的な基礎があれば、道に沿って習得、非常に簡単。 
      
        
        
        
      
    
      
        
        
        
      
     彼らは、2段階の教育(修士と学士)への移行と専門分野について話しました。 
      
        
        
        
      
     そして、主に省の叔母と叔父にとって興味深い他の公的なナンセンスについて 
      
        
        
        
      
     教育。 他に誰も知りません まあ、すきの教師と開発者は、多くの重要な言葉にあまり意味がありませんでした。 
      
        
        
        
      
    
      
        
        
        
      
     興味深い点が1つありました。もちろん、大手企業のIT教師のインターンシップは大規模です。 
      
        
        
        
      
     私たちの学部の教師のためにこのようなインターンシップを実施する機会があります。 
      
        
        
        
      
     ただし、小さなバージョンでは、最も古いミンスク企業の1つ(EPAMではありません:)。 
      
        
        
        
      
    
      
        
        
        
      
      「アプリケーション統合」という大きな名前のレポートがありました。 プロセスの翻訳について話しました 
      
        
        
        
      
      MS BizTalk Serverの顧客。 レポートのタイトルがまったく対応せず、問題について 
      
        
        
        
      
     アプリケーションの統合はまったく伝えられませんでした。 
      
        
        
        
      
    
      
        
        
        
      
     ウィキペディアが書かれているオープンシステムであるMediaWikiについて非常に興味深い活発な講演がありました。 
      
        
        
        
      
     彼らは彼女と一緒に無料のフラッシュドライブを提供しました。 私が見たまでフラッシュドライブに何があります。 
      
        
        
        
      
     このシステムは本当に面白いです。プロジェクトを文書化するために時々使用します。 
      
        
        
        
      
     そして、「コミュニケーションは情報ではない」という興味深いフレーズが発せられました。 
      
        
        
        
      
     それは私のトウモロコシを通過しました-しばらくの間、私は組織で働く愚かさを持っていました、 
      
        
        
        
      
      ICQログが唯一のプロジェクトドキュメントでした。 
      
        
        
        
      
    
      
        
        
        
      
      「エンタープライズプロジェクト管理プロセスの自動化」を報告します。 ハ、スケジュールを変更して 
      
        
        
        
      
      XMLに関する特定の問題の解決策の.NET実装に関する別のレポートがありました。 主催者にFe。 
      
        
        
        
      
    
      
        
        
        
      
     その後、いくつかのレポートを見逃し、「アプリケーション設計プロセスの組織化」 
      
        
        
        
      
     ソフトウェア会社で。」 レポートは、原則として、悪くはなく、タイトルと一致しません。 について 
      
        
        
        
      
     インターフェース、使いやすさ、ユーザー体験。 私はプロフェッショナリズムによる部門が好きでした: 
      
        
        
        
      
      1.初心者 
      
        
        
        
      
      2.マスター 
      
        
        
        
      
      3.自分の仕事スタイルを持つ男。 
      
        
        
        
      
     このようなp3から、業界、または少なくともそのような卓越した性格を動かすことができます。 
      
        
        
        
      
     プロジェクトの相互作用の組織について、デザイナーや他の兄弟の役割について、 
      
        
        
        
      
     私はあまり注意を払いません。 
      
        
        
        
      
    
      
        
        
        
      
      「要件とその解決策を識別する典型的な問題」を報告します。 良い報告。 
      
        
        
        
      
      1.アナリストと顧客のギャップ 
      
        
        
        
      
      2.「はい、しかし...」症候群 
      
        
        
        
      
      3. Zは彼が何を望んでいるか分からない 
      
        
        
        
      
      4. 3へのアクセスなし 
      
        
        
        
      
      5. Z-と互いに矛盾 
      
        
        
        
      
      6.いいえC 
      
        
        
        
      
      7.ドキュメントなし 
      
        
        
        
      
      8.要件の変更 
      
        
        
        
      
      9.未検出の要件 
      
        
        
        
      
      10.分散チーム 
      
        
        
        
      
      11.何も必要ありません 
      
        
        
        
      
      12.管理が前進する 
      
        
        
        
      
      13.多くのZ 
      
        
        
        
      
    
      
        
        
        
      
     ここにある。 解決する方法と問題を解決するためのテクニックが示されました。 スピーカー-uml2.ruのメンバー。 
      
        
        
        
      
    
      
        
        
        
      
     最新の講演はアジャイルアナリストです。 アジャイルの分析のギャップについて、彼が 
      
        
        
        
      
     チームを支援する方法、プロダクトオーナーとのやり取りなどを支援します。 
      
        
        
        
      
     面白くて活気があります。 
      
        
        
        
      
    
      
        
        
        
      
     すべてのレポートが公開され、おそらくビデオが公開されます。 どこでのみ、それは明確ではありません。 
      
        
        
        
      
    
      
        
        
        
      
     明日はSEFに行きません。  「サンオープンネットワークシステム:新しい時代の戦略とリソース」に進みます。 
      
        
        
        
      
    
      
        
        
        
      
     ずさんなコードはあまり気にしないでください。眠りにつく時間であり、早起きしてください。午前中に受験する必要があります。