软件开发的整个过程中有些什么约束
项目三个约束条件(Triple Constraint):时间日程(项目周期)、性能规规(质量)、以及资金(成本费用)预算。
项目的假设没找到具体定义。
约束条件和假设是可以贯穿整个项目的。
比如,项目必须在10月份完成(约束条件),预算是100万(约束条件)。
我们提供5个熟练的队员(假设有5个人,假设他们是熟练的)。
到后期,5个人来了4个(这时就不是假设了,是问题了)。
4个人中,还有一个菜鸟(又成问题了)。
假设也是风险的来源,如果不成立,就会转为问题。
...
如何从软件开发的角度分析一个软件并将软件开发说明写出来?
首先,你需要明白为什么需要文档。
你要理解文档和代码一样重要,都是开发人员的劳动成果(artifact)。
其次,你要确定你采用的周期模型和开发方法。
不同的模型或方法会有不同的文档需求,这需要你自己裁剪直到适合你的开发团队,别忘了,文档也是为了提高开发效率、质量用的,让开发人员过多的写一些无味的文档,反而会降低效率。
再次,你要作出一些文档模板,模板中对文档的用途和结构做出明确的说明。
最后,就可以填充啦。
附一个RUP的需求描述文档模板 1.0 简 介 [介绍本文档的整体结构。
] 1.1 目的 [说明本软件需求规格说明书的目的。
软件需求规格说明书不仅需要完整的描述系统的行为,还需要说明非功能性的需求、设计约束以及其它相关的因素。
] 1.2 范围 [简要介绍本需求规格文档适用的项目/应用程序及其主要特性或其它子系统、相关的用例模型和受其影响的其它任何事物。
] 1.3 定义、术语和缩写 [详细定义正确地理解本文档的相关术语,包括定义、首字母缩写词和缩略语。
可以通过引用术语表说明。
] 1.4 参考资料 [说明本文档引用的任何其它相关文档。
要列出文档的标题、文档编号、日期、和出版单位并说明文档的来源。
] 1.5 概要 [说明本文档余下部分包含的内容及组织方式。
] 2.0 说 明 [本节列出影响产品和需求的一般因素,但不需列出具体的需求,只需描述将在第3节中详细描述的需求的背景,以便于理解需求。
这包括:产品总体效果,产品功能,用户特征,约束、假设和依赖,以及需求子集等。
特别关键的是除了需要说明产品是或说解决什么,还要说明产品不是或不是解决什么。
] 2.1 用例模型 [如果使用了用例模型,本小节概述适用于本系统的用例模型或子模型,包括所有用例和角色的名称和简要说明及用例图和关系。
可将用例报告作为附件在此引用。
] 2.2 假设与依赖 [说明所有重要的技术可行性、子系统或组件的可用性或可作为此说明书所描述的软件的基础的其它相关假设。
] 3.0 需求描述 [详细描述软件的需求。
其详细程度能够使设计人员设计出满足这些需求的系统;测试人员能够测试此系统是否真的满足这些需求。
在使用用例建模时,这些需求采用用例和可用的其它补充文档捕获 。
] 3.1 用例报告 [用例模型通常定义了系统的主要功能性需求和一些非功能性需求。
对用例模型中的每个用例都需要在此引用或附上用例报告。
保证清晰的标明每个需求。
] 3.2 补充说明 [描述没有包含在用例中的其它需求。
此处应包含补充需求说明中适用于此系统的具体需求说明或特征,并重新提炼以足够详细地说明此系统。
这些信息可直接记录在此文档中,也可以作为附件引用到单独的补充说明文档。
同样要保证需求被清晰的定义。
] 4.0 辅助信息 [辅助信息使此文档更容易使用。
这可以是目录、索引、附录、用例示意图、用户界面原型等。
如果包含附录,要明确说明此附录是否是需求的一部分。
]
产品需求文档应该包含哪些内容
规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
2 适用范围本规范适用于集团开发项目的(软件)《需求说明书》的编写。
3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称,任务提出者,用户及实现该软件的计算机网络。
3.1.2 参考资料列出有关资料(名称,发表日期,出版单位,作者等)。
3.1.3 术语和缩写词列出本文件中用到的专门术语的定义,及术语缩写词。
3.2 软件总体概述3.2.1 目标软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束说明影响软件开发、运行环境和系统能力(如预告出错类型的能力)的某些假设和约束。
3.3 详细需求详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求对系统中每一个功能,要详细描述(图示或文字)。
概述 叙述功能名称,目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么,如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求定量地描述此软件系统应满足的具体性能需求。
可考虑以下方面:3.3.2.1精度说明系统的精度要求,如:数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性说明系统的时间特性要求,如:解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性说明当需求发生某些变化时系统的适应能力,指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量包括系统的设计容量和理论(计算)容量。
3.3.3 输入和输出解释各输入输出数据类型,并逐项说明某媒体、格式、数值范围等。
对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.3.4 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境描述所开发软件运行所需的环境。
3.4.1 设备环境描述运行软件系统所需的设备能力,如:处理器的型号和内存容量。
存储媒体的数量。
通信网络(包括说明网络结构,线路速度及通讯协议等)。
3.4.2 支持软件环境列出与待开发的软件互相配合的支持软件(包括名称,版本号和文件资料),必要时还应列出测试软件,还要指出该软件用的编程语言,编译程序,操作系统和数据管理系统。
3.4.3 接口说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
产品需求文档应该包含哪些内容
规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。
2 适用范围本规范适用于集团开发项目的(软件)《需求说明书》的编写。
3 编写内容提示1 引言3.1.1 背景说明说明被开发软件的名称,任务提出者,用户及实现该软件的计算机网络。
3.1.2 参考资料列出有关资料(名称,发表日期,出版单位,作者等)。
3.1.3 术语和缩写词列出本文件中用到的专门术语的定义,及术语缩写词。
3.2 软件总体概述3.2.1 目标软件开发的意图、应用目标、作用范围以及需说明背景材料。
3.2.2 系统模型图示说明该软件的所有功能及其相互关系和数据传递情况。
3.2.3 假设和约束说明影响软件开发、运行环境和系统能力(如预告出错类型的能力)的某些假设和约束。
3.3 详细需求详细描述此软件系统的功能需求和性能需求。
3.3.1 功能需求对系统中每一个功能,要详细描述(图示或文字)。
概述 叙述功能名称,目标和作用。
输入 输入该功能的信息。
处理 描述该功能做什么,如何对输入信息进行加工并转换成输出信息。
输出 列出内部生成的文件。
3.3.2 性能需求定量地描述此软件系统应满足的具体性能需求。
可考虑以下方面:3.3.2.1精度说明系统的精度要求,如:数据的精度要求。
数字计算的精度要求。
数据传送的误码率要求。
3.3.2.2 时间特性说明系统的时间特性要求,如:解题时间。
询问和更新数据文件的响应时间。
系统各项功能的顺序关系。
3.3.2.3 灵活性说明当需求发生某些变化时系统的适应能力,指出为适应这些变化而需要设计的软件成分和过程。
3.3.2.4系统容量包括系统的设计容量和理论(计算)容量。
3.3.3 输入和输出解释各输入输出数据类型,并逐项说明某媒体、格式、数值范围等。
对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.3.4 数据管理能力说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作估算。
3.3.5 故障处理列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.4 环境描述所开发软件运行所需的环境。
3.4.1 设备环境描述运行软件系统所需的设备能力,如:处理器的型号和内存容量。
存储媒体的数量。
通信网络(包括说明网络结构,线路速度及通讯协议等)。
3.4.2 支持软件环境列出与待开发的软件互相配合的支持软件(包括名称,版本号和文件资料),必要时还应列出测试软件,还要指出该软件用的编程语言,编译程序,操作系统和数据管理系统。
3.4.3 接口说明本软件与其他软件之间的接口、数据通信协议等。
3.4.4其他说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。
想开发个软件,是自己组织团队好还是外包给软件公司?
我个人建议还是自己组织团队吧。
因为包给软件公司。
软件公司通常都有他自己的一套软件。
不会另外开发一个与本身毫无相关的软件。
还有包给公司他还不一定会同意你。
而组织团队。
虽然费用上是多了点。
但组织上还是比那包给公司容易很多。
因为组织是没有任何规定自由。
有很多人都不喜欢被人约束。
找些志同道合的人来组团。
分工合作。
毕竟开发软件并非易事。
起码要20个人以上。
电脑的配置要高级等等。
。
简单说一句。
组织虽然费用自己和同伙平分。
但更自由。
软件工程(移动互联网应用与开发方向)
其实我也想知道,因为有同学叫我转去他那个专业!!!但我报的那个是电子信息工程-移去通信的,不知道他们有什麽区别。
。
。
。
找到这些,应该对你有用吧~~~浅谈移动互联网应用的开发 中国的移动互联网用户已经达到2.33亿,随着越来越多的互联网用户开始访问移动互联网,和一些不浏览互联网的用户开始访问移动互联网,可以想象移动互联网在以多么惊人的速度进行增长。
未来,移动互联网将成为IT发展的下一个蓝海。
那么未来移动互联网可以为我们做什么?其实移动互联网就是把一个随身携带的手机,连到一个浩瀚的互联网上,能够帮助我变成一个更强大的我,可以应用手机的这种不会失去的记忆力,可以用互联网上巨大的知识联合起来帮我解决问题。
笔者作为移动互联网领域的从业者,从开始接触移动互联网应用的开发,到目前对移动互联网的应用开发有了一些研究和认识,整个过程中颇有感触。
总体说移动互联网应用的开发,在开发方式上与桌面应用和Web应用开发有很多相似,由于移动终端硬件的特殊性,在服务内容、类型和推广上却是有很大的不同。
一旦手机等移动终端连接到互联网上,那么除了通话和上网之外,手机等移动终端应用的想象空间将会非常大,并将会给我们的生活带来很大便利。
但我们也要清醒的认识到,由于移动终端硬件设备和操作系统的差异性非常大,导致在移动终端上进行软件开发时会面临很多问题和限制,这些问题是我们无法回避的,也是我们无法改变的,但我们需要清楚的认识到这些问题,以指导我们的开发和推广。
下面,笔者就针对在移动互联网应用开发过程中出现的一些问题,做简要的阐述: 操作系统繁多移动操作系统目前是Windows Mobile、Symbian、Android、iPhone等并存,且还有各大运营商发布的操作系统等。
繁多的操作系统,导致需要提供非常多的平台版本介质,况且还有操作系统本身的不兼容性,比如Android2.0/1.5之间存在的兼容问题,Windows Phone7完全不向下兼容问题等,操作系统处于混战的状态。
开发语言繁多手机平台的多样性,导致开发语言种类的繁多,开发团队需要熟悉和了解较多的语言和开发环境,并由此带来了非常高的开发和维护成本,这也是与传统软件不一样的地方。
对于中小型的团队来说,都要求开发成员掌握至少两门以上的开发语言,因此在开发移动互联网产品时,通常会按照市场占有率的高低,来决定平台介质的开发顺序。
键盘和屏幕适应手机的屏幕可谓是五花八门,各种各样,有320*240、480*640、320*640等,程序在开发中,需要针对不同的屏幕做UI适应,同样不同的输入方式,如触摸屏、QWERTY、软键盘,在UI设计以及易用性上,就会有不同的要求,开发者需要考虑这两种输入模式的差异,提供更加友好的输入模式。
网络和流量的限制目前,国内3G还没有普及,使用互联网服务的用户,仍然是使用2G的网络,这就要求应用在提供服务的时候,一定是要假设用户当前的带宽是每秒几十K级别的水平,不能完全按照3G的通信质量来提供服务,否则就会出现窄道走大车的问题,带来不好的用户体验以及流量浪费。
内存、电池限制手机终端不同于PC,在内存使用和电池的续航上有很多限制,比如,目前通用的内存范围从16M~256M,程序在开发过程中,需要谨慎的考虑内存的分配情况,如不注意,就会导致用户手机变慢或死机等现象,并会被用户抛弃。
手机电池续航能力不足,已经成为制约手机终端应用发展的一个非常重要的因素,通常用户对于电池续航时间是非常敏感的,比如我们在桌面系统使用的后台线程运行、定时更新数据等方式,在终端应用上,就需要慎重使用。
终端匹配的繁杂由于屏幕、键盘、CPU、内存、电池、屏幕等差异,应用在各个终端上的适配是一个非常庞大的工作,如果按照传统软件的测试方法,基本上是不可行的,这也是目前终端软件开发面临的一个主要的难题,暂时还不清楚如何在各种手机上做兼容性测试。
正是由于上述这么多的问题和限制,笔者对如何提供移动互联网服务?服务内容是什么?移动互联网的应用开发该怎么做等问题给予了以下应对策略:从国内互联网发展的趋势来看,娱乐、游戏、沟通、资讯始终是互联网上最主要的服务,国内的互联网主力用户(15~30岁)以及用户的知识水平,决定了互联网的主要业务方向,而在Apple Store中,下载排在最前面的是办公、协作、工具类的应用,不是游戏娱乐类应用。
工程师开发创新的时候就应务实的,以更符合用户需求为标准进行针对性的开发。
移动舆情是我们面向移动互联网用户提供的一种服务,它以前仅仅是我们面向政府或企业用户提供的一种专业服务,但我们最终在移动领域提供的服务,必定是面向绝大多数移动互联网用户的服务,因此服务的提供和运营要充分考虑国情,只有让用户量变大,才有可能持续增长和盈利,否则很难有发展。
移动互联网应用的开发架构和过程受制于前边提到的问题和限制,以及移动终端的计算能力,在移动互联网应用的开发上,区别于传统软件的开发,客户端一定要简单,要减少客户端的计算,把计算放到服务器上,笔者认为,“云计...
在排序问题中,假设和约束的区别
转载,供参考。
软件开发项目进度控制 一、影响软件开发项目进度的因素 要有效地进行进度控制,必须对影响进度的因素进行分析,事先或及时采取必要的措施,尽量缩小计划进度与实际进度的偏差,实现对项目的主动控制。
软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。
在软件开项目的实施中,人的因素是最重要的因素,技术的因素归根到底也是人的因素。
软件开发项目进度控制常见问题主要是体现在对一些因素的考虑上。
常见的问题有以下几种情况: 1、80-20原则与过于乐观的进度控制 80-20原则在软件开发项目进度控制方面体现在:80%的项目工作可以在20%的时间内完成,而剩余的20%的项目工作需要80%的时间。
这个80%的项目工作不一定是在项目的前期,而可能是分布在项目的各个阶段,但是剩余的20%左右的项目工作大部分是在后期。
所以软件开发在进入编码阶段后会给人一种“进展快速”的感觉,使得项目经理、项目团队成员、用户以及高层领导产生了过于乐观的估计。
有些领导看到软件交付给用户了,就一块石头落地“总算交差了”,同时又可能撤出一些被认为不必要的人力资源。
但很多情况下这是为了对付用户不合理的交付期限要求而采用的不得已的措施。
这样的结果是拖延了后期的工作,同时如果软件还不成熟的话,会给用户造成不好的影响。
2、范围、质量因素对进度的影响 软件开发项目比其他任何建设项目都会有更经常的变更,大概是因为软件程序是一种“看不见”又“很容易修改”的东东吧,用户是想改就改,造成需求的蔓延,项目经理有时还不知如何拒绝,加上要说“我能”的心理因素,一般都会答应修改。
这样集少成多,逐渐影响了项目进度。
如果某项工作在进度上表面上达到目标了,但经检验其质量没有达到要求,则必然要通过返工等手段,增加人力资源的投入,增加时间的投入,实际上是拖延了进度。
不管是从横向或纵向来看,部分任务的质量会影响总体项目的进度,前面的一些任务质量中会影响到后面的一些任务质量。
3、资源、预算变更对进度的影响 资源,最主要的还是人力资源,有时某方面的人员不够到位,或者在多个项目的情况下某方面的人员中途被抽到其他项目、或身兼多个项目、或在别的项目不能自拔无法投入本项目。
还有一个很重要的资源,就是信息资源,如某些国家标准、行业标准,用户可能提供不了,而是需要去收集或购买,如果不能按时得到,就会影响需求分析、设计或编码的工作。
其他资源,如开发设备或软件没有到货,也会对进度造成影响。
预算其实就是一种资源,它的变更会影响某些资源的变更,从而对进度造成影响。
4、低估了软件开发项目实现的条件 低估软件开发项目实现的条件表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。
首先是低估技术难度。
软件开发项目团队成员,有时甚至是企业的高级项目主管也经常低估项目技术上的困难。
低估技术难度实际上也就是高估人的能力,认为或希望项目会按照已经制定的乐观项目计划顺利地实施,而实际则不然。
软件开发项目的高技术特点本身说明其实施中会有很多技术的难度,除了需要高水平的技术人员来实施外,还要考虑为解决某些性能问题而进行科研攻关和项目实验; 其次,低估了协调复杂度,也低估了多个项目团队参加项目时工作协调上的困难。
软件开发项目团队成员比较强调个人的智慧、强调个性,这给项目工作协调带来更多的复杂度。
当一个大项目由很多子项目组成时,不仅会增加相互之间充分沟通交流的困难,更会增加项目协调和进度控制上的困难。
另外,企业高级项目主管和项目经理也经常低估环境因素,这些环境因素包括用户环境、行业环境、组织环境、社会环境、经济环境。
低估这些条件,既有主观的原因,也会有客观的原因。
对项目环境的了解程度不够,造成没有做好充分的准备。
5、项目状态信息收集的情况 由于项目经理的经验或素质原因,对项目状态信息收集的的掌握不足,及时性准确性完整性比较差。
另外其它一些原因也会造成这种现象。
某些项目团队成员报喜不报忧,不希望别人知道自己工作的不好的情况,例如软件程序的编制,可能会先编制一些表面的东西,现有界面,看起来好像完成任务了,实际上只是一个“原型系统”或演示系统。
给领导造成比较乐观的感觉。
如果项目经理或者管理团队没有及时地检查发现这种情况,将对项目的进度造成严重的影响。
当然,如果出现这种需要时时刻刻都互相提防的氛围,管理人员就应该从管理的角度,从制度的角度检讨一下,进行改进,让大家实事求是地进行沟通。
温伯格说:“无论你多么聪明,离开了信息,对项目进行成功的控制就是无源之水、无本之木。
” 6、执行计划的严格程度 没有把计划作为项目过程行动的基础,而是把计划放在一边,比较随意去做。
例如对于项目团队内部沟通或外部沟通,在计划中要说明清楚人员、周期、方式、方法,不能遗漏,但在实际项目过程中,可能出现沟通没有按时或没有完整地达到所有项目干系人的情况。
若项目计划本身有错误,执行错...
转载请注明出处51数据库 » 软件开发 假设与约束