看到实践这个词，明白这是什么意思。实践就是实行的意思吧。对软件工程实践也有个模糊的概念。但还要想弄清这个实践是什么意思。上百度百科查出来一段：
实践是人类自觉自我的一切行为。内在意识本体与生命本体的矛盾是推动人类自我解放的根本矛盾，其外在化为人类个体及组织、阶级通过生产关系联系的整体对于自然及个体间或者集体关系、阶级关系形成的解放活动。实践只有在自觉的意识下才是人性的、人格的。
真是复杂的哲学啊！
在软件工程中的实践给出的概念：实践是软件计划和开发时需要考虑的方方面面，包括概念、原则、方法和工具等。它表达了一些细节——需要考虑的技术问题以及怎样实现软件过程中的东西，即实际构造高质量软件所必需的东西。
软件过程模型由一组活动组成，这些活动确定了软件工程实践的框架。通用过程框架活动（沟通、策划、建模、构造和部署）和普适性活动确定了软件工程工作的框架。
软件工程实践核心原则：
（1）存在价值
软件系统因能给客户提供价值而有存在的价值，所有的决定都要基于这个思想。
（2）保持简洁
所有的设计都应该尽可能简洁，但不是简化。
（3）维护视图
清晰的视图是软件项目成功的基础。
（4）生产者要让消费者理解
软件系统必定由开发者以外的人员使用、维护和编制文档，这就必须要让别人理解你的系统。因此，已完成了说明、设计、实现，别人必须要弄懂你在做什么。
（5）面向未来
生命期持久的系统拥有更多的价值。真正具有工业实力的软件系统必须持久耐用。永远不要把自己的设计局限于一隅。构建系统过程中准备所有可能方案以解决普遍问题，而不是仅着眼于某个特定问题的一个方案，这会为将来整个系统的利用提供可能。
（6）计划复用
高水平的复用系统是开发软件系统过程中很难实现的一个目标，代码和设计复用是面向对象技术带来的重要好处。在复用前先策划可以降低成本，并增加可复用构件以及构件化系统的价值。
（7）认真思考
在行动之前清晰、完整的思考通常能产生更好的结果。
沟通实践原则
高效的沟通是一个软件工程师所面临的最具挑战性的工作。
（1）倾听。（2）有准备的沟通。（3）需要有人推动。（4）最好当面沟通。（5）记录所有决定。（6）保持通力协作。（7）聚焦并协调话题。（8）采用图形表示。（9）继续前进原则。（10）谈判双赢原则。
以上的原则，其实大部分都在遵循。以以往的沟通经历来说倾听，当面沟通，继续前进，双赢是最重要的。
策划实践原则
沟通活动协助软件开发团队定义全局目标，但理解这些目标与为达到这些目标制定计划并不是一回事。策划活动包括一系列的管理和技术实践，可以为软件开发团队定义一个便于他们向着战略目标和战术目标前进的路线图。
过度计划是一种时间的浪费，但适度的计划是制止混乱的良方。制定计划应该遵循策划实践原则：
（1）理解项目范围。范围为团队提供一个目的地。（2）客户参与策划。客户定义了一些优先权，确定了项目约束。为了适应这种情况，必须常商谈交付的顺序、时间线以及其他与项目有关的问题。（3）采用迭代计划。（4）基于已知估计。提供一种关于工作量、成本和任务工期的指标。（5）计划考虑风险。对已经明确了容易发生且影响最大的风险，制定必需的应急计划。项目计划应该可以调整以适应可能发生的变化。（6）保持脚踏实地。（7）调整计划粒度。粒度主要指项目计划的细节。（8）制定计划确保质量。（例如正式技术评审）。（9）描述如何适应变化。（10）经常跟踪，校正计划。
建模实践
在软件工程中，要创建两类模型：分析模型和设计模型。分析模型通过信息域、功能域、行为域三个不同域描述软件来表达客户的需求。设计模型表述了可以帮助开发者高效开发软件的特征：架构、用户界面以及构件细节。
分析建模实践原则
每一个分析方法都有其独立观点，但所有的分析方法都具有共同的操作原则：
（1）必须描述并理解问题的信息域
信息域包括流入系统的数据，流出系统的数据以及收集和组织永久性数据对象。
（2）必须确定软件所要实现的功能
功能可以在不同抽象层次上描述，必须涉及从整体意图到过程细节的描述。
（3）必须描述软件的行为。
软件行为受外部环境交互驱动。
（4）描述信息、功能和行为的模型必须以一种能揭示分层细节的方式分解开来。
（5）分析任务应该从本质信息转向实现细节。
设计建模实践原则
许多方法可以导出不同软件设计要素。部分方法是数据驱动的，通过数据结构来得到程序构架和处理构件；另外一部分是模式驱动的，使用问题域信息来开发架构风格和处理模式；还有一些方法是面向对象的，使用问题域来创建数据结构以及操作这些数据结构的方法。无论使用什么方法，都使用同一套设计原则：
（1）设计可追溯到分析模型。
分析模型描述了问题的信息域，用户可见的功能，系统的行为以及一套分析类。分析类把业务对象和为这些对象服务的方法结合在一起。设计模型将这些信息转化为系统架构：一套实现主要功能的子系统以及一套实现分析类的构件级设计。除去与软件基本构造相关的设计外，设计模型的各个元素都应该能在分析模型上找到其相应的部分。
（2）经常关注待建系统的架构
软件架构是系统骨架，决定着系统接口、数据结构、程序控制和行为、测试的方法以及在建系统的可维护性等。
（3）数据设计与功能设计同等重要
（4）必须设计接口（包括内部接口和外部接口）
（5）用户界面设计必须符合最终用户要求。
（6）功能独立的构件级设计
（7）构件之间以及构件与外部环境之间松散耦合
（8）设计表述应该做到尽可能易于理解
（9）设计应该迭代式进行。每次迭代，设计者都应该尽力简化。
构造实践原则
构造活动包括一系统编码和测试任务，从而为向客户和最终用户交付可运行软件做准备。最初的测试为构件级，称为单元测试。在构建系统时进行集成测试；测试系统是否完全按照需求开发进行确认测试。由客户检验系统是否按照需求实现了所有功能进行验收测试。
编码实践原则
（1）准备原则：在写代码前，确保：理解了要解决的问题；理解基本设计原则和概念；编程语言和IDE环境；构件级编码完成后进行单元测试。
（2）编码原则：在开始编码时，确保：遵循结构化编程方法约束算法；选择满足设计要求的数据结构；理解架构并开发相符接口；保持逻辑尽可能简单；便于测试的方法开发嵌套循环；命名规则；注释代码
（3）完成第一阶段的编码之后，要确保：适当的代码走查；单元测试，改正错误；重构
测试实践原则
测试的目标就是发现错误。好的测试用例能最大限度的发现尚未发现的错误。
（1）所有测试都应该可以追溯到用户需求
（2）测试计划应该远在测试开始前就开始着手。
（3）将Pareto原则应用于软件测试。这个原则认为：在测试中，80%的错误都可以在大概20%的程序构件中找到根源。
（4）测试应该从微观开始，逐步转到宏观。
（5）穷举测试是不可能的。
部署实践原则
部署活动包括三个动作：交付、支持和反馈。软件增量交付对于任何一个软件项目来说都是重要的里程碑。准备交付一个软件增量时所应该遵从的原则：
（1）客户对于软件的期望必须得到管理。
（2）完整的交付包应该经过安装和测试。
（3）技术支持必须在软件交付之前就确定下来。
（4）必须为最终用户提供适当的说明材料。
（5）有缺陷的软件应该先改正再交付。