×

Loading...
Ad by
  • 推荐 OXIO 加拿大高速网络，最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务
Ad by
  • 推荐 OXIO 加拿大高速网络，最低月费仅$40. 使用推荐码 RCR37MB 可获得一个月的免费服务

@Florida

说得对， 看来这个问题是普遍存在。但是正像您说的， 经验还是决定项目成败的根本。 我觉得RUP等新概念，新工具的目的就是要把个人经验对项目的影响程度减到最少。

phoebus(天行者)
本文发表在 rolia.net 枫下论坛以前没有相关business经验， 在这个领域的项目几乎就不可能新手来做。象金融，证券，保险等都是非常专业的。但是现在采用这些标准化的Process，和工具， 与非常有经验的团队相比，差别应该缩小很多。

不管怎么说， 这些都是best practice, 也就是经验的浓缩。但是要怎么消化这个浓缩果汁， 怎么用好best practice？ 又需要一层经验。

经典的Design pattern都有很多applicable & not applicable, 可以说明得很透彻了。 但是对应RUP和UML的applicable & not applicable还差得很远。 希望大家能一起交流经验。

现在我就有2个问题， 一个请看帖子 #1347180。

第二个问题是我在国内网站交流时，别人问的一个问题： 如何把设计阶段的“拆分package”和分析阶段（System analyze 不是 requirement analyze）的Use case挂起钩来？ 目的是尽量使一个use case使用最少量的Package, 否则Package和use case交叉太多， 系统就会很凌乱，测试的时候，或者给程序员分工的时候就会遇到麻烦。

其实这个问题也和第一个问题有关：如何掌握System Use case的细度。只要够细，packaging的时候对系统的了解就足够， 设计的时候就不容易交叉太多。 但是太细了， elaboration阶段化太多时间和精力，把这个阶段当作construction就麻烦了。

当然反过来说， 如果第二个问题搞清楚， 对第一个问题也有一部分解答：Use case的细度作到对整个系统有足够的了解即可，或者作到对packaging有把握就好。

需要很多实例分析。 有什么相关的书讲这个吗？更多精彩文章及讨论，请光临枫下论坛 rolia.net
(#1347865@0)
Last Updated: 2003-8-27
This post has been archived. It cannot be replied.
Report

Replies, comments and Discussions:

  • 工作学习 / IT技术讨论 / 按照RUP的要求, CONSTRUCTION 阶段的每个ITERATION都要进行 Analyze, Design, Coding, Testing. 这个要求甚至超过了extreme-programming. -phoebus(天行者); 2003-8-27 {626} (#1347192@0)
    由于Architecture&Analyst不能对每个模块每个CASE进行细节Analyze&Design, 这样是否以后junior developer根本没有人要了.

    多种新技术都宣传: 开发人员从此不需了解database, thread, 甚至J2EE, 但是实际工作中发现都是假的, 也许有些技术能够让人少考虑一些问题, 比如用WEB/J2EE对thread pooling, connection pooling的考虑是少一些, 但是又多出很多问题要考虑: performance的考虑不同以往了, multi-tier增加更多的因素需要考虑.

    不像某些宣传的那样, 这些考虑都是Architect的事情, Architect不可能面面俱到, 只能在一定HIGH LEVEL 上考虑.细节还要靠每个做模块的人. 事实上不考虑这些问题的developer对项目有很大的损害.

    领导项目的大侠是否有什么经验可以讨论?
    • My point -ling7199(Michaell); 2003-8-27 {566} (#1347630@0)
      Agree. Architect only can the high level design, like how to use the framework, how to transfer the object, where do you use XML, how to solve the concurrency etc.. Logically, develper only need to coding, but sometimes designer also will make mistake(because he does not touch too detail for the implement), some problems only will be meet at the implement layer. That is the key value for a good developer. Just my point, for reference. By the way, RUP is only a methodology and tools, the key for software development still is experience and business knowledge.
      • 说得对， 看来这个问题是普遍存在。但是正像您说的， 经验还是决定项目成败的根本。 我觉得RUP等新概念，新工具的目的就是要把个人经验对项目的影响程度减到最少。 -phoebus(天行者); 2003-8-27 {1244} (#1347865@0)
        本文发表在 rolia.net 枫下论坛以前没有相关business经验， 在这个领域的项目几乎就不可能新手来做。象金融，证券，保险等都是非常专业的。但是现在采用这些标准化的Process，和工具， 与非常有经验的团队相比，差别应该缩小很多。

        不管怎么说， 这些都是best practice, 也就是经验的浓缩。但是要怎么消化这个浓缩果汁， 怎么用好best practice？ 又需要一层经验。

        经典的Design pattern都有很多applicable & not applicable, 可以说明得很透彻了。 但是对应RUP和UML的applicable & not applicable还差得很远。 希望大家能一起交流经验。

        现在我就有2个问题， 一个请看帖子 #1347180。

        第二个问题是我在国内网站交流时，别人问的一个问题： 如何把设计阶段的“拆分package”和分析阶段（System analyze 不是 requirement analyze）的Use case挂起钩来？ 目的是尽量使一个use case使用最少量的Package, 否则Package和use case交叉太多， 系统就会很凌乱，测试的时候，或者给程序员分工的时候就会遇到麻烦。

        其实这个问题也和第一个问题有关：如何掌握System Use case的细度。只要够细，packaging的时候对系统的了解就足够， 设计的时候就不容易交叉太多。 但是太细了， elaboration阶段化太多时间和精力，把这个阶段当作construction就麻烦了。

        当然反过来说， 如果第二个问题搞清楚， 对第一个问题也有一部分解答：Use case的细度作到对整个系统有足够的了解即可，或者作到对packaging有把握就好。

        需要很多实例分析。 有什么相关的书讲这个吗？更多精彩文章及讨论，请光临枫下论坛 rolia.net
        • 新工具的目的并不是"把个人经验对项目的影响程度减到最少", 而是把个人经验最好地验证、组织起来以发挥最大的效用. -xhis(枫下恩仇#13 xhis); 2003-8-28 (#1348170@0)

More Topics

  • 脑洞大开，突发奇想，用力来传播信息
  • 看大家讨论日语，俺也正在认真学习。其实语言问题应该是很快也很容易就解决的，可能比自动驾驶来的还快。TREK里面，全宇宙的人都在大脑里安装了UNIVERSAL TRANSLATOR，外星人之间相互交流无障碍。废话少说，看视频。。。加上个MIC和耳机，不同国家的人就可以无障碍交流。
  • 肉脸真有搞 IT 的？Linux 把俄国中国伊朗踢出去了好像肉脸 IT 没啥感觉似的
  • 请问web developer和software developer技术上有什么区别？
  • Elon Musk 带着川普总统奔向火星了。
    • 枫下论坛主坛 /  工作学习 /  IT技术讨论