有时候,当我孤独地坐着等待生命大门关闭时,一种与世隔绝的感觉就会像冷雾一样笼罩着我。远处有光明、音乐和友谊,但我进不去,命运之神无情地挡住了大门。我真想义正词严地提出抗议,因为我的心仍然充满了热情。但是那些酸楚而无益的话语流溢在唇边,欲言又止,犹如泪水往肚里流,沉默浸透了我的灵魂。然后,希望之神微笑着走来对我轻轻耳语说:“忘我就是快乐。”因而我要把别人眼睛所看见的光明当作我的太阳,别人耳朵所听见的音乐当作我的乐曲,别人嘴角的微笑当作我的快乐。

发布新日志

  • CMMI 配置库知识

    2014-12-22 08:43:32

    原文转载http://www.cnblogs.com/laichenshui/archive/2010/11/19/1881670.html

    配置库的相关知识

    通过建立物理配置库的设立规范、各配置库目录的设立原则,确保配置库的统一与规范,确保项目产品得到有效的管理与运用,提高资源的共享与利用;通过变更管理活动,保证产品的完整、正确、一致,防止配置项被随意地修改而导致混乱;规范组织财富库的建立、更新与维护,确定组织财富库得到合理的使用与管理。

     

    角色

    职责

    项目经理

       提出基线变更请求

       审批非基线变更请求

       审核非基线变更发布申请

    项目其他成员

    在权限之内操作配置库

    CM工程师

      创建物理配置库

      建立配置库目录并分配权限

      维护配置库

      对变更的配置项进行出、入库管理,并且在基线变更发布后改变基线

      执行配置审计

      通告配置项状态

    CCB

       审批基线变更请求

      审核基线变更实施结果

    变更实施人

      填写软件变更单提取配置项

      实施对基线、非基线变更涉及配置项的具体修改

    测试工程师/评审人员

    对变更进行测试或评审

    EPG

    建立、管理和维护组织财富库

     

    1. 主要步骤

    1.1.           创建物理配置库

    5.1.1 创建物理配置库

    CM工程师需要创建开发库、受控库、产品库三个物理配置库:

    2 开发库:用于存放项目期间处于开发状态的相关文档和代码。以及存放项目组工作期间的相关沟通记录等。

    2 受控库:用于存放经过验证后的产品(包括基线产品);建立测试区,用于存放开发工作结束后需要进入测试的配置项,以及为变更实施提供工作空间。

    2 产品库:存放发布后的产品。

    各配置库之间的关系如下图所示意:

     

    图5-1-1 开发库、受控库、产品库关系图

    1.2.建立配置库目录结构

    5.2.1 建立配置库目录结构

    l  开发库目录结构:

    项目组创建开发库的目录结构,要求依据以下表格来创建,使用统一的结构与名称,二级目录允许依据不同项目的特征有所裁剪。

    目录结构

     

    一级目录

    二级目录

    存放工作产品示例

    010.项目立项

     

    《立项申请表》       

    《项目建议书》        

    《项目可行性分析报告》

    《项目实施申请表》   

    《项目立项公告》     

    《可行性分析报告附表》

    《立项评审检查单》

    020.项目策划

    010.项目策划

    《项目总体计划》

    《WBS》   

    《项目估计记录》   

    《计划变更申请表》 

    《项目计划审批表》 

    《特批申请表》     

    《项目实施计划》     

    020.配置计划

    《配置管理计划》

    030.测试计划

    《总体测试计划》

    040.质保计划

    《质量保证计划》

    030.需求开发

     

    《需求规格说明书》

    《产品功能列表》

    《需求跟踪矩阵》

    040.系统设计

    010.概要设计

    《概要设计说明书》

    020.详细设计

    《详细设计说明书》 

    《数据库设计说明书》

    050.编码

    010.源代码

    程序代码

    020.安装包脚本

    程序安装包脚本

    030.安装包

    程序安装包

    060.测试

     

    《测试问题报告》     

    《集成&确认测试计划》

    《集成&确认测试报告》

    070.用户文档

     

    《产品发布说明》

    《用户操作手册》

    《用户安装手册》

    《升级说明》   

    《升级包说明》 

    080.产品验收

     

    《产品移交申请表》 

    《产品移交文档清单》

    090.项目结项

     

    《项目总结报告》    

    《项目结项评估报告》

    100.项目管理

    010.项目报告

    《项目阶段报告》 

    《项目**数据表》

    020.配置报告

    《变更申请单》

    《发布申请表》

    《配置状态报告》

    《配置审计表》

    《阶段活动报告》

    030.会议记要

    《会议纪要》

    110.质保管理

     

    《QA工作报告》         

    《QA检查单》           

    《问题跟踪表》         

    《QA评审检查内容汇总表》

    120.规范性文档

     

    项目内部规范性文档

    130.系统约定

     

    项目内部系统约定文档

    140.参考资料

    010.参考资料1

    项目内部普通级别的参考资料

     

    020.参考资料2

    项目内部机密级别的参考资料

     

    l  受控库目录结构:

    项目组创建受控库的目录结构,要求依据以下表格来创建,使用统一的结构与名称,二级目录允许依据不同项目的特征有所裁剪。

    目录结构 

     

    一级目录 

    二级目录 

    三级目录 

    存放工作产品示例 

    000.基线管理

    010.计划基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

     

    020.需求基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

     

    030.设计基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

     

    040.编码基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

     

    050.测试基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

     

    060.产品基线

    V1.0.0.0

    已发布的基线工作产品

     

     

    ……

    已发布的基线工作产品

    010.项目立项

     

     

     

    020.项目计划

    010.项目计划

     

     

     

    020.配置计划

     

     

     

    030.测试计划

     

     

     

    040.质保计划

     

     

     

    050.测量分析计划

     

     

    030.需求开发

     

     

     

    040.系统设计

    010.结构设计

     

     

     

    020.详细设计

     

     

    050.编码

    010.源代码

     

     

     

    020.安装包脚本

     

     

     

    030.安装包

     

     

    060.测试

    010.测试计划/报告

     

     

     

    020.确认测试区

    010.源代码

     

     

     

    020.安装包脚本

     

     

     

    030.安装包

     

     

    030.变更区

    V1.0.0.0

     

     

     

    ……

     

     

    040.调试测试区

    V1.0.0.0

     

     

     

    ……

     

    070.用户文档

     

     

     

    080.产品验收

     

     

     

     

    【注】

    1、基线管理的二级目录下的六个基线目录,要根据项目实际定义的基线进行裁剪。

    2、基线管理的三级目录创建规则是:把确定的基线标识作为目录,以区分不同的基线。

    3、被纳入基线管理的工作产品只需要存放在基线管理目录中即可,不需要在基线管理目录外重复存放。

    4、测试的二级目录下变更区的三级目录创建规则是:把发生变更的所在基线标识作为目录,以区分开不同基线基础上发生的变更。

    5、测试的二级目录下调试测试区的三级目录创建规则是:把进行调测的所在基线标识作为目录,以区分开不同基线基础上进行的调测。

     

    l  产品库目录结构:

    公司统一建立唯一产品库。项目组负责创建本项目的产品目录结构,要求依据以下表格来创建,使用统一的结构与名称,三级目录允许依据不同项目的特征有所裁剪。

    目录结构

     

    一级目录

    二级目录

    三级目录

    备注存放工作产品示例

    010.项目标识

    010.基线版本系列

    000.基线版本 

     

     

     

    010.ServicePack系列   

     

     

     

    020.HotFix系列

     

     

     

    030.Beta系列 

     

     

     

    040.TEST系列 

     

     

     

    050.产品文档 

     

    注释:

    1、《××产品发布备忘录》放在二级目录下,每个基线版本都创建一个对应的产品《××产品发布备忘录》

    2、四级目录创建规则:

    1)Service Pack系列、Hot Fix系列的升级包目录名前,加上以“001.”为起始、步长为1递增的三位数统一流水号;不同基线版本系列下的流水号都以“001.”为起始。这样可以降低逆序升级的风险。

    2)Beta系列、TEST系列不需要在目录名前增加流水号。

    产品库目录示例:

    目录结构

     

    一级目录

    二级目录

    三级目录

    四级目录

    010.E-SIM 5.0

    010.E-SIM 5.1.0.0

    000.E-SIM 5.1.0.0

     

     

     

    010.ServicePack系列   

    002.E-SIM 5.1.0.0 SP001

     

     

     

    005.E-SIM 5.1.0.0 SP002

     

     

     

    查看(722) 评论(0) 收藏 分享 管理

  • 软件的性能测试如何做

    2012-10-16 17:30:18

    软件测试每周一问有的软件没做性能测试,客户反馈了很多性能问题;有的软件没做性能测试,客户从没抱怨性能有问题;有的软件做了性能测试,客户依然反馈了很多性能问题;有的软件做了性能测试,客户从没抱怨性能有问题。到底要不要做性能测试,这是一个大问题。如何判断你的软件是否需要做性能测试?欢迎大家讨论交流!

    会员godn_1981的精彩回答:

            这确实是个问题。
            其实我倒觉得问题不是要不要做的问题,而是怎么做,做多少的问题!
            请注意,没有任何一个软件不需要做性能测试,而是说需要程度到底有多高,这个需求程度决定了花多少精力去做,并且怎么做的问题。
            就算一个只有1000行代码的小程序,你怎么能保证它不需性能测试?你怎么知道它里面就没有内存溢出?你怎么知道它有没有耗费了不必要的资源?
            所以问题不是做不做的问题,而是花多少代价,怎么做的问题。

            一般性能测试有几个层次,或者说两个需求。
            a.为了找出性能问题
            b.为了给出性能指标
            c.为了给出需要的配置
            而我们国内现在常做的软件无非有几种:1.单机版应用程序 2.C/S或者B/S的项目(一般是外包项目或者政府软件,银行,医疗证券类软件)
            对于单机版应用程序来说,一般作性能测试是比较简单的,一般需求是两个,
            第一,你要测试一下有没有内存泻漏,或者深情况下内存溢出,或者有没有申请一些没必要的资源。这个一般要用一些分析工具
            第二,一般一个单机版应用程序,你总要给出,最低配置或者建议配置什么的,那么你给客户这个东西 就需要性能测试,测试一下在各种配置下面的运行情况,给出理想的建议值
            对于C/S或者B/S结构的软件就比较复杂了,一般是必须要做性能测试的。这个性能测试一般从以下方面考虑:
    第一,优化
            这个还是去考虑性能有没有问题,这个是起码的要求。特别是B/S系统,有没有多余请求,资源有没有释放之类的问题,要先考虑的。这类的问题,一般用网络分析工具就可以搞定。
    第二,时间
            这个是一般性能测试的重点。一般是用性能测试工具LR或WAS之类的做,这个叫负载测试。一般你测试一个软件,总要给老大一个结论,500人并发时,响应时间大概是几秒,300人并发时,是几秒。这个是每个客户都会要的。
    第三,配置
            这个也是性能测试的重点。这个一般叫压力测试。譬如一般客户会向你要一个数据:我想500人同时并发,响应时间在3秒之内,那么我的服务器要求最低配置是多少?这个嘛,你就只管压吧!压垮了,升级服务器,再压,又垮了,继续升级,到客户要求的性能指标达到为止,呵呵~~~~~~~~~~~~
            总结一下,不是要不要做的问题,而是怎么做,按照客户要求哪些需求,哪些指标做的问题!

  • 软件测试主管任职考评标准

    2012-08-23 15:59:20

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签: 软件测试 测试职业发展 测试管理

      在建立各领域的任职资格体系时,此为较早的一篇想法,一是和大家分享,二是给有志于从事管理的测试人员展示一下,除了技术之外,还应该关注那些方面。

      一、考核维度

      拟晋升为测试主管的测试工程师,需从三个方向进行综合考核评判:能力、业绩、态度,三者缺一不可。

      其中:

      能力细化为管理能力(项目管理、人员管理、技术管理)和素质能力(技术能力、沟通能力、表达能力);

      业绩细化为绩效和各种工作交付件的数量、质量:案例、培训、经验分享、出差、评审;

      态度细化为主动性、务实性和责任心;

      360°考核细化为:上级、同事、下级、内部客户、外部客户。

      二、要求标准

      2.1 能力

      2.1.1 项目管理

      1、有实际负责过项目的经历,对本领域项目模型和运作模式较为理解并较为清晰的描述。熟悉本领域项目的优缺点,并有针对性的给出相关的测试建议和意见。

      2、测试项目的交付成果可靠,测试遗漏率较低:通过访谈、封闭版本修改流确认。

      3、明晰周例会的目的和作用,能召开合格的周例会。

      4、明确工作分解分配的方法,能根据SMART原则,制定周计划。周计划的主动偏差率受控。

      5、对所负责的项目进度、风险、缺陷、瓶颈点掌握全面,对项目保持动态评估。

      6、对发布项目的技术支持和补丁版本发布,有较好的节奏,做好维护、备份、问题追溯、文档更新工作。

      2.1.2 人员管理

      1、了解自己属下的性格和技能情况,能指出每个下属的性格特点、技能优缺点,并且给于自己的使用建议和使用方法。

      2、关心人员的成长和工作状态,在周例会中或其他正式场合沟通。

      3、为下属量身制定提升计划,并取得实际的成果。

      4、对不同性格的人、对新老员工有一定的区分对待的管理方法。

      5、绩效面谈言之有物,对属下有指导和提升作用。

      2.1.3 技术管理

      1、熟悉公司研发的主流程,熟悉测试领域的交付件;熟悉测试流程,明确产品测试的各交付件和检查点。

      2、对本领域的内部调试命令做到汇总,和定期更新,组织团队成员进行学习和考核。

      3、对本领域的测试方法和测试用例,做周期性刷新计划,保持测试基础工作的建设和推进。

      4、对本领域的测试工具进行摸索和运用,提高团队的自动化测试水平,提高团队工作效率。

    2.1.4 技术能力

      1、能执行本领域核心功能的测试设计工作,能对本领域的产品实现提出意见和建议,对业务实现逻辑较为清晰,可做到新人培训和测试指导。

      2、掌握基础的QTP、loadrunner的使用方法,能完成部分功能自动化设计和执行工作,可做到新人培训和测试指导。

      3、根据行业特点,对行业的特殊测试技术有所掌握,并能进行应用推广。

      2.1.5 沟通能力

      1、对别人的描述,能够总结出完整的思路,并提炼出重点。能够清晰的表达自己的意思和意图。

      2、对外的技术支持沟通顺畅。

      3、对领导的工作汇报清晰、准确。

      2.1.6 表达能力

      1、编写的各种交付件清晰准确:测试用例、测试报告、案例、总结等。

      2、能制作较好的ppt,完成培训、汇报工作。

      3、能准确的、正向的传达上级领导的指示。

      2.2 业绩

      2.2.1 绩效考核

      个人绩效考评:年度为A,或四个季度含两个A,不得出现C,如果有C,需要额外进行说明。

      2.2.2 案例编写

      1、保持季度1篇的原创技术文档编写,评审结果要求两星以上(0-3分),有一定的深度和学习推广价值。

      2、技术文档编写较多,在经验分享方便有较强主动性,作为业绩纳入考核。

      2.2.3 培训反馈

      1、年度完成对测试部门的培训课程1门,对产线相关领域的培训课程1门;

      2、培训反馈结果在良好及其以上。

      2.2.4 经验分享

      1、建立组内的经验分享方式,组织团队成员在业务、行业、测试方面的知识分享方法和氛围。

      2、自己主动分享的知识点数量和分享落地成果。

    2.2.5 出差反馈

      1、在各类售前、售中、售后性质的出差过程中,其他领域同事(售前、销售、办事处、客户等)的反馈和评价意见。

      2、出差后的个人总结文档质量:软件测试建议、客户关心的业务功能、完善测试场景构建、经验技巧分享等。

      2.2.6 业务评审

      1、在产品立项过程中,各项评审活动提出的意见和建议数目、质量。

      2、在各类同行评审、技术评审过程中,提出的意见和建议数目、质量。

      3、在组内用例、文档、案例评审中,提出的意见和建议数目、质量。

      2.3 态度

      2.3.1 主动性

      1、针对目前团队存在的问题和薄弱环节,能否从内部主动性的角度出发,改善或解决问题。

      2、周期性总结团队建设和规划方便的计划,制定组内学习计划,组内总结例会。

      2.3.2 务实性

      1、针对项目、团队建设提出的方案务实可行。

      2.3.3 责任心

      1、遇到问题,合理判别,不任意推诿责任,也不盲目承担责任,做好份内的工作。

      2、明确知晓自己的岗位职责,外部冲击较大时,明确区分哪些是不可抗力,哪些是借口理由,率领团队努力应对。

      2.4 360°考核

      2.4.1 上级

      2.4.2 同事

      2.4.3 下级

      2.4.4 内部客户

      2.4.5 外部客户

      由产品线和部门领导、人力资源共同出面,约请各角色,对此人在能力、态度、业绩方面做综合考评。

  • CMM流程

    2011-02-25 14:24:47

    CMM是指“能力成熟度模型”,其英文全称为Capability Maturity Model for Software,  英文缩写为SW-CMM,简称CMM

    一、CMM的基本框架 

    1.CMM的设计思想 

        任何软件开发和软件企业的发展都离不开软件过程,而软件过程必然要经历一个从不成熟到成熟,从不完善到完善的发展过程。它不是一朝一夕就能成功的,需要持续不断的对软件过程进行改进,才能取得最终的成效。CMM就是根据这一指导思想设计出来的。为此,模型必需满足如下四点对企业的指导作用: 

    1)为了正确和有序地引导软件过程活动的开展,要建立一个能够有效地描述和表示的软件过程的改进框架,使其能够对各阶段软件过程的任务和管理起指导作用。 

    2)以产品质量的概念和软件工程的经验教训为基础,指导企业控制开发、维护软件的生产过程和如何制定一套与之相适应的软件工程及管理体系。 

    3)指导软件企业通过判断自身当前的过程成熟度,针对软件质量和软件过程提高中最为关键的问题,来选择过程的提高策略。 

    4)引导企业将注意力放在具体的和经过努力可实现的目标上,并努力通过模型中提供的措施和手段去实现这些目标。 

    2.CMM的分级标准 

    1) 建立分级标准的作用 

    CMM模型描述和分析了软件过程能力的发展程度,确立了一个软件过程成熟程度的分级标准,如图2.1示。其作用: 

    ①一方面软件组织利用它可以评估自己当前所处的位置——过程成熟程度,并以此提出严格的软件质量标准和改进过程的方法和策略,通过不断的努力达到更高的成熟度。 

    ②另一方面该标准也可作为用户对软件企业的一种评价标准,使之在选择软件开发商时不再是盲目的和无把握的。 

    2)CMM的分级结构及其过程描述 

    ①初始级:软件过程的特点是无秩序或说无定规的,有时甚至是混乱的。软件过程定义几乎处于无章法、无步骤可循的状态,软件产品所取得的成功往往依赖于极个别人的努力和机遇。 

    ②可重复级:已建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。 

    ③已定义级:用于管理的和工程的软件过程均已文档化、标准化,并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。 

    ④已管理级:软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。 

    ⑤优化级:通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析,能够不断地、持续地对促进过程进行改进。 

    除第一级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个成熟级别,自然可以向上一更为成熟的高一级别迈进。CMM体系不主张跨级别的进化,因为从第二级开始,每一个低级别的实现均是更高级别实现的基础。 

    3.CMM各级的主要特性 

    前面已经反复提到,CMM标准共分五个等级,从第一级到第五级分别为:初始级、可重复级、定义级、管理级和优化级,从低到高,软件开发生产的计划精度越来越高,每单位工程的生产周期越来越短,每单位工程的成本也越来越低。需要提出的是,任何一个成熟度级别的关键过程域集都是本级描述的关键过程域集和所有下级的关键过程域集的并集。如3级的关键过程域就应有13个不同的域,其中7个是3级自己包含的,6个属于2级成熟度,而4级应有15个域。 

    这五个级别具体内容包括: 

    第一级:初始级(The Initial Level) 


    初始级的软件机构缺乏对软件过程的有效管理,其软件项目的成功来源于个人英雄主义而非机构行为,因此它不是可重复的。 



    第二级:可重复级(The Repeatable Level) 

    概述: 

    第二级软件机构的主要特点是:项目计划和跟踪的稳定性,项目过程的可控性和以往成功的可重复性。更具体的说: 

    机构建立了管理软件项目的策略和实现这些策略的过程。 
    新项目的计划和管理基于类似项目的经验。 
    过程能力的增强基于以各个项目为基础的有纪律的基本过程管理。 
    不同的项目可有不同的过程,而对机构的要求是具有指导项目建立适当管理过程的策略。 
    每个项目都确定了基本的软件管理控制,包括: 
    基于前面项目的经验和新项目特点,做出现实的项目承诺(如预算、交付期、软件质量等); 
    软件项目管理者要跟踪开支、日程、软件功能; 
    满足承诺的过程中的出现的问题要及时发现,妥善解决; 
    定义了软件项目标准,且机构确保其被遵守。 

    构成: 

    本级的关键过程领域(KPA)包括: 
    需求管理(Requirements Management) 
    客户的需求是软件项目的基础。软件需求管理的目的是在客户和软件项目之间达成对客户需求的一致理解。 

    软件项目计划(Software Project Planning) 
    为软件工程和项目管理建立一个合理的计划。 

    软件项目的跟踪和监督(Software Project Tacking and Oversight) 
    使管理者对实际的软件项目进展过程有足够的了解,以在项目效能偏离计划太多是采取有效措施。 

    软件子合同管理(Software Subcontract Management) 
    选择合格的分包商,并有效管理之。 

    软件质量保证(Software Quality Assurance) 
    对软件项目过程及其间生产的各个产品进行监管以保证最终软件质量。 

    软件配置管理(Software Configuration Management) 
    在整个软件生命周期里建立并维护软件项目的工作产品的完整性。 

    第三级:已定义级(The Defined Level) 

    概述 

    第三级的主要特征在于软件过程已被提升成标准化过程,从而更加具有稳定性、可重复性和可控性。处于第三级的企业具有如下一些特征: 

    机构采用标准的软件过程,软件工程和管理活动被集成为一个有机的整体。标准化的目的是使之可使管理者和技术人员有效工作。 
    有一组人员专门负责机构的软件过程,并且在机构中有培训计划来确保stuff和manager有知识和技能完成所赋予的角色。 
    标准的软件过程结合项目的特点即形成定义的软件过程,它包括一组集成的定义良好的软件工程和管理过程。 
    一个定义良好的过程包括就绪准则、输入、完成工作过程、验证机制、输出和完成准则。 
    在已建立的产品线上cost, schedule, functionality 均可控制,软件质量被加以跟踪。 
    过程能力体现在在机构范围内对一个定义的软件过程活动、角色和责任的共同理解。 

    构成 : 

    第三级主要处理以下的KPA: 

    机构过程关注(Organization Process Focus) 
    确立机构对于改进机构的软件过程能力的软件过程活动的责任。 

    机构过程定义(Organization Process Definition) 
    开发和维护一组有用的软件过程assets和提供一个用于定义定量过程管理的有意义的数据的基础 

    培训计划(Training Program) 
    开发个体的技能和知识以使他们能够更加有效的完成他们的角色 

    集成软件管理(Integrated Software Management) 
    基于业务环境和项目的技术需要,从机构的标准软件过程和相关的过程assets经过剪裁,将软件工程和管理活动集成为一个有机的定义的软件过程。 

    软件产品工程(Software Product Engineering) 
    一致地完成定义良好的工程过程。它描述了项目的技术活动,如需求分析,设计,编码和测试。 

    组间协调(Intergroup Coordination) 
    确立软件工程组主动介入其它工程组以便项目能更好满足客户要求的手段 

    同行评审(Peer Reviews) 
    早而且有效的排除软件工作产品中的缺陷。它可通过inspection,structured walkthrough等手段进行。 

    概括来说,第三级企业的重点是Engineering processes and organizational support。 

    第四级:已管理级(The Managed Level) 

    概述: 

    第四级的软件机构中软件过程和软件产品都有定量的目标,并被定量地管理,因而其软件过程能力是可预测的,其生产的软件产品是高质量的。具体地说,第四季的机构具有如下特征: 

    软件过程和产品有定量质量目标。 
    重要的软件过程活动均配有生产率和质量度量; 
    数据库被用来收集和分析定义软件过程的数据; 
    项目的软件过程和质量的评价有定量的基础; 
    项目的产品和过程控制具有可预测性。 
    缩小过程效能落在可接受的定量界限内的偏差; 
    可区分过程效能的有效偏差和随机偏差; 
    面向新领域的风险是可知并被仔细管理; 

    构成: 

    本级的关键过程领域包括: 

    定量过程管理(Quantitative Process Management) 
         定量地控制软件项目的过程效能。 

    软件质量管理(Software Quality Management) 
          定量了解项目软件产品的质量,并达到既定的质量目标。 

    第五级:The Optimizing Level 

    概述 


    概括来说,第五级的主要特点是技术和过程改进被作为常规的业务活动加以计划和管理。处于第五级的企业具有如下一些特征: 

    机构集中于连续的过程改进 
    具有标识弱点和增强过程的手段。 
    采用过程数据分析使用新技术的代价效益并提出改进。 
    项目队伍能够分析出错原因并防止其再次出现。 
    防止浪费是第五级的重点。 
    改进的途径在于已有过程的增量改进和使用新技术和新方法的革新 

    构成: 

    缺陷预防(Defect Prevention) 
    识别出错原因,防止错误再现(通过改变定义的软件过程) 

    技术变更管理(Technology Change Management) 

    识别有益的新技术(工具、方法和过程),并按有序的方式将其转移至机构之中。其重点在于在变化的世界中有效的完成革新。 

    过程变更管理(Process Change Management) 
    连续改进机构所采用的软件过程,以改进软件质量,提高生产率和减少产品开发时间 

    概括来说,第五级企业的重点是连续的过程改进。 

    4.CMM内部结构和特性简述 

        上面提到了CMM把软件开发组织的能力成熟度分为五个等级。除了第1级外,其他每一级均由若干关键过程域组成,每个关键过程域中规定了5种公共特性:执行约定、执行能力、实施活动、度量和验证的标准。换句话说,每一个关键过程域由若干关键实践活动所描绘,这些实践活动以5个公共特性进行归类,这些公共特性是关键实践描述的对象、也是基础和依据。CMM给每个关键过程规定了一些具体目标,按5个公共特性归类的关键惯例是按该关键过程的具体目标选择和确定的。如果恰当地处理了某个关键过程涉及的全部关键惯例,这个关键过程的各项目标就达到了,也就表明该关键过程实现了。这种成熟度分级的优点在于,这些级别明确而清楚地反映了过程改进活动的轻重缓急和先后次序。(关于关键过程域、关键实践、公共特性等概念后面会有详细解释) 

    二、CMM与软件过程可视性 

    1.软件过程的概念 

    软件过程是人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。其外部视图如P23页图2.2所示。 

    2.软件过程可视性的重要性与级别 

        软件工程和CMM都强调软件过程可视性的极为重要性,软件工程强调用软件开发方法来解决软件生产中的质量与效率的问题,而CMM则追求软件组织成熟度的不断提高,组织管理的不断进化来使软件质量、生产效率和生产周期得到明显的改善,二者不仅目标相同,而且都强调开发的可视性来支持开发管理。因此,软件过程可视性的提高,就成为提高软件开发组织成熟级别的关键。 

        软件过程的成熟度是可视的,在CMM中分成五级,反映了其不断改进和逐步完善的过程。 

        在初始级中,整个软件过程形同一团黑云,对管理人员和用户而言,只能看到项目的要求和结果,不能看到项目的进展状况和项目的软件过程,是否满足要求要到交付时刻才能知晓。 

        过度到可重复级,软件过程的可视性有所好转,开发分阶段进行,用一系列的黑盒表示。用户需求和阶段产品在一定程度上可以控制。管理人员可在若干关键点设置管理活动和检查质量并作出反应,用户也可通过关键点了解项目进展情况。 

        发展到已定义级,黑盒的内部结构逐步显示出来,组织拥有标准软件过程并用于各软件项目中。因此,各管理人员明确自己在过程中的管理责任和任务,并能预见可能的风险,为此作出一定的准备。由于已定义级的过程提供了很好的可视性,项目外的用户也能快速地得到较为准确的情况。 

        在管理级,管理者可以根据客观的度量,预见过程的经费支出和其他情况,定量地、有目标地做出决定。用户也能定量地理解过程的能力和所存在的风险。整个软件过程可以定量地指导和控制。 

        进化到优化级,人们可以很清楚地看到软件过程的内部结构。为了提高生产率和质量,组织上已经形成了有效地、不断地、系统地改进方法,并且制度化。对现有过程的认识,不仅仅考虑到过程的可能变化所产生的影响,而是能自觉地识别那些不够有效和可能出错的活动,加以改进与替换,达到更进一步的效果。管理人员有能力评估和定量跟踪变化的影响和效果,用户与开发组织关系良好。 

    三、CMM的阶梯式进化框架 

    1.进化框架 

        CMM为软件企业的过程能力提供了一个阶梯式进化框架,它采用分层的方式来解释它的组成部分,以适应不同成熟度企业的需要,如图2.4示。在第二至第五个成熟等级中,每个等级包含一个内部结构的概念,关于内部结构详细描述将在下面CMM内部结构的一栏中进行。 

    1)初始级 初始级的软件过程是混乱无序的,对过程几乎没有定义,项目的执行是随意的甚至是混乱的,项目的成功完全依赖个人的才能和经验,没有组织、标准、规程的保证,质量评判没有客观基准,管理方式属于反应式的。也许,有些企业制定了一些软件工程规范,但往往也是执行得不彻底。纵使有较好的执行,但若这些规范未能覆盖基本的关键过程要求,且执行没有政策和资源等方面的保证时,那么它仍然被视为初始级。初始级是混沌的过程。 

    2)可重复级  根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。因此,第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 

        实现二级(可重复级)已经不简单了。对一个软件企业来说,达到二级的要求就基本上进入了规模开发,开始跳出作坊式的开发模式,能把一个项目的经验或好的方法重现在下一个项目中,基本具备了一个现代化软件企业的基本架构和方法,具备了承接外包项目的能力。可重复级是经过训练的软件过程,其等级标志是分工合同化,主要工作内容为管理各种开发文档。可重复级的软件过程能力可归结为:规则化的或说定规的。 

        从二级一直往上走,是不间断的改进过程。效率不断在提高,时间控制更严格,品质更有保证,管理更有序。可以逐渐具备承接跨地区、跨部门的大型项目的实力。 

    3)已定义级 已定义级建立了组织的标准软件过程且已文档化,它包括了软件工程和管理过程的所有方面,集成为一个标准一致的有机整体,提供给各个项目剪裁使用。 

        在第二级仅定义了管理的基本过程,而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准,而且无论是管理还是工程开发都需要一套文档化的标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目均需依据这个标准过程,剪裁出项目适宜的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。定义级是标准一致的软件过程,等级标志是流程程序化,主要工作内容是管理软件开发过程。 

    4)已管理级 在已管理级,软件产品和软件过程均建立了量化的指标和质量的指标,评价软件过程的产品(最终产品和中间产品)和质量,是企业评价计划的一部分。 

        第四级的管理是量化的管理,是可量化级,其软件过程具有精确的定义、连贯的评价方法。所有过程需建立相应的度量方式,所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品,量化控制将使软件开发真正变成为一种工业生产活动。管理级是可预测的软件过程,等级标志是记录表格化,主要工作内容是度量软件开发过程和产品质量。第四级软件产品是高质量的。 

    5)优化级 第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程,即优化执行步骤。软件过程的不断改进成为整个企业的主要着眼点和前进的动力。如果一个企业达到了这一级,那么表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。优化级是可持续改进的软件过程,等级标志是资源最优化,主要工作内容是提高软件企业资源的利用水平。 

        从效果而言,在上述不同阶段,软件开发 生产的成熟程度给软件企业带来了完全不同的效果。第一阶段到第五个阶段,软件开发生产的计划精度越来越高,每单位工程的生产周期越来越短,每单位工程的成本越来越低。 

    2.成熟度级别进化 

        每一级向上一级迈进的过程中都有其特定的改进计划,具体情况如下。(各级的过程特征及其改进方向详见P27~P31相关表) 

    1)初始级的改进方向是:①建立项目过程管理,实施规范化管理,保障项目的承诺;②进行需求管理方面的工作,建立用户与软件项目之间的沟通,使项目真正反映用户的要求;③建立各种软件项目计划,如软件开发计划、软件质量保证计划、软件配置管理计划、软件测试计划、风险管理计划和过程改进计划等;④积极开展软件质量保证活动(SQA)。 

    2)可重复级的改进方向是:①不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具体经验归纳为全组织的标准软件过程。把改进组织的整体软件过程能力的软件过程活动,作为软件开发组织的责任;②确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软件过程中,从而可以跨项目改进软件过程效果,也可以作为软件过程剪裁的基础;③建立软件工程过程小组(SPEG)长期承担评估与调整软件过程的任务,以适应未来软件项目的要求;④积累数据,建立组织的软件过程库及软件过程相关的文档;⑤加强培训。 

    3)已定义级的改进方向是:①着手软件过程的定量分析,以达到定量地控制软件项目过程的效果;②通过软件的质量管理达到软件的质量目标。 

    4)已管理级的改进方向是:①防范缺陷,不仅在发现了问题时能及时改进,而且应采取特定行动防止将来出现这类缺陷;②主动进行技术改革管理、标识、选择和评价新技术,使有效的新技术能在开发组织中实施;③进行过程变更管理,定义过程改进的目的,经常不断地进行过程改进。 

    5)优化级的改进目方向是:①保持持续不断的软件过程改进。CMM5级是优化级,之所以称之为优化级不是因为它比第4级更高,它强调的是一个持续不断的优化过程。如果你在某一个阶段停顿下来,那么不进则退,你就有可能会掉下去。 

    3.成熟度举例——软件成熟度企业与不成熟企业的一个侧影 

        大家都见过或听说过某些软件企业人才跳槽后的故事吧。的确存在这样的事情,这些软件企业当出现一些关键的开发人员跳槽离开后,进行中的项目便瘫痪了下来,甚至前功尽弃,已运行中的项目也难以继续维护,给企业造成很大的损失。这就是不成熟企业的一个特征。 

        而在CMM框架中,运用2级中的一个基本软件工程(KPA)就可以使员工自觉而规范地管理软件生产过程中所有的资源、阶段性产品、产品源代码、文件以及最终生成的产品。严格遵循这套管理方法,程序员写完一段代码,经过一定测试之后,一旦提交到某个公共地方时,这个东西就不是你的了,已经成为项目小组或者是整个企业的了,而且跟随着完善的文档控制。如果你想对它进行任何修改,都要按照规范的程序把它从公共区域提取出来。规范的过程控制,将软件企业由于人员流动带来的风险降到了最低,同时还促使他们养成良好的职业素养。 

    四、CMM的内部结构 

    1.内部结构组成 

        CMM为软件过程能力的提高提供了一条改进的途径。CMM由5个成熟度等级组成,每个成熟度等级有着各自的功能。除第一级外,CMM的每一级按完全相同的内部结构构成的,不同的成熟度等级反映了软件组织的软件过程能力和该组织可能实现预期结果的程度。 

        在CMM中,除第1级外,每个成熟度等级都标志了该级别的软件组织所具有的过程能力。每个成熟度等级(第1级除外)规定了若干不同的关键过程域,一个软件组织如果希望达到某一个成熟度级别,就必须完全满足关键过程域所规定的要求,即满足关键过程域的目标。每一个关键过程域都含有属于5种类别(公共特性)中的若干关键实践,通过实现这些关键实践来达到关键过程域的目标。 

    2.各构成要素描述 

    1)关键过程域(KPA):是指在有关基础设施的保证支撑下的一系列相互关联的操作活动,这些活动反映了一个软件组织改进软件过程时必须集中力量改进的几个方面。可以简单地说,关键过程域是互相关联的若干软件实践活动和有关基础设施的一个集合。换句话说,关键过程区域标识了达到某个成熟度等级时所必须满足的条件。在CMM中一共有18个关键过程域,分布在第二至五级中,每个关键过程域规定了一个(组)必须满足的目标,并由五个公共特性归类的若干关键实践活动描述实现之。 

    2)目标:是指某个关键过程域中的关键实践,它表示每一个关键过程域的范围、边界和意图。目标被用来判断一个组织或项目是否有效地实现了某个特定的关键过程区域所规定的内容,即目标确定了关键过程区域的界限、范围、内容和关键实践。 

    每一个KPA都规定了一组目标,若这组目标在每一个项目都能实现,则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求,则表明达到了这个级别所要求的能力。例如,可重复级中需求管理关键过程域的目标是:在软件需求上建立、维护同用户的协议;软件项目计划关键过程域的目标则为:建立一个为开展和管理软件工程的合理设计;又如,软件项目跟踪和监控KPA的目标是:提供对实际进程的可见和监督,以便及时采取纠正措施。 

    3)公共特性:表征各种实践活动的分类,一共分为五类。这些特性(有时又称属性)有效地指出了一个关键过程域的实现范围、结构要求和实施内容。具体是: 

    ①执行约定(commitment to perform):又称实施保证,实施保证是企业为了建立和实施相应KPA所必须采取的活动,这些活动主要包括制定企业范围的政策和高层管理的责任。 

    ②执行能力(ability to perform):执行能力是企业实施KPA的前提条件。企业必须采取措施,在满足了这些条件后,才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。 

    ③实施活动(actives performed):实施活动也叫执行活动,执行过程描述了执行KPA所需求的必要角色、任务和步骤。在五个公共属性中,执行活动是唯一一项由项目来执行相关的属性,其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪以及改进措施等。 

    ④度量和分析(measurement and analysis):度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。 

    ⑤验证实施(verifying implementation):验证实施是验证执行活动是否与所建立的过程一致。实施验证涉及到管理的评审和审计以及质量保证活动。实施验证活动可通过管理和软件质量保证进行核查。 

    4)关键实践(KP):是指关键过程域中的一些主要实践活动。具体就是指为达到关键过程目标,建立起那些对软件过程活动起关键作用的方针、规程、措施、标准、活动以及相关基础设施的实践。每个关键过程域由若干关键实践组成,通过这些关键实践来达到关键过程域的目标。一般情况下,关键实践描述了应该“做什么”,但并不规定“如何做”去达到这些目标。有关关键实践的举例: 

    例如:可重复级需求管理关键过程域中,记录和管理系统需求的策略的实践活动,就是一个关键实践(执行约定);建立分析责任和分配系统需求这一实践活动,也是该过程域的一个关键实践(执行能力);还有,分配需求、提供资源和资金以及开展需求培训(执行能力),也都是该过程域的一些关键实践活动。当然,该过程域还有度量需求管理活动状态(度量与分析)…… 

    在一些文献中使用了“关键惯例”、“优秀实践”等词。关键惯例与关键实践在概念上基本相同,只是“关键惯例”似乎更加突出了使用以往成功经验和成果之意。“优秀实践”也大概如此。 

    上面提到了CMM把软件开发组织的能力成熟度分为5个等级。除了第1级外,其他每一级由几个关键过程域组成。每一个关键过程域都由上述分为5种公共特性的实践活动予以描述。关键过程域的分类详见图2.7。它列出了四个成熟度等级的共18个关键过程域。 

    3.功能综述 

    从上面所示的结构模型可以看出,CMM包括两大部分“软件能力成熟度模型”和“能力成熟度模型的关键惯例”。“软件能力成熟度模型”主要是描述此模型的结构,并且给出该模型的基本构件的定义。“能力成熟度模型的关键惯例”详细描述了每个“关键过程方面”涉及的“关键惯例”。这里“关键过程方面”是指一组相关联的活动,也就是关键过程域;每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面,它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域。反之,非关键过程域是指对达到相应软件过程成熟度等级的目标不起关键作用。可以归纳为:关键过程域是互相关联的若干软件实践活动和有关基础设施的一个集合。而“关键惯例”是指使关键过程方面得以有效实现和制度化的作用最大的基础设施和活动,对关键过程的实践起关键作用的方针、规程、措施、标准、活动以及相关基础设施的建立。关键实践一般只描述“做什么”而不强制规定“如何做”。各个关键惯例按每个关键过程方面的五个“公共特性”【执行约定(对执行该过程的承诺),执行能力(执行该过程的能力),实施活动(该过程中要执行的活动),度量和分析(对该过程执行情况的度量和分析),验证实施(证实所执行的活动符合该过程)】归类,逐一详细描述。当作到了某个关键过程的全部关键惯例就认为实现了该关键过程,如果实现了某成熟度级别以及比其低级所含的全部关键过程就认为达到了该级。 

    CMM总结:五层结构图 

    我们看到,在第五级上,技术和过程的改进像普通商业活动一样有计划、有管理地进行。由于组织不断的致力于改进过程的能力,所以软件开发组织的能力可持续改进。这种改进不仅表现在对存在的软件过程逐步改进,不表现在采用新技术和新方法方面的革新。 

    画一个图吧:(CMM的五层结构图) 
              ----------------- 
             /   优 化 级     / 
            /      (5)       / 
            ----------------- 
                   ↑ 
                   | 不断改进的过程 
                   | 
              ----------------- 
             / 可 管 理 级    / 
            /      (4)       / 
            ----------------- 
                   ↑ 
                   | 能预见的过程 
                   | 
              ----------------- 
             /   确 定 级     / 
            /      (3)       / 
            ----------------- 
                   ↑ 
                   | 标准一致的过程 
                   | 
              ----------------- 
             /  可 重 复 级   / 
            /      (2)       / 
            ----------------- 
                   ↑ 
                   | 有纪律的过程 
                   | 
              ----------------- 
             /  初 始 级      / 
            /     (1)        / 
            ----------------- 
  • tcp协议复习-option字段

    2009-08-21 17:07:25

    TCP 传输控制协议概述

           TCP是一种基于IP协议的,提供面向连接的,可靠的,全双工的字节流服务的传输层协议。

           TCP面向连接的概念可以理解为与2层相似的一种虚电路的概念,即在开始使用TCP传输数据之前,必须先建立一个连接(虚电路),在连接建立好之后,双方,也只能是连接的两端两个“端”才能开始进行数据交换。因此,广播和多播是不能应用于TCP的。

    TCP的主要特点

           TCP自己组织需要发送的数据块的大小。这一点可能让很多开发者感觉不爽,也是造成很多bug的原因。当应用开发人员使用write或者send发送数据后,其实是将数据拷贝到了kernelTCP的发送缓存中,这之后的事情就完全由TCP来决定了,TCP会把数据划分成它认为最合适的数据块。这个思想是和UDP完全不同的。

           TCP发送一块数据后,它会启动一个定时器timer,等待接收方的确认,如果在timer规定的时间内接收不到确认数据,则重新发送刚才的数据块。

           TCP收到来自另外一端的数据后,它会发送一个针对接受到的数据的确认,通常这个确认会推迟一段时间(非常短的时间)发送出去。

           TCP会始终保持一个整个TCP报文段(包括headerdata)的校验和,用于检测在数据传输中是否出现错误。如果有则丢弃当前收到的这个数据段。

           TCP必须对到达的数据进行排序。

           TCP必须能够丢掉重复的数据段。

           TCP的另外一个非常重要的功能是它可用提供流量控制。它的两端都有一定的固定大小的buffer空间。接手段必须告诉发送端自己所能接收的最大数据,而发送端发送的数据不能超过接收端buffer的大小。

           TCP不对它所传送的字节流做任何解释,它不知道所传送的字节流是二进制还是ASCII字符,这个问题是应用层应该考虑的问题。

    TCPHeader主要内容

    TCP报头总长最小为20个字节,其报头结构如下图(图1)所示;

                                                                                                         比特0             比特15   比特16             比特31

    源端口(16

    目的端口(16

    序列号(32

    确认号(32

    TCP偏移量(4

    保留(6

    标志(6

    窗口(16

    校验和(16

    紧急(16

    选项(032

    数据(可变)

    (图1 TCP报头结构)

           首先16位的src port16位的dst port用来区分应用程序。

           TCP Header中两个32位是一个序号与一个确认序号,这两个东西比较难理解。首先序号用来标识从发送端向接收端发送的数据字节流,它表示这个数据段中的第一个数据字节。其实序号就是一个发送端发送数据的计数器,发送端发送的第二个TCP包的序号减去第一个TCP包的序号就可以得出第一个TCP包发送的数据块的大小。序号是一个32位的无符号证书,达到232次方减1后又从0开始。

           需要注意的是,当建立一个TCP连接时,SYN标志变为1,此时序号字段包含了发送方主机选择的出示序号ISN,但是一般情况下这个ISN0,改发送方要发送的数据的第一个字节序号为这个ISN1,因此在建立TCP连接的第一个TCP包中,序号为0,因为ISN0,而建立TCP连接又没有要发送的数据,所以序号为0

           确认序号标识接收方(即发送确认的一方)所期望接收到的下一个序号,也就是它接收到的TCP包的序号加1,并且只有ACK位为1时此确认序号才生效。但是通常情况下这种情况总是正确的,因为一个TCP连接一旦建立,之后的报文中ACK位总会被设置。

           需要注意的是,序号和确认序号是有方向的,因为TCP提供的是全双工的服务,所以在每一个方向上的序号和确认序号都是不同的。

           确认序号其实就是表示已经收到了发送端发送的一些数据,但是当前确认序号所标识的数据还没有收到,这个确认序号可以被发送方用来判断是否需要重发。

           4位的Header长度标识当前TCP包的header长度,最长是60个字节,而正常的TCPheader长度是20字节。

           6位的标志位。URG:紧急指针有效;ACK:确认序号有效;PSH:接收方应该立刻将此包发给应用层;RST:复位一个连接;SYN:发起一个TCP连接;FIN:结束一个连接。

           16位的窗口大小。TCP的流量控制由连接每一端通过声明窗口大小来提供。窗口大小为字节数,从确认序号的值开始。比如一端声明窗口大小为4096,当前的确认序号为10000,则表明这一端当前能接收的最大字节数为4096,而它希望接收从序号10000开始的数据。

           16位的校验和。这个校验和覆盖整个TCP报文。它一定是由发送端来计算和填充的。而且必须由接收端进行验证。

           16位的紧急数据指针,只有当URG标志位为1时才有效。它是一个偏移量,标识从序号开始的直到指针所指的数据,这一段数据被发送端设置为紧急数据。

           TCP Header中还有一些options字段,最常用的是MSS字段,通常是SYN报文中携带这个字段,表明本端所能接收的最大长度的报文段。

           另外需要表明的是,TCP可以不携带任何数据,而且这种报文还很有用,可用用来确认数据,也可以用来处理超时。



  • OSI参考模型

    2009-08-19 09:40:11

    1 OSI参考模型
      
      谈到网络不能不谈OSI参考模型,虽然OSI参考模型的实际应用意义不是很大,但其的确对于理解网络协议内部的运作很有帮助,也为我们学习网络协议提供了一个很好的参考。在现实网络世界里,TCP/IP协议栈获得了更为广泛的应用。
      
      1.1 OSI参考模型的分层结构
      
      OSI参考模型(OSI/RM)的全称是开放系统互连参考模型(Open System Interconnection Reference Model,OSI/RM),它是由国际标准化组织(International Standard Organization,ISO)提出的一个网络系统互连模型。
      
      OSI参考模型采用分层结构,如图1-1所示。


        
       图1-1  OSI参考模型
      
      在这个OSI七层模型中,每一层都为其上一层提供服务、并为其上一层提供一个访问接口或界面。
      
      不同主机之间的相同层次称为对等层。如主机A中的表示层和主机B中的表示层互为对等层、主机A中的会话层和主机B中的会话层互为对等层等。
      
      对等层之间互相通信需要遵守一定的规则,如通信的内容、通信的方式,我们将其称为协议(Protocol)。
      
      我们将某个主机上运行的某种协议的集合称为协议栈。主机正是利用这个协议栈来接收和发送数据的。
      
      OSI参考模型通过将协议栈划分为不同的层次,可以简化问题的分析、处理过程以及网络系统设计的复杂性。
      
      OSI参考模型的提出是为了解决不同厂商、不同结构的网络产品之间互连时遇到的不兼容性问题。但是该模型的复杂性阻碍了其在计算机网络领域的实际应用。与此对照,后面我们将要学习的TCP/IP参考模型,获得了非常广泛的应用。实际上,也是目前因特网范围内运行的唯一一种协议。
      
      1.2 OSI参考模型中各层的作用
      
      在OSI参考模型中,从下至上,每一层完成不同的、目标明确的功能。
      
      1、物理层(Physical Layer)
      
      物理层规定了激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的物理媒体。
      
      在这一层,数据的单位称为比特(bit)。
      
      属于物理层定义的典型规范代表包括:EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等。
      
      2、数据链路层(Data Link Layer)
      
      数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
      
      在这一层,数据的单位称为帧(frame)。
      
      数据链路层协议的代表包括:SDLC、HDLC、PPP、STP、帧中继等。
      
      3、网络层(Network Layer)
      
      网络层负责对子网间的数据包进行路由选择。此外,网络层还可以实现拥塞控制、网际互连等功能。
      
      在这一层,数据的单位称为数据包(packet)。
      
      网络层协议的代表包括:IP、IPX、RIP、OSPF等。
      
      4、传输层(Transport Layer)
      
      传输层是第一个端到端,即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外,传输层还要处理端到端的差错控制和流量控制问题。
      
      在这一层,数据的单位称为数据段(segment)。
      
      传输层协议的代表包括:TCP、UDP、SPX等。
      
      5、会话层(Session Layer)
      
      会话层管理主机之间的会话进程,即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。
      
      会话层协议的代表包括:NetBIOS、ZIP(AppleTalk区域信息协议)等。
      
      6、表示层(Presentation Layer)
      
      表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。
      
      表示层协议的代表包括:ASCII、ASN.1、JPEG、MPEG等。
      
      7、应用层(Application Layer)
      
      应用层为操作系统或网络应用程序提供访问网络服务的接口。
      
      应用层协议的代表包括:Telnet、FTP、HTTP、SNMP等。
      
      1.3 OSI参考模型中的数据封装过程

    1.3 OSI参考模型中的数据封装过程
     
       图1-2  OSI参考模型中的数据封装过程
      
      如图1-2所示,在OSI参考模型中,当一台主机需要传送用户的数据(DATA)时,数据首先通过应用层的接口进入应用层。在应用层,用户的数据被加上应用层的报头(Application Header,AH),形成应用层协议数据单元(Protocol Data Unit,PDU),然后被递交到下一层-表示层。
      
      表示层并不"关心"上层-应用层的数据格式而是把整个应用层递交的数据包看成是一个整体进行封装,即加上表示层的报头(Presentation Header,PH)。然后,递交到下层-会话层。
      
      同样,会话层、传输层、网络层、数据链路层也都要分别给上层递交下来的数据加上自己的报头。它们是:会话层报头(Session Header,SH)、传输层报头(Transport Header,TH)、网络层报头(Network Header,NH)和数据链路层报头(Data link Header,DH)。其中,数据链路层还要给网络层递交的数据加上数据链路层报尾(Data link Termination,DT)形成最终的一帧数据。
      
      当一帧数据通过物理层传送到目标主机的物理层时,该主机的物理层把它递交到上层-数据链路层。数据链路层负责去掉数据帧的帧头部DH和尾部DT(同时还进行数据校验)。如果数据没有出错,则递交到上层-网络层。
      
      同样,网络层、传输层、会话层、表示层、应用层也要做类似的工作。最终,原始数据被递交到目标主机的具体应用程序中。

  • TCP/IP参考模型

    2009-08-18 17:49:11

    TCP/IP(Transmission Control Protocol/Internet Protocol,传输控制协议/网络协议协议)是Internet最基本的协议,简单的说,就是由底层的IP协议和TCP协议组成的。TCP/IP协议的开发工作始于20世纪70年代,是用于互联网的第一套协议。


    TCP/IP参考模型分为四层:

    一个协议族,比如TCP/IP,是一组不同层次上的多个协议的组合。TCP/IP通常被认为是一个四层协议系统,如图1 - 1所示。

    (点小图查看大图)
    点击图片看大图
        每一层负责不同的功能:
        1) 链路层,有时也称作数据链路层或网络接口层,通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆(或其他任何传输媒介)的物理接口细节。
        2) 网络层,有时也称作互联网层,处理分组在网络中的活动,例如分组的选路。在TCP/IP协议族中,网络层协议包括IP协议(网际协议),ICMP协议(internet互联网控制报文协议),以及IGMP协议(internet组管理协议)。
        3 ) 运输层主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中,有两个互不相同的传输协议: TCP(传输控制协议)和UDP(用户数据报协议)。

    该层提供端对端的通信。最重要的传输层协议是传输控制协议TCP

    • 传输控制协议TCP (Transport Control Protocol) - 数据流传输(面向连接,可靠)
    • 用户数据报文协议UDP (User Datagram Protocol) - 数据报文传输(无连接不可靠) 
          TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层,确认接收到的分组,设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信,因此应用层可以忽略所有这些细节。
      而另一方面, U D P则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机,但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。
          

    应用层

    该层包括所有和应用程序协同工作,利用基础网络交换应用程序专用的数据的协议。如,

    • HTTP(Hypertext Transfer Protocol),超文本传输协议。
    • TELNET (Teletype over the Network, 网络电传) ,通过一个终端(terminal)登陆到网络(运行在TCP协议上)。
    • FTP (File Transfer Protocol, 文件传输协议) ,由名知义(运行在TCP协议上) 。
    • SMTP (Simple Mail Transfer Protocol,简单邮件传输协议) ,用来发送电子邮件(运行在TCP协议上) 。
    • DNS (Domain Name Service,域名服务) ,用于完成地址查找,邮件转发等工作(运行在TCPUDP协议上) 。
    • NTP (Network Time Protocol,网络时间协议) ,用于网络同步(运行在UDP协议上) 。
    • SNMP (Simple Network Management Protocol, 简单网络管理协议) ,用于网络信息的收集和网络管理。

    网络模型OSI参考模型和TCP/IP参考模型的对比

    首次分享请先

  • 如判断这两个IP是否属于同一网段?

    2009-08-04 16:20:59

    教你一个手工判断的方法,然后你就知道程序如何判断了。  
       
      你把你的IP地址表达成   二进制共有32位,再把子网掩码表达成二进制共有32位,  
       
      IP1:01010110110101010101011010101010  
      IP2:01010110110101010101011011110011  
      Mask:11111111111111111111111110000000  
       
      你只需要看掩码中是“1”的那些位置,对应的两个IP地址的位是否相等,全部相等就是同一网段;有一个不等,就不是同一网段。  

    要想在同一网段,必需做到网络标识相同,那网络标识怎么算呢?各类IP的网络标识算法都是不一样的。A类的,只算第一段。B类,只算第一、二段。C类,算第一、二、三段。
      算法只要把IP和子网掩码的每位数AND就可以了。
      AND方法:0和1=0 0和0=0 1和1=1
      如:And 192.168.0.1,255.255.255.0,先转换为二进制,然后AND每一位
      IP      11000000.10101000.00000000.00000001
      子网掩码    11111111.11111111.11111111.00000000
      得出AND结果  11000000.10101000.00000000.00000000
      转换为十进制192.168.0.0,这就是网络标识,
      再将子网掩码反取,也就是00000000.00000000.00000000.11111111,与IP AND
      得出结果00000000.00000000.00000000.00000001,转换为10进制,即0.0.0.1,
      这0.0.0.1就是主机标识。要想在同一网段,必需做到网络标识一样。

      我们再来看看这个改为默认子网掩码的B类IP
      如IP:188.188.0.111,188.188.5.222,子网掩码都设为255.255.254.0,在同一网段吗?
      先将这些转换成二进制
      188.188.0.111 10111100.10111100.00000000.01101111
      188.188.5.222 10111100.10111100.00000101.11011010
      255.255.254.0 11111111.11111111.11111110.00000000
      分别AND,得
      10111100.10111100.00000000.00000000
      10111100.10111100.00000100.00000000
      网络标识不一样,即不在同一网段。
      判断是不是在同一网段,你会了吧,下面,我们来点实际的。
      一个公司有530台电脑,组成一个对等局域网,子网掩码和IP设多少最合适?
      子网掩码不说了,前面算出结果来了11111111.11111111.11111100.00000000,也就是255.255.252.0
      我们现在要确定的是IP如何分配,首先,选一个B类IP段,这里就选188.188.x.x吧
      这样,IP的前两段确定的,关键是要确定第三段,只要网络标识相同就可以了。我们先来确定网络号。(我们把子网掩码中的1和IP中的?对就起来,0和*对应起来,如下:)
      255.255.252.0 11111111.11111111.11111100.00000000
      188.188.x.x  10111100.10111100.??????**.********
      网络标识   10111100.10111100.??????00.00000000
      由此可知,?处随便填(只能用0和1填,不一定全是0和1),我们就用全填0吧,*处随便,这样呢,我们的IP就是
      10111100.10111100.000000**.********,一共有530台电脑,IP的最后一段1~254可以分给254台计算机,530/254=2.086,采用进1法,得整数3,这样,我们确定了IP的第三段要分成三个不同的数字,也就是说,把000000**中的**填三次数字,只能填1和0,而且每次的数字都不一样,至于填什么,就随我们便了,如00000001,00000010,00000011,转换成二进制,分别是1,2,3,这样,第三段也确定了,这样,就可以把IP分成188.188.1.y,188.188.2.y,188.188.3.y,y处随便填,只要在1~254范围之内,并且这530台电脑每台和每台的IP不一样,就可以了。

  • Byte、bit、bps、位、字、字节/包 ,报文,帧

    2009-08-04 16:16:24

    数据发送时,由上层向下层封装,   
    四层,协议层传输的是数据报文,主要是协议格式。
      三层,网络层传输的是数据包,包含数据报文,并且增加传输使用的IP地址等三层信息
       二层,数据链路层传输的是数据帧,包含数据包,并且增加相应MAC地址与二层信息
      数据接收的时候,下层向上层解封装

    具体区别就是所工作的层不同,可根据ISO七层模型或者TCP/IP四层模型理解

    GB=Giga Byte, Gb=Giga bit
    这个对于数码之家上玩U盘的会员来说,是要记住的,不然被卖家忽悠了都不知道


    我们经常说到网速,而提到网速,经常省略了单位,往往只是说G、M、K,其实G、M、K是数量的简略表示法,换算公式:1G=1024M,1M=1024K,1K=1024,就相当于我们中国人说的亿、万、千、百、十,只是数量的简略表示而已,并不是单位。

    B是Byte的意思,Byte是字节的意思,是存储空间的基本计量单位
    bit是位的意思,是说二进制数的长度单位,比如10011001就是8位二进制数
    这个bit就是网速的基本计量单位bps里的b,bps的意思是bits per Second,即每秒传输多少位数(二进制)
    为什么这里是bits而不是bit了呢?这是英文与中文的区别,复数的表示法。
    二进制数是计算机内部使用的基本表达语言,所以位(bit)是计算机中最小的数据单位。
    1字节在计算机里存储为一个8位进制数,这是固定的。

    提到了字节,不得不再提到“字”这个计量单位:“字”由若干个字节构成,字的位数叫做字长,字长就是说字所对应的二进制数的长度。不同的机器有不同的字长。例如一台8位机,它的1个字就等于1个字节,字长为8位。如果是一台16位机,那么,它的1个字就由2个字节构成,字长为16位。
    前期的DOS就是8位的,后期的DOS是16位的,Win9X是基于DOS的,所以也是16位的,NT核心的Windows是32位的,现在也有了64位的XP/2003,CPU也有了64位的,这个操作系统和CPU所说的位就是bit的意思,即二进制数的长度。
    字节是固定由8位二进制构成,64位系统就代表了64位的二进制代表一个字,换算成字节就是64/8=8,即是说由8字节构成一个字,32位系统就是32/8=4,4个字节代表一个字。
  • 软件工程基础学习记录

    2009-08-03 22:13:54

    随着软件开发的规模和需求增加,软件也出现了越来越多的问题。软件危机是软件的开发和维护过程中出现的一系列严重问题。

    软件危机包含的现象有:

    1 软件开发的成本和进度估计不准确。

    2 用户对“已完成”的软件不满意。

    3 软件质量不可靠。

    4 软件的可维护度低

    5 软件通常没有适当的文件数据。

    6 软件产品的供不应求

    基于以上问题,出现了软件工程的名词。软件工程是研究如何用系统化,规范化,数量化等工程原则和方法进行软件开发和维护的学科。包含了软件开发技术和软件项目管理。

    软件工程的基本原理:

    1 用分阶段的生命周期计划严格管理。

    对每个阶段的活动,逐一细分,然后估计出时间,这样的准确率要高很多。

    2 坚持进行阶段评审。针对问题在编码阶段已经出现,并且可以把问题控制在萌芽状态中这一思路

    3 实现严格的阶段控制。对于需求的确定,和改动,都需要有严格的评审和流程,一经改动,立即在后续流程执行。

    4 采用现代程序技术。指采用面向对象的技术。

    5 结果应能清楚的审查。对于开发的产品能够评定。

    6 开发人员少又精。主要是针对接口测试,开发人员越多,接口越多,工作量越大。

    7 承认不断改进软件工程实践的必要性  也就是与时俱进的意思。既然软件有这么多问题,那么改进也是一个过程。

    软件开发过程模型:

    瀑布模型:将软件生命周期划分为6个阶段:

    制定计划---需求分析---软件涉设计---程序编写---软件测试---程序维护阶段

    瀑布模型要求后一阶段按照前一阶段的工作结果继续进行,为线性方式运行。产生的文档比较多。