原贴地址:http://pku-group3.spaces.live.com/
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
随着城市化的加速发展,城市交通问题也显得越来 越突出,我们提出要做一个智能交 通疏导系统和模拟系统。这个系统可以通过地图编辑来绘制不同的道路、路口,可以 通过设定车辆数目来实现不同的路况,可以用来测试不同的调度算法。从严格的意义上来说,它应该是一个带有地图编辑功能的调度算法模拟平台。它支持用户通过 编程方式来实现不同的调度算法,可 以为交通控制理论的研究工作人员提供交通模型模拟和实验数据,也可以检验各种交通控制和调度算法的实际效果。
2. 是否有充足的时间来做计划? 项目原来预计有多少用户,实际有多少用户? 为什么有如此落差?
3. 计划的时间比较充足,预计的用户不会很多,因为使用本软件需要有一定的编程基础和交通领域的相关知识,或是相关领域的研究工作者。他们使用本 软件主要就是为了测试实现的算法是否“智能”,当然,如果从长期效应来讲,本软件为交通智能调度和算法研究提供了良好的工具。本软件的预计下载量在30,实际下载量在40左右。
4. 团队在计划阶段如何解决同事们对于计划的不同意见的?
主要通过开会讨论来统一不同意见,开会后会得出一个大家都 一致接受的结论。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
计划的工作并没有完全做完,我们定义了4个scope并且预计实现其中的2~3个,最终实际完成了第一和第二个scope。没有完全完成的主要原因还是因为项目的时间吃紧,尤其是到项目进行的后期。另外一个原因就是我们缺少熟悉交通领域知识的人来支持我 们完成系统的开发,很多交通领域的专业知识是我们发现不足后临时学习的,这也很大程度的拖慢了项目的进度。
2. 有没有发现你做了一些事后看来没必要,没多大价值的事?
没有。
3. 每一项任务都有清楚定义的和衡量的交付件?
大的任务我们有清楚的定义和衡量,但并不是具体到每一个任 务都有定义,开发过程中弹性很大。
4. 在项目的整个过程都按照计划进行?
大体上是按照计划来进行。在全组人员的共同努力下,项目按照原定计划在6月23日发布Beta版本, 并开始收集该版本的用户反馈信息。在发布Alpha版本之后的两个星期,我们陆续收到了用户反馈信息。项目的进行基本按照计划,在不影响版本发布的前提下,对进度和任务做了一些必要的 调整。
5. 在计划中有没有留下缓冲区,缓冲区有作用么?
留下了缓冲区,缓冲区主要是用来处理项目后期系统临近发布 时浮现出来的各种Bug。
6. 将来的计划会什么修改? (例如: 缓冲区的定义,加班)?
应该不会有什么修改。
资源
1. 我们有足够的资源来完成各项任务么?
没有,在项目过程中,由于组员本学期课业任务比较重,能投入项目的 时间并不多,所以项目时间比较紧张。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
项目中的各项任务都基本按照经验来估计,放宽一定的缓冲 区,采用保守估计,现在看来,这个方法虽然估计精度不是很高,但是从结果来看还是保证了项目按照计划如期交付。
3. 用户测试的时间,人力和软件/硬件资源是否足够?
Alpha版本的测试时 间是2周,有点短,收集的用户反馈深度不是很 够;而且项目人力也存在问题。软硬资源得到了 保障。
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
主要是关于交通领域的专业知识我们小组还是有所欠缺,如果 有一个有这方面背景的人能够给予支持效果肯定会好很多,至少可以节约大量的时间。系统也能更加专业和贴近用户的使用习惯。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
我们通过SVN来管理代码,每个员 工都会受到变更消息。另外我们还有QQ群等辅 助手段来进行沟通。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们采用了划分优先级的方式确定了哪些功能必须实现,哪些 功能推迟实现。调度算法是推迟的功能,因为项目必须实现的是一个算法模拟的平台,即平台本身,而算法是可以由用户自行实现的。当然,我们也致力于找到很好 的调度算法,目前,只实现了几种简单的调度供用户参考使用。
3. 项目的出口条件 (Exit Criteria)是否得到清晰的定义? 到底什么叫 ”做 好了”?
我们通过验收测试来测试系统是否“做好了”,出口条件就是 开发出这个系统并且完成需求阶段定义的90%以上的功能。
4. 对于可能的变更是否能制定应急计划?
没有应急计划,项目变更时通过开会讨论的方式来控制和处理 变更。
5. 员工是否能够有效地处理意料之外的工作请求?
员工基本能在完成本职工作的同时,完成意料之外的工作请 求,例如,文档、BUG修复等等。团队比较团结,组员积极性 较好。
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
第一周头脑风暴确定要做的系统为:城市交通智能管理模拟系统,确定主要的功能模块为:地图编辑器和 路况监视器,并确定每个模块要实现的具体功能,如地图编辑器模块的地图保存功能,路况监视器中的局部查看功能,全局查看功能,局部放大功能,打印实时信息 功能等,头脑风暴由全组人员参加。第二周讨论具体的实现,由PM(沈阳),一个DEV(何 建杉),一个TEST(万成铖)参加。
2. 设计工作有没有碰到模棱两可的情况,团队如何解决的?
没有。
3. 团队是否运用单元测试(unit test), 测试驱动的开发(TDD), UML, 或者其他工具来帮助设计和实现?这些工具有效么?
在开发的过程中进行了单元测试,但是是通过直接编写测试代码进行的,没有用到专门的工具。
4. 什么功能产生的bug 最多,为什么?
汽车自主控制功能,包括当前的车道,当前所处的路口,前方是否有车辆阻挡,前方是否为路口,相位是 否已打开等等。因为汽车所处的状态是一直变化的,不同车道的行为时不同的,而且有随机行为,所以比较容易出现问题。
5. 代码复审 (Code Review)是如何 进行的,是否严格执行了代码规范?
由于时间限制,对关键模块的代码由测试人员进行了人工走查。
测试/发布
1. 团队是否有一个测试计划?为什么没有?
测试工作开始的初期就制定了测试计划,测试计划就确定了软 件的特性和测试范围并且决定进行以下测试
Code Reviews
Blackbox Testing
Fault Injection
Stability Testing
在开发过程中由开发人员完成了基本的单元测试和白盒测试。
2. 是否进行了正式的验收测试?
在需求阶段我们定义了4个scope,目前我们实现到第二个scope并且发布了相应的Beta版。根据需求阶段定义的系统特性我们进行了验收测试来确保系统实 现了预期的功能。我们找不到最终用户来帮助我们进行验收测试,所以是由软件测试人员完成。
3. 团队是否有测试工具来帮助测试?
系统开发主要使用MFC技术,我们没有找到 比较适合的针对MFC程序的开源或者免费的测 试工具,更没有时间来开发钻用的测试工具,所以所有的测试代码都是由开发人员和测试人员手动编写。系统的特殊性决定了我们很难找到合适的测试工具。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
对软件效能的测试主要是通过运行系统并且观察结果来完成 的,软件运行以后效能必须在用户可以接受的范围以内,从软件实际运行的结果来看这些测试工作还是很有效的,我们先后争对效能进行过两次改进,每次改进都有 明显提高运行效率。
5. 在发布的过程中发现了哪些意外问题?
在发布过程中遇到的意外问题就是上传的资源意外被CSDN删除,或者是由于CSDN资源站不稳定导致用户下载资源是出现“当前资源不存在”的提 示。我们发现后又重新上传了对应版本。
Smart City 用户使用说明
2,点击鼠标右键切换贴图
3,按住shift和鼠标左键进行组合直线绘图
4,按住ctrl并点击鼠标右键选取上一幅贴图
5,按住ctrl+shift+点击鼠标左键或者拖动删除当前的贴图
1,点击“操作”=》“导入地图”
2,系统默认创建了3张地图分别为大(Large.map 16个路口)、中(Medium.map 8个路口)、小(Small.map 4个路口)。
3,选择相应的map文件以后系统会自动初始化车辆并且运行
设置 车辆的数目
设置车辆数目
设置相关属性在configure文件中设置,参考属性如下:
TIMER_TIME = 40;//定时器触发时间间隔,单位为毫秒,数值越大每个时间周期越长,车行走得越慢
INTERSECTION_CYCLE = 5000;//路口的时间周期,单位为毫秒
调度算法在CIntersection::manipulateIntersection()中设置
Smart City - Intelligent Traffic System (Beta) 发布
这是一个使用VC++编 写的城市交通疏导系统模拟平台,用户可以在这个平台的基础上开发自己的路口调度算法,非常适合交通相关专业学者发表论文,或做毕业设计时进行实验模拟。
该 资源为北京大学软件实现技术课程(微软精品课程)的研究项目,上传的是release运行版本,未附加代码。
如果您下载下来并运行程序,给出意见 或建议,即可免费获得源码。
同时请您保证该源码只用于学术研究,不用于任何商业用途。
您可以直接在资源评论中发表意见或建议并留下您的 email地址,也可以发送意见或建议到以下邮箱索要实现代码:
pku_smartcity@163.com