PMBOK项目管理知识体系中英文第六版PDF高清电子书，两个版本均带目录，含如何配置Adobe Reader记录上次阅读位置

软件体系结构原理、方法与实践（第2版）.张友生(带书签文字版).pdf

本资源为软件过程管理部分题答案，自己看书做的，若有其他理解可以交流
(2)项目定义软件过程(3)对定义好的过程进行审核,不符合标准则继续裁剪(4)应用和监控项目定义软件过程的实施3.PSP分为哪4个等级?对各个等级进行简单说明。个体度量过程PSP0:PSPO的目的是建立个体过程基线,通过这一步,学会使用PSP的各种表格采集过程的有关数据,此时执行的是该软件开发单位的当前过程,通常包括计划、开发(包括设计、编码编译和测试)以及后置处理三个阶段,并要作一些必要的试题,如测定软件开发时间,按照选定的缺陷类型标准、度量引入的缺陷个数和排除的缺陷个数等,用作为测量在PSP的过程中进步的基准个体规划过程PSP1PSP1的重点是个体计划,引入了基于估计的计划方法 PROBE( PROXy Based Estimating),用自己的历史数据来预测新程序的大小和需要的开发时间,并使用线性回归方法计算估计参数,确定置信区间以评价预测的可信程度。个体质量管理过程PsP2PSP2的重点是个体质量管理,根据稈序的缺陷善建立检测表,按照检测表诖行设计复查和代码复查(有时也称"代码走查"),以便及早发现缺陷,使修复缺陷的代价最小。随着个人经验和技术的积累,还应学会怎样改进检测表以适应自己的要求。个体循环过程PSP3PSP3的目标是把个体开发小程序所能达到的生产效率和生产质量,延仲到大型程序;其方法是采用螺旋式上升过程,即迭代增量式开发方法,首先把大型程序分解成小的模块,然后对每个模块按照PSP2.1所描述的过程进行开发,最后把这些模块逐步集成为完的软件产4.简要说明TSP的工作流程。TSP工作通常将工作划分为多个周期,没一个周期都是包含一套完整的需求、设计、实现和测试的开发过程(1)策略和计划:1.确定策略标准。2.概念设计。3估计规模和时间。4风殓估计。5.策略归档。2)需求:1.与客户沟通。2需求评审。3制定需求规格说明书。(3)设计和实现(4)测试和后期维护:1测试。2跟踪和度量测试情况。3后期维护分析缺陷评价质量。P99页:4请简要说明需求变更控制的流程和注意事项。需求变更控制的流程需求变更时,要提出变更申请,还要由CCB进行评估,评估的内容包括需求的重要性、时间和资金等。评估之后要做出通过与否的决定。如果CCB确认提交的变更请求,则将指派某个人对原来的需求进行修改,并对其进行验证最终才实施该需求的变更注意事项a.项目启动阶段的变更预防:重视需求分析和定义,前期需求开发越充分,项目后期的需求变更就越少b.项目实施阶段的需求变更:需求一定要与投入有联系,小的需求变更也要经过正规的需求管理流程,精确的需求与范围定义并不会阻止需求变更,注意沟通的技巧。项目收尾阶段的总结第六章2.简述成本的基本估算方法成本估算最主要的是对直接成本进行估算。同时为了有效的控制风险,除了给出预算的成本之外,还可以适当给出成本的浮动范围。经验估算法:进行估算的人应有专门的知识和丰富的经验,据此提出一个近似的数字。这种方法是一种罪原始的方法,还称不上估算,只是一种近似的猜测。它对要求很快拿出个大概的数字的项目是可以的,但对要求详细的估算显然是不能满足需求的。比例法:比例法是比较科学的一种传统估算方法,它以过去的项目为参考来预算目前的项目成本。工作分解结构表WBS全面计算:WBS是一种比较准确的一种成本估算方法。WBS估算要求先把项目任务进行合理的划分,分到可以确认的程度,如某种材料,某种设备和某一活动单元等,然后估算每个WBS要素的费用。Wbs成本估算又分为自上而下和自下而上两种估算方法。3.资源管理的主要内容包括哪些?资源管理是项目管理中非常重要的一环。而资源管理主要分为两个部分,人力资源管理和软硬件资源管理。人力资源管理是要在对项目目标、规划、任务、走展情况以及各种內外因变量进行合理、有序的分析、规划和统筹的基础上,采用科学的方法,对项目过程的所有人员予以有效的协调、控制和管理。项目人力资源管理可以理解为对人力资源的获取,培训、保留和使用等方面所进行的计划、组织、指挥和控制活动,主要内容有项目组织规划建立项日组织和组织建设3个方面软硬件资源管理是在项目管理中,一直强调着人力资源管理的重要性。但是,硬件、软件的管理和支持也不可忽视。网络故儫或服务器的崩溃就可能导致整个项目停滞不前,而缺少项目所需的软件也同样可能导致整个项目的失败。所以分别需要硬件资源、软件资源的分别管理。第七章2.有哪些指标可以用来测量软件过程质量?缺陷发现率:是指缺陷发现的频率,通用的计量单位有bug/ KLOC KLOC是指千行代码而bug/KLOC的意思是每干行代码平均产生的缺陷数量。这个数据不仅可以用来衡量产品的质量,也可以用来衡量过程的质量。实际上,产品的质量越差,缺陷率越高。而过程质量则恰恰相反,质量越差,缺陷率越低。因此当统计的缺陷发现率较低时,需要从多方面考虑原因,可能是产品质量很好以致很难发现产品中的缺陷,从而造成缺陷率偏低。也可能是因为工作的方法和策略不当,造成不能发现产品中的缺陷。质量成本:这是产品成本的一部分。它的定义是将产品质量保持在规定的水平上所需的费用。它包括预防成本、鉴定成本、内部损失成本和外部损失成本等。过程缺陷密度:它是一种度量标准,可以用来判定过程产品的质量以及检验过程的执行程度。DPF可以表示如下:D|PF=Dn/Sp其中Dn是被发现的缺陷数,Sp是指被测试的软件产品规模缺陷到达模式:产品的缺陷密度、或者测试阶段的缺陷率是一个概括性指标,缺陷到达模武可以提供更多的过程信息。一方面可以用于整个软件开发周期或某个特定的开发阶段,另一方面,缺陷到达模式还可以扩展到对于修正的和关闭的缺陷,可以获取有关开发工作人员工作效率、缺陷修正进程和质量进程等方面的信息。第八章1将项目过程的集成管理和产品集成的过程管理进行对比,找出他们的共同点和不同点。项目过程集成管理焦点在于组织单元之间关系的协调和处理,产品集成管理焦点在于产品构件接口标准、约定和验证。相同点:1都需要制定集成管理的管理规范.过程2:需要制定一个过程计划3:根据需求者,利益者的要求,设计相关需求文档4:任务和进度都要按照过程计划进行,安排5:要每日的识别、跟踪和解决问题,持续集成不同点:1产品过程管理需要符合国内或国际标准的接口规范设计规格2产品过程管理要接口先行设计3产品过程集成管理需要项目必须按照组织标准软件过程来制定项目计划4项目过程集成需要协调各相关利益者的关系5项目过程集成有其他必要的项目管理内容,技术活动3举一个例子,如何运用|PD提高产品集成的质量。华为是国内第一家引进和实施PD的公司,也是受益最大的国内全业。华为的PD可以分为两个大的阶段,这两个阶段的效果有明显差别;在BM为华为提|D咨询后,华为的|PD取得了巨大成功。华为的|PD主要由以下几个部分组成。固化的结构化研发流程,支持流程实施的跨部门团队以前华为的产品开发完全是研发部门的事情,技术方向由关键人物来迒择。在PD模式下,各部门都要有人参与到规划和实施的过程里,组成跨部门的团队,PMT与PDT(PT)。跨部门的团队基本上要在产品开发之前做出相关联的规划,并且在品开发的过程中相互协调,以保证这个产品从始至终都是技术领先、成本合理并且符合市场需求。华为共有约一百多个产品线,类似的产品线再一起组成一个大的产品线。每个大的研发产品线都有一个PMT,他们是由总监级(现在改为产品线总裁)或者资深的产品专家组成,负责对旗下各个产品线的研发活动作关键环节(立项评估,计划决策,实验局评估等)的监控和评估。监控和评估的主要依据就是看这个产品研发成本投入和未来市场效益的比较,以及技术、资金、人力等方面的可行性。决策评审点。决策评审点实际上是一种喇叭口的结构。也就是通过仔细的调查、研究和分析之后筛选出最有潜力的项目,并且在“动手"之前尽可能地诖行瞄准"和计算“提前量"。使得最后进入开发阶段的项目都是最健康和最明确的。应该说这种研发管道管理,是华为在以前最欠缺的。异步开发模式。|PD在开发过程中为华为第一次引进了“异步开发"的概念。这种流程实际上很好地使用了并行工程的思想,它比华为原来串行研发流程的效率要高很多。

This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process, and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply.
A Philosophy of Software Designby john OusterhoutCopyright o 2018 John K OusterhoutAll rights reserved. No part of this book may be reproduced, in any form or by any means, withoutpermission in writing from the author.Published by yaknyam Press, Palo alto, CACoverdesignbyPeteNguyenandShirinoReizy(www.hellonextstep.com)Printing History:April 2018First Edition(v1.0)November 2018: First Edition(v1.01)ISBN978-1-7321022-0-0Digital book(s)(epub and mobi) produced by Booknook bizContentsPreface1 Introduction1. 1 How to use this book2 The Nature of Complexity2. 1 Complexity defined2.2 Symptoms of complexity2.3 Causes of complexity2.4 Complexity is incremental2.5 Conclusion3 Working Code Isnt Enoug3.1 Tactical programming3.2 Strategic programming3.3 How much to invest?3.4 Startups and investment3.5 Conclusion4 Modules Should Be Deep4. 1 Modular design4.2 What's in an interface?4.3 Abstractions4.4 Deep modules4.5 Shallow modules4.6 Classitis4.7 Examples: Java and Unix 1/O4.8 Conclusion5 Information Hiding(and Leakage)Information hiding5.2 Information leakage5.3 Temporal decomposition5.4 Example Http server5.5 Example: too many classes5.6 Example Http parameter handling5.7 Example defaults in Http responses5.8 Information hiding within a class5.9 Taking it too far5.10 Conclusion6 General-Purpose Modules are Deeper6. 1 Make classes somewhat general-purpose6.2 Example: storing text for an editor6.3 A more general-purpose API6.4 Generality leads to better information hiding6.5 Questions to ask yourself6.6 Conclusion7 Different Layer. Different Abstraction7.1 Pass-through methods7.2 When is interface duplication OK?7.3 Decorators7.4 Interface versus implementation7.5 PaSs-through variables7. 6 Conclusion8 Pull Complexity Downwards8.Example: editor text class8.2 Example: configuration parameters34Taking it too far8Conclusion9 Better Together Or Better Apart?9.1 Bring together if information is shared9.2 Bring together if it will simplify the interface9.3 Bring together to eliminate duplication9.4 Separate general-purpose and special-purpose code9.5 Example: insertion cursor and selection9.6 Example: separate class for logging9.7 Example: editor undo mechanism9.8 Splitting and joining methods9.9 Conclusion10 Define errors out of existence10. 1 Why exceptions add complexity10.2 Too many exceptions10.3 Define errors out of existence10.4 Example: file deletion in Windows10.5 Example: Java substring method10.6 Mask exceptions10.7 Exception aggregation10.8 Just crash?10.9 Design special cases out of existence10.10 Taking it too far10.11 Conclusion11 Design it Twice12 Why Write Comments? The Four Excuses12. 1 Good code is self-documenting12. i don 't have time to write comments12.3 Comments get out of date and become misleading12.4 All the comments i have seen are worthless12.5 Benefits of well-written comments13 Comments Should Describe Things that Arent Obvious from the Code13.1 Pick conventions13.2 Don t repeat the code13. 3 Lower-level comments add precision13.4 Higher-level comments enhance intuition13.5 Interface documentation13.6 Implementation comments: what and why, not how13.7 Cross-module design decisions13. 8 Conclusion13.9 Answers to questions from Section 13.514 Choosing names14.1 Example: bad names cause bugs14.2 Create an image14.3 Names should be precise4. Use names consistently14.5 A different opinion Go style guide14.6 Conclusion15 Write The Comments first15. 1 Delayed comments are bad comments15.2 Write the comments first15.3 Comments are a design tool15.4 Early comments are fun comments15.5 Are early comments expensive?15.6 Conclusion16 Modifying Existing Code16.1 Stay strategic16.2 Maintaining comments: keep the comments near the code16.3 Comments belong in the code, not the commit log16.4 Maintaining comments: avoid duplication16.5 Maintaining comments: check the diffs16.6 Higher-level comments are easier to maintain17 Consistency17.1 Examples of consistency17.2 Ensuring consistency17.3 Taking it too far17.4 Conclusion1 8 Code should be obvious18.1 Things that make code more obvious18.2 Things that make code less obvious18.3 Conclusion19 Software Trends19.1 Object-oriented programming and inheritance19.2 Agile development19.3 Unit tests19.4 Test-driven development19.5 Design patterns19.6 Getters and setters19. 7 Conclusion20 Designing for performance20. 1 How to think about performance20.2 Measure before modifying20.3 Design around the critical path20.4 An example: RAMCloud buffers20.5 Conclusion21 ConclusionIndexSummary of Design PrinciplesSummary of red FlagsPrefacePeople have been writing programs for electronic computers for more than 80years, but there has been surprisingly little conversation about how to designthose programs or what good programs should look like. There has beenconsiderable discussion about software development processes such as agiledevelopment and about development tools such as debuggers, version controlsystems, and test coverage tools. There has also been extensive analysis ofprogramming techniques such as object-oriented programming and functionalprogramming, and of design patterns and algorithms. All of these discussionshave been valuable, but the core problem of software design is still largelyuntouched. David Parnas classic paper "On the Criteria to be used inDecomposing Systems into Modules" appeared in 1971, but the state of the art insoftware design has not progressed much beyond that paper in the ensuing 45yearsThe most fundamental problem in computer science is problemdecomposition: how to take a complex problem and divide it up into pieces thatcan be solved independently. problem decomposition is the central design taskthat programmers face every day, and yet, other than the work described here, Ihave not been able to identify a single class in any university where problemdecomposition is a central topic. We teach for loops and object-orientedprogramming, but not software designIn addition, there is a huge variation in quality and productivity amongprogrammers, but we have made little attempt to understand what makes the bestprogrammers so much better or to teach those skills in our classes. I have talkedwith several people i consider to be great programmers, but most of them haddifficulty articulating specific techniques that give them their advantage. Manypeople assume that software design skill is an innate talent that cannot be taughtHowever, there is quite a bit of scientific evidence that outstanding performancein many fields is related more to high-quality practice than innate ability(see, forexample, Talent is Overrated by geoff colvin)For many years these issues have perplexed and frustrated me. I havewondered whether software design can be taught, and I have hypothesized thatdesign skill is what separates great programmers from average ones. I finallydecided that the only way to answer these questions was to attempt to teach acourse on software design. The result is cs 190 at Stanford University. In thisclass i put forth a set of principles of software design. Students then workhrough a series of projects to assimilate and practice the principles. The class istaught in a fashion similar to a traditional english writing class In an englishclass, students use an iterative process where they write a draft, get feedback, andthen rewrite to make improvements. In CS 190, students develop a substantialpiece of software from scratch. We then go through extensive code reviews toidentify design problems, and students revise their projects to fix the problemsThis allows students to see how their code can be improved by applying designprinciplesI have now taught the software design class three times and this book isbased on the design principles that emerged from the class. The principles arefairly high level and border on the philosophical (Define errors out ofexistence"), so it is hard for students to understand the ideas in the abstractStudents learn best by writing code, making mistakes, and then seeing how theirmistakes and the subsequent fixes relate to the principlesAt this point you may well be wondering: what makes me think i know allthe answers about software design to be honest i dont There were no classeson software design when i learned to program and i never had a mentor to teachme design principles. At the time I learned to program, code reviews werevirtually nonexistent. My ideas about software design come from personalexperience writing and reading code. Over my career I have written about250,000 lines of code in a variety of languages. Ive worked on teams thatcreated three operating systems from scratch, multiple file and storage systemsinfrastructure tools such as debuggers, build systems, and Gui toolkits,ascripting language, and interactive editors for text, drawings, presentations, andintegrated circuits. Along the way I've experienced firsthand the problems oflarge systems and experimented with various design techniques. In addition, Iveread a considerable amount of code written by other people, which has exposedme to a variety of approaches, both good and badOut of all of this experience, I've tried to extract common threads, both aboutmistakes to avoid and techniques to use. This book is a reflection of myexperiences: every problem described here is one that I have experienced

7个ANSYS有限元分析经典实例，出自清华大学机械工程系，详细的GUI操作，手把手教你学习ANSYS，实例皆为力学经典问题，实属ANSYS学习必备资料，不容错过，赶紧下载学习吧！
梁的有限元建模与变形分析计算分析模型如图所示习题文件名要求选择不同形状的截面分别进行计算。梁承受均布载荷:x图梁的计算分析模型梁截面分别采用以下三种截面(单位:):t2 k-i2+t了++w3矩形截面园截面工字形截面进入首先在D盘建立一个文件夹,命名为Beam程序击选择盘建立的文件夹Bcam→输入设置计算类型选择单元类型定义材料参数一定义截面分别定义矩形截面、圆截面和工宇形截面:矩形截面员截面工字形截面:生成几何模型生成特征点→依次输入三个点的坐标:生成梁连接两个特征点,网格划分选择(根据所计算的染的截面选择编号)→拾取特征点模型施加约束最左端节点加约束最石端节点加约束施加方向的载荷分析计算结果显示退出系统坝体的有限元建模与应力应变分析计算分析模型如图所示习题文件名图2-1坝体的计算分析模型进入首先在D盘建立一个文件夹,命名为dam程序点击选择盘建立的文件夹dam-输入设置计算类型选择单元类型定义材料参数生成几何模型生成特征点→依次输入四个点的坐标:生成坝体截面→依次连接四个特征点网格划分依次拾取两条横边→依次拾取两条纵边模型施加约束√分别给卜底边和竖直的纵边施加和方向的约束给斜边施加方向的分布载荷命令菜单栏在下方的下拉列表框内选择作为设置的变量:在窗口中出现写入所施加的载荷函数:文件扩展名:返回:将需要的文件打开,任给一个参数名,它表小随之将施加的载荷→拾取斜边;→在下拉列表框中,选择:选择需要的载荷参数名→分析计算结果显示退出系统受内压作用的球体的有限元建模与分析计算分析模型如图所示习题文件名承受内压图受均匀内压的球体计算分析模型(截面图)进入首先在D盘建立一个文件夹,命名为程序点击选择盘建立的文件夹输入设置计算类型选择单元类型定义材料参数生成几何模型√生成特往点依次输入四个点的坐标:生成球体截面命令菜单栏→依次连接→依次拾取四条边命令菜单栏网格划分→拾取两条直边→拾取两条曲边模型施加约束给水平直边施加约束→拾取水平边:√给竖直边施加约束拾取竖直边给内弧施加径向的分布载荷→拾取小圆弧;分析计算结果显示退出系统受热载荷作用的厚壁圆筒的有限元建模与温度场求解计算分析模型如图所示习题文件名圆筒内壁温度℃,外壁温度℃。两端自由且绝热图受热载付作用的厚壁圆筒的计算分析模型(截面图)进入首先在D盘建立一个文件夹,命名为程序点击选择盘建立的文件夹输入设置计算类型选择单元类型定义材料参数生成几何模型生成特征点依次输入四个点的坐标:生成圆柱体截面依次连接四个特征点网格划分→拾取两条水平边→→拾取两条竖直边模型施加约束分别给两条直边施加约束→拾取左边拾取右边分析计算结果显示退出系统

很详细，很好的一本书。对学习ansys在热和电磁方面的人很有帮助。

这是分布式领域的一本经典书籍．值得一看的．

这是一个大纲型指导文档，从整体上对博通SDK架构进行介绍

厦门大学大数据技术基础课程教材 由林子雨倾情编写 内容详实 讲解细致 是您外出旅游 居家生活之必备材料