下载文档原格式
ASPICE软件质量保证设计文档英文版Document Title: ASPICE Software Quality Assurance Design DocumentIntroductionThis document outlines the design of the software quality assurance process for ASPICE (Automotive SPICE) compliant software development. The goal is to ensure high-quality software products that meet the requirements of the automotive industry.ScopeThe scope of this document covers the entire software development lifecycle, from requirements analysis to testing and validation. It includes the processes, tools, and responsibilities related to software quality assurance.Objectives1. Define the software quality assurance process2. Establish quality standards and metrics3. Ensure compliance with ASPICE requirements4. Identify and mitigate risks related to software quality5. Improve overall software development efficiency and effectivenessProcess OverviewThe software quality assurance process consists of the following key activities:1. Requirements analysis and validation2. Design review and verification3. Code review and static analysis4. Testing and validation5. Defect tracking and resolution6. Process improvement and lessons learnedQuality StandardsThe software quality assurance process will adhere to industry best practices and ASPICE guidelines. Quality standards will be defined for each phase of the software development lifecycle to ensure consistency and reliability.MetricsMetrics will be established to measure the effectiveness of the software quality assurance process. Key performance indicators (KPIs) will be used to track progress, identify areas for improvement, and ensure that quality objectives are met.ComplianceCompliance with ASPICE requirements is essential for successful software development in the automotive industry. The software quality assurance process will be designed to ensure full compliance with all relevant standards and regulations.Risk ManagementRisk management is a critical aspect of software quality assurance. Risks related to software quality will be identified, assessed, and mitigated throughout the development lifecycle to minimize the impact on product quality.ConclusionThe ASPICE software quality assurance design document outlines the process, standards, metrics, compliance, and risk management strategies for ensuring high-quality software products in the automotive industry. By following these guidelines, we aim to improve overall software development efficiency and effectiveness.。
AADO ActiveX Data Object ActiveX 数据对象ALM Application Lifecycle Management 开发生命周期管理ANSI American National Standard Institute 美国国家标准工会AOP Aspect-Oriented Programming 面向方面的程序设计AI Artificial Intelligence 人工智能AI Action Item 活动项API Application Programming interface 应用编程接口ASCII American Standard Code of Information InterchangeASP Active Server Page 动态服务端网页Absolute location 绝对位置Agile methodology 敏捷方法学Application-independent 程序相依性BBDE Borland Database Engine Borland 数据引擎BSF Bean scripting FrameworkBean 脚本框架BVT Build Verification Tests 创建确认测试CCA Comprehensive audit 综合检查CASE Computer Aided Software EngineeringCBD Component-Based Development 基于组件的软件开发CCB Configuration Control Board 配置控制部CDR Critical Design Review 关键设计评审CD&UT Coding and Unit Testing phase 编码与单元测试阶段CGI Common Gateway Interface 公用网关接口CLR Common Language Runtime 公共语言运行库CLS .NET Common Language SpecificationCMM Capability Maturity Model 成熟度模型CMMI Capability Maturity Model IntegrationCOM Component Object Model 组件对象模型CORBA Common Object Request Broker Architecture 公共对象请求代理体系结构COSS Common Object Service Specification 公共对象服务规范CRLCMP Computer Resource Life Cycle Management Plan 计算机资源生命周期管理计划CRM Customer Relationship management 客户关系管理CSCI Computer Software Configuration Item 计算机软件配置项CSS Cascading Style Sheets 级联样式表case sensitve 区分大小写character references 字符引用class completion 类自动生成class factory 类工厂client zero configuration 客户零配置compact envent handler 小型事件柄critical software 重要软件customize tag 自定义标记DDAO Data Access Object 数据访问对象DBA DataBase Administrator 系统管理员DbC Design by Contract 按契约设计DBCC DataBase Consistency Checker 数据库一致性检查器DBDD Data Base Design Description 数据库设计描述DCL Data Control Language 数据控制语言DCOM Distributed Component Object Model 分布式组件对象模型DCR document Change Request 文档更改请求DD Detailed Design Phase 详细设计阶段DDD Detailed Design document 详细设计文档DDL Data Definition Language 数据定义语言DDR Detailed Design Review 详细设计评审DHTML Dynamic HypweText Markup Language 动态超文本标记语言DID Data Item Description 数据项描述DII Dynamic Invocation Interface 动态调用接口DLL Dynamic-Link Library 动态链接库DML Data Manipulation Language 数据操纵语言DNA Distributed interNet Application Architecture 分布式网络应用体系结构DNS Digital Nervous System 数字神经系统DOM document Object Model 文档对象模型DS Design Specification 设计规范DSI Dynamic Skeleton Interface 动态框架界面DSO Data Source Object 数据来源对象DSS Decision Support Servers 决策支持服务器DSSSL document Style Semanticsand Specification Language 文档样式语义和规范语言DTC Distributed Transaction Coordinator 分布式事务协调器DTD document Type Definition 文档类型定义DTS Data Transformation Services 数据转换服务data consistency 数据一致性data provider 数据提供者data warehouse 数据库仓库deployment descriptor 部署描述符design level 设计层differential backup 差异备份disk array 磁盘阵列drag and drop 拖放dual interface 双重接口EEDI Electronic Data Interchange 电子商业文书交换标准EJB Emterprise JavaBeans 企业BeanSession EJB 会话EJBEntity EJB 实体EJBMessage Driven EJB 消息驱动EJB 处理实体EJB的持久性模式：BMP Bean_Managed Persistence Bean 管理持久性CMP Container_Managed Persistence 容器管理持久性E-R图Entity-Relationship Approach 实体-关系图ERM Employee Relationship Management 员工关系管理early binding 前期捆绑event handler 事件句柄event handling 事件处理FFA Functional Audit 功能检查FCA Functional Configuration Audit 功能配置审查FI Formal Inspection 正式检查FQR Formal Qualification Review 正式鉴定评审FTP File Transfer Protocol 文件传输协议filegroup backup 文件组备份full database backup 完全数据库备份GGNOME GNU Network Object Model EnvironmentGPL General Public License 通用公共许可协议Generative peogramming 生成式程序设计Generic programming 泛型程序设计HHB HandBook 手册HTML HyperText Markup Language 超文本标记语言HTTP HyperText Transfer Protocol 超文本传输协议HWCI HardWare Configuration Item 硬件配置项IID Identification Number 鉴别号IDD Interface Design Description 接口设计描述IDL Interface Description Language 接口描述语言IDE Integrated Development Environment 集成开发环境IIOP Internet Interoperability Protocol 基于Internet的ORB间协议IIS Internet Information Server 互联网信息服务器IL Intermediate Language 中间语言IMC Integrated Marketing Communication 整合营销信息渠道IRS Interface Requirements Specification 接口需求规格说明ISAPI Internet Server Application Programming Interface 互联网服务器应用程序设计接口ISP Internet Service Provider 互联网提供商IS&AC Installation and Acceptance phase 安装与验收阶段IT&ST Integrating and System Testing phase 组装与系统测试阶段IV&V Independent Verification and Validation 独立验证与确认independent uint testing 独立的单元测试information hiding 信息隐藏integrated security 集成安全iterative and incremental 迭代增量式interpreted language 解释语言JJAF Java Activation Framework Java启动框架java IDL java Interface Definition Language java接口定义语言java RMI java Remote Method Invocation java远程方法调用JDBC Java DataBase Connectivity Java数据库连接JIT Just-In-Time 实时JMAPI Java Management API Java管理应用编程接口JMS Java Message Service Java消息服务JNDI the Java Naming and Directory Interface Java命名和目录接口JNDI API（Application Programming interface 应用编程接口）JNDI SPI（Service Provider Interface 服务提供者接口）JPE Java Platform for the Enterprise 面向企业的java平台JSA Java Security API Java安全应用编程接口JSDK Java Servlet Development kit Java Servlet开发工具包JSP JavaServer Pages Java服务器网页JTS Java Transaction Service Java事务服务JVM Java Virtual Machine Java虚拟机KKPI Key Performance Indicators 关键运行指标LLDAP Lightweight Directory Access Protocol 轻量级目录存取服务协议late binding 后期捆绑location paths 位置路径log reader agent 事务日志读取代理MMDI Multiple document Interface 多文档界面MIDAS Multitier Distributed Application Services SuiteMMC Microsoft Management Console 微软控制台MSMQ Microsoft Message Queue Server 消息队列服务MTS Microsoft Transaction Server 事务处理服务器M/S Mobile/Servermanagement reviews 管理评审merge replication 合并式复制metrics management 度量管理middle ware 中间间mixed security 混合安全multi-dimensional array 多维数组Multi-Protocol Network Library 多协议网络库multiple inheritance 多重继承NNDS Non-Developmental Software 不可开发软件NSAPI Netscape Server Application Programming InterfaceNested conditions 嵌套条件Nested loops 嵌套循环Non-Functional requirement 非功能性需求notification message 通知消息OODBC Open Database Connectivity 开放数据库互连OLTP Online Transaction Processing 联机事务处理OMA Object Management Architecture 对象管理体系ORB Object Request Brober 对象请求代理OS Object Services 对象服务CE Common Facilites 通用设施AO Application Objects 应用对象OMG Object Management Group 对象管理组织OMT Object Modeling Technique 对象模型技术OOA Object Oriented Analysis 面向对象分析OOD Object Oriented Design 面向对象设计OOP Object Oriented Programming techniques 面向对象编程技术Encapsulation 封装Inheritance 继承Polymorphism 多态Oracle Data Migration Assistant Oracle 数据迁移助手Oracle Database Assistant Oracle 数据库助手Oracle Web Publishing Assistant Oracle Web 发布助手PPA Physical Audit 物理检查PCA Physical Configuration Audit 物理配置审查PCT Private Communication TechnologyPD Preliminary Design Phase 概要设计阶段PDD Preliminary Design document 概要设计文档PDR Preliminary Design Review 初步设计评审（概要设计评审）PDS 项目开发总结PIP 项目实施计划Perl Practical Extraction and Report LanguagePHP Hypertext Preprocessor 超文本预处理器(Tcx 公司)PM Project Manager 项目经理PME模型property,mrthod,event模型PRM Partner Relationship Management 伙伴关系管理PRR 阶段评审报表PRR Product Readiness Review 产品准备就绪评审PP&O Project Planning and Oversight 项目计划与监督PPP 项目进展报表PWS Personal Web ServerPass criteria 通过准则Pass-by-address 按地址传递Pass-by-value 按值传递Performance monitor 性能监视器Plug-in 外挂组件project entrust organization 项目委托单位project undertaking organization 项目承办单位QQA Quality Assure 软件质量保证quality assurance 质量保证RRA Requirements Analysis Phase 需求分析阶段RAID Redundant Array of Inexpensive Disks 廉价磁盘冗余阵列RDB Relation DataBase 关系数据库RDF Resource Definition Framework 资源定位架构RDO Remote Data Object 远程数据对象RM Relation Model 关系模型RMI Remote Method Invocation 远程方法调用（java）RMT 评审成员签字表RPC Remote Procedure Call 远程过程调用(C++)RPL Review Problem 评审问题记RS Requirement Specification 需求规范RSR Review Summary Report 评审总结报告RSA(加密法) 来自其创始者Ron Rivest、Adi Shamir和Leonard Adleman三人名字的缩写refactoring 重构reference count 引用计数regression testing framework 回归测试框架relative location 相对位置repeating patterns 样板重复Replication Conflict Resolution Tool 同步复制冲突分析工具run-time interpreter 实时解释器SSA System Analyst 系统分析员SA&D System Analysis and Design 系统分析和设计SA&SD System Analysis and software definition phase 系统分析与软件定义阶段SAX Simple API(Application Interface) for XML XML 简单应用程序接口SCL 源程序清单SCM Software Configuration Management 软件配置管理SCMP Software Configuration Management Plan 软件配置管理计划SDD Software Design document 软件设计文档（分成概要设计说明书[PDD]和详细设计说明书[DDD]）SDF Software Development File 软件开发文件SDI Simple document Interface 单文档界面SDL Software Development Library 软件开发库SDP Software Development Plan 软件开发计划SDR System Design Review 系统设计评审SEI Software Engineering Institute 软件工程学会SEPO Software Engineering Process Office 软件工程过程办公室SGML Standard Generalized Markup Language 标准通用标记语言SIDC Solution Integration Development Center 解决方案整合研发中心SMIL Synchronized Multimedia Integration Language 多媒体同步整合语SMS System Management Server 系统管理服务器SOAP Simple Object Access Protocol 简单对象存取协议SOW Statement of Work 工作说明SPR Software Problem Report 软件问题报告单SQA Software Quality Assurance 软件质量保证SQAP Software Quality Assurance Plan 软件质量保证计划SQL Structured Query Language 结构化查询语言SRR 软件需求评审SRR System Requirements Review 系统需求评审SRS Software Requirment Specification 软件需求规格说明SSDD System/Subsystem Design Description 系统/子系统设计描述SSL Secure Sockets LayerSSR Software Specification Review 软件规格说明评审SSS System/Subsystem Specification 系统/子系统规格说明STP 软件测试计划STR 软件测试报告STR Software Trouble Report 软件故障报告STSC Software Technoligy Support Center 软件技术支持中心STT Secure Transaction Technology SUM 用户手册SVD Software Version Description 软件版本描述SVG Scalable Vector Graphics 向量图形格式SV&VP Software Verification and Validation Plan 软件验证与确认计划SV&VR Software Verification and Validation Review 软件验证与确认评审SW_CMM SoftWare Capability Maturity Model 软件能力成熟度模型service component 服务组件service Provider Software 服务提供者软件simple message 简单消息single dimensional array 一维数组snapshot agent 同步处理代理snapshot replication 快照式复制software 软件software development organization 软件开发单位software feature 软件特性software item 软件项software life cycle 软件生存周期software verification and validation report 软件验证与确认报告standard security 标准安全synchronous message 同步消息TTA Technical Architecture 技术架构师TD Transport Department 运输署（交通部）TCP/IP Transmission Control Protocol/Internet Protocol 传输控制协议/网际协议TCP/IPSockets Network Library TCP/IP 套接字网络库TLD文件T ag Library Descriptor Files 标记库描述符文件TR Technical Report 技术报告TRR Test Readiness Review 测试准备就绪评审TSSD Total Software System Development phase 整个软件系统的开发阶段testing 测试test item 测试项thin client 瘦客户tightly bound system 紧密结合系统transaction control 事务控制transaction log backup 事务日志备份transactional replication 事务式复制UUAT User Acceptance Test 用户（验收）测试UCS Universal Character Set 世界通用字集，是ISO 颁布的10646号标准UDA Universal Data AccessUDF Unit Development Folder 单元开发文件夹UDP User Datagram ProtocolUDT Uniform Data Transfer 统一数据传输UML Unified Modeling Language 统一建模语言URI Uniform Resource Indentifier 统一资源标示码，internet 标准，记载于RFC 2396 URL Uniform Resource Locator 统一资源定位码URN Uniform Resource Name 统一资源名UT unit testing 单元测试UTF Unicode/UCS Transformation Format 统一码/通用字集变换格式unit test plan 单元测试方案user 用户user documentation 用户文档VVCL Visual Component LibraryVFI Visual Form Inheritance 可视化窗体继承validation 确认verification 验证WWAP Wireless Application Protocol 无线应用协议WBS Work Breakdown Structure 工作明细结构WFC Windows Foundation Classes Windows 基础类WWW World Wide Web 全球信息网服务W3C World Wide Web Consortium 全球信息网协会well-formed 格式完整white box testing 白箱测试ZXKMS XML Key Management SpecificationXACML eXtensible Access Control Markup LanguageSAML Security Assertions markup LanguageXML eXtensible Markup Language 可扩展标记语言（延伸标记语言）XML NameSpace XML 命名空间XLink XML Linking Language XML 连结语言XLL eXtensible Linking language 延伸链接语言XP eXtreme Programming 极端编程（极限编程）XPath XML Path Language XML 路径语言XPointer XML Pointer Language XML 指针语言XSL eXtensible Stylesheet Language 可扩展样式表语言XSLT eXtensible Stylesheet Language Transformations 可扩展样式表语言转换(结构转换)XSL-FO (格式化输出)WS-Security Web 服务安全性规范常用网络服务和它们对应的端口（TCP协议）：ECHO 7 回送（显示）收到的信息DISCARD 9 放弃收到的信息DAYTIME 13 产生目标机上的当地时间FTP 21 FTP协议端口Telnet 23 TELNET协议端口SMTP 25 发送邮件协议SMTP端口HTTP 80 WEB协议端口POP3 110 POP3邮件接收协议端口NNTP 119 网络新闻传输协议（新闻服务器）端口端口以16位数字表示，其范围在0∽65535之间。
(完整)软件工程专业英语编辑整理：尊敬的读者朋友们：这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（(完整)软件工程专业英语）的内容能够给您的工作和学习带来便利。
同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。
本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为(完整)软件工程专业英语的全部内容。
软件工程英语文档:Documents 软件工具：Software Tools 工具箱：Tool Box 集成工具：Integrated Tool 软件工程环境：Software Engineering Environment 传统：Conventional 经典：Classical 解空间:Solution Domain 问题空间：Problem Domain 清晰第一，效率第二Clarity the first，Efficiency the next。
设计先于编码Design before coding使程序的结构适合于问题的结构Make the program fit the problem开发伴随复用,开发为了复用Development with reuse, Development for reuse。
靠度量来管理：Management by Measurement软件度量学：Software Metrics 软件经济学：Software Economics 软件计划WHY软件分析WHAT软件实现HOW 软件生存周期过程的开发标准Standard for Developing Software Life Cycle Process 软件开发模型：Software Development Model 编码员：Coder 瀑布模型：Waterfall Model 快速原型模型：Rapid Prototype Model增量模型：Incremental Model 线性思维：Linear Thinking 演化模型:Evolutionary Model 螺旋模型：Spiral Model 对象：Object 类：Class 继承：Inheritance 聚集:Aggregation 消息：Message 面向对象＝对象Object+分类Classification+继承Inheritance+消息通信Communication with Messages 构件集成模型：Component Integration Model 转换模型：Transformational Model净室软件工程:Cleanroom Software Engineering 净室模型:Cleanroom Model 软件需求规格说明书：Software Requirement Specification ,SRS 分析模型：Analysis Model 便利的应用规约技术：Facilitated Application Specification Techniques ，FAST结构化语言:Structured Language 判定树:Decision Tree 基数：Cardinality 事件轨迹：Event Trace 对象－关系Object-Relationsship 结构化分析：SA(Structured Analysis）由顶向下，逐步细化Top-Down Stepwise Refinement 面向对象分析：Object—Oriented Analysis包含：Contains 临近：Is Next To 传到：Transmits to 来自:Acquires from 管理:Manages 控制:Controls 组成：Is Composed of 细化：Refinement 抽象：Abstraction 模块：Module 策略：Strategy 信息隐藏：Information Hiding 数据封装：Data Encapsulation 抽象数据类型：Abstract Data type模块化设计：Modular Design 分解：Decomposition 模块性：Modularity 单模块软件:Monolithic Software 模块独立性：Module Independence内聚：Cohesion 偶然性内聚：Coincidental Cohesion逻辑性内聚:Logical Cohesion 时间性内聚：Temporal Cohesion 过程性内聚: Procedural Cohesion通信性内聚: Communicational Cohesion顺序性内聚：Sequential Cohesion功能性内聚：Functional Cohesion非直接偶合:No Direct Coupling 数据偶合:Data Coupling 特征偶合：Stamp Coupling 控制偶合：Control Coupling 外部偶合：External Coupling 公共偶合:Common Coupling 内容偶合：Content Coupling 由底向上设计:Bottom—Up Design 自顶向下设计：Top—Down Design 正式复审:Formal Review 非正式复审：Informal Review 走查，排练：Walk—Through 会审：Inspection 映射：Mapping 传入路径：Afferent path 传出路径:Efferent path 变换中心:Transform Center 接受路径:Reception path 动作路径：Action path 事务中心：Transaction Center 分支分解：Factoring of Brandches瓮形：oval-shaped 一个模块的控制域：Scope of Control一个模块的作用域:Scope of Effect结构化程序设计：Structured Programming通心面程序：Bowl of Spaghetti 流程图：Flow Diagram 编码：Coding方框图：Block Diagram PDL (Pidgin）:Program Design Language伪代码:Pseudo Code JSD:Jackson System Development 对象建模技术:Object Modeling Technique基础设施:Infrastructure 控制线程：Thread of Control 保护者对象：Guardian Object 协议：protocol UML：Unified Modeling Language OMG:Object Management Group 统一方法：Unified Method 关联：Association 泛化：Generalization 依赖：Dependency 结点:Node 接口：Interface 包：Package 注释: Note 特化：Specialization 元元模型：Meta-Meta Model 用户模型:User Model 静态图：Static Diagram 动态图：Dynamic Diagram 用例视图:Use Case View 逻辑视图:Logical View 并发视图：Concurrent View 构件视图：Component View 实现模型视图：Implementation Model View 部署视图：Deployment View 航向：Navigability 重数:Multiplicity 共享聚集：Shared Aggregation 组合：Composition 泛化:Generalization 简单消息：Simple Message 同步消息：Synchronous Message 异步消息：Asynchronous Message 事件说明：Event_Signature 守卫条件：Guard_Condition 动作表达式:Action_Expression 发送子句:Send_Clause 时序图:Sequence Diagram 协作图：Collaboration Diagram 前缀:Predecessor 循环子句:Iteration-Clause 活动图：Activity Diagram 构件图：Component Diagram 配置图：Deployment Diagram 建模过程指导（RUP）：Rational Unified Process 可执行代码：Executalbe Codes 实现:Implementation 编码风格：Coding Style 标准：Classical 控制流的直线性：Linearity of Control Flow 程序风格设计要素：先求正确后求快Make it right before you make it faster. 先求清楚后求快Make it clear before you make it faster. 求快不忘保持程序正确Keep it right when you make it faster。
Software testing life cycle The trend of testing is changing and updating day by day. Testers are now learning and using more techniques. Testing is not just finding a few bugs and error in the software it has a more extensive range and scope. Testing is a process which we follow after the development of software to get ensure whether the software is bug-free or not.Software testing is the most critical process in the creation of the software life cycle. Testing also possesses its testing life cycle, so the need for the testing starts from the starting of theprojects. Software testing life cycle follows the same process steps involved in the software development life cycle.As we know before the development of any software, it follows the software development life cycle. In the same manner, the testing phase of software development also supports the software testing life cycle. In this article, we will study the software testing life cycle in- depth and you will get to know about every phase of software development life cycle accurately.Lifecycle: let’s understandSequences of changes from one to another known as a life cycle. These changes can happen at any phase of development. The software testing life cycle is almost similar to the software development life cycle. As we all know software development life cycle involves some steps in sequences. Testing also involves some steps that must be executed in a proper way. The purpose of software testing is the execution of testing activities in such a way so that it could make the software bug free. Hence we can say life cycle is a process of change that can occur at any instance of point in the process of anydevelopment. It is a planned way of executing the entities involved in the life cycleWhat is Software Testing Life Cycle and Why is Testing important?Before talking about the software testing life cycle now, we will talk about why testing is essential?Testing is quite important because with the help of testing we check the whole process and try to find out those potential which can break down the process of any activity.1-It detects the issues and errors that can arise during the software development life cycle. And helps to find out the mistake made by the programmer during the implementation of the software2-It helps to maintain the Quality of the product. If we provide a quality product, it will help us to gain customer confidence.3-Help to find out the bug that can stop the process of development. And we can fix them easily4-It’s essential to ens ure that there should be no failure after the application development Because it can increase the cost, in the future or the later stages of the event.Now we know about the testing and its benefits, let’s talk about the software testing life cycle.Software testing life cycle is a process that involves the execution of specific steps in such a systematic way so that it could give us the surety that after the complete implementation of the process it will provide us desired result. In the software testing life cycle, we make proper planning and precise execution for every activityso that it could perform its desired task. Software testing life cycle has many phases, and every phase has different goals and objective are set.Here are some phases involved in the software testing life cycleRequirement PhaseIn this phase of the software testing life cycle, we examine and study the need for the process. And we arrange a brainstorming session with the other team member and talk about the requirements involved in the whole process,whether they are examinable or not. The primary purpose of this phase is to find the scope of the testing, and if any entity can’t be tested, we take a backup for this situation and make some strategy so that we could overcome such situations.Planning PhasePractically, we can consider the planning phase as the first phase of software testing life cycle. In this phase, we find out the resources and activities, which help us to reach the desired goal. The planning phase is a way of identifying, gathering and tracking the metrics. Wheneverwe do the planning, we should care about all the resources involved in it and. With the help of this, we make a proper strategy for the rest of the process.The planning phase involves two essential factors.Test strategy Risk analysis and mitigationWhat is Test Strategy?Test Strategy means using available resources at one’s disposal and uses them in such a manner so that it could achieve the desired goaleffectively. Test strategy is part of the planning, and it ensures that how the testing objectives would be met adequately to the desired expectations.Here are some advantages of a practical test strategy are;It reduces the possibility of risks which may arise during the STLC.we can focus and analyze the different aspect of the system under the testwe can clear the clarity of the requirements such as people, procedures, tools and infrastructure.Risk analysisRisk analysis is a process of identifying those issues which can make a negative impact on the whole process of development. It could be related to any process either it is software testing life cycle or any business life cycle.With the help of risk analysis, we minimise or avoid the possibility of those events which can affect the whole process and cause an error. It is a process of preparing ourselves for thoseevents which can occur while the development or testing the software.organizations use risk analysis to prevent those events which can be harmful to the process. It helps to minimise the probability of failureBenefits of risk analysis1-Help to identify the overall impact of the risk on the whole process and provide exact details of issues that can arise at any instance of time during the process.2-Improve the overall process.3-Steps in the risk analysis processThere are few steps involved in the risk analysis are given belowConduct a risk management surveyFirst of all, we conduct the risk management survey, and we work on those potentials which can affect the whole body of the process. We talk about those potentials and make a backup plan for them.Identify the risks:After conducting the risk management survey now the second step is to identify the threat and its potential. Once the risk is identified, we move towards the next stepAnalyze the risksOnce the threat is identified we analyse what is kind of risk it is? And what issues it can arise in the whole process.Develop a risk management planafter examining the entire process we develop the risk management plan and work on it in sucha way so that it could be implemented during process failure.Implement the risk management planif we face any issues while the software testing life cycle we implement the backup plan which we made while the risk management processMonitor the risks:<p style="text-align:left"> After implementation, we keep tracking the potential which caused an error in the whole process and makes sure that issue or risk should not arise again.Analysis Phase:In this phase, we identify what could be tested in the software testing life cycle. And behalf of this we perform the analysis process.There are many things which affect the test conditions on behalf of its identification.Product/project risksThe complexity of the productLevels and depth of testingAvailability of the stakeholders.Software development life cycle involved.Test management Skills and knowledge of the team.Design Phase:This phase involves many tasks and defines how to test, the test conditions, and in this phase, we divide the test conditions into the sub-conditions by which we increase the coverage.Identify test data.Identify and create a test environment.Make the requirement traceability metrics.make the test coverage metrics.Implementation Phase:The implementation phase involves the creation of individual test cases. In this phase, we assign the priority level to the test cases and identify which test case will take part in the reversion suite. It is quite necessary to review the test case before finalizing it. And take the accomplishment of the test case before the actual implementation takes place. In case your project consist of automation, identify thecandidate test case for automation and then we should move further for proper scripting of the test case. But the thing is you must not forget to review them.Execution Phase:The execution of all entities in the process takes part in this phase. But the most important thing is before starting the performance make sure that every object is met. Implement the test cases, and simultaneously fill your traceability by which you could trace the whole process.Conclusion Phase:Finally, in this phase of the software testing life cycle, we perform the final process by reporting and making the database. It is necessary because its a requirement of your project and also it depends on stakeholders choice we create a report and ask the stakeholders whether they want monthly or daily reports. Making a report for every single phase and requirements is quite an important thing. In the conclusion phase, we estimate our expenses and review the whole process.Closure Phase:It is the ending phase of software testing life cycle by which ensure whether the expectations are met or not. As we can see software testing life cycle is similar to the software development life cycle, but it is a lit bit more complicated. It involves all the phases involved in any software development life cycle and provides the essential detail of the development.ConclusionNow with the help of this article, we can understand the process of the software testing life cycle and know about the details of every single phase which get involved in the process.The method of software testing life cycle is almost the same as the software development life cycle but with the cycles are essential for the development of any software. Hence we can say we can get the initial idea of the life cycle and its functionality by learning this topic.。
一、第1章软件工程概述1. Software deteriorates rather than wears out because(软件通常是变坏而不是磨损的原因是)A:Software suffers from exposure to hostile environments(软件暴露在不利的环境中)B:Defects are more likely to arise after software has been used often(软件错误更容易在使用后被发现)C:Multiple change requests introduce errors in component interactions(在组件交互中需求发生变化导致错误)D:Software spare parts become harder to order(软件的备用部分不易组织)2. Today the increased power of the personal computer has brought about an abandonment of the practice of team development of software.(如今个人电脑性能的提升导致遗弃了采用小组开发软件的方式。
)A:True（真）B:False （假）3. Which question no longer concerns the modern software engineer?（现如今的软件工程师不再考虑以下哪个问题？）A:Why does computer hardware cost so much?（计算机硬件为什么如此昂贵？）B:Why does software take a long time to finish?（软件为什么开发时间很长？）C:Why does it cost so much to develop a piece of software?（开发一项软件的开销为什么这么大？）D:Why cann't software errors be removed from products prior to delivery? （软件错误为什么不能在产品发布之前被找出？）4. In general software only succeeds if its behavior is consistent with the objectives of its designers.（通常意义上，只有表现得和设计目标一致的软件才是成功的软件。
常见的软件过程中的度量指标英文回答：Common Software Process Metrics.Software process metrics are quantitative measures of the characteristics of a software process. They are used to track progress, identify bottlenecks, and improve the quality of the process. Common software process metrics include:Time metrics: These metrics measure the amount of time it takes to complete a software process or activity. Examples of time metrics include:Cycle time: The time it takes from the start of a software process to the delivery of the final product.Lead time: The time it takes from the initial request for a software product to the delivery of the finalproduct.Defect detection time: The time it takes from the introduction of a defect into a software product to its detection.Cost metrics: These metrics measure the amount of money it costs to complete a software process or activity. Examples of cost metrics include:Total cost of ownership: The total cost of a software product over its entire lifetime, including development, maintenance, and support costs.Return on investment: The ratio of the benefits of a software product to the costs of developing and maintaining it.Quality metrics: These metrics measure the quality of a software product or process. Examples of quality metrics include:Defect density: The number of defects in a software product per unit of code.Mean time between failures: The average amount of time between failures of a software system.Customer satisfaction: The level of satisfaction of customers with a software product or process.Productivity metrics: These metrics measure the productivity of a software team or individual. Examples of productivity metrics include:Lines of code per day: The number of lines of code written by a developer per day.Story points completed per sprint: The number of story points completed by a team in a sprint.Process maturity metrics: These metrics measure the maturity of a software process. Examples of process maturity metrics include:Capability maturity model integration (CMMI) level: A measure of the maturity of a software process based onthe Capability Maturity Model Integration framework.ISO/IEC 27001 certification: A certification thata software process meets the requirements of the ISO/IEC 27001 information security standard.Software process metrics can be used to improve the quality and efficiency of software processes. By tracking these metrics, organizations can identify areas for improvement and make changes to their processes accordingly.中文回答：常见的软件过程度量指标。
软件开发⽤英语怎么说 软件开发是根据⽤户要求建造出软件系统或者系统中的软件部分的过程。
软件开发是⼀项包括需求捕捉、需求分析、设计、实现和测试的系统⼯程。
通常采⽤软件开发⼯具可以进⾏开发。
那么你知道软件开发⽤英语怎么说吗?下⾯来学习⼀下吧。
软件开发的英语说法1： software development 软件开发的英语说法2： software engineering 软件开发的相关： 软件开发⼯具 programming tool 软件开发⼯程师 Software Engineer 统⼀软件开发过程 The Unified Software Development Process 软件开发⽣命周期 Software Development Life Cycle 软件开发单位 software development unit 软件开发模型 Software Development Model 软件开发的英语例句： 1. Ah yes. I'm meeting the senior partners to discuss software development. 啊,是的. 我要见⼀些⾼级合伙⼈,讨论软件开发的问题. 2. How software testing fits into the software development process. 软件测试是怎样融合到软件开发流程的. 3. It analyzes the influences of object - oriented development technology to software metrics. 着重分析⾯向对象软件开发技术的发展对软件度量的影响. 4. Undertook software development projects for industrial and commercial organization. 承担⼯商企业的软件开发项⽬. 5. So , component composition become the direction of software development and reuse. 构件组装成了软件开发和复⽤的必然趋势. 6. The software involves database, GIS, and man machine interface. 软件开发涉及数据库、地理信息(GIS) 、⼈机交互界⾯三部分. 7. Paul Allen joins MITS as director of Software Development. 保罗·艾伦成为MITS的软件开发主任. 8. Products: Computer software development and related consulting services Computerconsulting services. 经营范围: 计算机软件开发及其相关咨询服务. 9. CAMCTO is a rapid application development tool for engineering. CAMCTO是⼀款适⽤于⼯程学的⾼速应⽤软件开发⼯具. 10. What is the best feature of the big - bang model of software development? 软件开发中的“⼤爆炸”模型,最值得称道的地⽅是什么? 11. Knowledge of the Agile Software Development process is also a plus. 以及对Agile软件开发过程的认知. 12. However, almost all of the embedded software development using C language. 不过, ⼏乎所有的嵌⼊式软件开发都使⽤了C语⾔. 13. Software developers mostly focus on the research of the software development framework. 软件开发框架的研究⼀直是软件开发者关注的课题. 14. What major challenge is the component approach to system development addressing? 组件式软件开发⽅法欲解决软件开发上的哪些挑战或难题呢 ? 15. The increasing scale and complexity of software challenges software development dramatically. 软件的规模和复杂度不断增加,使得软件开发⾯临巨⼤挑战.。
J OURNAL OF O BJECT T ECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2006Vol. 6, No. 1, January-February 2006 Software Design Metrics for Object-Oriented SoftwareK.K.Aggarwal, Yogesh Singh, Arvinder Kaur and Ruchika MalhotraUniversity School of Information Technology, Guru Gobind Singh IndraprasthaUniversity, Kashmere Gate, Delhi 110006, IndiaAbstractThe importance of software measurement is increasing leading to development of newmeasurement techniques. As the development of object-oriented software is rising,more and more metrics are being defined for object-oriented languages. Many metricshave been proposed related to various object-oriented constructs like class, coupling,cohesion, inheritance, information hiding and polymorphism. The applicability of metricsdeveloped by previous researchers is mostly limited to requirement, design and implementation phase. Exception handling is a desirable feature of software that leadsto robust design and must be measured. This research addresses this need and introduces a new set of design metrics for object-oriented code. Two metrics are developed that measure the amount of robustness included in the code. The metrics areanalytically evaluated against Weyuker’s proposed set of nine axioms. These set ofmetrics are calculated and analyzed for standard projects and accordingly ways inwhich project managers can utilize these metrics are suggested.1 INTRODUCTIONPrograms fail mainly for two reasons: logic errors in the code and exception failures. Exception failures occur when a program is prevented by unexpected circumstances from providing its specified service. Exception failures can account for up to two-thirds of system crashes [Cristian95]; hence, are worthy of serious attention. On 4th June 1996, maiden flight 501 of the European Space Agency's new Ariane 5 heavy-lift rocket, developed at a cost of $7000 M over a 10 year period, ended in failure, after 39 seconds of its launch [Aggarwal01, Maxion98]. The problem was identified as a software exception caused during execution of a data conversion from 64-bit floating point to 16-bit format; the number was too big, so that an overflow error resulted after 36.7 seconds. This resulted in an operand error. The data conversion instructions were not protected from causing an operand error. No justification was found for not making the software robust.Cite this article as follows: K.K.Aggarwal, Yogesh Singh, Arvinder Kaur, Ruchika Malhotra,: “Software Design Metrics for Object-Oriented Software”, in Journal of Object Technology, vol. 6. no. 1, January-February, pp. 121-138 http://www.jot.fm/issues/issue_2007_01/article4SOFTWARE DESIGN METRICS FOR OBJECT-ORIENTED SOFTWARE Software is robust if it behaves “reasonably”, even in circumstances that were not anticipated in the requirement specification-for example, when it encounters incorrect input data or some hardware malfunction (say a disk crash). A program that assumes perfect input and generates an unrecoverable run-time error as soon as the user inadvertently types an incorrect command would not be robust. It might be correct, though, if the requirement specification does not state what the action should be upon entry of an incorrect command. It implies that software should be capable of diagnosing certain classes of errors. Robust design dictates error conditions to be anticipated and error-handling paths to be set up to re-route or cleanly terminate processing, when an error does occur. This is achieved after using exception-handling mechanism. A number of metrics have been proposed by researchers [Braind98, Briand99, Lorenz94, Harrison98, Chidamber94, Chhabra04], which measure the desirable characteristics of software. Exception handling is also a desirable software feature that leads to robust design and must be measured. A set of metrics has been proposed in this paper, to measure the robustness of design. The metrics are proposed, analyzed and evaluated on sample data set. The effect of using error handling functions in place of exception handling mechanism is also studied.The paper is organized into following sections: Section 2 gives introduction to exception handling. Section 3 gives overview of proposed software metrics and formally defines them. Section 4 introduces various techniques available to find number of possible exceptions. Section 5 states Weyuker’s properties and evaluates the metrics on these properties. A brief description of the sources from which the empirical data is collected and then analysis of metrics based on this data has been done in section 6. The discussion of work carried is presented in section 7.2 EXCEPTION HANDLING FUNDAMENTALSExceptional conditions are any unexpected occurrences that are not accounted for in a system's normal operation. Many different types of conditions can cause exceptions, depending on the specific program under consideration. Examples of such conditions include trying to divide by zero, stack overflow/underflow, array index out of bound, illegal use of null pointer reference, type mismatch, wrong command-line argument, security violation, and invalid data returned from another program. Failure due to exceptional conditions is a serious problem, not only in mission-critical applications, but also in commercial software systems and custom, home-developed code where quick, accurate results are essential. Programs are often logically correct but, nevertheless, fail due to mishandled exceptions. Some sort of error handling mechanism can be used to deal with such exceptional conditions. Error handling mechanism helps in constructing a robust system and reduces the cost to failure. In OO languages such as C++ and Java, this error handling mechanism is called exception handling. In computer languages that do not support exception handling, errors must be checked and handled manually through error codes, which is quite troublesome and cumbersome process. Exception handling is 122J OURNAL OF O BJECT T ECHNOLOGY V OL.6, NO.1the method of building a system to detect and recover from exceptional conditions. Reducing the occurrence of exception failure is beneficial for several reasons:1.Software would be more robust, resulting in lower operating cost and higheravailability.2. A substantial percentage of security vulnerabilities would be removed. Thecomputer security community has observed common mechanisms (e.g., buffer overflow) that cause exceptions and security vulnerabilities simultaneously and claim that eliminating exception failures would remove about 50 percent of security vulnerabilities [Maxion00].Exception Handling Model in Java and C++ consists of three constructs [Venugopal97]:Try: The block of code in which the exception can occur is specified in try block. There can be nested try blocks.Catch: In catch block, the action to be taken if any exception occurs is specified. In some cases, more than one exception can be raised by a single piece of code. In such cases more than one catch block can be specified. Each catch clause catches a different type of exception.Throw: It is used to manually raise an exception. The innermost try block in which the exception is raised is used to select the catch block that specify action to be taken when the exception occurs.Java adds two more constructs finally and throws:Throws: An exception thrown out of a method is specified by throws.Finally: It contains code that must be executed before a method return.Syntax of Try and Catch block is as follows:try {. . .} catch ( . . . ) {. . .} catch ( . . . ) {. . .} . . .Java defines several exception classes and also allows the programmer to create new exception classes to handle situations specific to particular application. Exceptions can be generated by runtime system or they can be manually generated by the code [Schildt01].Some popular runtime exceptions are: arithmetic error e.g., divides by zero, array index out of bound, assignment of an array element of incompatible type, creation of an array with negative index, invalid use of null reference etc. Exceptions generated manually can be invalid range of an input variable, incorrect date format and so on. These exceptions can be specific to an application.V OL.6, NO.1 J OURNAL OF O BJECT T ECHNOLOGY123SOFTWARE DESIGN METRICS FOR OBJECT-ORIENTED SOFTWARE124J OURNAL OF O BJECT T ECHNOLOGY V OL.6, NO.1V OL.6, NO.1 J OURNAL OF O BJECT T ECHNOLOGY125SOFTWARE DESIGN METRICS FOR OBJECT-ORIENTED SOFTWARE126J OURNAL OF O BJECT T ECHNOLOGY V OL.6, NO.1V OL.6, NO.1 J OURNAL OF O BJECT T ECHNOLOGY127SOFTWARE DESIGN METRICS FOR OBJECT-ORIENTED SOFTWARE128J OURNAL OF O BJECT T ECHNOLOGY V OL.6, NO.1V OL . 6, NO . 1 J OURNAL OF O BJECT T ECHNOLOGY 129correspond to notions about the differences between the software artifacts being measured [Basili79]. However, most recommended properties tend to be informal in evaluation of metrics. It is always desirable to have a formal set of criteria with which the proposed metrics can be evaluated. Weyuker has developed a formal list of properties for software metrics and has evaluated number of existing software metrics against these properties [Weyuker98]. Although many authors have criticized [Zuse90, Fenton91] this approach but still it is a widely known formal analytical approach and have been referred by many notable authors for evaluating their measures [Henderson96, Chidamber94]. The similar approach has been followed in this paper for analysis of proposed metrics.Weyuker’s (1988) first four properties address how sensitive and discriminative the metric is. The fifth property requires that if two classes are combined their metric value should be greater than metric value of each individual class. The sixth property addresses the interaction between two programs/classes. It implies that interaction between program/class A and program/class B is different than interaction between program/class C and program/class B given that interaction between program/class A and program/class C is same. The seventh property requires that a measure be sensitive to statement order within a program/class. The eighth property requires that renaming of variables does not affect the value of a measure. Last property states that the sum of the metric values of a program/class could be less than the metric value of the program/class when considered as a whole [Henderson96].Let u be metric of program/class P and Q Property 1: This property states that))()()((),(Q u P u Q P ≠∃∃ It ensures that no measure rates all program/class to be of same metric value.Property 2: Let c be a nonnegative number. Then there are finite numbers of program/class with metric c . This property ensures that there is sufficient resolution in the measurement scale to be useful.Property 3: There are distinct program/class P and Q such that )()(Q u P u =.Property 4: For object-oriented system, two program/class having the same functionality could have different values.()()(()())∃∃≡≠P Q P Q u P u Q and Property 5: When two program/class are concatenated, their metric should be greater than the metrics of each of the parts.()()()()()())∀∀≤+≤+P Q u P u P Q u Q u P Q ( and Property 6: This property suggests non-equivalence of interaction. If there are two program/class bodies of equal metric value which, when separately concatenated to a same third program/class, yield program/class of different metric value. For program/class P , Q , R()()()(()()()())∃∃∃=+≠+P Q R u P u Q u P R u Q R and Property 7: This property is not applicable for object-oriented metrics [Chidamber94].SOFTWARE DESIGN METRICS FOR OBJECT-ORIENTED SOFTWARE130 J OURNAL OF O BJECT T ECHNOLOGY V OL . 6, NO . 1Property 8: It specifies that “if P is a renaming of Q ; then )()(Q u P u =”Property 9: This property is not applicable for object-oriented metrics [Chidamber94]. Axiomatic Evaluation of NCBC on Weyuker’s PropertiesProperty 1 is satisfied by the proposed metric as two object-oriented classes P and Q can always differ in catch block count. Let n P =)(μ then there are finite numbers of class with metric value n ensuring sufficient resolution. Thus Property 2 is also satisfied. There is probability (non zero) that )()(Q u P u =. Therefore Property 3 is satisfied. The decision of implementing catch blocks in methods per class is totally independent of functionality i.e. logic used in the class. This satisfies Property 4. Let p P u =)(and q Q u =)(. Then m q p Q P u −+=+)(, where m is the catch blocks common to a class. In some cases.)()()()(Q P u Q u Q P u P u +≥+≥ This does not satisfies Property 5. Now, Let p P u =)(and p Q u =)(, and a class R has number of catch blocks r such that it has m catch blocks common with class P and n common with Q , where n m ≠.nr p R Q u mr p R P u −+=+−+=+)()(This shows that )()(R Q u R P u +≠+ and Property 6 is satisfied. The renaming of class or method does not affect the value of metric proposed hence satisfying Property 8. Axiomatic Evaluation of EHF on Weyuker’s PropertiesLet )(P u and )(Q u be metric of Program P and Q .Property 1 is satisfied by the proposed metric, as two object-oriented program can always differ in exception value. There can be many different values of the proposed metric. This satisfies Property 2. The proposed metric also satisfies Property 3. It is assumed that classes are not dependent on each other in system P , then the metric of P will be nothing but the summation of exception classes, which can be same for another different unrelated system Q . The choice of exception classes is design decisions, which does not depend upon the functionality of software, therefore Property 4 is satisfied.Let p P u =)(and q Q u =)(. Thenm q p Q P u −+=+)(.Let y and b be total number of possible exception classes in program P and program Q .Let x and a be number of exception classes in program P and program Q then,)/()()(/)(/)(b y a x Q P u b a Q u y x P u ++=+== and where x + a is the number of exception classes combined by concatenating program P and program Q .y + b is the number of possible exception classes combined by concatenatingprogram P and program Q .Thus, it is possible that, )()(Q P u P u +≥ or )()( Q P Q u +≥Therefore, Property 5 is not satisfied. Now, let P and Q be two programs such thatp Q u P u ==)( )(and let R be another program with EHF value r R u =)(. Then, n r p R Q u m r p Q P u −+=+−+=+)(similarly ,)(. This shows that )()(R Q u R P u +≠+. Therefore, Property 6 is satisfied. The renaming of systems P and Q does not affect the metric values. Hence, Property 8 is satisfied.Thus all properties except 5 are satisfied by both metrics. The property 5 is notsatisfied by many earlier metrics like DIT of Chidamber and Kemerer [Chidamber94]. 6 ANALYSIS OF METRICS ON EMPIRICAL DATA To analyze proposed metrics their values are computed for five different projects out of which case studies and design of three projects are presented in book “Introduction to Object-Oriented Analysis and Design” and “Object-Oriented and Classical Software Engineering”, authored by S.R. Schach. Their respective codes are available on Internet at [Schach02, Schach04]. The projects are developed in Java language and will be referred herein after as Project 1, Project 2, and Project 3. The proposed metrics is also applied on another project referred here as Project 4. Project 4 enables intranet users to book holidays and uses Java programming for developing the system. Project 5 is same version of Project 1 but uses validation functions instead of exception handling in some cases whereas in other cases probable faults are not covered by the code.Analysis of Metric NCBC on Collected DataThe summary statistics and histogram for Project 1 to Project 4 are shown below. To indicate the metric value the histograms of the NCBC value are given. The percentages of classes are shown on Y-axis. In the first column of Figure 4(a) the classes for which the NCBC value was 0 percent is shown. The other columns indicate the classes for which metric NCBC equal to 37, 57, 71, 89 and 100 percent respectively.(b)(a)(d)(c)Figure 4: Number of Catch Blocks per Class for (a) Project 1 (b) Project 2 (c) Project 3 (d) Project 4Figure 6: Percentage increases in LOC in Project 5Figure 7: Bar Chart of Exception Handling Factor Metric Min MaxREFERENCES[Aggarwal01] K.K Aggarwal, Yogesh Singh, Software Engineering. New Age International, Publishers, 2001.[Basili79] V.Basili, R.Reiter. Evaluating Automable Measures of Software Models.IEEE, Workshop on Quantitative Software Models, 107-116, 1979.[Briand98] L.Briand, W.Daly and J. Wust, Unified Framework for Cohesion Measurement in Object-Oriented Systems. Empirical Software Engineering,3, pp. 65-117, 1998.[Briand99] L.Briand , W.Daly and J. Wust, A Unified Framework for Coupling Measurement in Object-Oriented Systems. IEEE Transactions on softwareEngineering, 25, pp.91-121, 1999.[Chidamber94] S.R.Chidamber and C.F.Kamerer, A metrics Suite for Object-Oriented Design. IEEE Trans. Software Engineering, vol. SE-20, no.6, 476-493, 1994. [Cristian95] F. Cristian, Exception Handling and Tolerance of Software Faults, Software Fault Tolerance, M. R. Lyu, ed., Wiley, Chichester, pp.81-107, 1995. [Fenton96] N.Fenton et al, Software Metrics: A Rigorous and practical approach.International Thomson Computer Press, 1996.[Harrison98] R.Harrison, S.J.Counsell, and R.V.Nithi, An Evaluation of MOOD set of Object Oriented Software Metrics. IEEE Trans. Software Engineering, vol.SE-24, no.6, pp. 491-496, June 1998.[Henderson96] B.Henderson-sellers, Object-Oriented Metrics, Measures of Complexity.Prentice Hall, 1996.[Jitender04] Jitender Kumar Chhabra, K. K. Aggarwal and Yogesh Singh, Measurement of, object-oriented software spatial complexity. Information and SoftwareTechnology, Volume 46, Issue 10(2004) 689-699[Lorenz94] M.Lorenz, and J.Kidd, Object-Oriented Software Metrics. Prentice-Hall, 1994.[Maxion00] R. A. Maxion and R. T. Olszewski, Eliminating Exception Handling Errors with Dependability Cases: A Comparative, Empirical Study. IEEETransactions on Software Engineering, vol. 26, no. 9, pp.888-906, 2000. [Maxion98] R. A. Maxion and R. T. Olszewski, “Improving Software Robustness With dependability cases”, Twenty-Eighth Annual International Symposium onFault-Tolerant Computing, pp.346-355, June 1998.[Pressman01] R.Pressman, Software Engineering. McGraw-Hill, Boston, 2001.。
