软件项目经理面试题(有答案)_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
软件项目经理面试题(有答案)
上传于||文档简介
&&软​件​项​目​经​理​面​试​题​及​答​案
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩15页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢项目前期项目经理如何做好需求分析_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
项目前期项目经理如何做好需求分析
||文档简介
　　光环国际创办于2001年，一直专注于项目...|
总评分0.0|
&&需​求​分​析​是​项​目​开​发​的​基​础​,​基​础​打​的​牢​不​牢​直​接​关​系​到​后​面​所​有​的​工​作​,​是​项​目​实​施​成​败​的​关​键​。​P​M​在​项​目​前​期​该​如​何​做​好​需​求​分​析​？
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
你可能喜欢信息化规划
通过咨询项目或年度顾问方式，帮助您架起业务和IT的桥梁，解决业务和IT创新融合、现有系统取舍难、IT架构、建设路径、IT治理、IT支出优化等IT策略问题。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
通过电话，与您交流信息化现状及要解决的管理问题，帮助您确定IT建设的基本思路，回答您在IT规划方面的常见困惑。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
声明：此服务畅享IT不收取任何费用！
如觉满意，可为畅享IT向您的朋友圈进行口碑宣传。
与您签订总包或三方合同，帮您解决业务和IT规划落地走样、IT详细设计缺失、难以寻觅靠谱的技术供应商、多个供应商协调难、维护升级服务保障难等棘手问题。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
供应商选型
为您推荐与企业需求、预算相匹配的靠谱服务商、产品商，解决产品选型没有底、服务商质量难保障的问题。
现已开通地区上海--%>
对需求设计给出建议，对企业准备的需求文件提出评审意见。
目前已有73位项目经理成为畅享IT监理团顾问--%>
通过典型客户参观、专家评价等方式，对您预选择的供应商给出第三方评价。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
声明：此服务畅享IT不收取任何费用！
！如觉满意，可为畅享IT向您的朋友圈进行口碑宣传。
与您签订监理合同，以里程碑专家评审、项目变更协调、风险控制研讨、供应商关系协调、CIO智力网络等为主要服务内容，与甲乙方一起实现上线成功。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
通过电话，交流您IT建设的现状及面临的问题，在IT建设路径、供应商选择、IT项目棘手问题处理等方面提供智力和资源支持。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
声明：此服务畅享IT不收取任何费用！
！如觉满意，可为畅享IT向您的朋友圈进行口碑宣传。
开发维护外包
畅享IT帮助寻找可靠的、性价比高的开发力量，签订外包合同或三方合同，为企业提供可信赖的开发量，为IT供应商解决开发力量不足的问题。
畅享IT帮助寻找靠谱的、性价比高的维护力量，签订外包合同，对客户满意度负责，为客户解决维护运营服务保障难的问题。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
对IT系统、IT项目或IT管理进行评估，出具中立评估报告，解决IT评价难、取舍难的问题。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
企业若对供应商产品或服务不满意，可请畅享IT做案例采访，进行曝光。
拨打400-698-9918
立刻联系您身边的IT顾问，获得专业梳理（节假日不休）
声明：此服务畅享IT不收取任何费用！
！如觉满意，可为畅享IT向您的朋友圈进行口碑宣传。
400-698-9918
【畅享IT讲堂】企业必看：如何打造透明化管理？（12月15日）
跨界融合o聚势创新 第十二届信息化领袖峰会暨畅享网CIO年会
IT选型免费咨询
【畅享IT讲堂】招募主讲人，还不赶紧教学去！
畅享网招募IT服务合伙人！
每月一主题，每周一会议，畅享IT讲堂，您的免费进修学堂，赶紧去学习吧
当前位置：&&&
&&&&&&正文
(共 34 条) 上一页 1
9725|回复:
职能部门：
城市：上海
16:05:32 |
本文摘自我正在编写的网络新书《中式太极敏捷》。最新版请访问：&太极敏捷：先迭代，后敏捷。迭代式（Iterative）开发是敏捷（Agile）软件工程的基础，敏捷过程和方法（如 Scrum、XP、AgileUP、MSF for Agile 等等）所带来的许多好处与迭代有关。不懂瀑布式（Waterfall）开发与迭代式开发的区别，就无法真正理解敏捷。假设一个 9 个月的软件开发项目，最终确认有 100&个需求（项）；开发团队有 8 个人，2 人负责需求，2 人负责设计（兼编程），2 人负责编程，2 人负责测试。现在国内主流（主观印象，未经科学统计）的做法是，瀑布式，举例如下：需求阶段 2 个月设计阶段 2 个月（概要设计和详细设计）开发阶段 3 个月测试阶段 2 个月部署和交付阶段 1&个月以上是合同（契约）签订之后，双方约定的正式开发工期；合同签订前，是否存在一个需求阶段，我们另外讨论。这种开发方式其实存在很大的风险和浪费。瀑布式流程的缺点：&我们是否应该采用瀑布式，真的需要 2 个月的需求阶段呢？一种简单的回答是：根据项目的风险程度和不确定性（Uncertainty）来定。对于风险低、确定性高、效率要求不高的软件开发项目，可以采用瀑布式。&迭代的做法自 1990 年代中期以来，国外流行的是迭代式。当前采用迭代的主流过程模型有：几乎所有的敏捷过程 Scrum, XP, AgileUP, FDD, Crystal ...MSF for Agile, MSF for CMMIIBM RUPCMU SEI 的 CMMI 样板过程 TSP等等可以这么说，在软件工程生命周期选择瀑布还是迭代模型这个问题上，国外软件工程界已经基本达成了共识。典型的迭代做法取消了以上瀑布阶段划分，取而代之的是 9 个长度为 1 个月的迭代，每个月都会包含一些需求、设计、开发和测试等工作。这里所说的阶段（Phase）是指一段连续的时间，比如 2-3 个月。如果是贯穿整个软件工程做需求（通常到项目中期需求会稳定下来），比如采用迭代开发，那么就不存在一个传统意义上的需求阶段。因为每个月、每个迭代，都包含了需求、设计、开发和测试等任务，每个迭代所包含的工作类型都是相似的，不存在一个集中（只）做需求的阶段，以及需求阶段、设计阶段、编程阶段、测试阶段的叫法。所以 10 年前基于迭代式开发的 RUP 就已经把软件项目周期改成了起始、细化、构造、移交 4 个阶段，这种叫法更科学。&不需要需求阶段的理由瀑布式是一种最简单的开发模型，正因为它简单，所以无法应对许多复杂的项目。敏捷方法认为，所有复杂的软件开发项目都具有非线性、不确定的特征。我分析，迭代式开发取消了瀑布式的需求阶段，主要有以下几点理由。理由 1：完成一个项目中所有需求及其细节的定义、分析和确认，究竟需要多长时间，是不确定的。瀑布方式认为，我们可以事先用一个专门的需求收集、整理、分析和评审阶段来确认、稳定所有的用户需求，比如 2 个月。过去 40 年软件工程项目管理的统计数据表明，这种依靠低效的瀑布阶段做出来的需求，很大一部分是浪费，因为软件需求变化是一种常态，对于绝大多数的大规模、复杂软件项目来说，情况更是如此。任何人作出的任何计划，都是一种对未来的预测或臆测。我们凭什么认定某个项目 2 个月就能完成需求分析？是否有什么科学依据？需求分析能否在 2 个月内完成，或者到底需要几个月完成让客户确认，3 个月，4 个月，还是 5 个月，这是一种不确定。此外，客户已经签字确认、表面上冻结的需求文档，在项目的中后期，是否会发生变化？这也是一种不确定。敏捷迭代开发认为，事先指定这 2 个月的需求阶段缺乏科学依据，顶多是一种估算，到底能不能在 2 个月内完成所有需求的分析和确认，要看实际的进度，可能是 3 个月，也可能是 4 个月。谁都希望料事如神。关于针对未来事件计划和预测的准确性，往往存在这样一些规律。1）掌握的有效信息越多，计划和预测就越准。2）目标时间跨度越短，计划和预测就越准。&理由 2：通过设计、开发、演示等启发、反馈和验证手段，可以更快地帮助用户确认和稳定需求，整体提高需求分析质量。迭代反对的是，2 个月里单纯的只做书面的需求分析，没有架构设计和少量开发、测试的验证，这样做出来的需求质量往往是不高的。在这 2 个月里，迭代开发不会单纯地只做需求分析，还会做一些系统设计、原型开发和界面演示等工作，以便获得更高质量的需求定义。并不是说，迭代开发不能像瀑布式那样，一次性完成所有需求的分析和确认，当然也可以在一个月之内拿出一份（表面上完备、准确、高质量的）需求文档，但它究竟有多可靠呢？应该用实践来检验。迭代采用 Evolutionary Requirements 的做法。确认和稳定所有的需求，究竟需要一次确认，还是需要多次确认（通过多个迭代多次确认），这需要根据项目的实际情况和特点来定。理由 3：&需求分析与系统的并行开发相结合，可以有效地提高开发效率，缩短项目整体工期。显然，迭代比瀑布更科学、更合理，也更符合复杂软件项目开发的实际。&需要需求阶段的理由&理由 1：所有需求是一个整体，无法分批确认。（X）有一种理由认为，这 100 个需求的分析和确认工作必须而且只能一起、同时完成，比如在第 2 个月的最后一周。事实上，很多需求是可以分批、分层次确认的。有的需求很早就可以确认，有的很难确认、稳定。有一批需求一旦经客户确认、稳定了，就可以进入开发，而其他需求可以继续分析、确认和稳定，这样并行开发，就节省了时间。&理由 2：迭代开发无法一次性、集中地给出完整的需求文档（SRS）（X）一些观点认为：由于敏捷开发是一个迭代、一个迭代地做需求，每次只分析一小块，客户拿到完整的需求文档要等很长时间，比如 3-4 个月以上，甚至更长。例如，迭代 1 只完成 20 个需求分析，迭代 2 只完成 30 个需求分析，迭代 3 完成 30 个，迭代 4 完成 20 个，这样完成 100 个需求的分析，就至少需要 4 个月（迭代长度为 1 个月）。客户会等不及。所以，我们要用 2 个月集中做需求（平均每月做 50 个），一次性拿出全部的需求文档让客户确认。其实，这是一种误解。敏捷迭代开发是一种并行开发。如果客户要求 2 个月内拿出需求文档，敏捷团队可以完全参照过去瀑布式的做法，拿出一份完整的需求文档。例如，我们可以让 2 名或更多的需求分析员，采用过去瀑布式的工作方式，连续工作 2 个月，交出一份包含 100 个需求可让客户&确认&的需求文档。额外地，除了需求分析外，敏捷团队还会让团队中的其他成员做一些架构设计和原型开发，用来验证需求细节的可行性。敏捷团队会根据这 2 个月中的试验、开发和反馈结果，如实地告诉客户，由于时间紧迫，这 100 个需求当中，有 30 个需求我们进行了风险探测、初步设计和预开发，成功的把握很大，而另外 70 个需求当中有 10 个需求，可能还存在一定问题或风险，还需要我们花一段时间进一步确认。相反，瀑布式团队会怎么做？他们会拍拍胸脯，告诉客户：没问题，这 100 个需求就是你们需要的，我们 100% 能在预定日期前交付！&理由 3：并行开发的人手不够（？） 为什么我们需要 2 个月的需求阶段，2 个月的设计阶段？是因为前 4 个月团队人员不能全部到位，其他开发人员需要参与其他项目的开发，4 个月后编程人员才能加入。这点似乎也很有道理。...&<div class="votes" id="Score
畅享论坛提示：看帖后顺手回帖，是对辛苦发帖者的鼓励，是美德。
敏捷就是又好又快，多快好省！欢迎访问太极敏捷顾问团 /BizClub.aspx?id=2488
张恂，资深软件工程专家顾问；近 20 年专业编程经验，10 余年软件工程和研发项目管理与咨询经验；迭代与敏捷过程改进、软件项目管理、面向对象技术资深教练；资深 OU3（OOAD/UML、Use Case、UP）、业务建模和需求分析、软件架构与设计模式、CMMI-Agile 集成专家；太极软件工程（TSE，太极敏捷、太极建模、太极编程、太极架构、太极项目管理...）创始人。
行业：计算机软件
职能部门：研究/开发
城市：上海
17:05:41 |
需求分析阶段应该是需要有的，但是需求分析这项工作应该一直贯穿在软件开发过程中，因为需求会不断补充和调整。感觉需求不能平行拆分，应该是由粗到细，由面到点，否则，平行的需求可能会影响软件架构的设计。实际中可能不会这么理想，但这也算是个努力的方向。
行业：计算机软件
职能部门：
城市：上海
17:23:08 |
nj21 >> 感觉需求不能平行拆分，应该是由粗到细，由面到点，否则，平行的需求可能会影响软件架构的设计。实际中可能不会这么理想，但这也算是个努力的方向。对，好的做法是 T 型开发，点面结合。
敏捷就是又好又快，多快好省！欢迎访问太极敏捷顾问团 /BizClub.aspx?id=2488
张恂，资深软件工程专家顾问；近 20 年专业编程经验，10 余年软件工程和研发项目管理与咨询经验……
行业：计算机软件
职能部门：部门经理
城市：广州市
金币：1521
我们的做法是做需求的同时分析系统中的关键典型用例（尽可能覆盖使用到的技术）并实现之，目标是需求结束的时候，技术架构也稳定了，可以进入大规模开发。
敏捷就是又好又快，多快好省，欢迎访问太极敏捷顾问团:/BizClub.aspx?id=2488
行业：计算机软件
职能部门：
城市：上海
10:04:29 |
LS 这么做是非常敏捷的！
敏捷就是又好又快，多快好省！欢迎访问太极敏捷顾问团 /BizClub.aspx?id=2488
张恂，资深软件工程专家顾问；近 20 年专业编程经验，10 余年软件工程和研发项目管理与咨询经验……
行业：计算机软件
职能部门：部门经理
城市：广州市
金币：1521
11:47:21 |
一直以来的做法都是如此，技术这类的风险在前期阶段是需要尽可能识别和规避的。
敏捷就是又好又快，多快好省，欢迎访问太极敏捷顾问团:/BizClub.aspx?id=2488
行业：机械制造
职能部门：IT工程师
城市：武汉市
16:09:06 |
我有一个简单的应用，由于接口技术的限制，整整延迟了1个月。
Doing right things & Doing things right
行业：计算机软件
职能部门：
城市：上海
16:21:10 |
延迟 1 个月不算多，算正常。
敏捷就是又好又快，多快好省！欢迎访问太极敏捷顾问团 /BizClub.aspx?id=2488
张恂，资深软件工程专家顾问；近 20 年专业编程经验，10 余年软件工程和研发项目管理与咨询经验……
行业：机械制造
职能部门：IT工程师
城市：武汉市
22:06:48 |
关键是工期本来也只要3个月，却在连接技术上浪费了1个月时间
Doing right things & Doing things right
行业：计算机软件
职能部门：部门经理
城市：广州市
金币：1521
引用 sue_huangyong 发表于
22:06:48 的话：关键是工期本来也只要3个月，却在连接技术上浪费了1个月时间呵呵，本来只要3个月是拍脑袋拍出来的么？领导要求？&
敏捷就是又好又快，多快好省，欢迎访问太极敏捷顾问团:/BizClub.aspx?id=2488
行业：化工
职能部门：项目管理
城市：佛山市
金币：3453
12:27:29 |
在强调迭代的同时，也要注意计划没有变化快，一定要有变更的机制，抑制不合理的需求。
行业：计算机软件
职能部门：计算机软件
城市：上海
15:25:37 |
不需要？ 才怪！！！不管是集中做需求，还是贯穿整个软件工程做需求，怎么不需要一个阶段？
行业：计算机软件
职能部门：计算机软件
城市：上海
15:26:29 |
其实，是集中做需求，还是贯穿整个软件工程做需求，具体项目具体分析。没有绝对～
行业：计算机软件
职能部门：
城市：上海
16:09:28 |
引用 Sharemember 发表于
15:25:37 的话：不需要？ 才怪！！！不管是集中做需求，还是贯穿整个软件工程做需求，怎么不需要一个阶段？这里所说的 Phase 是指一段连续的时间，比如 2-3 个月。如果是贯穿整个软件工程做需求（通常到项目中期需求会稳定下来），比如采用迭代开发，那么就不存在一个传统意义上的需求阶段。因为每个月、每个迭代都包含了需求、设计、开发和测试等任务，每个迭代的工作都是相似的，不存在一个集中（只）做需求的阶段，以及需求阶段、编程阶段、测试阶段的叫法。所以 10 年前 RUP 把软件项目周期改成了起始、细化、构造、移交 4 个阶段，这种叫法更科学。
敏捷就是又好又快，多快好省！欢迎访问太极敏捷顾问团 /BizClub.aspx?id=2488
张恂，资深软件工程专家顾问；近 20 年专业编程经验，10 余年软件工程和研发项目管理与咨询经验……
行业：计算机软件
职能部门：计算机软件
城市：上海
11:19:14 |
小项目的话，怎么可能那么长的需求阶段？项目刚开始的时候，不是集中（只）做需求的阶段吗？这时候谁都不会开始做设计，除非傻子。如果用户的要求都不知道就开始做设计，那是闭门造车。猜想楼主是从程序员做起的吧？ 一般对做需求的认识不是那么深的...
行业：计算机软件
职能部门：部门经理
城市：广州市
金币：1521
11:36:24 |
项目开始阶段，需求的工作量占大部分，但“不是集中（只）做需求”，这时候要在需求的基础上分析关键用例，以进一步进行技术选型，及早发现问题，规避技术风险。
敏捷就是又好又快，多快好省，欢迎访问太极敏捷顾问团:/BizClub.aspx?id=2488
(共 34 条) 上一页 1
您还未登录，不能对文章发表评论！请先
07:53:35 948/ 07:53:35 964/ 07:53:35 979
专业服务公司IT系统蓝图与您共绘制
计算机软件
互联网/移动互联网/电子商务（中小型）
顾问/咨询/会计/招聘服务
培训/教育/科研院校（中小型）
广告/公关/会展
媒体/影视/艺术
本次活动针对以上行业
点击系统名称填写公司信息化现状，畅享网将核实贵公司的信息化现状。
核实信息后您将获得：
您所在行业的信息建设状况一手数据
100畅享金币
下载VIP权限3个月
截止日前填写还能获得专业行业信息化分析报告。