GameDesign.tex

\documentclass[UTF8,nofonts]{ctexart}
\setCJKmainfont[BoldFont=STSong,ItalicFont=STKaiti]{STSong}
\setCJKsansfont[BoldFont=STHeiti]{STXihei}
\setCJKmonofont{STFangsong}
\setcounter{secnumdepth}{5}
\usepackage[hmarginratio=1:1]{geometry}
\usepackage{array,float,graphicx}
\usepackage{pstricks-add}
%表格style
\newcolumntype{L}[1]{>{\vspace{0.5em}\begin{minipage}{#1}\raggedright\let\newline\\
\arraybackslash\hspace{0pt}}m{#1}<{\end{minipage}\vspace{0.5em}}}
\newcolumntype{R}[1]{>{\vspace{0.5em}\begin{minipage}{#1}\raggedleft\let\newline\\
\arraybackslash\hspace{0pt}}m{#1}<{\end{minipage}\vspace{0.5em}}}
\newcolumntype{C}[1]{>{\vspace{0.5em}\begin{minipage}{#1}\centering\let\newline\\
\arraybackslash\hspace{0pt}}m{#1}<{\end{minipage}\vspace{0.5em}}}
%section style
\makeatletter
\renewcommand{\section}{\@startsection{section}{1}{0mm}
  {-\baselineskip}{0.5\baselineskip}{\fontsize{16pt}{16pt}\bf\leftline}}
\makeatother
%引用style
\makeatletter
\def\@cite#1#2{\textsuperscript{[{#1\if@tempswa , #2\fi}]}}
\makeatother
\pagestyle{empty}
\usepackage{fancyhdr}

%封面
\title{\Huge 软件过程简介\vskip 8cm}
\author{\large	
  班级：\underline{软件工程1102班} \\姓名：\underline{\hspace{28pt}靳杰\hspace{30pt}}\hspace{10pt} \\学号：\underline{\hspace{10pt} U201112375 \hspace{10pt}}}
\date{\Large\today}

\begin{document}
\maketitle
\thispagestyle{fancy} % IEEE模板在\maketitle后会自动声明\thispagestyle{plain}，
\lhead{} % 页眉左，需要东西的话就在{}内添加
\chead{} % 页眉中
\rhead{} % 页眉右
\lfoot{} % 页眉左
\cfoot{} % 页眉中
\rfoot{\thepage} %页眉右，\thepage 表示当前页码
\renewcommand{\headrulewidth}{0pt} %改为0pt即可去掉页眉下面的横线
\renewcommand{\footrulewidth}{0pt} %改为0pt即可去掉页脚上面的横线
\pagestyle{fancy}
\rfoot{\thepage}
\onecolumn{
\tableofcontents}
\newpage
\part{\textbf{软件基本过程}}
软件基本过程是构成软件生存期主要部分的那些过程，包括需求、设计、编码、测试等过程。
\section{\textbf{需求工程}}
应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
\subsection{\textbf{主要内容}}
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item ①需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；
\item ②需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；
\item ③形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；
\item ④需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；
\item ⑤需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。
\end{itemize}
\subsection{\textbf{基本活动}}
\subsubsection{\textbf{抽取需求}}
抽取需求是认识问题之所在，获取足够多的知识，最后成为问题领域的专家。需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法、组织会议法以及基于目标的方法等，还有知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。
\subsubsection{\textbf{模拟和分析需求}}
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 指导抽取；
\item 帮助需求工程师了解进展；
\item 帮助发现问题；
\item 帮助检查对问题的理解。
\end{itemize}
\subsubsection{\textbf{传递需求}}传递需求需要书写软件需求规格说明。作用：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 传达对需求的理解；
\item 作为软件开发项目的一份契约；
\item 作为评价后续工作的基线；
\item 作为控制需求进化的基线。
\end{itemize}
\subsubsection{\textbf{认可需求}}
对需求规格说明感兴趣的群体包括：用户、客户；系统分析员、需求分析员；软件开发者、程序员；测试员；项目管理者。

让上述人员对需求规格说明达成一致，其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
\subsubsection{\textbf{进化需求}}
因为客户的需要总是不断（连续）增长的，但是一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化（变化）就成为软件进化的首要问题。对传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性并进行关于变化的推理。
\subsection{\textbf{需求获取}}
	需求包括业务需求，用户需求和功能需求以及非功能需求，在需求开发之前，我们需要先定义好需求开发的过程，形成文档，内容包括：需求开发的步骤，每一个步骤如何实现，如何处理意外情况，如何规划开发资源等。
	
需求获取包括以下方法和技能：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 项目范围确定：开需求开发前期，我们应该获取用户的业务需求，定义好项目的范围，使得所有的涉众对项目有一个共同的理解。
\item 用户确定：确定用户群和分类，对用户组进行详细描述，包括使用产品频率，所使用的功能，优先级别，熟练程度等等。对每一个用户组确定用户的代言人。对于大型项目，我们需要先确定中心客户组，中心客户组的需求具有高级别的优先级，需要先实现的核心功能。
\item 用例确定：与用户代表沟通，了解他们需要完成的任务，得到用例模型。同时根据用例导出功能需求。用例描述应该采用标准模板。
\item 系统事件和响应：业务事件可能触发用例，系统事件包括系统内部的事件以及从外部接受到信息，数据等等，或者一个突发的任务。
\item 获取方法：召开需求讨论会议，观察用户的工作过程，采用问答式对话，采用诱发式需求诱导等等。
\item 检查完善：问题报告和补充需求建议
\end{itemize}
\subsection{\textbf{需求分析}}
需求分析是对用户的需求获取之后的一个粗加工过程，需要对需求进行推敲和润色以使所有涉众都能准确理解需求。分析过程首先需要对需求进行检查，以保证需求的正确性和完备性，然后将高层需求分解成具体的细节，创建开发原型，完成需求从需求获取人员到开发人员的过渡。
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 绘制关联图：关联图确定系统和外部的交互。划分了系统的范围和界限，构建了系统对外的接口。
\item	原型开发：对于敏捷方法，推荐完成一个界面的原型，一个初步的系统实现，通过原型，让所有涉众对开发的项目有了一个初步的映像，同时可以提供对需求的检验。
\item	需求优先级别：采用分析的方法确定产品的功能，用例和单项需求的优先级别，以优先级为基础，确定各项功能和需求都包括在哪个版本中，在项目开发过程中，需求的优先级别根据实际情况进行调整。
\item	需求建模：图形分析模型对需求描述更加抽象。主要可以采用UML的建模分析。
\item	数据字典创建：建立系统中所用到的数据项和结构的定义，数据字典可以使参与项目开发的每一个人都使用统一的定义。
\item	子系统：建立系统的结构，同时将需求分配到各个子系统和模块中。
\end{itemize}
\subsection{\textbf{需求规格说明}}
获取的需求需要文档化，以需求规格说明书的形式固化下来。文档化需求前，首先要定制文档模版，依据模版撰写需求文档。在撰写中选择最准确的表达方式，同时注意保证文档的良好结构和易读性。
\subsection{\textbf{需求验证}}
为了尽量不给设计、实现、测试等后续开发活动带来不必要的影响，需求规格说明书完成之后要对需求进行验证。验证的主要任务是执行验证和问题修改。需求验证需要被反复执行多次，它贯穿于需求开发过程的始终，如在需求获取中，需要验证获得的用户需求是否正确和充分地支持业务需求？在需求分析中，需要验证建立的分析模型是否正确地反映了问题域特征？验证细化的系统需求是否充分和正确地支持用户需求？在需求规格说明中，验证需求文档是否组织良好、其内容是否充分、是否正确反映了涉众的意图，是否能作为后续开发的基础等。验证方法有同级评审、原型与模拟、测试用例开发、用户手册编写、利用跟踪关系和自动化分析等方法。每次执行验证时都会发现一些需求描述不清、需求缺失、需求冲突，或不切实际的需求等问题，要求对每一个问题逐一给出相应的修改建议。这些问题应该在验证后根据反馈的修改意见及时得到修正。

需求验证通过后，会形成需求规格说明书极限文档，该文档被纳入配置管理，作为指导系统后续开发的依据。
\subsection{\textbf{需求跟踪管理}}
需求开发活动结束之后，为是需求能持续、稳定和有效地指导后续的软件开发，更好地处理来自客户、管理层等各方群体的变更请求，需要建议良好的配置管理，对需求基线进行版本控制。

需求跟踪分为两类：正向跟踪和方向跟踪。正想跟踪确保系统中的每一个需求元素都可跟踪到生存周期后续阶段的输出制品中。反向跟踪是指在生存周期每个阶段输出的制品都反向追溯到提出需求的涉众。正向跟踪是确保所开发的软件满足系统要求的最基本手段。

支持需求跟踪矩阵的方法之一是建立一个从需求元素到设计元素、到构造元素、到测试用例的映射关系，并用一个映射矩阵来记录这种跟踪关系。
\section{\textbf{设计阶段}}
设计阶段从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。
\subsection{\textbf{概要设计}}
主要包括：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 1、结构设计
\item 2、接口设计
\item	3、全局数据结构设计
\item 4、过程设计
\end{itemize}
\subsubsection{\textbf{设计软件系统的逻辑结构}}
没有“结构化”设计的软件系统，以后根本谈不上什么维护升级，就是简单的除虫也成了个问题，就算软件代码写得再好也只是“乱码”，所以要写好软件，概要设计是非常关健的，具体工作如下：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item (1) 采用某种设计方法，将一个复杂的软件系统按功能划分成许多有关系条理的模块。
\item (2) 准确定义每个模块的功能。
\item (3) 确定模块之间的调用关系。
\item (4) 对每个模块确定其接口（要以文档对接口的数量，顺序，作用，属性等进行详细说明，这很重要）。
\item (5)对所设计的模块进行评估，尽量找出错误和不合理的地方，进行改正（这比软件做出来后的修改要容易得多）。
\end{itemize}
软件结构的设计是非常重要的工作，它直接影响以后的详细设计和编码，不合理的结构将有可能把未完成的系统埋葬，所以应选用能力强和经验比较丰富的程序员来做。
\subsubsection{\textbf{设计软件所需要的数据库系统}}
一个好的软件一般都有一个专门为其设计的数据库系统，数据库的设计已自成理论体系，但一般数据库的设计工作可分为数据结构设计和数据库设计，数据库设计还分为概念设计、逻辑设计和物理设计，每一项都有很多的知识和原则，对应具体项目具体分析。		
\subsubsection{\textbf{编写概要设计文档}}
软件工程很强调文档的作用，概要设计也一样，要做好这阶段应有的文档才算是基本完成任务，对文档的编写主要是概要设计和数据库设计说明书，另外还有对需求分析阶段的用户手册和测试计划进行必要的修改，以更合理的对应所设计的软件系统。
\subsubsection{评审}
这主要是对这阶段工作的一次回顾，看看有什么遗漏或错误的地方没有。评审也有很多不同的技术性手段，可一般都将重点放在功能、性能、可行性、接口正确性等方面。
\subsection{\textbf{详细设计}}
详细设计就是把我们在概要设计里所划分出来的模块要实现的功能用相应的设计工具详细的描述出实现步骤来，也即是写出代码的算法，在详细设计里所有的表述无论是语言或是图表，都应做到有精确的唯一解释，绝不允许出现有“二义性”或“多义性”的表述，所谓精确的表述就是要做到无论这份文档到了那个程序员手中，他都能看得懂文档的含意而且只有一个含意，不可能再解读出第二层意思来。

详细设计的任务就是为每个模块所要完成的功能进行具体而精确的描述，要根据功能描述再转化成精确的、结构化的软件过程描述，软件过程描述一般可直接对应到相应的代码，也就是以后程序员会根据这些过程描述来编写程序代码，具体如下：
\begin{itemize}
\setlength{\itemsep}{0pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\item (1)为每个模块进行详细的算法设计。这是需要用相应的工具来完成的，因为自然语言通常很容易具有“二义性”，而工具能做到含义唯一性。
\item	(2)为模块内的数据结构进行设计。
\item	(3)对数据库进行物理设计。这不是实现数据库，而是设计出数据库的具体物理结构。
\item	(4)其它设计（前期特殊代码设计、I/O格式设计、界面友好设计等）。
\item	(5)编写详细设计说明书。
\item	(6)评审。
\end{itemize}

最后详细设计有两个主要输出：对概要设计中标识的组件的逻辑设计和系统的单元测试。
\section{\textbf{编码实现}}
在软件编码阶段，先由开发人员共同讨论确定软件代码评审表，然后开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。
\section{\textbf{测试}}
测试是对内部实现逻辑测试，以发现错误；对外部进行功能测试，以确保所有输入都生成与需求一致的实际输出。测试是动态验证软件的过程。测试工作依据测试对象的不同，可分为单元测试、集成测试、系统测试和验收测试4种。无论哪种测试都包括制定测试计划、编写测试用例、准备测试环境、执行测试用例和测试结果分析5个活动。不同测试的目标、志新世纪有所不同，具体如下：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item	单元测试的主要执行者是开发人员或测试人员，根据详细设计的工作成果设计各模块的单元测试用例。在编码工作中，通过分别运行单元测试用例验证各模块的实现逻辑的正确性。通常情况下，单元测试计划在纤细设计工作的中后期完成，各模块单元测试用例的设计与执行则在详细设计的后期或编码前完成。
\item	集成测试的主要执行者是软件测试人员，根据系统设计成果首先制定集成测试计划、设计集成测试用例、构造集成测试环境；然后将已通过单元测试的模块，按照一定的顺序逐步集成，测试其接口的正确相信，直至形成一个完整的软件系统。
\item	系统测试的主要执行者是系统测试人员，其主要目的是验证完整的软件系统在预定的硬件环境下的执行情况，这时的硬件环境可以是真实的，也可以是构造的测试环境。系统测试计划根据需求分析和系统设计工作的成果编写，测试用例的设计可在需求分析之后启动，在进行系统测试之前完成。
\item	验收测试的执行者是客户，客户根据系统需求和开发合同，从实际的生产数据中抽取典型的数据作为测试数据，全面验证软件系统合同的满足情况。但限于客户/用户的实际水平，通常是开发方帮助用户来编写测试用例、协助其完成整个测试过程。系统测试用例与验收测试用例的差别很小。\\
通过系统测试的软件江北打包成全功能的可运行的软硬件系统被部署到用户现场，准备进行验收测试，此时还伴随用户培训等活动的展开。
\end{itemize}
\subsection{\textbf{目标}}
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 1、软件测试人员的基本目标是发现软件中的错误；
\item 2、软件测试人员所追求的是尽可能早地找出软件的错误；
\item	3、软件测试人员必须确保找出的软件错误得以关闭。
\end{itemize}	
\subsection{\textbf{常见测试}}
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 回归测试、功能测试
\item 压力测试、负载测试
\item	性能测试、易用性测试
\item	安装与反安装测试、回复测试
\item	安全性测试、兼容性测试
\item	内存泄漏测试、比较测试
\item	Alpha测试、Beta测试
\end{itemize}
\subsection{\textbf{测试阶段成果}}
《软件测试报告》《软件缺陷报告》
\part{\textbf{支持过程}}
支持过程是指为了保证基本过程的正常运行、目标的实现和质量的提高所从事的一系列活动（过程），他们可被主过程的各个部分或全部采用，并由使用它们的组织负责实施，也可由用户负责实施。这些过程包括文档、配置管理、质量保证、验证、确认、联合评审、审核、问题解决。
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item ①文档过程：一组活动，用于记录任何其他过程所产生的特定信息。
\item ②配置管理过程：一组活动，用于捕获和维护开发过程中所产生的信息和产品，以便于后序开发与维护。
\item ③质量保证过程：一组活动，用于客观地保证产品和相关过程与需求文档和计划保持一致。
\item ④验证过程：用于检验产品的活动；是用于实现的需求定义和产品规范，确定某项活动的软件产品是否满足所给定或所施加的要求和条件的过程。验证过程一般根据软件项目需求，按不同深度确定验证软件产品所需要的活动，包括分析、评审和测试，其执行具有不同程度的独立性。为了节约费用和有效进行，验证活动应尽早与采用它的过程（如软件获取、开发、运行和维护）相结合。该过程的成功实施期望带来如下结果：
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item 根据需要验证的工作产品所定制的规范实施必要的检验活动。
\item 有效地发现各类阶段性产品所存在的缺陷，并跟踪和消除缺陷。
\end{itemize}
\item ⑤确认过程：用于确认产品的活动。确认活动是一个确定需求和最终的、已建立的系统或软件是否满足特定的预期用途的过程，集中判断产品中所实现的功能、特性是否满足客户的实际需要。确认过程和验证过程构成了软件测试缺一不可的组成部分，
\item ⑥联合评审过程：有两方使用的、评估其他活动的状态和产品的活动。联合评审过程是评价一项活动的状态和产品所需遵循的规范和要求。
\item ⑦审核过程：用于确认项目与需求、计划与合同的符合程度。审核过程是判断各种软件活动是否符合用户需求、质量计划和合同随需要的其他各种要求。
\item ⑧问题解决过程：一组在分析和根除存在问题时所要执行的活动。不论问题的性质或来源如何，这些问题都是在实施开发、运行、维护或其他过程期间暴露出来的，需要得到及时修正。问题解决过程的目的是计时提出相应对策、形成文档，以保证所暴露的问题得到分析和解决，并能预见这一问题领域的发展趋势。
\end{itemize}
\part{\textbf{组织过程}}
组织过程是一个组织用来建立、实施一种基础结构、并不断改进该基础结构的过程，包括管理、基础、改进、培训等过程。

	%管理过程
	%基础设施过程
	%改进过程
	%培训过程
构造一个软件系统时，软件项目管理是对该软件生存周期的所有活动（除交付后的维护轰动之外）的全面管理。它将人力、资金、技术组织到最优过程中以求按时、按质交付产品，项目管理包括的主要活动有：\\ \\ \\
\begin{center}
\psset{shadowcolor=black!70,shadowangle=-90,shortput=nab}
\begin{psmatrix}[rowsep=0.7,colsep=0.7]

\rput(-6,1){\rnode{A}{\psframebox{项目启动与建议}}} \rput(-2,1){\rnode{B}{\psframebox{项目规划与进度}}} \rput(2,1){\rnode{C}{\psframebox{项目组织与执行}}}
\rput(2,0){\rnode{D}{\psframebox{项目监督与评价}}}\rput(6,0){\rnode{E}{\psframebox{项目交付与总结}}} \\%2

\end{psmatrix}
\ncline{->}{A}{B}
\ncline{->}{B}{C}
\ncangle[angleA=-90,angleB=90]{->}{C}{D}
\ncangle[angleA=90,angleB=-90]{->}{D}{C}
\ncline{->}{D}{E}
\ncangle[angleA=180,angleB=-90]{->}{D}{B}
%\rput[tl](0,3){\rnode{A}{\psframebox{Node A}}}
%\rput[br](4,0){\ovalnode{B}{Node B}}
%\ncdiag[angleA=-90, angleB=90, arm=.5, linearc=.2]{A}{B}
\end{center}	
	软件项目的生存周期包括项目启动、项目规划、项目实施和项目收尾4个阶段。
\begin{itemize}
 \setlength{\itemsep}{0pt}
 \setlength{\parskip}{0pt}
 \setlength{\parsep}{0pt}
\item ①项目启动:项目启动是确定项目的目标和范围。在项目开始阶段，项目管理者负责定义项目的商业需求，确定项目的目标和实现方法，大致估算项目的进度，编写完成项目建议书。
\item	②项目规划:项目规划是建立项目的基准计划。在项目规划阶段，项目管理者要明确项目的各种活动、里程碑和可交付的成果，制定软件开发计划。\\
软件开发前首先要选定作为标准输入的过程模型，然后定义项目的开发过程。过程模型是制定项目计划的基础。为了指定计划，首先要顾及项目的复杂性（大小、功能点多少），从而导出工作量和预算成本；初步按此过程模型或已定义的过程安排本项目的主要活动（框架活动）及质量保证活动（主要的评审对象），直至交付前后的培训，确立重要的里程碑；组件开发小组，明确组间关系；进行分线分析和评估，按风险分析报告调整过程活动；组件SQA小组，指定质量保证计划；将质量保证活动插入到项目计划。项目计划是围绕过程模型不断细化、反复求精的过程。\\项目计划随着各项活动开展不断丰富，他指标数该做哪些事情（人物），什么时候必须完成才能使整个项目按期完成。其中，根据人力情况有些是可以并行做的，有些是实施中发现比预想计划工作量大（或小），甚至出现了瓶颈。这些都要靠项目调度和追踪来妥善处理。项目追踪是项目计划实施的指南和保证，是项目管理的中心活动。
\item	③项目实施:项目实施是按照计划执行和监控项目。项目管理者根据项目任务的要求选择合适的开发人员，组建项目团队和协调项目资源，按照计划执行和推进整个项目。在项目执行过程中，项目管理者必须密切关注项目的进展情况，综合评价整个项目的实际进展，及时发现和报告实际情况与计划的偏差，在必要的情况下采取纠正行动，同时控制和管理鲜蘑菇的变更。
\item	④项目收尾:项目收尾是交付产品以及总结经验教训。项目团队进行正式的项目交付工作，客户对所交付的软件产品进行验收，项目团队培训用户并移交文档，最后分析和总结项目的经验和教训。
\end{itemize}
\part{实验总结}
这次实验主要内容是抒写软件基本过程，支持过程和组织过程的基本内容。由于自身软件项目经验较少，对软件过程不清晰，所以大部分内容是从网上和书本上找到的。不过，在整理他人的内容的过程中也开始慢慢理解软件开发过程。总之，通过本次实验，对软件过程的基本过程、支持过程和组织过程都有了进一步的了解，收获较大。
\end{document}