关于开源软件:
开源软件是一种重要的可复用软件制品来源,当前得到广泛复用的许多软件开发框架以及软件的组件都是开源软件。
软件的开源确确实实带来了不少的好处,难道开源不会引起一系列的版权争议吗?
如果出了问题,谁来负责呢?尽管理论上这听起来很合理,但如果我们一开始就使用可信赖的软件产品,远比在遭受经济损失之后才去控告软件供应商要好的多。几乎所有的主要软件公司都利用最终用户许可证的支持来解决一些由于他们软件的问题而带来的可能要负责的困扰。Microsoft和IBM公司有着庞大的,一流的法律职员,使得顾客的控诉不可能成功。在将来法律可能会越来越偏向软件供应商。
在购买商业软件包上我们已经拥有巨大的投资,这仅仅是“必然花费谬误”的一种形式。软件许可证,好像为写字楼付的租金,是一些消费,但不是投资。如果别的产品能很好的以较低的成本实现你的组织的需要,那么过去把钱花费在低级的软件上对决策不应该产生影响。记住,你可能面临严重的政治上的反对,它来自于那些选择了赞成使用昂贵的,低级的产品,而不愿意承认他们的错误的守旧者。同时,考虑到它们可能被再次扩展,在训练职员和相关基础设施上的投资是完全合理的。
关于软件需求
软件需求是用户解决问题或达到目标所需条件或权能。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面或所述条件或权能的文档说明。它包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。
将来的软件需求必然是复杂的,假如我们不形成体系,而是杂乱无章的为需求人服务,就会形成雇佣兵体系,这对一个行业的远大发展是不理想的,一个好的环境难道不更利于发展吗?
而且有时候也会有优秀的用户遇到糟糕的需求,用户参与不足,用户需求不明晰,因为用户没有参与过开发,相关说明无法解释清楚而发生的情况,营销人员或经理经常喜欢只给出一个粗略的说明,希望开发人员在开发过程中充实它。用户方面会不会真正成为问题?
关于软件的集成与发布
当前,在很多软件项目中集成与发布过程仍然主要以手工的方式完成。开发人员需要手工合并其他开发人员的代码,再手工编译代码并手工运行单元测试。交付团队需要手工安装与配置软件所需的操作系统、数据库、应用服务软件以及第三方软件,并手工将软件与相关的数据复制到试运行环境与生产环境,最后启动软件。在上述手动集成与发布过程中,任何一个步骤都有可能出错,而且不可避免地引入各种人为失误,导致集成与发布过程不可重复也不可靠,增加开发团队与交付团队及时交付的难度,同时浪费大量时间。此外,在这种手动集成与发布过程中,软件在开发过程中一般处于不可运行状态,而往往在完成大部分开发工作时,才第一次有了可运行可工作的版本,才第一次被部署到试运行环境进行测试,导致到了集成与发布阶段才发现软件并不能满足客户的需求、开发环境与生产环境不一致所导致的各种错误,增加修复错误的代价,甚至推迟发布日期。为了避免这些问题,要尽快地向用户交付有用的、可运行、可工作的软件。
软件的集成与发布是否能够形成一条长期的流水线?形成了流水线,又是否能够长期存在呢?会不会因为版本变动而需要重新设计流水线,又或者公司是否能够长期担负这种流水线?
本来产品是没问题的,程序员甲和程序员乙分别做的改动也是没问题的,但是合在一起,就可能有问题吗?
如果没人使用版本控制工具,那么版本变动,是否会导致重要文件丢失呢?
以上便是我在读《现代软件工程基础》而想到的问题。