SOFTWARE DEVELOPMENT LIFE CYCLE MODELS 5/13/2018

Outlines Classic software process models Modern software process models 5/13/2018

Process? What are you talking about? 5/13/2018

Requirement Gathering 5/13/2018

Requirement Analysis 5/13/2018

Design 5/13/2018

Implementation 5/13/2018

Testing 5/13/2018

Delivery 5/13/2018

Maintenance 5/13/2018

Project Management 5/13/2018

Process: putting pieces together 5/13/2018

Classic: Waterfall Model 5/13/2018

Characterized by Advantage Disadvantage Feedback loops Documentation-driven Advantage Maintenance is easier Disadvantage Can not see the product until the end 5/13/2018

Classic: Rapid Prototyping Model 5/13/2018

Characterized by Advantage Requires Rapid prototyping to determine what the client needs Advantage Deliver what the client really wants No feedback loop needed Requires Rapid prototyping Modify prototype easily 5/13/2018

Classic: Spiral Model Click here to see flash movie 5/13/2018

Precede each phase by Follow each phase by Strengths Weaknesses Alternatives Risk analysis Follow each phase by Evaluation Planning of the next phase Strengths Identify and manage risks Weaknesses For large-scale software only For internal (in-house) software only 5/13/2018

Modern: Iteration and Incrementation Real software development process is iterative and incremental process We make mistakes Moving target Miller’s Law 5/13/2018

5/13/2018

During each increment, several iterations are performed 5/13/2018

During each mini project we A project as a whole is considered as a set of mini projects (increments) During each mini project we Extend the artifacts (increment); Check the artifacts (test) If necessary, change the relevant artifacts (iteration) The final set of artifacts is the complete product 5/13/2018

Each iteration can be viewed as a waterfall life-cycle model Requirements phase Analysis phase Design phase Implementation phase 5/13/2018

Strengths of Iterative-and-Incremental Model There are multiple opportunities for checking that the software product is correct We can mitigate (resolve) risks early We have a working version of the software product from the start 5/13/2018

Forever: Code-and-Fix Model No design No specification Maintenance nightmare 5/13/2018

Comparisons Model Strength Weakness Code-and-fix Fine for short program that require no maintenance Totally unsatisfactory for nontrivial program Waterfall Disciplined approach, documentation driven Delivered product may not meet client’s needs Iterative-and-incremental Multiple chances to check for errors Always have a working version Mitigate risks early Spiral model Risk driven Only for large in-house project Competent in risk management 5/13/2018

Agile Software Development Methodology To satisfy the customer through early and continuous delivery of valuable software 5/13/2018

Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 5/13/2018

Agile Methods Agile methods: Agile Alliance (www.agilealliance.org) Extreme Programming Scrum Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Agile Alliance (www.agilealliance.org) A non-profit organization promotes agile development 5/13/2018

Extreme Programming The term “extreme” comes from taking those commonsense principles and practices them to extreme levels XP is a light-weight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing environment. 将常识性的原理和实践用到了极致 【commonsense】adj.具有常识的 【principle】n.法则, 原则, 原理 某些人在第一次接触 XP 时，会搞到吃惊或愤怒。XP 中没有一样概念是新的。大多数概念和编程一样老。 某种程度上 XP 是保守的－－它的所有技术都经过数十年（对于实现策略）或数百年（对于管理策略）的验证。 XP 的创新之处在于： *把所有这些实践结合在一起 *取保仅可能彻底地执行它们 *取保这些实践能在最大可能程度上相互支持 5/13/2018

Values of Extreme Programming Communication Simplicity Feedback Courage 四个价值 1、沟通 2、简单 3、反馈 4、勇气 XP 编程实际上是由这四个价值所驱动的，而不是实践所驱动的。 也就是说，如果实现某些XP实践，而得不到这四个价值的话，便失去了XP编程的意义。 5/13/2018

XP Life Cycle XP的生命周期包括五个结段： 1。 考察阶段（一般会持续几周到几个月） --客户在故事卡片上写出他们对第一版的性能的要求。 --开发团队开始熟悉开发工具和环境并对他们进行有效的测试 --开发团队也会通过建立样品模型来验证产品结构的可行性 2。 计划阶段（一般会持续几天） --确定故事卡所有故事的开发先后次序 --和顾客在第一版的性能的要求上达成协议 --开发人员对工作量进行初步估计 --根据这个估计定出开发的进度表 --一般来说，第一版开发的时间不应超过两个月 3。 多次反复到发布产品阶段（一般一次反复会持续1到4周） --这个阶段包括几次反复过程 --按反复的次数把计划阶段定出的进度表进行细分，每次反复要1到4周内完成 --首次反复的目的是要建立系统的整体结构。 这个目的可以通过选择有助于建立系统整体结构的故事来实现。 --每次反复中要完成的故事要由客户决定。 --客户设计的功能测试要在每次反复的后期完成。 --在最后的反复的后期，系统可以进入生产化阶段。 4。生产化阶段 --在把产品交付客户之前，要对系统的性能进行进一步的测试和检查 --如果这个阶段要有新的更改，这些更改是否要加到这次产品发布，团队要做出相应的决定。 --这个阶段的反复可以从3周减到1周。 --推迟实现的想法和建议要载入文档，以备维护阶段实现时使用。 5。维护阶段 --第一版的产品交付客户之后，团队要在保证产品正常运行的同时，不断推出新的性能。 --由于这个阶段的客户支持的任务，开发速度会减慢，所以这个阶段要加新人进来，也要改变团队的结构。 6。死亡阶段 项目有两种情形会进入死亡阶段 --客户再无新故事要加， 系统的性能和可靠性符合客户要求，所有的文档都不能再更改 --如果系统的性能不符合客户要求，或者再开发下去的费用太高 5/13/2018

Role and Responsibilities Programmer Analyze, design, test, program and integrate. Customer define stories to be implemented, the order stories implemented define functional test cases Tester Help customers write functional test cases Run functional tests regularly Broadcast test results Maintain testing tools 角色和责任 1、程序员： 是XP的核心。 和别人沟通； 习惯于简单； 会重构（复杂难学的技能）； 放弃对系统某个部分的所有权； 需要勇气。 2、客户： 两个重要部分的另外一半。程序员知道如何编程，客户知道要编制什么。 如何编写故事； 编写功能测试； 3、测试员： 5/13/2018

Tracker (your are the conscious of the team) Trace the estimates made by team and give feedback on how accurate they are Trace the progress and evaluate whether a goal is reachable given the resource and time constrains Coach Responsible for the process as a whole Remain calm when everyone is panicking Consultant External member possessing the specific technical knowledge needed Manager (big boss) Makes the decisions 4、跟踪者： 进行大量的估算，然后观察事实与猜想是否相符。 还负责从整体上观察项目。 还是团队历史的记录者。 5、教练： 6、顾问： 帮助解决疑难问题 7、大老板： 5/13/2018

Scope of Use Aimed for small and medium sized teams (3 to 20 people) The physical environment and the business culture affecting the development unit If you want to try XP, for goodness sake don’t try to swallow it all at once. Pick the worst problem in your current process and try to solving it the XP way.”(Beck 1999a) 1、适合中小团队（3－20个人） 2、工作环境也是非常重要的 3、企业的文化对开发部门的影响是ＸＰ的另一个关键问题 4、（落后的）技术条件也可能成为阻止ｘｐ成功的一个不可逾越的障碍 5/13/2018

Scrum 5/13/2018

5/13/2018

Roles Artifacts Product Owner - Scrum Master Team Product Backlog Sprint Backlog Product Owner: decides on and prioritizes functionality; serves as single point of contact to answer team’s questions about functionality; decides whether to release ScrumMaster: guides team throughout the process, helping resolve obstacles and remove impediments and run interference Team: does the work; produces something releasable by end of sprint , consists of programmers, testers, UI designers, etc. Product Backlog – all functionality and work that would like to have done for a product, fairly coarse-grained (all tasks not yet fleshed out), rough time estimates; Sprint Backlog – work defined for turning product backlog for a single sprint into potentially deliverable product functionality; more finely-grained tasks developed as start of sprint (4-16 hours). 5/13/2018

Team (programmers, testers, UI designers,etc.) Product Owner decides on and prioritizes functionality; serves as single point of contact to answer team’s questions about functionality; decides whether to release Scrum Master guides team throughout the process helping resolve obstacles remove impediments run interference Team (programmers, testers, UI designers,etc.) does the work; produces something releasable by end of sprint Product Owner: decides on and prioritizes functionality; serves as single point of contact to answer team’s questions about functionality; decides whether to release ScrumMaster: guides team throughout the process, helping resolve obstacles and remove impediments and run interference Team: does the work; produces something releasable by end of sprint , consists of programmers, testers, UI designers, etc. Product Backlog – all functionality and work that would like to have done for a product, fairly coarse-grained (all tasks not yet fleshed out), rough time estimates; Sprint Backlog – work defined for turning product backlog for a single sprint into potentially deliverable product functionality; more finely-grained tasks developed as start of sprint (4-16 hours). 5/13/2018

Product Backlog Sprint Backlog all functionality and work that would like to have done for a product fairly coarse-grained (all tasks not yet fleshed out), rough time estimates; Sprint Backlog work defined for turning product backlog for a single sprint into potentially deliverable product functionality; more finely-grained tasks developed as start of sprint (4-16 hours). Product Owner: decides on and prioritizes functionality; serves as single point of contact to answer team’s questions about functionality; decides whether to release ScrumMaster: guides team throughout the process, helping resolve obstacles and remove impediments and run interference Team: does the work; produces something releasable by end of sprint , consists of programmers, testers, UI designers, etc. Product Backlog – all functionality and work that would like to have done for a product, fairly coarse-grained (all tasks not yet fleshed out), rough time estimates; Sprint Backlog – work defined for turning product backlog for a single sprint into potentially deliverable product functionality; more finely-grained tasks developed as start of sprint (4-16 hours). 5/13/2018

A Scrum Sprint Sprint Planning Daily Scrum Commit to certain functionality & estimate Produces Sprint Backlog Daily Scrum 15 minutes @ start of day What have you done since last Scrum? What will do before next Scrum? What obstacles? Daily scrum helps bring the team together and holds each member accountable to the rest of the team – builds on sense of collective ownership. Reveals problems that can be solved together and keeps team members from waiting on each other. 5/13/2018

A Scrum Sprint Sprint Sprint Review Sprint Retrospective Team does the work! Sprint Review Show off completed functionality Sprint Retrospective What went well during the Sprint? What could be improved for the next? Sprint: team members have responsibilities: attend Daily Scrum, keep work updated in Sprint Backlog, communicate! Sprint Review: informal demo, whole team participates, afterwards Product Owner determines whether or not to deploy new functionality 5/13/2018

Approximate relative costs of the phases of the software life cycle [Schach 1999] 5/13/2018

5/13/2018

Key points to know Classic Agile Processes suit projects and customers Waterfall Spiral Iterative and incremental Code-fix Agile XP Scrum Processes suit projects and customers 5/13/2018

The Mythical Man-Month 5/13/2018

5/13/2018 他的思想的论著都收入了这本“神话般的人X月” 我们在这里要讲的三篇文章就是从这本书里调选出来的 5/13/2018

5/13/2018 Frederick P. Brooks, Jr. Kenan Professor of Computer Science Department of Computer Science University of North Carolina Chapel Hill, N.C. 27599-3175 brooks@cs.unc.edu Phone: (919) 962-1931 Fax: (919) 962-1799 照片上的这个人是Brooks教授。 说起软件工程领域里的工作来，我们不能不提到他。 他在30几年前提出的许多有关软件的管理和开发的思想，至今还在实践中不断地得到 证实和应用。他对软件开发过程的认识和焦虑，正是敏捷型开发方式中所要解决的问题 5/13/2018

A few facts about him: Degree: Award and medals: Industry experience: 5/13/2018 A few facts about him: Degree: Ph.D from Harvard University (1956) Award and medals: ACM Turing award winner (1999) John von Neumann Medal, IEEE (1993) Too many to list here … Industry experience: IBM Corporation: System/360: Manager of whole project, 1961-64 下面是有关他的个人的一些背景材料： 1。 学位：1956年哈佛大学博士 2。 得到的荣誉和奖章 --1999年获得ACM的图灵奖（这是计算机界的最高荣誉，相当于自然科学领域的诺贝尔奖） --1993年获得IEEE的von Neumann奖章 --不计其数，在这里不能一一列举 3。 工业经验 --曾在IBM Corporation工作过，是System/360项目的经理（1961-64） 5/13/2018

A few facts about the book: 5/13/2018 A few facts about the book: Classic book on software project management Published in 1975 and republished in 1995 Tar pit The mythical man-month No silver bullet (added in 1995) 有关这本书的一些背景 1。 是软件项目开发管理的经典著作 2。 1975年出版，1995年再版（20年之后）时加入了些新内容 我们在这里选择的三篇文章是 --沥青坑 --神话般的人X月 --没有银色的子弹（这是1995年再版时加入的文章） 5/13/2018

Some invaluable insights from the book 5/13/2018 Some invaluable insights from the book The Mythical Man-Month: Question: If you are a project manager and your project running behind schedule, what do you think about assigning more programmers to the project? Answer: Assigning more programmers to a project running behind schedule, could actually make it even later. 3。书中提出的一些宝贵的思想 --”神话般的人X月“一文中，他提出了著名的理论”往一个已经拖期的项目上再加程序员只能使该项目更加拖期“ --跟踪进度方面，当人们问道：“一个项目怎么会拖期拖了一年？”， 答案是：“一天一天的拖。” 所以每个层次 的管理人员都要密切注视以确保每个小小的里程碑得以实现是。 --概念上的完整统一：为了开发一个用户喜欢的系统，系统必须做到概念上的完整统一。要想做到这一点的唯一 途径就是把结构和实现分开。 5/13/2018

5/13/2018

How does a large software project get to be one year late? Answer: 5/13/2018 Progress Tracking: Question: How does a large software project get to be one year late? Answer: One day at a time! Continued attention to meeting small individual milestones is required at each level of management. 3。书中提出的一些宝贵的思想 --”神话般的人X月“一文中，他提出了著名的理论”往一个已经拖期的项目上再加程序员只能使该项目更加拖期“ --跟踪进度方面，当人们问道：“一个项目怎么会拖期拖了一年？”， 答案是：“一天一天的拖。” 所以每个层次 的管理人员都要密切注视以确保每个小小的里程碑得以实现是。 --概念上的完整统一：为了开发一个用户喜欢的系统，系统必须做到概念上的完整统一。要想做到这一点的唯一 途径就是把结构和实现分开。 5/13/2018

Conceptual Integrity: 5/13/2018 Conceptual Integrity: In order to make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. 3。书中提出的一些宝贵的思想 --”神话般的人X月“一文中，他提出了著名的理论”往一个已经拖期的项目上再加程序员只能使该项目更加拖期“ --跟踪进度方面，当人们问道：“一个项目怎么会拖期拖了一年？”， 答案是：“一天一天的拖。” 所以每个层次 的管理人员都要密切注视以确保每个小小的里程碑得以实现是。 --概念上的完整统一：为了开发一个用户喜欢的系统，系统必须做到概念上的完整统一。要想做到这一点的唯一 途径就是把结构和实现分开。 5/13/2018

5/13/2018 The Pilot System: When designing a new kind of system, a team will design a throw-away system (whether it likes it or not). --试点系统：在设计新系统时，团队要设计一个试点系统，然后不管是否喜欢它，最终要舍得把它扔掉。 --交流： 为了避免大灾难，所有在同一个项目中共事的团队之间一定要想方设法的保持联系。 --软件是看不着的：好多事情只有在新产品已经开发出一些功能，给用户试用过后才会变得更明确。这个 经历会生成一些本质的东西，这些本质上的东西会导致用户的需求或者用户看问题的角度的变化。为了 满足用户需求的变化，系统本身也需要更改。 5/13/2018

5/13/2018 Communication: In order to avoid disaster, all the teams working on a project should remain in contact with each other in as many ways as possible. --试点系统：在设计新系统时，团队要设计一个试点系统，然后不管是否喜欢它，最终要舍得把它扔掉。 --交流： 为了避免大灾难，所有在同一个项目中共事的团队之间一定要想方设法的保持联系。 --软件是看不着的：好多事情只有在新产品已经开发出一些功能，给用户试用过后才会变得更明确。这个 经历会生成一些本质的东西，这些本质上的东西会导致用户的需求或者用户看问题的角度的变化。为了 满足用户需求的变化，系统本身也需要更改。 5/13/2018

5/13/2018 Software is invisible. Many things only become apparent once a certain amount of work has been done on a new system, allowing a user to experience it. This experience will yield insights, which will change a user's needs or the perception of the user's needs. The system will therefore need to be changed in order to fulfill the changed requirements of the user. --试点系统：在设计新系统时，团队要设计一个试点系统，然后不管是否喜欢它，最终要舍得把它扔掉。 --交流： 为了避免大灾难，所有在同一个项目中共事的团队之间一定要想方设法的保持联系。 --软件是看不着的：好多事情只有在新产品已经开发出一些功能，给用户试用过后才会变得更明确。这个 经历会生成一些本质的东西，这些本质上的东西会导致用户的需求或者用户看问题的角度的变化。为了 满足用户需求的变化，系统本身也需要更改。 5/13/2018