管理方面 问题 1. 忽视软件过程管理 (1) 没有规范和切实可行的管理体系,过程管理无章可循,仅凭个人经验实施 (2) 不能真正技术实施和过程管理的工作任务,概括为“没事做”和“没人做”并存的现象 2. 计划过程粗略,执行控制不力 (1) 项目管理计划粗略 (2) 开发计划不充分 3. 缺乏需求基准 4. 缺乏成本控制体系和过程 5. 质量保证过程薄弱 1. 加强对技术过程的管理控制 (1) 做到过程管理规范一致、有章可循,将管理要素融入到技术实施过程,同事去分技术实施和过程管理,指派专门人员或小组具体负责过程管理 2. 完备的计划过程,严格的执行控制 (1) 制订详细和完备的计划,对计划的过程、跟踪、变更进行全程指导,同时保证计划的“粒度”和执行的严肃性 (2) 开发过程管理强调制订充分的开发计划和切实可行的开发目标 3. 建立需求基准和项目范围基准 4. 基于WBS的成本控制体系,基于进度的成本控制过程 5. 质量保证过程贯穿项目始终 措施 技术方面 问题 1. 需求分析 (1) 客户并不(确切地)知道自己需要什么 (2) 需求在项目过程中发生改变 2. 软件设计 常见错误 (1) 僵化——设计难以改变。有时单一的改动,却牵连很多模块,导致有依赖关系的模块连锁改动 (2) 脆弱性——设计易于遭到破坏。新增加的功能引起了其他部分发生错误,修正这些错误又引出更多的错误 (3) 牢固性——设计难以重用 (4) 黏滞性——难以做正确的事情。保持初始设计的改动比破坏初始设计的改动更困难 (5) 不必要的复杂性——过度设计 3. 代码编写 (1) 程序员各自为战,缺乏分工合作 1. 需求分析阶段 (1) 在项目开始之初,充分了解项目目标、交付成功和范围;确定客户的人和假设;撰写项目远景陈述,包括特殊功能、给用户带来的好处、出现的风险、解决的问题,让用户阅读,保证理解的一致性 (2) 为变更请求定义明确的过程;为每个开发阶段设定转折点,超过转折点就不允许改变;在将要完成的阶段中,不允许临时改变,若确实需要改变,需通过正式变更的方式进行 2. 软件设计 (1) 邀请业务专家参与设计过程,保证软件的业务架构 (2) 可维护性需求作为度量需求,多利用设计模式 (3) 提前分配资源,测试人员提前参与 3. 代码编写 (1) 通过交叉检视评审,人员相互熟悉工作,避免缺乏合作 (2) 通过单元测试,避免语言工具掌握不熟练带来的偶然错误,加强措施 (2) 对编程语言及工作不能准确掌握 (3) 不必要的重复 (4) 晦涩混乱的表达 4. 测试 培训和知识共享提高开发人员水平 (3) 避免复制代码,坚持设计回溯,对冗余代码及时重构 (4) 制订统一的规范,保证代码到软件外观整体风格的统一 4. 测试 (1) 加强观念教育,重视测试,但不能完全依赖测试发现问题 (2) 认识到测试的局限性,利用分阶段集成,自动化测试等手段增强缺陷发现能力 (3) 及早分配人力资源,测试人员从前期就开始参与 (4) 建立缺陷跟踪流程
因篇幅问题不能全部显示,请点此查看更多更全内容