希赛网 · 知识导航  
 
    软考英语    通信工程英语    软件工程    项目管理    操作系统    数据库系统    计算机网络    IT新技术    硬件数码    应用系统    计算机基础    IT职场  
希赛网 > IT英语 > 软件工程 > 软件工程新方法和技术简介

软件工程新方法和技术简介

www.educity.cn   发布者:jy5212   来源:网络转载   发布日期:2013年08月27日   

From Nothing, to Monumental, to Agile

Most software development is a chaotic activity, often characterized by the phrase "code and fix". The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new features to the system. Furthermore bugs become increasingly prevalent and increasingly difficult to fix. A typical sign of such a system is a long test phase after the system is "feature complete". Such a long test phase plays havoc with schedules as testing and debugging is impossible to schedule.

We've lived with this style of development for a long time, but we've also had an alternative for a long time: Methodology. Methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient. They do this by developing a detailed process with a strong emphasis on planning inspired by other engineering disciplines - which is why I tend to refer to them as engineering methodologies.

Engineering methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down.

As a reaction to these methodologies, a new group of methodologies have appeared in the last few years. For a while these were known a lightweight methodologies, but now the accepted term is agile methodologies. For many people the appeal of these agile methodologies is their reaction to the bureaucracy of the monumental methodologies. These new methods attempt a useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff.

The result of all of this is that agile methods have some significant changes in emphasis from engineering methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.

However I don't think this is the key point about agile methods. Lack of documentation is a symptom of two much deeper differences:

Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the the skill of the development team, so the role of a process is to support the development team in their work.
In the following sections I'll explore these differences in more detail, so that you can understand what an adaptive and people-centered process is like, its benefits and drawbacks, and whether it's something you should use: either as a developer or customer of software.

Predictive versus Adaptive

Separation of Design and Construction

The usual inspiration for methodologies is engineering disciplines such as civil or mechanical engineering. Such disciplines put a lot of emphasis on planning before you build. Such engineers will work on a series of drawings that precisely indicate what needs to be built and how these things need to be put together. Many design decisions, such as how to deal with the load on a bridge, are made as the drawings are produced. The drawings are then handed over to a different group, often a different company, to be built. It's assumed that the construction process will follow the drawings. In practice the constructors will run into some problems, but these are usually small.

Since the drawings specify the pieces and how they need to be put together, they act as the foundation for a detailed construction plan. Such a plan can figure out the tasks that need to be done and what dependencies exist between these tasks. This allows for a reasonably predictable schedule and budget for construction. It also says in detail how the people doing the construction work should do their work. This allows the construction to be less skilled intellectually, although they are often very skilled manually.

So what we see here are two fundamentally different activities. Design which is difficult to predict and requires expensive and creative people, and construction which is easier to predict. Once we have the design, we can plan the construction. Once we have the plan for the construction, we can then deal with construction in a much more predictable way. In civil engineering construction is much bigger in both cost and time than design and planning.

So the approach for software engineering methodologies looks like this: we want a predictable schedule that can use people with lower skills. To do this we must separate design from construction. Therefore we need to figure out how to do the design for software so that the construction can be straightforward once the planning is done.

So what form does this plan take? For many, this is the role of design notations such as the UML. If we can make all the significant decisions using the UML, we can build a construction plan and then hand these designs off to coders as a construction activity.

But here lies the crucial question. Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

All of this brings a few questions to mind. The first is the matter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing. The models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. While this is helpful it leads to errors in the design that are often only uncovered during coding and testing. Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software.

Another issue is that of comparative cost. When you build a bridge, the cost of the design effort is about 10% of the job, with the rest being construction. In software the amount of time spent in coding is much, much less McConnell suggests that for a large project, only 15% of the project is code and unit test, an almost perfect reversal of the bridge building ratios. Even if you lump in all testing as part of construction, then design is still 50% of the work. This raises an important question about the nature of design in software compared to its role in other branches of engineering.

These kinds of questions led Jack Reeves to suggest that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker. Indeed anything that you can treat as construction can and should be automated.

This thinking leads

标签: 软件工程
1 2
   主编推荐
全局导航
IT认证学院
Adobe认证Cisco认证H3C认证IBM认证IT认证资讯Java认证Linux认证Microsoft认证Oracle认证华为认证
IT英语
IT新技术操作系统基础英语计算机网络软件工程软考英语数据库系统通信专业英语项目管理英语应用系统硬件数码职场英语
程序开发学院
.NETC语言_C++语言DelphiPowerBuilderWeb开发嵌入式开发移动开发游戏开发PHPPythonPerlRuby
等考学院
考试大纲二级考试经验二级模拟试题一级考试资料二级考试资料一级模拟试题三级模拟试题四级模拟试题一级考试经验三级考试经验四级考试经验四级考试资料三级考试资料等级考试动态
软件工程学院
CASE工具构件与中间件软件测试软件过程改进软件设计软件外包需求分析软件质量保证系统分析与建模系统规划业界观点敏捷开发
软考学院
程序员电子商务设计师法律法规考试大纲考试政策历年试题软件评测师软件设计师软考英语数据库系统工程师网络工程师网络管理员网络规划设计师系统分析师系统架构设计师信息技术处理员信息系统管理工程师信息系统监理师
通信学院
初级通信工程师传输与接入高级通信工程师互联网技术交换技术考试大纲考试动态考试题库设备环境通信法规终端与业务综合能力
网络工程学院
交换技术接入技术路由技术实施案例网络布线网络存储网络服务器网络管理无线网络系统应用网络协议网络设备
项目管理学院
系统集成项目管理工程师信息系统项目管理师CPMP考试IPMPPMP考试prince2认证项目采购管理项目成本管理项目范围管理项目风险管理项目沟通管理项目配置管理项目人力资源管理项目时间管理项目管理案例项目管理动态项目管理工具项目经理项目整合管理项目质量管理项目干系人管理
职称考试学院
职称考试题目职称考试指南职称考试资料
研究生院
考研英语考研题库招生信息就业指导考研经验考研政治考研数学
信息安全实验室
网络安全黑客教程杀毒防毒安全设置脚本攻防黑客入侵工具使用漏洞分析加密解密手机安全安全技术
物联网学院
生物识别二维码射频技术传感器物联网感知层物联网网络层物联网传输层物联网应用层物联网标准物联网前沿技术智能生活智慧城市物联网案例分析云计算虚拟化技术
Java学院
Javascript教程Java教程Java核心技术Java高级技术J2EE教程J2ME教程XML教程Java开源技术
Linux学院
Linux系统管理Unix教程Linux教程Linux编程Linux集群Linux内核技术Linux安全Linux服务器Solaris教程AIX教程
Windows学院
Windows系统管理Windows教程Windows安全Windows服务器Windows网络管理Windows故障Windows优化Windows动态
数据库学院
数据库开发Oracle数据库MySQL数据库Sybase数据库DB2数据库SQL Server数据库数据仓库Informix数据库