程序分析总结

1 / 33 程序分析总结 项目开发总结报告 1 引言 编写目的 说明编写这份项目开发总结报告的目的，指出预期的阅读范围。 背景 说明： a 本项目的名称和所开发出来的软件系统的名称； b 此软件的来源或任务提出者、开发者、用户及安装此软件的计算中心。 定义 2 / 33 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 参考资料 列出收集和用到的参考资料，如： a 程序代码及文档的来源及出处； b 为完成本项目所收集和自学的资料； c 本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 实际开发结果 产品 说明 最终制成的产品，包括： a 程序系统中各个程序的名字，它们之间的层次关系，以3 / 33 千字节为单位的各个程序的程序量、存储媒体的形式和数量； b 程序系统共有哪几个版本，各自的版本号及它们之间的区别； c 每个文件的名称； d 所建立的每个数据库。 如果开发中制订过配置管理计划，要同这个计划相比较。 主要功能和性能 逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。 基本流程 用图给出本程序系统实际的基本处理 流程。 研制过程与进度 4 / 33 详细描述开发程序的完整过程，包括开发的各个阶段、制品、活动，并画出开发流程图；列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。 费用 列出原定计划费用与实际支出费用的对比，包括： a. 工时，以人月为单位，并按不同级别统计； b. 计算机的使用时间，区别 CPU时间及其他设备时 间； c. 物料消耗、出差费等其他支出。 明确说明，经费是超出了、还是节余了，分析其主要原因。 3 开发工作评价 对生产效率的评价 5 / 33 给出实际生产效率，包括： a 程序的平均生产效率，即每人月生产的行数； b 文件的平均生产效 率，即每人月生产的千字数； 并列出原订计划数作为对比。 对产品质量的评价 说明在测试中检查出来的程序编制中的错误发生率，即每干条指令中的错误指令数。如果开发中制订过质量保 证计划或配置管理计划，要同这些计划相比较。 对技术方法的评价 给出对在开发中所使用的技术、方法、工具、手段的评价。 对主动学习的评价 对团队合作的评价 6 / 33 碰到的问题及其解决方法 给出对于开发中出现的主要问题、原因分析及其解决方法 。 4 收获与体会 列出从这项开发工作中所得到的最主要的收获和体会 5 经验与教训 列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的建议。 分析一个奇怪的程序 assume cs:codesg codesg segment mov ax,4c00h int 21h mov ax,0 start: 7 / 33 s: nop nop mov di,offset s mov si,offset s2 mov ax,cs:si mov cs:di,ax s0: jmp short s s1: mov ax,0 int 21h mov ax,0 s2: jmp short s1 nop codesg ends end start 从 start 开始，一步步往下，到 mov cs:di,ax 结束， cs：di指向 cs:si, 即 cs:s处等于 cs:s2处的内存单元，之后 jmp short s这步先不管，到 jmp short s1 这句时，程序跳到 s1处，即执行 EBF6(F6即 -a)这个指令 (由 jmp指令后的第一个字节的地址减去标号处的地址得出 )，就是说 s1处的指令为 EBF6，即 s 处的指令也为 EBF6，即跳到开头 处，程序返回。 程序开发 :目前主流开发技术的分析和总结 8 / 33 主流的程序设计语言： C+、 Delphi(ObjectPascal)、 Java、C# 桌面应用程序框架： MFC、 VCL、 QT、 JavaAWTSWING、 .Net 企业应用程序框架： WindowsDNA、 J2EE、 .NetFramework 开发工具： VisualBasic、 Delphi、 VisualC+、 C+Builder、VisualC# *程序设计语言：C+DelphiJavaC#(虽然他刚刚推出，但因为微软为之倾注了大量心血，一定会成为一种重要的开发语言 ) *桌面应用程序框架 :MFCVCL *企业应用程序框架 :WindowsDNAJ2EE.Net *COM技术：我单独提出这项技术，是因为它无法简单的被视为语言、桌面应用程序框架或企业应用程序框架，它与这些9 / 33 都有关系。 程序设计语言 C+语言的演进 最初要从二进制代码和汇编说起，但那太遥远了。我们就从面向过程的语言说起吧。这种面向过程的高级语言终于把计算机带入了寻 常的应用领域。其中的 C 语言因为它的简单和灵活造就了Unix和 Windows 这样的伟大的软件。 面向对象的语言是计算机语言的一个合乎逻辑的进化，因为在没有过多的影响效率、简单性的前提下提供了一种更好的组织数据的方法，可使程序更容易理解，更容易管理 这一点可能会引出不同意见，但事实胜于雄辩， C+终于让 C语言的领地越来越小，当今还活着的计算机语言或多或少的都具备面向对象的特征，所以这一点并不会引起太多困惑。C+的成功很大程度要归因于 C， C+成为它今天的样子是合乎逻辑的产物。因为在面向过程的时代， C 几乎已经统一天下了。今天著名的语言象 JavaC#都从 C 借鉴了很多东西，10 / 33 C#本来的意思就 是 C+。其实 C+曾经很有理由统一面向对象程序设计语言的天下来着，但可惜的是， C+太复杂了。即使是一个熟练的程序员，要你很清楚的解释一些问题你也会很头痛。举几个还不是那么复杂的例子来说： 对 =的重载 成员转换函数 拷贝构造函数 转化构造函数之间有什么区别和联系呢？ 定义一个类成员函数 private:virtualvoidMemFun()=0;是什么意义呢？ int(*(*x(int)4)(double);是什么意思？ 还有其他的特征，比如说可以用来制造一种新语言的typedef 和宏，让你一不小心就摔跤的内存问题 诸如此类， C+是如此的复杂以至于要学会它就需要很长的时间，而且你会发现即使你用 C+已经好几年了，你还会发现经常有新东西可学。你想解决一个应用领域的问题 比如说从数据库里面查询数据、更改数据那样的问题，可是你却需要首先为 C+头痛一阵子 才可以，是的，你精通 C+，你可以很容易的回答我的问题，可是你有没有想过你付出了多大的代价呢？我不是想过分的谴责 C+，我本人喜欢 C+，我甚11 / 33 至建议一个认真的开发普通的应用系统的程序员也去学习一下 C+， C+中的一些特性，比如说指针运算 模板 STL 几乎让人爱不释手，宏可以用几个字符代替很多代码，对系统级的程序员来说， C+的地位是不可替代的， Java 的虚拟机就是 C+写的。 C+还将继续存在而且有旺盛的生命力。 Java和 C# Java和 C#相对于 C+的不同最大的有两点： 第一点是他们运行在一个虚拟环境之中，第二点是语法简单。对于开发人员而言，在语法和语言机制的角度可以把 Java 和 C#视为同一种语言。 C#更多的是个政治的产物而不是技术产物。如果不是 Sun 为难微软的话，我想微软不会费尽心力推出一个和Java差不多的 C+，记得 Visual J+吗，记得 WFC 吗？看看那些东西就会知道微软为 Java 曾经倾注了多少心血。而且从更广泛的角度来说，两者也是非常相似的 C#和 Java面对的是同样的问题，面向应用领域的问题：事务处理、远程访问、 Webservice、 Web 页面发布、图 形界面。那么在这一段中，我暂且用 Java 这个名字指代 Java 和 C#两种语言 尽管两者在细节上确实有区别。 Java是适合解决应用领域的问题的语言。最大的原因 Java 对于使用者来说非常简单。想想你学会并且能够使用 Java 需要多长时间，学会并12 / 33 且能够使用 C+要多长时间。由于 Java很大程度上屏蔽了内存管理问题，而且没有那么多为了微小的性能提升定义的特殊的内容，他让你尽量一致的方式操作所有的东西，除了基本数据类型，所有的东西都是对象，你必须通过引用来操 作他们；除了这些之外， Java还提供了丰富的类库帮助你解决应用问题 因为它是面向应用的语言，它为你提供了多线程标准、 JDBC 标准、 GUI 标准，而这些标准在 C+中是不存在的，因为 C+并不是直接面向解决应用问题的用户，有人试图在 C+中加入这些内容，但并不成功，因为 C+本身太复杂了，用这种复杂的语言来实现这种复杂的应用程序框架本身就是一件艰难的事情，稍后我们会提到这种尝试 COM 技术。渐渐的，人们不会再用 C+开发应用领域的软件，象 MFCQTCOM这一类的东西最终也将退出历史舞台。 Delphi Delphi 是从用 C+开发应用系统转向用 Java 开发应用系统的一个中间产物。它比 C+简单，简单的几乎象 Java一样，因为它的简单，定义和使用丰富的类库成为可能，而且Delphi 也这么做了，结果就是 VCL 和其他的组件库。而另一方面，它又比运行于虚拟环境的 Java 效率要高一些，这样13 / 33 在简单性和效率的平衡之中， Delphi 找到了自己 的生存空间。而且预计在未来的一段时间之内，这个生存空间将仍然是存在的。可以明显的看出，微软放弃了这个领域，他专注于两方面：系统语言 C+和未来的 Java(其实是 .Net)。也许这对于 Borland 来说，是一件很幸运的事情。如果我能够给 Borland 提一些建议的话，那就是不要把 Delphi 弄得越来越复杂，如果那样，就是把自己的用户赶到了 C+或 Java的领地。在虚拟机没有最终占 领所有的应用程序开发领域之前， Delphi 和 Delphi 的用户仍然会生存得很好。 桌面应用程序框架 目前真正成功的桌面应用程序框架只有两个，一个是 MFC，一个是 VCL，还有一些其他的，但事实上并未进入应用领域。遗憾的是我对两个桌面应用程序框架都不精通。但这不妨碍我对他做出正确的评价。 MFC 是 SDK 编程的正常演化的结果，就象是 C+是 C 的演化14 / 33 结果一样。 MFC 本身是一件了不起但不那么成功的作品，而且它过时了。这就是我的结论。 MFC 凝聚了很多天才的智慧 当然， OWL 和 VCL 也一样，侯捷的深入浅出 MFC把这些智慧摆在了我们的面前。但是这件东西用起来估计不会有人觉得很舒服，如果你一直在用 Java、 VB 或者 Delphi，再回过头来用 MFC，不舒服的感觉会更加强烈。我 不能够解释 MFC为什么没有能够最终发展成和 VCL一样简单好用的桌面程序框架，也许是微软没精力或者没动力，总之 MFC就是那个样子了，而且也不会再有发展，它已经被抛弃了。我有时候想，也许基于 C+这种复杂的语言开发 MFC 这样的东西本身就是错误的 可以开发这样的一个框架，但不应当要求使用它的人熟悉了整个框架之后才能够使用这个系统，但很显然，如果你不了解 MFC的内部机制，是不太可能把它用好的，我不能解释清楚为什么会出现这种现象。 相比之下 VCL要成功的得多。我相信很多使用 VCL 的人可能没有像 MFC的用户研究 MFC那样费劲的研究过 VCL的内部机制。但这不妨碍他们开发出好用好看的应用程 序，这就足够了，还有什么好说的呢？ VCL 给你提供了一种简单一致的机制，让你可以写出复杂的应用程序。在李维的15 / 33 Borland故事那篇文章中曾经说过，在 Borland C+ 推出之后 Borland就有人提出开发类似 C+ Builder 一类的软件，后来竟未成行。是啊，如果 C+ Builder 是在那 个时候出现的，今天的软件开发领域将会是怎么样的世界呢？真的不能想象。也许再过一段时间，这些都将不再重要。因为新生的语言如 Java和 C#都提供了类似于 VCL的桌面应用程序框架。那个时候，加上 Java 和 C#本身的简单性，如果他们的速度有足够块，连 Delphi 这种语言也要消失了，还有什么好争论的呢？只是对于今天的桌面程序开发人员来说， VCL 确实是最好的选择。 企业应用程序框架 Windows DNA Windows DNA 的起源无从探究了。随着 .Net的推出，事实上Windows DNA 将成为历史的陈迹。 Windows DNA 虽然是几乎所有的企业应用程序开发人员都知道的一个名词，但我相信Windows DNA 事实上应用的最广泛的是 ASP而不是 COM+。真正的 COM 开发有多少人真正的掌握了呢，更不要提 COM+(我有必要解释一下： COM+是 COM的执行环境，它提供了一系列如事务处理、安全等基础服务，让应用程序开发人员尽量少16 / 33 在基础架构设计上花精力 ) 当然我这里指的 COM 开发不是指 VB 下的 COM 开发，所以要这么说，是因为我觉得如果不能理解用 C+进行 COM 开发，也就不能真正的理解 COM 技术。如果以一种技术没有被广泛理解和应用作为失败的标志，那么 Windows DNA 实际上是失败了，但这不是它本身的错，而是基于 C+的 COM 技术的失败造成的。多层应用、系统开发角色分离的概念依然没有过时。 J2EE J2EE是第一套成功的企业应用程序开发框架。因为它把事务处理、远程访问、安全这些概念带入了寻常百姓家。这种成功我认为要归因于 Java的简单性。 Java 的简单，对于 J2EE容器供应商来说一样重要。开发一个基于 Java 的应用服务器要比基于 C+的更容易。而且由于 Java的简单性，应用系统开发者出错的机会也会少一些，不会像 C+的开发者那样受到那么多挫折。开发基于 Java 的企 业应用系统的周期会更短，这恐怕是不容争辩的事实。不论如何，是 J2EE 让事务处理、远程访问、安全这些原来几乎都是用在金融系统中的概念也被一般的企业用户使用并从中获得利益。 专题五 实质性程序总结 17 / 33 情形及认定 应对的实质性程序 选择大额交易，检查相应的支持性文件、销售发票等），确认收入的真实存在。 获取管理当局的书面声明 实施如下分析程序： 将本期的主营业务收入与上期的主营业务收入、销售预算或预测数等进行比较，分析主营业务收入及其构成的变 1.营业收入 /发生 【提示】：招投标、业绩评价等原 因 【提示】：发货一段时间后再确认 收入，与 “ 截止 ” 认定相关 动是否异常，并分析异常变动18 / 33 的原因； 比较本期各月各类主营业务收入的波动情况，分析其变动趋势是否正常，是否符合被审计单位 季节性、周期性的经营规律，查明异常现象和重大波动的原因； 将本期重要产品的毛利率与同行业企业进行对比分析， 检查是否存在异常； 根据增值税发票申报表或普通发票，估算全年收入，与实际收入金额比较。 根据原材料的采购数量、单位产品的耗费等确认其生产量和销售量的合理性，并查明异常情况的原因 结合应收账款的审计，选择主要客户函证本期销售额 【提示】：至少 3条路线 以账簿记录为起点，追查至销售发票和发运凭证。 以发运凭证为起点，追查至销售发票和账簿记录 以销售发票为起点，追查至发运凭证和账簿记录 19 / 33 关注期末已记录 销售但尚未发运的货物，并审查。 2.营业收入 /截止 对大额款项期后退货进行审查 抽取资产负债表日后若干大额交易，审查入账日期、品名、规格、单价、数量等与支持性文件是否相符。 通过测试资产负债表日后若干天的客户确认收货的单据，将其与收入明细账进行核对；同时从收入明细账选取在资产负债表日前若干天凭证，检查客户是否提前确认收入。 复核资产负债表日前后销售和发货水平，确定业务活动水平是否异常，并考虑是否有必要追加实施截止测试 1 程序 取得资产负债表日后所有的销售退回记录，检查是否存在提前确认收入的情况； 20 / 33 (10)结合 对资产负债表日应收账款的函证程序，检查有无未取得对方认可的大额销售； 调整重大跨期销售。 (12).检查有无特殊的销售行 使用分解的数据进行分析程序。如按产品种类、月份、 生产线等，与以前同期进行比较。 向被审计单位的客户函证相关的条款和背后协议。如商品接受条件、付款标准等 询问内部法律顾问或营销人员，了解是否在期末有异常的交易条款。 期末 或临近期末实地观察被审计单位的发货情况，并实施相应的截止测试 对于自动化系统生成、记录的信息，通过测试自动化系统的控制确定其准确性。 21 / 33 关注被审计单位次年初的退货情况。 1.将本期销售收入金额与以前可比期间的对应数据或预算数进行比较； 2.分析月度或季度销售量变动趋势； 3.将销售收入变动幅度与销售商品及提供劳务收到的现金、应收账款、存货、税金等项目的变动幅度进行比较； 4.将销售毛利率、应收账款周转率、存货周转率等关键财务指标与可比期间数据、预算数或同行业其他企业数据进行比较； 5.分析销售收入等财务信息与投入产出率、劳动生产率、产能、水电能耗、运输数量等非财务信息之间的关系； 6.分析销售收入与销售费用之间的关系， 包括销售人员的人均业绩指标、销售人员薪酬、差旅费用、运费，以及销售机构的设臵、规模、数量、分布等。 对异常或偏离预期趋势或关系的舞弊风险的调查方法 22 / 33 1.如果注册会计师发现被审计单位的毛利率变动较大或与所在行业的平均毛利率差异较大，注册会计师可以采用定性分析与定量分析相结合的方法，从行 业及市场变化趋势、产品销售价格和产品成本要素等方面对毛利率变动的合理性进行调查。 2.如果注册会计师发现应收账款余额较大，或其增长幅度高于销售收入的增长幅度，注册会计师需要分析具体原因 (如赊销政策和信用期限是否发生变化等 )，并在必要时采取恰当的措施，如扩大函证比例、增加截止测试和期 2 3.期末收入增加过快，尤其 12月份营业收入 /发生 后收款测试的比例等。 3.如果注册会计师发现被审计单位的收入增长幅度明显高于管理层的预期，可以询问管理层的适当人员，并考虑管理层的答复是否与其他审计证据一致，例如，如果管理层表示收入增长是由于销售量增加所致，注册会计师可以调查与市场需求相关的情况。 23 / 33 实施如下分析程序 复核应收账款借方累计发生额与主营 业务收入是否合理，并将当期应收账款借方发生额占销售收入净额的百分比与管理层考核指标比较和被审计相关赊销政策比较，如存在异常应查明原因； 计算应收账款周转率、应收账款周转天数等指标，并与 被审计单位以前年度指标、同 4.应收账款 /存在 对应收账款贷方发生额进行分析，关注是资金流入、坏账冲销、还是债务重组等，尤其关注关联方交易。 对未函证的应收账款实施替代程序，如检查其销售合同、销售发票、发运凭证等 检查有无不属于结算债权的情况，如有，建议被审计单位进行 调整。 进行截止性测试 24 / 33 测试关于坏账准备的会计估计； 通过分析程序，比较前期坏账准备的计提情况，计算本期计提坏账准备是否充分 检查应收账款的账龄分析是否正确 1.取得或编制坏账准备明细表，复核加计是否正确，与坏账准备总账数、明细账合计数核对是否相符； 2.将应收账款坏账准备本期计提数与资产减值损失相应明细项目的发生额核对是否相符； 3.检查应收账款坏账准备计提和核销的批准程序，取得书面报告等证明文件，评价计提坏账准备所依据的资料、假设及方法。 4.实际发生坏账损失的，检查转销依据是否符合有关规定，会计处理是否正确。 5.已经确认并转销的坏账重新收回的，检查其会计处理是否正确。 25 / 33 6.检查函证结果。 7.实施分析程序。通过比较前期坏账准备计提数和实际发生数，以及检查期后事项，评价应收账款坏账准备计提的合理性。 8.确定应收账款坏账准备的披露是否恰当。 3 5.应收账款 /计价与分摊 4 【提示】：产品更新换代，产品因检查减值准备计提是 否充分，关注其会计处理是否落后而被淘汰的风险或产品降低价正确。 格幅度过大 【提示】： 检查存货跌价准备计提的依据和方法前后各期是否一致 26 / 33 存货增幅较大，超过收入的增幅，抽 查计提了存货跌价准备的存货项目，其期后售价 是否低于原始成本 可能造成存货的积压。 进行原材料、产成品的计价测试，包括检查前后各期是否一致、计价方法是否正确、收发计价方法是否准备等。 检查被审计单位存货的记录，确认应重点关注的存货的存放地点或存放项目 在预先不通知的情况下对特定地点的存货进行监盘或不同地点的同一种存货进行同时盘点。 存货监盘过程中实施额外的程序，如更严格的拆箱检查，利用专家工作进行品质检查等。 将存货盘点记录与永续记录进行比较 要求被审计单位在报告期末或临近期末实施盘点，以降低被审计单位在盘点日至报告期间操纵存货数量的风险。 12.存货 /存在 【提示】：存货数量期末比期初数量增加较多 27 / 33 13.货币资金 /存在 能受招投标的影响） 取得并检查银行对账单和银行存款余额调节表。 【提示】：货币资金增长较快函证银行存款余额，并检查记录回函。 结合应收账款、存货、固定资产、无形资产等进行审查； 【特别提示】：应收账款如果提示回款速度慢、回款率低，千万注意与 “ 计价与分摊 ” 有关，因为需要计提坏账准备。 14.资产减值损失 /准确性 /完整性 同时与 “ 资产减值准备 ” 的 “ 完整性 ” 有关 复核、测试管理层计提减值准备的过程，包括评价计提减值准备依据的数据及假设；测试计提减值准 备的过程； 考虑对减值准备的批准程序。 了解被审计单位与识别有关的内部控制； 28 / 33 审阅截至审计工作完成日止被审计单位历次董事会纪要和股东大会会议记录，确定是否存在未决诉讼或仲 裁、未决索赔、税务纠纷、债务担保、产品质量保证、财 15.预计负债 /完整性 务承诺等方面的记录； 向被审计单位的法律顾问和律师进行函证，以获取法律顾问和律师对被审计单位资产负债表日业已存在的，以及资产负债表日至复函日期间存在的或有事项的确认证据，检查其是否满足预计负债确认的条件； 5 文件名称 : 手机软件 软件测试报告 文件编