只显示主题贴
在通过点击多次ie图标打开浏览器，这样浏览器就是多个线程的，在访问servlet时就产生了两个sessionId,
如何保证当用第一个浏览器登录网站，然后在第二个浏览器中访问网站时直接是处于登录状态的
- 进入论坛 入门讨论 版
我用过一些编辑器，多不是太好，最后还是用Ultra Editor,不知道有什么好的建议啊，现在编的脚本太多了
- 进入论坛 AJAX 版
我觉得在项目中把这种职能定的太死，又回到了瀑布模型了，如果要想做到敏捷，快速迭代很重要，如果把各个开发阶段分的太清，各人的职能分的太清，还怎么能迭代阿
开始的需求调研，应该是合同签订前进行，其实只是一些功能点的需求（说白了），而更细致的需求是需要在开发过程中进行的，如果让一个人专门去做需求，个人视角比较窄，难免会有需求偏离的问题，一般在敏捷里采用，用户参与团队开发的方式来做，共同讨论需求，但是，很多时候用户不会来参与团队，这时就需要行业专家来完成这一角色
- 进入论坛 软件开发和项目管理 版
我认为，你们各有各的道理，其实在中国大部分项目中有一个比较怪异的现象，就是客户需求，并不代表着实际的需求，尤其在一些国企中。之所以这样说，是因为大部分人还没有真正理解软件的价值。他们自己都不知道需要什么样的软件，本来还可以用demo的形式给用户来个感性认识，但是大多数 做项目 时，看demo的不是最终用户，而是那些高层领导，那些领导大多数注重的是界面的好不好看，你给他提供的技术流行不流行，至于你给他提供的功能，大体上有了就行了，这时楼主说的比较有用了。评价软件，不只看软件本身做的好不好，而是软件所达到的效果，软件毕竟是为人服务的，比如说，原来企业中做同一件事需要十个人现在需要2个这就是软件的价 ...
- 进入论坛 软件开发和项目管理 版
楼上的仁兄，说得不错，客户就是我们的上帝.
但是我觉得你的那种方式并不适合所有的项目
客户需求固然重要,但是不同的软件种类,它的地位就不一样.在一个比较大的软件项目里,用户的需求就会有众口难调的问题.你虽然认真耐心的做客户需求,但是客户有时候对软件的概念还很模糊,他只能从数据和界面上提供需求,而对于软件的骨架,他们的需求往往提供不了帮助,
在这里就像你买海尔一样,首先有个品牌效应,然后再去做细致的工作.可能更省力一些.在软件里边的品牌效应不一定像买电器,其实首先应该给他们灌输一些软件的思路,这会给你以后的需求调研带来很大帮助,这样的软件才能比较成熟,就像sap一样,人家给你提供的不仅仅是一套软 ...
- 进入论坛 软件开发和项目管理 版
领域专家确实很重要，行业软件很需要这一类人，其实他是代表的一个总客户，因为客户虽然是实际业务的运营者，但是，客户一般不可能使一个人，这些客户大部分只知道整个业务的某个片断，这就给需求调研带来很大困难，其实现在很多的需求调研大部分都是敷衍，没有完成真正的价值，这就把压力放到实施阶段了，很多软件都是在实施阶段进行很大的修改，这主要是没有在前期进行很好的业务建模。
我一般都把客户的需求分成三个层次：
一是业务模型二是数据接口和数据需求三是界面表现
业务模型，是整个软件的核心，只有做好了他才能使整个软件正向前进，保证后续工作的进行
- 进入论坛 软件开发和项目管理 版
之所以称是软件工程，并不是指理论，他是指正过软件构建过程是作为一种工程，理论是指软件工程学
所有这些理论，书籍所讲的只不过前人的经验的提炼，所有这些没有最好的，只有最适合的，中国人讲究天时地利人和，所以什么样的软件开发过程都不能盲目应用，要因时而定，因地制宜，因人而异。
我觉得失败的经验对我们更重要，如果一个人按照一种方式失败了，那么，其他人照他这样去做肯定会失败，而且其他人看到了这些经验肯定不会再去做，但是如果我们接受的是成功的经验，那么一些人，可能就盲目的模仿了，其实不可能有和比尔盖茨同样经历的人
我觉得软件工程虽然是一种偏向宏观的科学，但是在掌握时应该细致一些，这样可能应用时更容易取各 ...
- 进入论坛 软件开发和项目管理 版
我觉得不要太强调把整个过程的分得过于清晰，而应该根据具体情况来定，如果团队开发一个熟悉的领域，当然可以先进行业务建模，然后进行需求调研，但是如果涉足一个新的领域的话，我认为需求调研中就应该包含业务调研，需求调研不应该只是被动的接受客户提出的要求，还应该主动去了解行业的知识，客户的业务运转模式，和业务规则，通过调研人员主动去认识业务，并且这里存在一个管理思路的问题，一个软件并不只是迎合用户目前的业务，而是通过软件来提高用户的生产效率达到一个更好的效果，虽然现在国内软件做的并不是那么好，但这总是个方向。有点跑题，但是我觉得如果有能力在需求调研前业务建模当然是好，要是不行，我觉得在系统分析时做比较合 ...
- 进入论坛 软件开发和项目管理 版
评论排行榜