什么是研究? 问题是什么?
假设前提是什么?(理论基础)
解决问题的方法是什么?(论证过程) 结论是什么?(贡献及期待) 关于研究的简单实例 东方关于女人美的观点:(理论基础)
手如柔荑(tí) 、肤如凝脂、领如蝤蛴(qiúqí) 、齿如瓠(hù)犀、螓(qín)首蛾眉、巧笑倩兮、美目盼兮 出自《诗经.卫风.硕人》 手指细如嫩荑、皮肤白皙如凝脂、颈脖美丽如蝤蛴洁白圆润、牙如瓠籽白又齐、宽宽的额头、弯弯的眉毛 、浅笑盈盈酒窝俏、美目左顾右盼眼波俏 论证过程 手如柔荑(X)肤如凝脂(?)领如蝤蛴(X)齿如瓠犀(?)螓首(√)蛾眉(X)巧笑( √ )倩兮(X)美目盼兮(?) 西方关于美的观点:(理论基础) 黄金分割定理(Golden Section)
把一条线段分割为两部分,使其中一部分与全长之比等于另一部分与这部分之比。 (1/x)=(x/(1-x))
其比值是[5^(1/2)-1]/2或二分之根号五减一,取其前三位数字的近似值是0.618。由于按此比例设计的造型十分美丽,因此称为黄金分割。
这个数值的作用不仅仅体现在诸如绘画、雕塑、音乐、建筑等艺术领域,而且在管理、工程设计等方面也有着不可忽视的作用。 结论:
在东方文明看来,蒙娜丽莎不美 在西方文明看来,蒙娜丽莎美 展望:
东西方审美观的差异:进一步研究其他类型的审美观不一致问题,例如建筑,…. 再进一步联想到:不同社会文明的差异给人类社会发展带来的影响研究 问题是什么研究要针对问题。
问题来源于:社会实践需要、追踪科学前沿和热点 嵌入式系统研究的问题:
嵌入式系统的可靠性(稳定运行的时间) 嵌入式系统的性能(运行速度、功耗) 嵌入式系统的可演化性(结构) 嵌入式系统的正确性(行为)
嵌入式系统地正确性:系统建模与验证 如何找到研究问题
首先,从项目实践中获取候选问题列表: 实践中经常遇到的问题是什么? 实践中难以解决的问题是什么?
实践中最重要的要解决的问题是什么? 其次,通过交流确定候选题目:
与导师交流,如果研究领域导师熟悉,很快就可以确定
广泛阅读最新的文献,通过阅读文献,尤其是会议论文,能够确定目前这一领域的热点研究问题是什么
与同学交流,包括高年级同学、其他专业同学、其他学校同学 依据自己的兴趣爱好 如何确定研究内容
首先,从收集的文献中确定一篇合适的文献作为起点,仔细阅读,回答: 文章研究的问题是什么?其背景是什么?其意义是什么? 文章解决问题的理论依据是什么?
文章解决问题的方法是什么?包括论证过程、实验数据、实验工具 文章解决问题得到的有用结论是什么?应用价值和科学价值何在? 其次,针对详细阅读的论文,仔细思考以下问题: 文章中有哪些方面的内容值得进一步研究? 文章还有哪些问题没有涉及到? 文章的研究方法可以进一步改进吗? 文章的实验数据存在问题吗? 文章的实验工具可以改善吗?
文章的结论,尤其是展望值得进一步研究吗? 文章的研究在实际应用中还存在哪些问题? 文章的结论可靠吗?与实际相符吗? 再次,确认前面提到的各种问题: 查找相关文献
学习与论文有关的基本理论 动手验证论文的实验
进一步思考前面的问题,通过批判性思维反驳,记录反驳的依据 与同学进行交流讨论 与导师交流讨论
RAD模型的不足
技术风险很高的情况不适合采用;
(如新软件要求与已存在的程序有高可互操性时,或系统难以被适当地划分为若干功能等情况)
需要足够的人力以创建足够的RAD小组;
开发者和用户需要在很短的时间内完成系统开发。
渐增模型
前述生存期模型,均是一次性地将整个系统交给用户:
瀑布模型是假设当线性阶段完成之后就能交付一个完善的系统。原型模型主要用来帮助开发者获取用户需求,待需求稳定后再开发最终系统提供给用户。RAD模型则先将系统主要功能分给若干RAD小组开发,然后集成起来形成最终系统提交给用户。 业务和产品需求的变化,市场竞争和商业压力等等 以逐步增加软件产品的方式构造软件---渐增模型
渐增模型的特点
? 可以根据需要补充人员 ; ? 能够有计划地管理技术风险;
? 能够减少全新软件产品对用户带来的影响; ? 不需要大的资金支出;
? 用户能及早使用及早发现问题; ? 投资回报随功能渐增而渐增。 渐增模型的不足:
如果产品整体结构设计不当,则难以为其增加新的增量; (对设计水平要求较高)
由于采用增量开发,故难于进行彻底的测试。 螺旋模型
螺旋模型的特点:
既保持了传统生命周期模型中系统的阶段性方法,又将迭代演化的思想吸收到模型中; 螺旋模型是风险驱动的。
(风险分析使得用户和开发者能够更好地理解和对待每一个阶段的风险) 螺旋模型适合于大型软件的开发 螺旋模型的不足:
要求软件开发人员善长风险分析;
风险分析会导致项目终止而终止合同,出现违约诉讼; 对于小项目,风险分析的成本可能与整个项目的成本相当。 敏捷原则
? 最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
? 即使在开发后期,也欢迎需求改变。敏捷过程利用变化来为客户创造竞争优势。 ? 经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间
间隔越短越好。
? 在整个项目开发期间,业务人员和开发人员必须天天在一起工作。
? 围绕有积极性的个人构建项目团队。为他们提供所需的环境和支持,并信任他们能
够完成工作。
? 在团队内部,最有效果并富有效率的信息传递方法是面对面的交流。 ? 可运行的软件是首要的进度度量标准。
? 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、
稳定的开发速度。
? 持续关注优秀的技能和好的设计,增强敏捷能力。 ? 简单(是不必做的工作最大化的艺术)是必要的。 ? 最好的架构、需求和设计出自于自组织的团队。
? 每隔一段时间,团队应反省如何才能有效地工作,并相应地调整自身的行为。 极限编程(Extreme Programming,简称XP)是由Kent Beck、Ward Cunningham、Ron Jeffries等人通过整理优秀团队的共同之处而提出的敏捷过程。
所谓极限,Kent Beck认为是:尽力而为,然后处理其结果。
极限编程专注于编程技术、清晰沟通和团队协作,只需做能够为客户创造价值的事情,是一组确保项目开发成功的规则,适用于任何规模的团队,适合模糊或快速变化的需求。 站立式会议大多在9点钟开始,团队集中讨论当前的工作,对具体问题寻求解决建议。站立会议一般持续很短的时间,应该回答:自昨天开始已经做了什么?从现在开始你将做什么?阻碍迭代目标的有什么?有没有未完成的事情?在需求或技术等方面是否有与其他人员有关的决定等。站立式会议的目的是相互交流学习,了解项目的进度。
极限编程过程强调小规模、频繁地发布代码和测试。一方面,小型发布有利于尽早为客户提供业务价值,使客户增加信心。另一方面,客户可以通过使用小型发布的软件系统,能够获取更多的其他需求,发现系统存在的缺陷,通过反馈将更有力地指导项目成功,包括改善进度估算、完善故事、改变故事实现的优先级等。
在发布阶段,如果需要文档,则应该在当前版本趋于稳定时撰写文档,主要包括:
系统文档,为理解系统提供一个总览信息,如系统技术架构、高层次系统需求、关键设计决策总结、重要的设计模型等等;
系统操作文档,描述系统涉及的依赖关系、与其他系统交互的特性、预期系统负载等; 系统支持文档,描述解决问题时的参考信息、疑难问题的上报流程、维护团队的联系列表等; 用户文档,如参考手册、用户指南、支持指南及培训资料等。极限编程实践:
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读,免费范文网,提供经典小说综合文库任胜兵老师软件工程课件知识点整理在线全文阅读。
相关推荐: