这周我们小组学习了第十一章学习内容-----软件设计与实现
首先我们要分析与设计方法
在“需求分析”阶段，我们要搞清楚：在问题领域中的现实世界里，都有哪些实体？如何抽象出我们真正关心的属性？实体之间的关系是什么？用户关心的是什么？
在“设计与实现阶段”，我们要搞清楚：软件是怎么解决这些需求的？
在“测试”和“发布”阶段，我们要搞清楚：软件真的解决了这些需求吗？
软件团队的所有相关人员都需要处理，了解这些信息，如果在处理的过程中有误解和遗失，就会导致开发过程出现问题，以至最终产品不能满足用户的需求。
分析与设计有许多方法：
以文字为主的：Word、PowerPoint文档。
以图形为主的：Mind Map，ERD,DFD,UML的各种图
用数学语言描述：Vienna Development Method
用类自然语言+代码构造的描述，如Literate Programming
图形建模和分析方法
我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系以及各个事物之间的信息传递。
思维导图：人们经常用图形来帮助他们了解概念，强化记忆。思维导图没有严格的语法意义，一般来说都是从图形的正中开始写下一个概念，然后按照绘图者所关心的属性扩展。
实体联系图：当我们注重与表达现实世界中的实体和他们之间的关系，那么就需要用到实体关系图ERD。这是一个理解和抽象的过程。
UCD：用例图的元素简单，绘图简明，它的主要目的是尽快让团队成员和利益相关者理解系统的需求。
从SPEC到实现
n 一个开发人员拿到设计文档（Spec）他会做以下几件事情：
估计开发所需的时间。
n
试着写一些快速原型的代码。
n
看到初始效果后开始设计文档。
n
按照设计文档写代码，并从中发现意外的问题。
n
写好代码后进行自我复审。
n
进行单元测试。
n
交给相关的测试人员。
n
修改测试人员发现的问题，然后交给同时进行复审。
开发阶段的日常管理
闭门造车
当场景，功能都计划好的时候，要给员工足够多的时间，让他们投入到工作中去，而不要经常打断他们。要尽量减少非开发时间，团队成员自我时间管理也很重要。
每日构建
在我们的全球调查中，我们发现成功公司中有94％每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去构建。当有一个能运行的系统时，即使只是一个简单的系统，团队积极性也会上升。
小强地狱
在开发过程中，开发人员一定会遇到很多小强。但是如果我们每遇到一个小强就去修复的话太过于浪费时间。这就导致有些开发人员积攒了大量的小强，进而影响了其他测试人员的任务。因此就要进行小强地狱！如果开发人员的小强数量超过一规定值，则此开发人员将被送入“小强地狱”，在“地狱”中，只能进行小强的修复，不能进行开发，直到小强数量低于规定阈值。当然，阈值由团队根据实际情况来定，不能过低而让全队人员都去“地狱”，也不能过高影响测试进度。
目前小组的实践项目进度：正努力实现计算一年内两天间隔天数的代码，目前得出以下实现功能的模块
//日期结构体
typedef sruct D
{
int year;
int month;
int day;
}Date;
//判断是否闰年
int IsLeapYear(int year)
{return(year%400==0||year%4==0&&year%100!=0)};
//获得某年某月最大天数
int GetMaxDay(int year,int month)
{
switch(month)
{
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
return 31;
case 4:
case 6:
case 9:
case 11:
return 30;
case 2:
return IsLeapYear(year)?29:28;
default:
return -1;
}
}