meteorWJ's Home—Floating clound

敏捷宣言：个体和迭代，超越过程和工具 工作的软件，超越完整的文档   客户协作，超越合同谈判   响应变更，超越履行计划 敏捷原则： 1. 优先级最高的是，通过早期和持续交付有价值的软件来满足客户。 2. 欢迎变更需求，即使在开发的后期提出。敏捷过程为客户的竞争优势而控制变更。 3. 以两周到两月为周期，频繁地交付可运行的软件，首推较短的时间定量。 4. 在整个项目过程中，每一天开发人

　报表测试根据项目的定义有大有小,有时只是作为软件的一个部分进行测试,有时整个项目都是测试各种报表.但不论如何,报表的作用始终都是将系统中已经存在的数据根据用户的设置计算加工/整理汇总/最终以清晰的格式展示给用户,以便用户进一步做数据分析或统计.　　软件中的报表实现一般分为定义报表的所需数据(一般可以通过选择或手工输入条件来缩小数据范围)和定义报表格式两个部分.报表格式除了如国家各行业标准中规定的

任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。　　黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特

     正式接触软件需求分析可能只有一个学期多一点的时间, 一直听说做一个软件最重要的是需求, 开始的时候不太在意这句话,以为只要代码实现了就没有多大的问题了。直到接触到了现实的项目才发现这句话真的是深藏不露啊。     记得专业实践是帮一个老师做一个项目，用户是某个部队，项目是一个政治教育评估系统，最早的时候好像并没有给出太多的要求，只是说做出一个他们想要的教育评估系统的中心部分就可以了，因为

JUnit 是JAVA语言事实上的标准测试库。JUnit 4是三年以来最具里程碑意义的一次发布。它的新特性主要是针对JAVA5中的标记(annotation)来简化测试，而不是利用子类、反射或命名机制。本文将讲述如何使用JUnit 4，当前前提是你最好具有JUnit的使用经验.　　JUnit, 由Kent Beck 和 Erich Gamma开发，几乎是JAVA开发最重要的第三方工具。正如Ma

  需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到

前言　　1.1. 引言　　对于大部分软件系统，如何测试及有效的测试，是一个很头痛的问题。在软件工程上，测试是软件工程中极其重要的一部分; 但在具体的实际情况上，无论是时间、人手及资源的调配等原因，使国内大部分软件公司没有进行过理论上的完整的测试。　　本文想要描述的，就是一种简单可行，又能使软件系统达到最低质量要求的一组测试方法。　　1.2. 测试目的　　对于任何一款软件来讲，它

   最近开始学习UML,在中看到有关于其他需求的部分,觉得这点还是比较容易被忽略的.在这里, 提出来和大家共享,呵呵...Ready？GO！    第七章—其他需求     除了用例之外，还有一些其他的重要的UP需求制品，这里谈到的是一些次要的需求主题而不是OOA/D。这些内容与案例研究的关系密切，能提供更为完整的需求。     其他需求制品包括：                        

1 引言 1.1 编写目的：阐明编写详细设计说明书的目的，指明读者对象。 1.2 项目背景：应包括项目的来源和主管部门等。 1.3 定义：列出本文档中所用到的专门术语的定义和缩写词的愿意。 1.4 参考资料： 　　● 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源 　　●项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；需求规格说明书；概要设计说明书；测试计划（初稿）；用户

由于[GOF95]是论述软件模式的著作的第一本，也是OO设计理论著作中最流行的一本，因此有些人常常使用设计模式（Design Pattern）一词来指所有直接处理软件的架构、设计、程序实现的任何种类的模式。另外一些人则强调要划分三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、成例(Idiom)。成例有时称为代码模式(Coding

本文内容包括: 什么是RUP？ 什么是MSP？ 与MSP一起使用RUP 结束语

SWOT分析模型(SWOT Analysis) 　　SWOT分析法（也称TOWS分析法、道斯矩阵）即态势分析法，20世纪80年代初由美国旧金山大学的管理学教授韦里克提出，经常被用于企业战略制定、竞争对手分析等场合。 目录 [隐藏]

1 前言　　需求分析阶段是管理信息系统（MIS）开发最重要的阶段。MIS开发的需求阶段首先是了解和澄清用户的需求，然后严格地定义被开发的软件系统的需求规格说明书[1]。常用的软件需求分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法、面向对象的方法和原型法等。原型法由于改变了系统的分析、设计和实现三个顺序阶段的观点[2]，改变了传统的自顶向下的开发模式，降低了软件需求的风险，因

 摘要　　当今，经济和社会生活对软件的依赖程度急剧增长，软件需求日益复杂，软件开发成为一项跨越技能，职责范围和时间阶段的综合团队活动。实践证明，良好的需求管理过程对于降低开发成本和保障项目成功至关重要。　　这里是我们采用的需求管理过程，希望能与大家分享，互相学习和借鉴。欢迎留言！　　我们将需求管理过程分为三个大的阶段：Discover阶段

  做过软件的人都听过这样的抱怨：需求变化太快，软件系统经常要

 敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。      敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软

    RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。 RUP和类似的产品--例如面向对象的软件过程（OOSP），以及OPEN Process都是理

不全和错误的地方还望高手补充：Access Control List（ACL） 访问控制列表access token 访问令牌account lockout 帐号封锁account policies 记帐策略accounts 帐号adapter 适配器adaptive speed leveling 自适应速率等级调整Address Resolution Protocol(ARP) 地址解析协议Ad

 软件工程(Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。      在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业

    软件需求是(1)用户解决问题或达到目标所需的条件或权能(Capability)。　　            (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。　　           (3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。                （IEEE软件工程标准词汇表(1997年)中定义）一、软件需求的发展   

客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。 1、 分析人员要使用符合客户语言习惯的表达 　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计

在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。 真的是这样吗？敏捷过程到底是如何做需求分析

需求分析检查表   这个需求检查表包含一系列关于你的项目需求的自测题。本书并没有论及如何提出一份好的需求文件，这个检查表也同样没有。但用这个检查表，你可以检验一下在创建工作时，你的工作基础是否牢固可靠。并不是表中所列出的每一个问题都适用于你的项目。如果你正在从事一个非正式项目，你会发现根本不需要考虑这个问题，你也会在其中发现一些需要考虑但并不需要回答的问题。但如果你正在从事一个大型的正视项目，

 在OOA/D的开发过程中有很多种，比如：up，xp,scrum,dsdm等，不管是那一种都要将项目分解成为一系列的子项目，每次的子项目就是一次迭代，在每次的迭代中对前一次的迭代进行refactory。以前曾经看过Craig Larman的一篇关于OOA/D的文章，里面对开发过程的描述令我获益匪浅，尤其是在实践中的体会更能让人有所启发。作者在对很多应用xp项目的了解中发现，当前没有任何一个成功案例

  需求分析1.        引言1.1    目的说明编写这份报告的目的，指出预期的读者。1.2    背景指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3    参考资料列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、

Extreme Programming 中的需求分析，是通过Planning Game 完成的。虽然我们从Planning  Game开始，讨论Extreme Project的具体过程，但实际上，Planning Game中的一些阶段几乎贯穿了项目 开发的始终。（用Game这个词，可以让大家的心理放松些。）         做计划，是一件说起来容易做起来难的事情。做计划时，程序员考虑的是怎么样

扩大软件开发的规模从目前的情况来看，软件开发的速度缓慢、代价高昂而又极易出错，常常会生产出存在大量缺陷的产品，在可用性、可靠性、性能、安全以及其他服务质量方面造成严重的问题。根据 Standish Group [Sta94] 的统计，美国公司每年投资约 175,000 个软件开发项目，投资额约为 2,500 亿美元。这些项目中只有 16％ 能够在预算内按计划完成。另有 31％ 的项目主要由