Chapter One 软件和软件工程

原创
2014/04/21 20:39
阅读数 268

要点浏览


概念

    软件是开发并维护的产品。在不同体系的设备上运行,并产生各种结果,以及各种可以copy及store的描述信息。

    软件工程包括过程、各种方法/实践以及各种工具,以协助相关人员构建高质量的软件产品。

人员及责任

    软件工程师开发并为软件提供技术支持。

重要性

    软件无处不在。软件工程可以构造更高效、高质量的复杂软件系统。

步骤

    开发软件就像开发任何成功的产品一样,需采用灵活、可适应的针对软件的开发过程,完成可满足使用者需求的高质量的软件产品。这就是软件工程化方法。

工作产品

    软件工程师角度;最终用户角度。


1.1 软件的本质

软件扮演着信息转换的角色:产生、管理、获取、修改、显示或者传输各种不同的信息。

本身是产品,也是其产生的信息的载体(生产信息,并存储及处理信息)。信息也是软件产品的重要组成部分。


软件特性:

    1. 软件是设计开发的,而不是传统意义上生产制造。

(软件的功能和逻辑是人的思想的产出。虽然存在客观实际的要求,但是归纳为需求时就会产生严重的问题。导致需求的不断变更。熟悉业务,并熟悉一定的软件特点,能够抽象出一个比较完整的系统结构和需求。

软件是人的思想的产出、)


    2. 软件不会磨损。

软件的不断变更时软件退化的根本原因。

(软件是否可以通过套层的架构来实现部分功能升级?现在的框架是不是本身就是在架构基础上进行分层套接?

分层模式的好处和坏处,以及随着复杂性提高,其优势和劣势的放大效应。后期维护,数据备份和恢复。)

    3. 虽然整个工业向着给予构建的构造模式发展,但是大多数软件仍是根据实际的顾客需求定制的。

在软件领域,中间件技术现在貌似还不是很成熟。


系统软件,应用软件,工程/科学软件,嵌入式软件,产品线软件,Web应用软件,人工智能软件

新方向:开放计算,网络资源,开源软件。


遗留软件

    当代软件工程的目标是“修改基于进化理论建立的方法论”,即“软件系统不断经历变更,新的软件系统从旧系统中建立起来,并且……新旧所有系统都必须具有互操作性和协调性。”


1.2 Web应用的特性

    网络密集性 network intensiveness

    并发性 concurrency

    无法预知的负载量  unpredictable load

    性能 Performance

    可用性 availability

    数据驱动 data driven

    内容敏感性 content sensitive

    持续演化 content evolution

    响应即时性 immediacy

    安全性 security 单个客户通讯端安全 服务器端安全

    美观性 aesthetics


1.3 软件工程

    在制定解决方案之前要理解问题

    设计是软件工程中的关键之一。

    质量和可维护性都来自于好的设计。


软件工程的定义

    Fritz Bauer: 软件工程是:建立和使用一套合理的工程原则,以便经济地获得可靠的、可以在实际机器上高效运行的软件。

    IEEE[IEEE93a]: 软件工程是:(1) 将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。(2) 在(1)中所描述方法的研究

    支持软件工程的根基在于质量关注点(quality focus)。

    软件工程的基础是过程(Process)。

    软件工程方法(method)为构建软件提供技术上的解决方法(“如何做”)。涵盖:沟通、需求分析、设计建模、编程、测试和技术支持。

    计算机辅助软件工程 computer-aided software engineering.


1.4 软件过程

    活动(Activity)主要实现宽泛的目标(如与利益相关者进行沟通),与应用领域、项目大小、结果复杂性及实施软件工程的重要程度没有直接关系。

    动作(action)包含了主要工作产品(如体系结构设计模型)生产过程中的一系列任务。

    任务(task)关注小而明确的目标,能够产生实际产品(eg.如果构建一个单元测试)。


软件工程的过程框架

    沟通: 技术工作开始之前,和客户(及其他利益相关者!!)的沟通和协作是极其重要的。这样做的目的是理解利益相关者的项目目标,并收集需求以定义软件特性和功能。

    策划:如果有地图,任何复杂的旅程都可以变得简单。策划活动就是为软件项目创建一个“地图”,制定软件项目计划指导团队的项目旅程。软件项目计划,主要是定义何描述软件工程工作,包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划

    建模:首先会有一个框架草图,辅助理解整个项目的体系结构以及各个构建的关联和连接,以及其他特性。可以通过把草图不断细化来更好的理解问题、寻找解决方案。软件工程师也是如此。

    构建:包括编码(手写/自动生成)和测试问题。

    部署:软件(全部或者部分增量)交付到用户,用户进行评测并反馈意见。

    框架活动一般可以迭代应用,每次项目迭代会产生一个软件增量(software increment)

贯穿始终的普适性活动(主要关注:项目管理、跟踪和控制)

    软件项目跟踪和控制:评估进度,采取措施保证进度。

    风险管理:对影响项目成功和质量的风险的评估。

    软件质量保证:确定和执行软件质量保证的活动。

    技术评审:评估产品,尽量在错误传播到下一个活动前,发现并清除错误。

    测量:定义和收集过程、项目和产品的度量,以帮助团队在发布软件的售后满足利益相关者的要求。同时,测量还可以与其他框架活动和普适性活动配合使用。

    软件配置管理:在整个软件过程中,管理变更所带来的影响。

    可复用管理:定义产品复用的标准(包括软件构件),并建立构建复用机制。

    工作产品的准备和生产:包括生成产品(诸如建模、文档、日志、表格和列表等)所需要的活动。


    软件工程过程不是教条的法则,要求软件团队机械的执行,而应该是灵活可调节以适应现实情况(根据软件所需解决的问题、项目特点、开发团队和组织文化等进行适应性调整)

    实施时需要考虑的方面:

    1. 活动、动作和任务的总体流程,以及相互依赖关系。

    2. 在每一个框架活动中,动作和任务细化的程度。

    3. 工作产品的定义和要求的程度。

    4. 质量保证活动应用的方式。

    5. 项目跟踪和控制活动应用的方式。

    6. 过程描述的详细程度和严谨程度。

    7. 客户和利益相关者对项目参与的程度。

    8. 软件团队所赋予的自主权。

    9. 队伍组织和角色明确程度。


1.5 软件工程实践

    通用的框架活动(沟通、策划、建模、构造和部署)和普适性活动构成了软件工程工作的体系结构的骨架。

1.5.1 实践的精髓

    《How to Solve it》

    1. 理解问题(沟通和分析)

        It's tough, not easy as you thought. 基本的几个需要回答的问题:

        谁讲从问题的解决中获益?也就是说,谁是利益相关者?

        有哪些是未知的?哪些数据、功能、特征和行为是解决问题必需的?

        问题可以划分吗?是否可以描述为更小、更容易理解的问题?

        问题可以图形化描述吗?可以建立分析模型吗?

    2. 计划解决方案(建模和软件设计)

        Don't hurry. Take your time in a better way. 以前曾经见过类似问题吗?在潜在的解决方案中,是否可以识别一些模式?是否已经有软件实现了所需要的数据、功能、特征和行为?

        类似问题是否解决过?如果是,解决方案所半酣元素是否可以复用?

        可以定义子问题吗?如果可以,子问题是否已有解决方案?

        能用一种可以很快实现的方式来描述解决方案吗?能构建出设计模型吗?

    3. 实施计划(代码生成)

        Done is valuable, really really very valuable. 可能不是最好的解决方案,但可以保证在实施过程中不至于迷失方向。

        解决方案和计划一致吗?源码是否可追溯到设计模型?

        解决方案的每个组成部分是否可以证明正确?设计和代码是否经过评审?或者更好的算法是否经过正确性证明?

    4. 检查结果的正确性(测试和质量保证)

        Introspection is good quality. Confirm is indeed needed.无法保证前面的工作都是完美的,所以要通过其他方式/测试来发现尽可能多的错误。需要回答下列问题:

        能否测试解决方案的每个部分?是否实现了合理的测试策略?

        解决方案是否产生了与所要求的数据、功能、特征和行为一致的结果?是否按照项目共同利益者的需求进行了确认。


1.5.2 一般原则

        “原则”在字典的定义是:“某种思想体系所需要的重要的根本规则或者假设”。无论关注哪个层次,原则都可以帮助我们建立一种思维方式,进行扎实的软件工程实践。因此,原则非常重要。

    David Hooker提出的七个关注软件工程整体实践的原则:

        1. 存在价值

        在开始一个软件项目之前,应首先确保软件具有商业目标并且让用户体会到它的价值。

        2. 保持简洁

        所有的设计都应该尽可能简洁,但不是过于简化。这样更易于理解和易于维护。简洁比所有巧妙的措辞更加美妙。在注意每个原则的本意时,也要注意它实际的好处,如果这些好处微不足道,你还需要坚持吗?特别是在初创时。

        3. 保持愿景

        原则的一致性是系统品质保证的重要推动力。授权体系架构师,时期能够保持愿景,并保证系统实现始终与愿景保持一致,这对项目开发成功至关重要。

        4. 关注使用者

        关注相关人员,方便处理,有利于达成系统最终目标。将这些理念落实为具体的措施,穿插进开发的每个过程中。

        关注使用情况和逻辑:最终采用的算法是应对极端情况,还是应对平时的普通情况?关注点和重点要重合。

        5. 面向未来

        软硬件更新换代很快,但是真正具有“产业实力”的软件系统必须持久耐用。永远不要把自己的设计局限于一隅,要经常问问:“如果出现……应该怎样应对”,构建可以解决通用问题的系统,为各种可能的方案做好准备,这很可能会提高整个系统的可复用性。

        6. 计划复用

        复用既省时又省力。但是需要前瞻性的设计和计划。提前做好复用计划,将减低开发费用,并增加可复用构建以及构件化系统的价值。

        7. 认真思考

        如果仔细思考过后,还是把事情做错了,那么这就变成了很有价值的经验。思考的一个副作用是学习和了解本来一无所知的事情,成为研究答案的起点。把“认真思考”作为明确的思想应用到系统中,就产生了价值。

        使用钱六条原则需要认真思考,浙江带来巨大的潜在回报。

1.6 软件神话

    大部分时候,我们都更重视和屈服于诱惑,也就是是选择短期目标。而忘记自己最初的那个长期目标。短期目标和长期目标的取舍,决定了软件的脆弱。(软件开发的所有过程都是人为控制和控制人,为避免做出错误判断,就需要制定一个合理的长远计划,一个合理的制度,然后坚定的执行。而非屈服于短期的压力和诱惑。)

    软件既有自身的从业人员的问题,也有来自其他行业的误解。

    

展开阅读全文
打赏
0
2 收藏
分享
加载中
更多评论
打赏
0 评论
2 收藏
0
分享
返回顶部
顶部