《软件工程》作业及答案1-1 什么是软件危机?它有哪些典型表现?为什么会出现软件危机?答: 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。
软件危机典型表现：对软件开发成本和进度的估计常常很不准确。
用户对“已完成的”软件系统不满意的现象经常发生。
软件产品的质量往往靠不住。
软件常常是不可维护的。
软件通常没有适当的文档资料。
软件成本在计算机系统总成本中所占的比例逐年上升。
软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。
管理和控制软件开发过程相当困难。
软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
目前相当多的软件专业人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成软件危机的主要原因。
1-2 假设你是一家软件公司的总工程师，当你把图1.1给手下的软件工程师们观看，告诉他们及早发现并改正错误的重要性时，有人不同意你的观点，认为要求在错误进入软件之前就清除它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢?”你怎么反驳他?1-3 什么是软件工程?它有哪些本质特性?怎样用软件工程消除软件危机?答: 软件工程是指导计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。
软件工程本质特性：1、软件工程关注于大型程序的构造；2、软件工程的中心课题是控制复杂性；3、软件经常变化；4、开发软件的效率非常重要；5、和谐地合作是开发软件的关键；6、软件必须有效地支持它的用户；7、在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。
消除软件危机的途径：为了消除软件危机，首先应该对计算机软件有一个正确的认识。
必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。
应该开发和使用更好的软件工具。
为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。
1-6 什么是软件过程?它与软件工程方法学有何关系?答: 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件工程方法学包含软件过程。
1-7 什么是软件生命周期模型?试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优缺点，说明每种模型的适用范围。
答: 生命周期模型简洁地描述软件过程，规定了把生命周期划分成哪些阶段及各个阶段执行顺序。
瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法；这种模型的问题是，最终开发出的软件产品可能并不是用户真正需要的。
快速原型模型正是为了克服瀑布模型的缺点而提出来的。
它通过快速构建起一个可在计算机上运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。
增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点，但是，要求软件具有开放的结构是使用这种模型时固有的困难。
风险驱动的螺旋模型适用于内部开发的大型软件项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。
快速原型模型：适合小型软件； 螺旋模型：适合内部开发的大规模软件项目。
2-1 在软件开发的早期阶段为什么要进行可行性研究?应该从哪些方面研究目标系统的可行性?答: 可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
至少应该从下述三方面研究每种解法的可行性：（1）技术可行性；（2）经济可行性；（3）操作可行性。
2-5 北京某高校可用的电话号码有以下几类：校内电话号码由4位数字组成，第1位数字不是0；校外电话又分为本市电话和外地电话两类，拨校外电话需先拨0，若是本市电话则再接着拨8位数字(第1位不是0)，若是外地电话则拨3位区码再拨8位电话号码(第1位不是0)。
请用2.5.2小节讲述的定义数据的方法，定义上述的电话号码。
答: 电话号码＝［校内电话|本市电话|外地电话］ 非零数字字符=[1|2|3|4|5|6|7|8|9] 校内电话=非零数字字符+3{数字}3本市电话=0+非零数字字符+7{数字}7外地电话=0+区码+非零数字字符+7{数字}73-1 为什么要进行需求分析?通常对软件系统有哪些需求?答: 为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。
对软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发者带来烦恼。
确定对系统的综合要求：1、功能需求；2、性能需求；3、可靠性和可用性需求；4、出错处理需求；5、接口需求；6、约束；7、逆向需求；8、将来可以提出的要求，分析系统的数据要求。
3-2 怎样与用户有效地沟通以获取用户的真实需求?答: 与用户沟通获取需求的方法：访谈；面向数据流自顶向下求精；简易的应用规格说明技术；快速建立软件原型4-2 在什么情况下应该使用形式化说明技术?使用形式化说明技术时应遵守哪些准则?答: 在开发大型软件系统的过程中应该使用形式化说明技术。
应用形式化方法的准则：（1）应该选用适当的表示方法。
（2）应该形式化，但不要过分形式化。
（3）应该估算成本。
（4）应该有形式化方法顾问随时提供咨询。
（5）不应该放弃传统的开发方法。
（6）应该建立详尽的文档。
（7）不应该放弃质量标准。
（8）不应该盲目依赖形式化方法。
（9）应该测试、测试再测试。
（10）应该重用7-8 对一个包含10000条机器指令的程序进行一个月集成测试后，总共改正了15个错误，此时MTTF=10h;经过两个月测试后，总共改正了25个错误(第二个月改正了10个错误)，MTTF=15h 。
要求：(1) 根据上述数据确定MTTF 与测试时间之间的函数关系，画出MTTF 与测试时间τ的关系曲线。
在画这条曲线时做了什么假设?(2) 为做到MTTF=100h ，必须进行多长时间的集成测试?当集成测试结束时总共改正了多少个错误，还有多少个错误潜伏在程序中?答:(1)所做假设:1)单位长度里的错误数近似为常数;2)失效率正比于软件中剩余的错误数,而平均无故障时间与剩余的错误数成反比. 3)发现的每一个错误都立即正确地改正了.(2)由Shooman 公式：MTTF=I T /(K*(E T -E C (T))) 其中，I T =104,MTTF 1=10,n 1=15,MTTF 2=15,n 2=25。
得：MTTF 1=I T /(K*(E T -E C (T 1)))10=10000/(K*(E T -15))MTTF 2=I T /(K*(E T -E C (T 2)))15=10000/(K*(E T -25))(1)解得程序中固有的错误总数E T =45,此外K=100/3。
(2)设MTTF=100,有100=10000/(（100/3）*(45-x))解得x=42。
所以，当集成测试结束时，改正了42个错误，还剩3个错误。
7-9 如对一个长度为100000条指令的程序进行集成测试期间记录下下面的数据：(a) 7月1日：集成测试开始，没有发现错误。
(b) 8月2日：总共改正100个错误，此时MTTF=0.4h (c) 9月1日：总共改正300个错误，此时，MTTF=2h根据上列数据完成下列各题：(1) 估计程序中的错误总数；(2) 为使MTTF 达到10h ，必须测试和调试这个程序多长时间?(3) 画出MTTF 和测试时间τ之间的函数关系线。
答: 由Shooman 公式：MTTF=I T /(K*(E T -E C (T))) 其中，I T =105,MTTF 1=0.4,T 1=160,n 1=100,MTTF 2=2,T 2=320,n 2=300。
得：MTTF 1=I T /(K*(E T -E C (T 1)))0.4=100000/(K*(E T -100))MTTF 2=I T /(K*(E T -E C (T 2)))2=100000/(K*(E T -300)) (1)解得程序中固有的错误总数E T =350,此外K=1000。
(2)设MTTF=10,有10=100000/(1000*(350-x))解得x=340。
由可靠性积累曲线E C (t)=E T (1-exp （-K 1t ）)得：100=350*(1-exp （-160K 1）)300=350*(1-exp （-320K 1）)解得：K=0.01。
代入 340=350*(1-exp （-K 1t ）)= 350*(1-exp （-0.01t ），得：t=(ln(35))/0.01=356h 因此求得为使 MTTF=10，测试和调试该程序需要花费365h 。
8-1 软件的可维护性与哪些因素有关?在软件开发过程中应该采取哪些措施才能提高软件产品的可维护性?答: 1、决定软件可维护性的因素主要有下述5个：1、可理解性；2、可测试性；3、可修改性；4、可移植性；5、可重用性。
在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。
在正式的和非正式的设计复审期，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预作准备。
代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。
在设计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。
每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。
在测试结束时进行最正式的可维护性复审.在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。
维护应该针对整个软件配置，不应该只修改源程序代码。
