- 首先就要获得完整的需求,在需求分析阶段做了大量的工作与客户各个环节的代表性用户进行沟通,充分了解和熟悉客户的业务。
并且从需求到设计阶段都保持与用户的沟通和交流。让用户的业务专家一直参与我们的需求,分析和设计工作。 其次我们会在需求分析
后就编写测试计划,在开发的每个阶段都进行相应的测试来保证代码是乎合相应需求的。在代码编写过程中,每完成一个类都由程序进行
单元测试,每完成一个功能点或模块都要进行集成测试,每一次集成测试都对上一次的已经测试通过的产品进行迭代, 也就是以前测试成功的
都会加入到本次测试中来。使得每个完成的功能和模块完成后都是一个可以运行的,可以看得到的产品;同时也欢迎用户来见证我们的集成测试结果。
代码编写完成后进行最后一次集成测试,然后交由独立的测试小组对项目进行系统测试
- 开闭原则(OCP)
- 里氏代换原则(LSP)
- 依赖倒转原则(DIP)
- 接口隔离原则(ISP)
- 合成/聚合复用原则
- 迪米特法则(松耦合)
- python经常被用于web开发
- 系统管理、服务器运维的自动化脚本
- PyQt、PySide、wxPython、PyGTK是Python快速开发桌面应用程序的利器
- 服务器软件(网络软件
- 网络爬虫
- 数据分析、人工智能
- Python使用叫做命名空间的东西来记录变量的轨迹。命名空间是一个 字典(dictionary),
它的键就是变量名,它的值就是那些变量的值。在一个 Python 程序中的任何一个地方,都存在几个可用的命名空间。 - 每个函数都有着自已的命名空间,叫做局部命名空间,它记录了函数的变量,包括函数的参数和局部定义的变量。
- 每个模块拥有它自已的命名空间,叫做全局命名空间,它记录了模块的变量,包括函数、类、其它导入的模块、模块级的变量和常量。
- 还有就是内置命名空间,任何模块均可访问它,它存放着内置的函数和异常
- 你到底为了什么而优化?
- 小心对待优化的衡量标准
- 优化且只优化关键部分
- 高层次优化更好
- 不要过早优化
- 依靠性能分析数据,而不是直觉
- 不能指望优化解决所有问题
- 详细介绍
- A.不断的变更使组件接口之间引起错误
- 什么是模块化设计
- 模块化设计的原则
- 模块化设计的关键
2)保持模块在功能及结构方面有一定的独立性和完整性。
3)模块间的接合要素要便于联接与分离。
4)模块的划分不能影响系统的主要功能。
- 详细介绍
- 以详细设计或源代码作为基础,导出程序的控制流图
- 计算得到的控制流图G的环路复杂性V(G)
- 确定线性无关的路径的基本集
- 生成测试用例,确保基本路径集中每条路径的执行
- 驱动模块:
- 桩模块:
- 黑盒测试
- 白盒测试
- 瀑布模型
按照软件生命期划分成六个部分顺序进行。但是这其中也会带来问题,相较于快速原型模型和增量模型,瀑布模型要求用户在最初就提出一套清晰完整的需求,在软件编程之前必须先撰写出详细的需求说明书。用瀑布模型开发的软件系统可能不满足客户的需求。
- 迭代模型
每次迭代就会产生一个可发布的产品,也就是把一个大项目拆成若干个小项目,分步实施。适合于分多期实施的项目,第二期的程序代码会完全替换第一期的代码。缺点是项目风险高。
- 增量模型
将软件产品作为一系列的增量构件来设计、编码的。这样既可以快速的向用户提交可完成部分功能的产品,有能让用户有较充裕的时间适应新系统。这样的开发模型需要开放式的体系结构,同时可能会导致开发的软件设计差、效率低。
- 喷泉模型
软件开发过程的各个阶段是相互迭代的、无间歇的。软件的某个部分常常被重复工作多次,相关对象在每次迭代中加入渐近的软件成分。适合于面向对象的软件开发,开发效率相对较高。缺点是常规的项目管理方法不适用。
- 演化模型
- 快速原型模型
通过一些快速原型语言先构建出软件产品的原型系统,这样可快速的和用户交互,用户通过该原型系统具体的了解该款软件,并通过原型发现用户需求的遗漏,同时用户参与度相较于瀑布模型加大了不少,弥补了瀑布模型的不足。但可能导致系统设计差、效率低,难于维护。
- 螺旋模型
使用原型及其他方法来尽可能降低风险。在软件开发的每个阶段,都增加一个风险分析过程。螺旋模型结合了快速原型模型的迭代性质和瀑布模型的系统性和可控性特点,适用于内部开发的大规模软件项目。
- 静态测试
- 动态测试
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
- 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
- 即使到了开发的后期,也欢迎改变需求。
- 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
- 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
- 围绕被激励起来的个人来构建项目。
- 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
- 工作的软件是首要的进度度量标准。
- 敏捷过程提倡可持续的开发速度。
- 不断地关注优秀的技能和好的设计会增强敏捷能力。
- 简单使未完成的工作最大化。
- 最好的构架、需求和设计出自于自组织的团队。
- 每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
- 迭代长度的不同
- 在迭代中, 是否允许修改需求
- 在迭代中,User Story是否严格按照优先级别来实现
- 软件的实施过程中,是否采用严格的工程方法,保证进度或者质量
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.
Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”
- 面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了;面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为。
- 面向过程
- 面向对象
- BBS是“电子公告板”。BBS在国内一般称作网络论坛,早期的BBS与一般街头和校园内的公告板性质相同,只不过是通过电脑来传播或获得消息而已 BBS系统最初是为了给计算机爱好者提供一个互相交流的地方。70年代后期,计算 bbs 机用户数目很少且用户之间相距很远。因此,BBS系统(当时全世界一共不到一百个站点)提供了一个简单方便的交流方式,用户通过 BBS可以交换软件和信息。到了今天,BBS的用户已经扩展到各行各业,除原先的计算机爱好者们外,商用BBS操作者、环境组织、宗教组织及其它利益团体也加入了这个行列。只要浏览一下世界各地的BBS系统,你就会发现它几乎就象地方电视台一样,花样非常多。 编辑本段BBS系统 起初的BBS系统是报文处理系统。系统的唯一目的是在用户之间提供电子报文。随着时间的推移,BBS系统的功能有了扩充,增加了文件共享功能。因此,目前的BBS用户还可以相互之间交换各种文件。只需简单地把文件置于BBS系统,其它用户就可以极其方便地下载这些文件。 早期的BBS系统是一台配有调制解调器的普通PC机,上面运行了一个BBS程序。BBS程序有各种版本,包括单线路的简单系统到支持十几甚至上百条电话线路的复杂系统。最早的BBS系统系统把全部报文存放在一个地方,可现在的BBS软件却允许操作人员根据报文内容来组织报文。比方说,基于PC的 BBS软件很可能包括有专用于DOS、OS/2和Windows的报文部分。 编辑本段BBS管理 BBS(论坛)一般由站长(创始人,超级管理员,administrator)创建,并设立各级管理人员对论坛进行管理,包括论坛管理员(Administrator)、超级版主(Super Moderator,有的称“总版主”)、版主(Moderator,俗称“斑猪”、“斑竹”)。 超级版主是低于站长(创始人)的第二权限(不过站长本身也是超级版主,超级管理员,administrator) 一般来说超级版主可以管理所有的论坛版块(普通版主只能管理特定的版块)。
- 提高软件项目开发效率和质量的关键是人才储备。
- 提高代码的规范性。编码规范 可以提高代码的可读性,并且在代码修改的时候很容易。
- 对功能进行分类,并拆分。分析出几种处理逻辑。编写代码时,部分代码可以copy。可以提编码速度。
- 对功能进行分类,并合并。提出共通类。
- 组织人员 组织人员,建立分析小组,其中包括领域专家:主角,也就是用户方面的问题专家,了解软件所解决问题的领域知识。系统分析员:导演,软件开发人员方面的人 ,其主要分析 ,抽象领域专家的知识,形成软件模型。
- 客户访谈 客户访谈,也就是获取用户需求,其主要方法是调查研究。其主要内容包括:
(1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明,对软件的需求获取是很有必要的。
(2) 市场调查。了解市场对待开发软件有什么样的要求;了解市场上有无与待开发软件类似的系统。如果有,在功能上、性能上、价格上情况如何。
(3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析;访问用户领域的专家所得到的信息将有助于对用户需求的理解。
(4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述,对用户需求可以有更全面、更细致的认识。
- 需求获取
- 需求分析
- 编写需求规格说明书
- 需求评审
A/B测试其实是一种"先验"的实验体系,属于预测型结论,与"后验"的归纳性结论差别巨大。A/B测试的目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信。
A/B测试如同GitHub、Docker、APM一样在美国市场已经被各类企业逐渐采用,相信在中国也能被广大开发者所接纳,其测试范围也不仅仅局限于网页优化,目前移动端的A/B测试需要同时支持前端(Web/H5、iOS、Android)及后端(Node.js、PHP、Java),相对于Web端的A/B测试,移动端的技术难度与复杂度都要高得多。
- 包含关系 包含关系描述的是一个用例需要某种功能,而该功能被另外一个用例定义,那么在用例的执行过程中,就可以调用已经定义好的用例。表示符号:< >
- 关联关系 企鹅和气候有关联. student与course。
- 依赖关系 凡是动物,生存都需要水和空气,这种必须的需求,我们称之为依赖关系。用虚线一端带箭头表示,箭头指向依赖物。
- 泛化关系 会员注册时可以采用电话和邮件两种方式。用例“会员注册”和“电话注册”、“邮件注册”之间是泛化关系。本质都是一样的,都是注册,而且一样大。
- 扩展关系 用一个用例(可选)扩展另一个用例(基本例)的功能,将一些常规的动作放在一个基本用例中,将可选的或只在特定条件下才执行的动作放在它的扩展用例中。表示符号:< >。
- 面向对象编程(Object-Oreinted Programming) 是一种编程范式。指在设计程序时大量运用类实例对象的方式。OOP一旦在项目中被运用,就成了时刻要考虑的东西。
- 面向服务架构(Service-Oreinted Architecture) 是将软件设计成一组可互操作的服务的一套原则或方法论。通常在考虑系统架构时才会触及SOA。
- 基 于组件开发(Component-Based Development) 是一种软件工程实践,设计时通常要求组件之间高内聚,松耦合。其接口可能是OO的,调用方式可能是以Service的方式。基于组件开发关注系统层次、子 系统边界和子系统间通讯的的设计,处于代码层面但不像OOP的一样是时刻需要运用的东西。
- 详细请看
- 确定交互的上下文。
- 找出参与交互的对象类角色,把他们横向排列在顺序图的顶部,最重要的对象安置在最左边,交互密切的对象尽可能相邻。在交互中创建的对象在垂直方向应安置在其被创建的时间点处。
- 对每一个对象设置一条垂直的向下的生命线。
- 从初始化交互的信息开始,自顶向下在对象的生命线之间安置信息。注意用箭头的形式区别同步消息和异步消息。根据顺序图是属于说明层还是属于实例层,给出消息标签的内容,以及必要的构造型与约束。
- 在生命线上绘出对象的激活期,以及对象创建或销毁的构造型和标记。
- 更具消息之间的关系,确定循环结构及循环参数和出口条件。
- 结构化开发方法
结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的,即所谓的SASD方法,也可称为面向功能的软件开发方法或面向数据流的软件开发方法。
Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析(SA)对软件进行需求分析,然后用结构化设计(SD)方法进行总体设计,
最后是结构化编程(SP)。它给出了两类典型的软件结构(变换型和事务型)使软件开发的成功率大大提高。
- 面向数据结构的软件开发方法
Jackson方法是最典型的面向数据结构的软件开发方法,Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构。三种基本的结构形式
就是顺序、选择和重复。三种数据结构可以进行组合,形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手,导出程序框架结构,再补充其
它细节,就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效,如商业应用中的文件表格处理。该方法也可与其它方法结合,
用于模块的详细设计。
- 面向问题的分析法
PAM(Problem Analysis Method)是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构,指导系统的分解,
在系统分析指导下逐步综 合。这一方法的具体步骤是:从输入、输出数据结构导出基本处理框;分析这些处理框之间的先后关系;按先后关系逐步综合处理框,
直到画出整个系统的PAD图。这一方法本质上是综合的自底向上的方法,但在逐步综合之前已进行了有目的的分解,这个目的就是充分考虑系统的输入、输出数据
结构。PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图,是到目前为止最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间
同样存在着鸿沟,这一方法仍只适用于中小型问题
- 原型化方法
产生原型化方法的原因很多,主要随着我们系统开发经验的增多,我们也发现并非所有的需求都能够预先定义而且反复修改是不可避免的。当然能够采用原型化方
法是因为开发工具的快速发展,比如用VB,DELPHI等工具我们可以迅速的开发出一个可以让用户看的见、摸的着的系统框架,这样,对于计算机不是很熟悉的用户就
可以根据这个样板提出自己的需求。
这个作业属于那个课程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
作业要求 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10618 |
作业目标 | 搜集学习中存在的问题 |
作业正文 | https://www.cnblogs.com/Eternity-5/p/12468057.html |
其他参考文献 | https://baidu.com |