请教软件团队开发的步骤请教！ 请前辈指点，小弟先感谢了！

背景：自己是一名高校教师（自己也是学计算机的，c# sqlsever等基本入门），对教务管理业务很熟悉，自己也开发了一些小的教学管理软件。问题：假如我现在建立了个小团队（3人，只懂开发，基本不懂业务），现在想开发一套高校的教务管理软件（vs2010+sqlsever2008+asp.net+c#）,但不知道这种团队的开发应该怎样来操作？想请前辈帮我解答一下以下问题：
1、我第一步应该做什么？（自已用搭建了一个TFS2010的环境）
2、应该怎么把需求描述出来供开发人员来开发？ 是用word描述一个文字版本的还是用相应的软件来描述需求？
3、从开始到最后的软件完成，我作为一个项目的牵头人需要做哪些工作？

解决方案 »

  1.   

    用VS2010上画画UML好了，你作为头头，那就你来架系统架构，并划分模块 用于分工
      

  2.   

    比如说你放一个软件以及问题管理系统到面向学校全体师生的网络上，假设在前1周内重量级的问题（BUG和需求）少于20个，那么你的产品管理工作可能就是失败了。因为这时候产品不稳定，明显的bug以及非常类似bug的设计争议问题肯定有至少20个，为什么不能立刻被人家指出来？说明没人关心它。所以靠外界手段来管理项目，而不用整天“窝里斗”地去些什么文档、讨论什么需求，用敏捷、持续发布的理念去管理项目里程碑开发计划。这是可以解决很多在学校里、不“接地气”的高高在上的开发人员的问题的。
      

  3.   

    传统的软件工程是基于文档驱动的，自然而然地会导致瀑布式的开发。现在，即使淘宝、百度那么大的产品也是3、5天就上线一次地。没有什么需求是早期以前就定死了的，你的长期产品计划不用搞成什么八股文似地“国标”软件开发文档，实际上只需要用一两页A4纸管理好自己的整个项目就行了。逻辑设计只需要抓紧一周时间，然后就可以一边开发一边设计。产品要非常容易访问（知道一个互联网url就可以了），千万不要预设麻烦的什么巨大类库。可以循序渐进地发布一个一个产品页面，对用户来说感觉产品不知不觉地丰富起来，每隔两周就出现一些非常想要的东西。一个管理软件和普通网页，完全可以混淆起来。这样容易让用户愿意自己可以主动地去尝试使用它。用户喜欢网页冲浪式的设计思路，最讨厌传统的mis软件那种只为专业用户设计的思路了。
      

  4.   

    建议如下:
    1.需求文档 -- Word即可,尽量描述清楚业务,然后尽早先做出一套Demo,从而直观的发现问题和分析问题.
    2.系统用例 -- 这个时候建议用visio画画UML图,基本能满足要求的.
    3.数据库设计 -- 这个需要建立在前两个的基础上,尽量少的出现冗余和缺失.
    4.开发,测试.
    同时建议LZ为简单的话可以用个Excel跟踪任务,从而制定计划,如果要更专业一点,也可以用Project去画甘特图,从而跟踪每天的任务量.
      

  5.   

    第一步，你把最终软件的界面画在PowerPoint上，没有比这个更重要的了
    Trust me
      

  6.   

    红色的字是client给出的回复，所以说软件做的前后差距是非常大的，就像你看小说你的妞，每个人都会去无限联想，你需要让所有人打破这个想象，实实在在告诉他们，看照片，这就是那个妞。
    对于客户来说，软件界面就是所有，他们不关心业务，不关心后台，不关心性能和设计。
      

  7.   

    1.先是需求调研，用word写需求报告，你们小组一共才三个人，沟通很方便，大家都把自己的思想表达出来，前期的准备工作很重要。
    2.搭框架、开发，这个就不用说了，看你们的技术和能力了。
    3.测试、实施，测试的话很多公司都是自己的东西自己测试，但是你们三个人便于交流，可以互相的找bug，这样效果会更好。
    4.维护，这段比较辛苦，好的东西都是不断的完善出来的，一开始谁也不能想的那么周全。贵在坚持么！
    祝你早日成功啊！！！！！
      

  8.   

    this is not the content that fits in one page...
      

  9.   

    2个人把需求读懂
    2个人结对
    一个TDD 一个VIEW.按照此功能写代码(小范围迭代)测试->重构->需求理解->是否有问题->修改->测试->重构......(迭代)->功能完成(View)
    -->next module(continue.)
      

  10.   

    你需要干的事：
    1.首分析你的业务需求，明确你的系统功能与界面，使用UML图去设计你的系统，画出用例，类图等，做个大致就差不多了，招集你的组员，讨论系统的功能与设计，明确目标，确定大致的设计方案。
    2.在上述基础上，再进不步细化你的设计与系统构想，如果有数据库，设计数据库模型，把类图设计再细化具体些，形成些简洁的文档做为设计方案给组员平时参考，并将工作拆解开，给各组员分派工作任务与职责。
    3.搭建个小的开发环境，最主要是有个版本控制器，如SVN，CVS等，建立你的项目雏形，看能否先最快速开发一个最简单的可以运行的东东，有系统的原始相貌就好。
    4。在这个最原始的胎胚上开始具体的详化的工作，首先实现出界面和主要功能体，简单的功能实现让一个人去做，复杂点的就让两个人同时去做，结对可使工作更有效，利于解决问题，将一个个功能实现出来。
    5.当项目开始进入了开发后，你就需要控制各个功能实现是否满足要求，当项目完成了40%以上后，有了主要的界面主功能部分，你就要确认考虑原先的设计是否能达到你设想的系统目标，如果是继续，如果否，原来设计是否有问题。
    6.最终把软件的每一个功能细节都实现出来，并做测试。
      

  11.   

    首先，我认为楼主的问题其实和软件项目管理是同一个问题。作为一个软件项目，而楼主又是教师，肯定对项目管理的知识非常了解，只是要运用到开发管理工作中。其实技术本身不是问题，问题是项目的管理，也就是软件团队开发的管理工作。
    针对每个问题，我的看法是：
    1、我第一步应该做什么？（自已用搭建了一个TFS2010的环境）
    我的答案：做一个立项报告（哪怕只有自己看），并让团队明白项目的目标，预算和分工以及大概的计划等信息，否则大家都是无头的苍蝇，技术再好估计也做不出什么东西的。2、应该怎么把需求描述出来供开发人员来开发？ 是用word描述一个文字版本的还是用相应的软件来描述需求？
    我的答案：这个问题视团队成员而定，如果楼主和团队成员都很强悍，那用软件最好了，规范，而且信息量大，能最大程度的消除歧义。但是如果整个团队水平不够高，大量的时间花在软件使用上，出来的东西成员又看不懂就麻烦了。所以这个问题问自己，问团队成员。3、从开始到最后的软件完成，我作为一个项目的牵头人需要做哪些工作？
    我的答案：简单的说，包括：立项，明确项目范围和需求，制定计划；需求分析与设计；编码；测试；审核；发布产品；项目收尾，写项目总结，以及其它的团队组织建设工作，比如经常请大家吃吃饭，鼓励士气等。可能我的答案不是楼主要的，我的建议是，既然是团队开发，那就按照项目管理去做，楼主的重点应该是管理也业务，而不是技术，否则你的小团队就不如你一个人效果好了
      

  12.   

    1.需求文档 -- Word即可,尽量描述清楚业务,然后尽早先做出一套Demo,从而直观的发现问题和分析问题.
    2.系统用例 -- 这个时候建议用visio画画UML图,基本能满足要求的.
    3.数据库设计 -- 这个需要建立在前两个的基础上,尽量少的出现冗余和缺失.
    4.开发,测试.
    同时建议LZ为简单的话可以用个Excel跟踪任务,从而制定计划,如果要更专业一点,也可以用Project去画甘特图,从而跟踪每天的任务量.
      

  13.   

    恰好自己写了一篇自己做过的系统的感触,欢迎大家指点啊
    http://blog.csdn.net/beijiguangyong/article/details/7276964
    =========================================================================================   

  14.   

    教务管理系统我上次给公司写了个解决方案，要是你需要可以给你，开发主要是调研那一块，如果调研不成功，那么后来的维护就太麻烦了，顾客的需求总是会变的，还有就是尽量避免用户操作时候的错误，调研过后签个合同，你就可以开始做项目了，可以先做静态的或者dome之类的给客户确认一下，或者建框架做少量的动态去确认，边开发边确认，后面你开发过就不用我说了，
      

  15.   

    第一次需求分析会，客户会提根据自己的理解，提出一个很简单的需求文档，让我们可以理解整个系统的功能需求和大致轮廓。会议上，所有人都很快地读一遍这个需求文档，然后向客户提出一点问题，算是对这份文档有一个初步的认识。会议结束后，每个人都会得到一份需求文档的复印件。因为打印室里总会有许多的废纸，所以我们每个人会有一个草稿本和几支铅笔。于是每个人从自己的角度，分析和理解这份文档里的概念、规则，然后涂鸦在这个草稿本上。有些性急的，甚至已经开始画一些简单的类图。然后又是一次项目组的会议。会上，会搜集和整理所有人的草稿和笔记，统一对业务概念和业务规则的认识，逐一梳理成形，在团队内部形成统一认识。这是讨论最热烈的时候。接着，把上述整理成果在与客户的会议上进行交流，确认我们对业务概念的定义、对业务规则的理解是否正确，差不多就是建立这个项目的“通用语言”。接下来，开始建立模型的用例图、类图，并使用白板、彩笔和客户方的代表进行交流，逐步完善这个模型。有了初步的模型图后，业务建模、UI设计和测试会先开始。此时只提供UI草图和UI操作流程图，让用户对系统的表现和使用有个初步的认识，同时也通过UI反馈和修正一些业务概念的定义，同时为使用说明书的编写打好基础。测试和业务建模此时彼此促进，从最简单的一个类开始，一步步实现聚合，并发掘一些隐式的业务概念和规则。这应该是最困难和最枯燥的一个阶段。在这个过程中，我们会用测试驱动的方式，用一些测试的用例给用户模拟系统的简单流程，并根据客户的反馈不断修正。权限管理、并发处理此时也会被引入模型。然后就是这个周而复始的迭代，直到最终模型成形。然后开始设计数据库的实现，决定数据库与模型之间的映射关系，常说的DAL层会在这个时候实现。接着，从模型提取出的服务，组成应用层的基本元素，开始设计和丰富应用层，并且根据UI层的需要，设计扁平的、用于UI交互的类，避免业务实体直接暴露给上层。此时，UI与数据库的测试，会是重点，也是难点。通过努力，系统的雏形算是出来了，然后会提交一个体验版本，由用户和项目组反复折磨后提出修正意见。然后又是若干次的反馈、修改，直到实现用户的需求，然后编制完成剩余的文档，结束。
    ------------------------------------------------------------------------------平均算下来，60%的时间用于和客户的交流，10%的时间用于项目组的内部讨论，20%的时间用于编码和测试，还有10%的时间用于插科打诨。当然，统一编码规范和培训的时间并未计入内。