星光不问赶路人,时光不负有|

项目开发流程

项目开发流程

开发流程图

开发基本流程

1.需求分析阶段

  需求分析分析的不仅仅是用户需求,应该是开发中遇到的所有的需求。比如,你首先要知道做这个项目是为了解
决什么问题;测试案例中应该输入什么数据......为了清楚地知道这些需求,你经常要和客户、项目经理以及项目
伙伴交流。
  软件需求分析就是回答做什么的问题。它是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把
它用软件工程开发语言(形式功能规约,即需求规格说明书)表达出来的过程。本阶段的基本任务是和用户一
起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到用户的认可。需求分析的主
要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求,设计建立
相应的软件系统的体系结构,并将整个系统分解成若干个子系统或模块,定义子系统或模块间的接口关系,对
各子系统进行具体设计定义,编写软件概要设计和详细设计说明书,数据库或数据结构设计说明书,组装测试
计划 。

2.设计阶段

  软件设计可以分为概要设计和详细设计两个阶段。实际上软件设计的主要任务就是将软件分解成模块是指能
实现某个功能的数据和程序说明、可执行程序的程序单元。可以是一个函数、过程、子程序、一段带有程序说
明的独立的程序和数据,也可以是可组合、可分解和可更换的功能单元。模块,然后进行模块设计。概要设计
就是结构设计,其主要目标就是给出软件的模块结构,用软件结构图表示。详细设计的首要任务就是设计模块
的程序流程、算法和数据结构,次要任务就是设计数据库,常用方法还是结构化程序设计方法。
  概要设计说明书:概要设计说明书又可称系统设计说明书,这里所说的系统是指程序系统。编制的目的是说
明对程序 系统的设计考虑,包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接
口设计。 运行设计、数据结构设计和出错处理设计等,为程序的详细设计提供基础。
  详细设计说明书:详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一
个程序 (每个模块或子程序)的设计考虑,如果一个软件系统比较简单,层次很少,本文件可以不单独编写,
有关 内容合并入概要设计说明书。
  数据库设计说明书:数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构
作出具体的设计规定。
  测试计划初稿:这里所说的测试,主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供
一个对该软件的测试计划,包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价
准则。

3.开发阶段

  软件开发是指把软件设计转换成计算机可以接受的程序,即写成以某一程序设计语言表示的"源程序清单"。
充分了解软件开发语言、工具的特性和编程风格,有助于开发工具的选择以及保证软件产品的开发质量。
当前软件开发中除在专用场合,已经很少使用二十世纪80年代的高级语言了,取而代之的是面向对象的开发语
言。而且面向对象的开发语言和开发环境大都合为一体,大大提高了开发的速度。开发工程师正式进入编码阶段,
这个过程虽然大部分时间用来写代码,但是可能还需要进行技术预研、进行需求确认。
  操作手册:操作手册的编制是为了向操作人员提供该软件每一个运行的具体过程和有关知识,包括操作方法
的细节。
  (简单点就是将项目拆分之后的多个小项目交给不同开发部门下的多个编程人员编写  )

4.测试阶段

  软件测试的目的是以较小的代价发现尽可能多的错误。要实现这个目标的关键在于设计一套出色的测试用
例(测试数据和预期的输出结果组成了测试用例)。如何才能设计出一套出色的测试用例,关键在于理解测试
方法。不同的测试方法有不同的测试用例设计方法。两种常用的测试方法是白盒法测试对象是源程序,依据的
是程序内部的的逻辑结构来发现软件的编程错误、结构错误和数据错误。结构错误包括逻辑、数据流、初始化
等错误。用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果。白盒法和黑盒法依据的是软件的
功能或软件行为描述,发现软件的接口、功能和结构错误。其中接口错误包括内部/外部接口、资源管理、集
成化以及系统错误。黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。黑盒法。
  测试分析报告:测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。
  项目开发总结报告:项目开发总结报告的编制是为了总结本项目开发工作的经验,说明实际取得的开发结果
以及对整个开发工作的各个方面的评价。

5.运行与维护阶段(上线)

  可以简单的理解为与客户或者上级达成一致后,系统进行试运行,稳定后上线。将项目打包给运维人员运行维护即可
  在实际开发过程中,软件开发并不是从第一步进行到最后一步,而是在任何阶段,在进入下一阶段前一般都
有一步或几步的回溯。在测试过程中的问题可能要求修改设计,用户可能会提出一些需要来修改需求说明书等。

三层架构

图示

三层架构介绍

  三层架构就是为了符合“高内聚,低耦合”思想,把各个功能模块划分为表示层(UI)、业务逻辑层(BLL)
和数据访问层(DAL)的三层架构,各层之间采用接口相互访问,并通过对象模型的实体类(Model)作为数
据传递的载体,不同的对象模型的实体类一般对应于数据库的不同表,实体类的属性与数据库表的字段名一致。

  三层架构区分层次的目的是为了“高内聚,低耦合”。开发人员分工更明确,将精力更专注于应用系统核心业
务逻辑的分析、设计和开发,加快项目的进度,提高了开发效率,有利于项目的更新和维护工作。

哪三层

1)表现层:用于显示数据和接收用户输入的数据,为用户提供可以交互的操作界面及表现逻辑。即用户所看到的界面,视图部分,就叫做表现层。
 
  (2)业务逻辑层:主要包含业务逻辑代码,它作为表现层和数据访问层之间的通讯桥梁,负责数据的传递和处理。即编写功能逻辑实现的部分,叫业务逻辑层;

  (3)数据访问层:主要用于实现对数据库的访问和操作。

三层架构的优势

  三层架构就是对一个功能模块分层设计,每一层只负责一件事。采用分层设计可避免模块间相同功能的重复编写,达到减少模块间的耦合性、提高独立性的系统设计要求。

在项目中使用三层架构的优势有:

(1)适于变化,利于维护。项目需求经常会发生变化,三层架构将功能模块分离,提高了项目的可维护性和代码的可重用性。项目结构更清楚,分工更明确,有利于后期的维护和升级。

(2)适用于协作开发。目前,多数项目是团队多人协作开发的,有的负责界面设计,有的负责数据库操作模块,三层架构将各个功能模块分离,各自负责各层的模块,有利于协作开发。

(3)主流趋势。在企业级的开发中,三层架构是基本要求,大多数项目都会采用三层架构。

(4)避免了表示层直接访问数据访问层,表示层只和业务逻辑层有联系,提高了数据安全性。

(5)方便系统的移植,如果要把一个 C/S 的系统变成 B/S 系统,只要修改三层架构的表示层就可以了,业务逻辑层和数据访问层几乎不用修改就可以轻松地把系统移植到网络上。

开发需要注意的事项

1.系统流程梳理

  由熟悉该软件业务的管理者或者其他人来进行一次严谨的描述,并进行讨论,加以完善和改进,让参与编码
的开发者在这个过程中不仅能够熟悉自己要做的那些功能的细节,还能对这个系统有一个大致的了解和熟悉,
只有这样,在开发中才会避免一些不必要的问题发生,而且还能发现一些隐藏的问题。

2.技术框架的选择

一般选择技术架构有几个衡量的点:

第一点:效率

  在开源领域能完成同一个技术目标的框架是多个的,比如在web开发的,最终开发出来的产品是要经过性能
这一关的,如果选择有误,整个软件可以说是失败的,因为不能用,你需要重新选择技术框架,并且要重新让
每一个开发者在新的框架上进行开发,这是在开发一个新的软件。

第二点:成本

  第一个是学习成本,第二个是经济成本

第三点:稳定性

  选择一个合适的软件版本
  假设A框架有两个版本,V1和V2,V1是稳定版本,V2还是测试版本,V2中添加了一些新的功能,而这些功能
正好满足你的项目需要,并且稳定版本是在你编码完成前就会发布,那么眼前有两个选择第一个选择,选择V1
版本并且要选择一个新的B框架来满足项目需要,这种方式风险是最低的;第二种选择,选择V2测试版本,最
终等到稳定版本发布后进行替换,这种方式也是可以选择的,不过风险相对第一种选择要高些,有一个优势就
是这一个框架就可以完全满足你的项目需求,成本相对低一点。

3.编码

第一点:代码风格

5个开发者就有5种代码风格!怎么样避免这种情况,只能在编码之前进行代码编码风格宣讲和讨论,把
规则制定下来,大家按这种风格进行代码编写。
  (1)缩进:缩进以 Tab 为单位,一个 Tab 为四个空格大小。全局数据、函数 原型、标题、附加说明、函数说明、标号等均顶格书写。

  (2)空格:数据和函数在其类型,修饰(如 __fastcall 等)名称之间适当空格并据情况对 齐。关键字原则上空一格,不论是否有括号,对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。

  (3)对齐:原则上关系密切的行应对齐,对齐包括类型、修饰、名称、参数等各部分对齐。
  另每一行的长度不应超过屏幕太多,必要时适当换行。

  (4)空行:程序文件结构各部分之间空两行,若不必要也可只空一行,各函数实现之间一般空两行。

第二点:注释

  注释:对注释有以下三点要求:
  A、必须是有意义;
  B、必须正确的描述了程序;
  C、必须是最新的。

  标题、附加说明;
  函数说明:对几乎每个函数都应有适当的说明,通常加在函数实现之前,在没有函数实现部分的情况下则加
在函数原型前,其内容主要是函数的功能、目的、算法等说明,参数说明、返回 值说明等,必要时还要有一
些如特别的软硬件要求等说明;
  在代码不明晰或不可移植处应有少量说明;及少量的其它注释

4.一些提高代码的工具使用

  在这里简单列出几类工具,网上有很多资料,需要根据自己的语言进行选择。
  第一类:代码自动检视bug工具

  第二类:代码统计工具

  第三类:代码重复率和复杂度工具

  第四类:代码覆盖率工具

5.不要随意修改代码,特别是别人的代码

  修改代码应该是放在一个时间段,而不是随意进行修改
  修改代码是有很大的风险的,修改的代码很有可能是公共代码,多处地方有调用,很有可能造成其他地方出
问题,小问题解决,大问题来了。当需要修改其他开发人员的代码时一定要和对方沟通下,避免造成不必要的
误会和引发潜在的问题。

本文作者:春游去动物园

本文链接:https://www.cnblogs.com/chunyouqudongwuyuan/p/16100227.html

版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   春游去动物园  阅读(182)  评论(0编辑  收藏  举报
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
展开
  1. 1 生分 川青
生分 - 川青
00:00 / 00:00
An audio error has occurred.

生分 - 川青

词:莎子

曲:邵翼天

编曲:林亦

混音:罗杨轩

吉他:林亦

制作人:谢宇伦

监制:曾炜超/陈显

策划:+7

统筹:黄染染

出品:漫吞吞文化

『酷狗音乐人 • 星曜计划』

全方位推广,见证星力量!

「版权所有未经许可 不得商业翻唱或使用」

我们怎么变得那么生分

用了几年也没解开疑问

有些事你不提我也不问

在陌生与熟悉间找平衡

有些话一开口会伤人

有些话一开口会伤人

所以我选择默不作声

所以我选择默不作声

爱一个人

若甘愿陪衬

甘愿牺牲

也许换个名分

也不是没可能

我不怕在爱里做个蠢人

我不怕在爱里做个蠢人

也不怕爱过之后再分

也不怕爱过之后再分

爱一个人

有万种身份

万种可能

只是没想到

我们最后友人相称

我们怎么变得那么生分

我们怎么变得那么生分

连说话都要掌握好分寸

怕不注意流言

见缝插针

怕不小心我们

成陌生人

我们怎么变得那么生分

用了几年也没解开疑问

有些事你不提我也不问

在陌生与熟悉间找平衡

有些话一开口会伤人

有些话一开口会伤人

所以我选择默不作声

所以我选择默不作声

爱一个人

若甘愿陪衬

甘愿牺牲

也许换个名分

也不是没可能

我不怕在爱里做个蠢人

我不怕在爱里做个蠢人

也不怕爱过之后再分

也不怕爱过之后再分

爱一个人

有万种身份

万种可能

只是没想到我们最后

友人相称

我们怎么变得那么生分

连说话都要掌握好分寸

怕不注意流言见缝插针

怕不小心我们成陌生人

我们怎么变得那么生分

用了几年也没解开疑问

有些事你不提我也不问

在陌生与熟悉间找平衡

我们怎么变得那么生分

我们怎么变得那么生分

连说话都要掌握好分寸

怕不注意流言见缝插针

怕不小心我们成陌生人

我们怎么变得那么生分

用了几年也没解开疑问

有些事你不提我也不问

在陌生与熟悉间找平衡