软件开发三步曲
软件过程与管理
风险的不利性
风险的可变性
风险的相对性
风险同利益的对称性
风险分类——参与者、技术、结构、任务
风险管理框架——
软件项目常见十大风险——
德尔菲法（Delphi method），是采用背对背的通信方式征询专家小组成员的预测意见，经过几轮征询，使专家小组的预测意见趋于集中，最后做出最终的预测
风险影响= (可能的危害)×(发生概率)
风险定义——
一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
风险是未来可能发生的问题，而不是当前已经发生的事情
风险的产生一般是有原因的，例如，开发人员离职导致项目延期
风险的三要素——
事件
事件发生的概率
事件的影响
风险的基本性质——
风险的客观性
内部和外部质量(internal and external quality)
功能性，可靠性，有效性，可维护性，可移植性，和可使用性
使用质量(quality-in-use)
有效性，生产率，安全和满意度
有效性：软件产品在指定使用环境下，使用户准确、完整地获得规定目标的能力；
生产率：软件产品在指定使用环境下，使用户花费合适的与有效性相关的资源数量的能力；
项目庞大或复杂
项目管理(PM)就是在项目活动中运用相关知识,技能,工具和技术满足项目的要求。
项目管理的十大知识领域——
项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理
项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理、项目利益相关者管理
项目管理的五个过程组——启动、计划、过程、控制、收尾
软件产品目标的三要素：
软件测试之-软件质量、软件质量特性
软件测试之-软件质量、软件质量特性1.1 软件质量定义1）ISO关于质量的定义为：⼀个实体的所有特性,,基于这些特性可以满⾜明显的或隐含的需求。
质量就是实体基于这些特性满⾜需求的程度。
2）质量的定义包含三个要素：实体、特性集合、需求。
对软件测试来说，实体即测试的对象。
实体的特性集合：不同实体，其特性集合不同。
3）软件质量评价的标准：需求，质量和需求对应，需求有三个层次：显式需求、隐式需求、⽤户的实际需求。
4）由以上可以引申出软件质量的3个层次：符合需求规格、符合⽤户显式需求、符合⽤户实际需求。
*1*符合需求规格：符合开发者明确定义的⽬标，是内部质量，即从软件启动到交付⽤户之间产⽣的所有中间产品的质量。
*2*符合⽤户显式需求：符合⽤户明确说明的⽬标，是验收质量。
即⽤户在验收时评价产品的质量。
*3*符合⽤户实际需求：包括⽤户明确说明的和隐含的需求，是使⽤质量，即⽤户在实际使⽤过程中对产品的质量评价。
1.2 软件质量⼤师1）戴明是世界著名的质量管理专家，提出戴明质量管理的⼗四项原则，简介易明，称为本世纪全⾯质量管理的重要理论基础。
*戴明质量管理的⼗四项原则**1*创造产品与服务改善的恒久⽬的最⾼管理层必须从短期⽬标的迷途中归返，转回到长远建设的正确⽅向。
也就是把改进产品和服务作为恒久的⽬的，坚持经营，这需要在所有领域加以改⾰和创新。
*2*采纳新的哲学必须绝对不容忍粗劣的原料，不良的操作，有瑕疵的产品和松散的服务。
*3*停⽌依靠⼤批量的检验来达到质量标准检验其实是等于准备有次品，检验出来已经是太迟，且成本⾼⽽效益低。
正确的做法，是改良⽣产过程。
*4*废除"价低者得"的做法价格本⾝并⽆意义，只是相对于质量才有意义。
因此，只有管理当局重新界定原则，采购⼯作才会改变。
公司⼀定要与供应商建⽴长远的关系，并减少供应商的数⽬。
采购部门必须采⽤统计⼯具来判断供应商及其产品的质量。
*5*不断地及永不间断地改进⽣产及服务系统在每⼀活动中，必须降低浪费和提⾼质量，⽆论是采购、运输、⼯程、⽅法、维修、销售、分销、会计、⼈事、顾客服务及⽣产制造。
超详细的三部曲：搭建Nessus漏洞检测系统
Nessus 被认为是目前全世界最多人使用的系统漏洞扫描与分析软件。
总共有超过75,000个机构使用Nessus 作为扫描该机构电脑系统的软件。
自从1998年开发至今已谕十年, 故为一架构成熟的软件需要的软件包如下：Nessus-3.2.0-es5.i386NessusClient-3.2.1-es5.i386安装软件包1 安装服务器端、客户端rpm包（安装过程中会初始化服务器端插件）2 添加执行程序路径、帮助文件路径。
Nessus的相关执行程序默认位于/opt/nessus/sbin 和/opt/nessus/bin/目录，帮组文件默认位于/opt/nessus/man/目录。
可分别调整环境变量PATH和MANPATH，以方便执行Nessus相关程序及查看帮助。
下面这种是永久生效的：1.#vi ~/.bash_profile2.3.export PATH=/opt/nessus/sbin:/opt/nessus/bin:$PATH4.5.export MANPATH=/opt/nessus/man:'manpath’6.7.:wq!添加完以后，wq！强制保存退出配置服务端安装好nessus后，系统中将增加一个名为nessusd的服务。
只需要添加一个用于扫描的用户，并启动nessusd服务，服务端就基本配置完成。
Ps：Nessus还提供了一系列的脚本程序用于简化操作呢1启动Nessusd服务2 添加扫描用户执行nessus-adduser脚本，将会进入添加用户的交互式界面，需要依次指定用户名、认证方式、扫面规则等。
主要步骤：a.输入新添加的用户名，该用户不需要是本地系统用户（例如scaner1）b.选择认证方式（证书或密码），默认使用密码认证。
c.如果选择使用密码认证，则重复输入两次密码确认 (例如pwd123）d.设置扫描权限规则（可以为空），即允许该用户扫描哪些网段或主机。
每行设置一条扫描规则，一般使用"accept|deny IP/mask"的形式，“default deny|accept”的形式用于定义默认规则。
技术架构怎么写
构设计是需求分析到软件实现的桥梁，也是决定软件质量的关键。
编制架构设计说明书是开发人员向架构师转变必定会经历的过程。
在架构师整个的成长过程中，必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。
作为一个架构师，我想尝试一下根据这三个过程对不同能力需要，写一次系列文章，包括《架构设计三部曲之如何写架构设计说明书》、《架构设计三部曲之如何评审架构设计说明书》以及《架构设计三部曲之如何做架构设计》，一来可以帮助自己整理思路，重新审视架构设计，二来也可以与大家分享心得，听取大家的意见，共同进步。
本篇属于系列中的第一篇。
那么到底如何编写架构设计说明书？该说明书应该包括哪些方面的内容呢？我们知道，架构设计说明书是阐述系统架构具体内容的，根据我之前的文章《我的架构观-架构未来的发展》我们明白架构的本质是呈现三大能力：即系统如何面向最终用户提供支撑能力、如何面向外部系统提供交互能力、如何面向企业数据提供处理能力。
因此从这个角度看，对架构设计说明书的章节的设置及章节内容安排应该要能说明清楚系统架构到底是如何呈现这三种能力的，让我们逐个分析：系统如何面向最终用户提供支撑能力：这一点是要从系统自身的能力来看，即本系统到底应该具备哪些功能，各功能间如何协作以满足支撑最终用户的使用，其实就是要讲系统的功能架构或逻辑架构，回答系统从功能粒度上划分了几个功能模块或子系统，各模块或子系统之间的内部接口关系如何等问题。
当然还有一个需要考虑的问题，在纵向维度上，随着架构设计理念的不断发展，逻辑架构模型从最初的展示-数据两层模型，到展示-逻辑-数据（所谓的MVC）三层模型,甚至到展示-调用接口-逻辑-数据接口-数据五层模型，不同层次表明系统内部设计的精细程度，因此在逻辑架构设计中也需要针对实际情况加上这种分层设计的内容。
尤其是对于powser/Server架构模式的MIS类系统，这种层次更为常见。
朱兰三部曲的具体实施步骤
朱兰三部曲的具体实施步骤引言朱兰三部曲（ZhuLan Trilogy）是一种软件工程开发方法论，由中国公司朱兰科技（ZhuLan Technologies）开发和推广。
该方法论在敏捷开发和DevOps流程的基础上，结合了最佳实践和最新技术，旨在提高软件开发的效率和质量。
朱兰三部曲由三个关键步骤组成，本文将详细介绍这些步骤以及实施方法。
一、需求分析与设计在朱兰三部曲中，需求分析与设计是第一个重要步骤。
在这个阶段，团队需要与客户和利益相关者合作，明确软件项目的目标和需求。
以下是具体的实施步骤：1.确定项目目标：与客户和利益相关者共同确定项目的目标和期望结果，确保团队对项目的整体理解。
2.收集需求：与客户和利益相关者一起收集和记录项目需求。
使用面谈、问卷调查等方法来获取详细的需求信息。
3.分析需求：对收集到的需求进行分析和整理，识别优先级和相关性。
确保需求准确、一致和可衡量。
4.设计解决方案：基于需求分析的结果，设计软件的解决方案。
确定软件架构、模块划分和技术选型等。
二、敏捷开发与迭代朱兰三部曲的第二个关键步骤是敏捷开发与迭代。
在这一阶段，团队将根据需求分析的结果，以迭代的方式进行软件开发。
以下是具体的实施步骤：1.制定项目计划：根据需求分析的结果，制定软件开发的计划。
确定开发周期、迭代次数和任务分配等。
2.迭代开发：将开发任务划分为多个小的迭代周期。
每个周期中，团队完成一部分功能的开发、测试和部署。
3.持续集成与测试：在每个迭代周期结束时，进行持续集成和自动化测试。
确保代码质量和功能的稳定性。
4.反馈与修正：根据每个迭代周期的测试结果和用户反馈，及时修正代码和功能，保证软件的稳定和可用性。
三、DevOps流程自动化朱兰三部曲的最后一步是DevOps流程自动化。
这一步骤旨在提高软件的部署、测试和运维效率，以及整个团队的协作效率。
以下是具体的实施步骤：1.持续集成与部署：建立持续集成和部署的流程，自动化代码的构建、测试和部署过程。
软件开发流程的具体内容
软件开发流程的具体内容软件开发是一个复杂而又精细的过程，需要经历多个阶段和环节。
下面将介绍软件开发的具体流程，以便更好地了解软件开发的全貌。
1. 需求分析阶段。
软件开发的第一步是需求分析阶段。
在这个阶段，开发团队与客户进行沟通，了解客户的需求和期望。
通过讨论和调研，确定软件的功能和特性，明确软件的用户群体和使用场景，为后续的开发工作奠定基础。
2. 设计阶段。
在需求分析的基础上，开发团队进行软件的设计工作。
包括系统架构设计、数据库设计、界面设计等。
设计阶段的目标是确定软件的整体结构和各个模块的功能，为后续的编码工作提供指导。
3. 编码阶段。
编码阶段是软件开发的核心阶段，开发团队根据需求和设计文档，进行具体的编码工作。
根据需求文档和设计文档，开发团队使用相应的编程语言和开发工具，编写软件的源代码。
4. 测试阶段。
编码完成后，软件需要进行测试。
测试阶段包括单元测试、集成测试、系统测试等多个环节。
测试人员根据测试计划和测试用例，对软件进行全面的测试，确保软件的质量和稳定性。
5. 部署和维护阶段。
软件通过测试后，进入部署和维护阶段。
开发团队将软件部署到目标环境中，并进行相关的配置和优化。
同时，开发团队需要对软件进行维护和更新，确保软件的稳定性和安全性。
总结。
软件开发流程包括需求分析、设计、编码、测试、部署和维护等多个阶段。
每个阶段都有其独特的任务和目标，需要开发团队的密切合作和高效协调。
只有经过严格的流程管理和质量控制，才能保证软件开发的顺利进行和最终的成功交付。
CANoe入门三部曲
基础应用CANoe是Vector公司的针对汽车电子行业的总线分析工具，现在我用CANoe7.6版本进行介绍，其他版本功能基本差不多。
硬件我使用的是CANcaseXL.1,CANoe软件的安装很简单，先装驱动，再装软件。
安装完成，插上USB，连接硬件，这样在控制面板中,VectorHardware进行查看通过查看信息可知，CANcaseXL中的两个piggy，一个是251（高速CAN），一个是7269（LIN），另外常用的还有1054（低速CAN，或称容错CAN），因为CANcaseXL中只能支持两路通讯，这样piggy可以自由组合2,硬件连接正常，打开CANoe软件File->NewConfiguration可以选择新建工程的模版，我们这里选择CAN_500kBaud.tcn,这样新建了波特率为500KCAN工程，可以File->SaveConfiguration,进行保存3,接下来就要使用CANdb++Editor工具对总线网络节点，消息，信号，进行定义了。
点击工具栏的这个图标，或开始菜单中找这个工具启动启动后，File->CreateDatabase,选择CANTemplate.dbc,选择目录及文件名，进行保存右键Networknodes->New，进行网络节点的定义,这里只需要填写Name即可，例如：Node_A然后添加Node_B，完成后如下图，这样在Networknodes目录下面添加出来两个节点节点添加完成后，下一步添加CAN消息，右键Messages->New,这是需要定义名称，ID，DLC 等信息，如下：然后在Transmitters页面，点击Add按钮，添加Node_A为发送节点，意思就是说，此消息是从Node_A节点发送出来的其实还有一种方法就是，此时暂时不定义发送节点，然后直接以拖曳的方式拖曳到发送节点上，功能上是一样的有了消息，消息里携带的东西自然是信号咯，那么我们开始创建一个信号右键Signals->New,填写如下信息信号当然要放到消息中咯，切换到Messages页面，Add我们刚刚建立的Message_A,当然和上面一样，采用拖曳的方式从Signal到Message中建立关联也是可以的。
软通质量意识答案
1. [单选题]2/2以下质量策划描述正确的是（）A:措施制定即可，无需跟踪B:未按照实际情况制定质量策划C:未及时进行策划D:PM是第一责任人A:QAB:PMC:PLD:POA:合理化改进建议B:TOPNC:优秀实践D:质量回溯A:版本迭代计划B:测试策略、质量策略C:需求分析，需求澄清D:SOW下发、开工会A:合理化改进建议B:优秀实践C:质量回溯D:版本复盘质量的定义就是（）A:满足需求B:符合要求C:输出好的产品D:满足客户A:质量控制B:质量策划C:健康迭代D:质量改进A:能力氛围建设B:主管带头C:客户满意度D:管理评审A:需求B:要求C:命令D:诉求A:L3 BU定制级B:L1 业务线流程C:L2 研发项目流程D:L0 客户A:针对单个问题暴露出的体系/潜在系统层面问题，重复性质量事故或一批某一类共性的技术类和管理类问题，管理者指定的针对重大事故、重大浪费/低效的事故调查。
B:在项目交付过程中或结束后，通过分析总结交付经验、教训、成果，便于下一阶段及后续交付借鉴，通过继承的方式达成能力提升C:基层员工以促进本职岗位的效率提升、提高产品/工作质量、降低成本为目的，就某个主题运用质量方法开展的改进活动。
一般是基层员工自发的改进行为。
D:一般为组织级的关键问题，涉及面广、改进难度大。
需要管理者驱动，成立专项改进项目的方式来进行改进A:版本转测不通过B:私自接纳客户需求C:迭代问题解决率<85%D:问题单回归不通过A:下次不犯就行了B:PDU内通报批评C:口头批评教育D:项目组内整改A:版本复盘B:TOPNC:合理化改进建议D:周例会A:诉求B:要求C:需求D:客户A:质量保证阶段B:质量控制阶段C:全面质量管理D:质量检验阶段A:十大编码军规B:C&C++安全编码规范C:JAVA安全编码规范D:Web应用安全规范A:过程策划B:控制策划C:组织与运作D:持续改进策划E:风险管理策划F:目标策划A:了解即可B:动作做标准C:做扎实D:不打折A:运作成本B:鉴定成本C:预防成本D:失败成本21. [多选题]2/2质量三部曲包括：A:迭代健康B:质量改进C:质量控制D:质量策划A:代码合入规范B:主流语言编程规范C:十大编码军规D:小语种编程规范A:操作周期一般2周～1个月B:操作周期一般3～6个月C:重要、典型或共性问题的改进D:适合项目组管理的改进A:质量回溯B:优秀实践C:版本复盘D:合理化改进建议A:执行监控B:确定目标C:差距分析D:质量计划26. [多选题]2/2以下哪些是不属于工作标准零缺陷的要求A:比XX同事/次好一些就行B:良品率达到99.99%就好C:第一次把事情做对D:差不多就好A:QCC改进项目B:合理化改进建议C:优秀实践D:质量回溯A:措施制定即可，无需跟踪B:未及时进行策划PM主导，QA引导D:未按照实际情况制定质量策划E:质量策划制定后无需刷新A:实现客户满意B:创造和传递价值C:卓越经营目标D:提供高质量产品A:质量就是满足客户提供高质量服务B:工作标准是零缺陷C:质量用不符合要求的代价衡量D:质量体系的核心在于预防质量即符合要求A:满足客户，高质量交付B:主动倾听，开放透明C:换位思考，客户为先D:及时闭环，持续改进A:错误B:正确A:正确B:错误A:错误B:正确A:正确B:错误A:正确B:错误A:错误B:正确A:正确B:错误A:错误B:正确A:错误B:正确A:正确B:错误A:正确B:错误A:正确B:错误A:正确B:错误45. [判断题]2/2代码合入错误（漏合文件、文件覆盖）属于质量红线要求,坚决不能触犯。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件开发三步曲【摘要】：大部分软件项目从开始到结束都会经历相似的历程,即项目的生命周期。
一个项目首先被创立起来(开始阶段),并安排相应的经理人员,配备项目团队成员和启动所需的资源,制定工作计划。
然后项目就进入正轨,开始迅速攀升。
这期间不断取得进度,这种势头一直持续,直至面临其终结时刻。
这个过程,这就是项目的三阶段——启动、实施和关闭。
第一步：项目启动项目启动阶段的工作，是项目成功的起点，如果这个阶段工作不规范，那整个软件项目就会“上梁不正下梁歪”了。
一、项目立项当市场部门获取到来自市场的需求信息，并在充分的市场调查与分析之后，认为有必要启动软件项目时，应该向相关的管理者正式的提出立项申请。
将立项申请正式化，能够有效地规范市场部门与技术开发部门之间的信息沟通渠道及工作流程，也能够有效地界定两个部门之间的职责划分，避免许多不必要的麻烦。
１．立项申请实践中，采用标准化的《软件开发立项申请表》来完成这一流程。
该表格由市场部门填写，报相关领导审批后提交给技术开发部门。
该表格中应该包括了以下信息：（1）问题 / 机会：这一部门主要是提供该软件项目的背景介绍，说明其想要解决的问题，或是什么样的市场机会，这个部分将成为管理者决策的主要依据。
（2）项目目标与成功标准：项目目标是指用精练的商业语言描述项目想要表达的目标，并且设立可量化的成功标准对其进行解释。
（3）目标描述：这一部分是对项目目标的详细说明，将目标分解成一个个点，使得项目目标更有可实施性。
（4）假设、风险及障碍：如果立项申请人对该项目做出了一些假设，或预计到的一些风险及障碍，须在立项申请表中说明。
（5）客户名单：为了能够方便技术开发部门下一步的工作，在立项申请表中还需要提供相关的客户联系办法，包括该项目的提出人、决策人、使用人的信息。
《软件开发立项申请表》样例2．立项审批立项申请提出后，就需要对该立项进行评审。
评审工作应主要集中在经济可行性、社会可行性、技术可行性三方面（1）经济可行性：主要是对该项目的投资回报率进行估算，评估该项目是否值得投入，预计的投入与产出大概是多少等，评估的主体是市场部门；（2）社会可行性：主要对该项目是否符合社会相关的法律法规，是否违背相关的规定等，评估的主体也是市场部门；（3）技术可行性：主要是对该项目所涉及到的技术条件是否满足，公司在这块是否有能力完成，评估的主体是技术开发部。
请表》上签字确认。
转到技术开发部门。
不过请注意，这一决定并不意味着该项目一定要做，而是决定投入更多的人力、物力进行细化。
二、初步需求调研1）确定项目范围2）细化主要功能需求三、初步项目计划1）项目估算2）资源计划3）进度计划4）形成初步的项目计划5）项目计划评审第二步：项目实施一、计划和执行项目计划的优劣，直接影响到是否能够准确地进行进度的监控、人员的安排等各方面事二、项目启动阶段到了项目实施阶段，我们已经获得了一个初步的项目计划和初步的软件需求说明书。
在初步的项目计划中，已经制订出需求分析、系统分析与设计、编码/单元测试、集成测试、验收测试等每个主要阶段的时间进度。
并且还根据每个阶段的人员需求、软硬件需求，制定了资源计划。
要注意的是，这个初步的项目计划是建立在初步的软件需求、历史项目数据、估算经验之上的。
所以应该在开发部、市场部、管理层、客户中达成一个共识：这是一个初步的项目计划，更加精确的项目计划将在过程中逐步得到。
三、项目实施步步为营1．项目实施：需求分析子阶段在项目启动阶段，我们已经进行过一次初步的需求分析，确定了项目的范围和主要的功能需求，而在项目实施阶段的需求分析子阶段中将进行详细的需求调研与分析。
这个阶段主要的活动如下图所示：在需求分析子阶段，将生成：（1）细化了需求分析子阶段的项目组计划；（2）需求模型细化需求分析子阶段的计划，就是对需求分析的工作进行计划、安排，具体来说，就是修改进度图（建议采用甘特图）而需求模型则主要包括软件需求说明书（SRS）。
a制定详细的用户访谈计划，采用面谈、收集用户的各种现有文档、报表等方式了解用户需求，形成软件需求报告。
b收集用户的专业术语与行业知识，对项目组队成员进行必要的领域知识培训。
c使用UML技术进行需求分析，建立软件的Use-case模型。
在这一阶段中，尽量争取客户加入工作，共同进行需求的分析与探讨；d确保在需求分析阶段，确信所有参与人员都知道该阶段的目的是“确定我们要做什么”，而且一直使用“问题域”的思想思考问题；e需求分析阶段，要进行用户的分类，注意管理层与操作层的两类用户有时间可能对系统的需求是冲突的，一定要注意；f在需求分析结束后，一定要编写出完整的软件需求说明书，并召开正式的软件需求评审会，让客户完整地了解项目组队所认识的系统需求，并与其达成共识，在此基础上签字确认。
2．项目实施：系统分析设计子阶段在需求分析阶段，我们将得到一个问题领域视角的软件系统模型，这一模型在与用户交流、确认方面起到了良好的作用，但却不能够有效地指导开发，因此需要将其转换成为解决领域视角的软件系统模型，这项转换工作就是:系统分析与设计。
这一阶段的工作，也有一个大家已经熟悉的名称:概要设计，但我认为称之为高层设计更为准确一些。
我认为在这一阶段，应该生成软件系统的体系结构，也就是整个软件系统的蓝图。
软件体系结构有四种不同的视图：（1）概念视图：与应用领域密切相关，在该视图中，系统的功能映射为概念构件，并配套一些连接器(用于协调和数据交换)；（2）模块视图：将概念视图的概念构件与连接器映射为子系统和模块.（3）运行视图:定义系统运行的实体及属性，如存储器的使用率和硬件分配;（4）代码视图:将运行视图中的运行实体转换成为部署的构件(可执行代码)、将模块视图中的模块转换成源程序构件，并将源程序构件生成部署构件。
从上面的定义中，我们可以知道，概念视图主要是站在问题领域进行分析，概念视图与上一篇中介绍的上下文范围图十分接近，只是更加细致一些而已。
然后使用模块视图将问题领域转换成为解决方案领域，在模块视图中，还只是比较宏观的。
下图就是一个模块视图的示例。
紧接着，通过模块视图分析出运行视图，在运行视图中，就直接表示出了硬件系统与软件系统的物理位置，为今后的部署提供依据。
┌─────┐│用户界面│└─────┘┌─────┐│用户管理│└─────┘┌─────┐┌────┐│关系数据库││Socket通││ 接口││ 信接口│└─────┘└────┘而具体的细化工作，就是完成代码视图，将整个系统分解成为一些源代码构件，并定义出每个构件的功能，与其它构件的接口，这些源代码构件就是工作分解的依据。
代码视图的构建大家可以参考系统分析相关的书籍。
在体系结构的分析与设计时，参与人员主要是系统构架设计师，人数视项目的大小不同，以1-6名为宜，并且应该细化系统分析与设计阶段的工作进度，形成新的项目组计划，修改甘特图。
3．项目实施：编码/单元测试子阶段项目实施:编码/单元测试子阶段在前面几个子阶段中，制订项目计划时都是由项目经理协同系统分析员、构架设计师自顶向下地进行分解、估算。
到了编码/单元测试子阶段，项目经理需要根据计划，往项目组队中增加开发人员，并根据开发人员专业知识、技能水平的不同，将构件分配到开发人员，由开发人员自底而上的进行项目进度的估算。
具体来说，就是向开发人员提供软件系统的蓝图，以及要求每个开发人员，在4个小时内完成所承担的构件的详细设计(我建议使用纸面设计，再根据需求有选择性地建档，建档时间不作具体要求)，并对构件进行项目进度估计，绘制个人进度甘特图，提交与项目经理。
项目经理与开发人员进行协商，然后统一进度，下发开发任务卡，并根据这些资料，细通过这样的一个过程，可以保证每一个开发人员不是被动地接受任务，而是主动地参与项目计划，使得进度计划成为了每一个人的承诺。
该方法大大地调动了积极性，收效良好。
4．项目实施：集成测试、验收测试子阶段集成测试是根据高层设计的结果组织的测试，是内部的测试。
验收测试是根据软件需求说明书组织的测试，是对客户交付之前的mll试。
在这两个阶段、应该制订相应的测试计划来进行。
5．进度监控与计划修正在项目的实施阶段，需要不断地进行进度的监控，并且根据监控的结巢修正项目计划，并将项目进度的实际情况，知会市场部门相关人员，井且让客户了解实际的进展。
对于项目经理来说，不同阶段的进度监控有一些不同。
在需求分析、系统分析与计划两个子阶段，可以通过生成的文档等制品通过评审作为里程碑，通过跟踪完成的情况，再分析是否按进度进行。
而在编码/单元侧试阶段贝U可以基于每个开发小组(也可以是l个人)的微进度计划来做挣值分析。
以此来判断项目是否落后于进度、是否超出预算、是否拖迟了进度等等。
6．EvA(挣值分析法)范例实际中，我就将EVA分析法应用到自己项目中。
例如，某个构件的开发人员小组，制定根据这样的微进度计划，我们可以得到这个构件组的计划工作量(BCWS)：第 1 周：BCWS=5；第2周：模块开发是跨2一3周的工作，预计在本周将获取15人日的价值，累计后BCWS=15+5=20；第 3 周：模块开发的延续，获取6个人日的价值，加上单元测试、模块集成，共有6+3+4=13个人日，累计BCWS=33。
当项目进行一周后，周五下午，项目经理和构件开发组成员共同进行挣值数据采集，统而ACWP则是实际付出的人日。
第l周投人1个人工作5天，计5人日;第2周投人了3个人，工作5天，不过其中有l个人被抽调出l天，因此合计为5 X 3一l=14人日，合计已投入19人日，即ACWP=19。
通过上面的分析，得到:BCWS=20 BCWP=17.6 ACWP=19于是:SV(速度偏差)=BCWP一BCWS=17.6一20= 一2.4(你落后干进度)SPI(进度效能指标)=BCWI〕/BCWS=17.6/20二0.88(你以进度计划的88%效能在工作) CV(成本偏差)=BCWP一ACWP=17.6一19二一1.4(已超预算1.4人日)CPI(成本状况指标)二BCWP/ACWP=17.6/19二0.926(你以超出预算约7.4%的状态在工作)预测:EAC(预计最终成本)二BAC/CPI=33/0.926=35.6人日VAC(预计成本偏差)=BA C-EA C=33-35.6=-2.6人日(将超预算2.6人日)SAC(预计项目的最终进度)=3/0.88=3.4周(原计划3周，估计将花费3.4周)修正项目计划当你遇到这样的情况时，就需要问自己:为何比计划多花费了工作量?项目计划合理吗?理解任务吗?是否有分』自的事?有什么未发现的障碍?然后对项目计划进行适当的调整，并与开发人员一同寻找解决方案，然后修正项目计划。