Software Engineering and UML notes

Software Engineering and UML notes

Introduction to Object-Oriented Software Engineering Chapter One

 

Required learning content:

  • Software crisis
  • The origin of Software Engineering
  • Definition of Software Engineering
  • Category of software engineering
  • Target software engineering practices
  • Software development includes activities
  • Software maintenance costs
  • The cost of fixing a bug

A software crisis

Software Definition: Software is all the programs and documentation development, use and maintenance procedures required.

 

Custom software crisis: a series of serious problems in software development and maintenance encountered in the process

which performed:

  1. Inaccurate estimates of software development costs and schedule;
  2. Software product quality is very reliable;
  3. Maintainability, software documentation is incomplete and substandard;
  4. Software costs increased year by year;
  5. Software development productivity is not high, can not meet the objective needs.

Software crisis reasons:

 

(1) For people to understand the concept and category of software.
 
Early software engineer advocating individual heroism, the entire software development is usually in a state of disorder. Most of them think that programming is all software development. This concept will lead to increases as the size of software, programmers are ignored and do not pay attention to the document, making the software product development is not perfect and difficult to maintain.

 

(2) increasing the size of the software, design is increasingly complex.
 Visual Studio / Office, etc. (M-> G)
 
(3) changes in software development organizations.
   While these factors changes, software development organizations are also changing. The early development of a small software might 1-2 developers can be completed. However, with the rapid growth of software size, software development organizations are also the same percentage increase, altered by the state alone a team of several developers to jointly develop a product. By the staff becomes a collaborative development team, this form of organizational change will inevitably bring challenges to collaborative software development organization. At the same time potentially schedule, cost and quality issues.

 


 

II. Software Engineering

Definition of software engineering: software engineering is to guide the development and maintenance of computer software engineering science. Using engineering concepts, principles, techniques and methods to develop and maintain software (1968) .

The core software engineering three elements: quality, time and budget.

Target software engineering: at a given cost, on-time delivery of high quality software products.

Software Engineering Category: Software engineering is a discipline, the purpose is to produce can be delivered on schedule, within budget and meet customer needs no wrong software products.

Software quality control quality elements influencing factors:

 

1. Run feature on software

 

Reliability: within a given time interval, the probability of successful operation of the software
validity: time and space efficiency of the software (validation testing: verify software functionality and other features are consistent with the user's requirements)
Availability: ease of use of the software
understandable : the structure clear, direct questions reflect the needs, easy to understand
maintainability: ease of modification of software after delivery
 
2. The ability to withstand changes on software
Flexibility: the desired function or change the behavior of the software workload
 
3. With regard to software ability to adapt to the new environment
Portability: software from one environment to another of the ease of
reusability: software components may be applications where the extent of multiple
interoperability: a plurality of software and exchanging information with each other using the exchanged capability information

 

 insert:

The principle of well-known software engineering expert BWBoehm software engineering practices (published in 1983)

1. With a phased plan to strict life-cycle management.

(1) must have a project plan;
(2) the project should be divided life cycle phases, each should have a plan;
(3) plans to tiered or phased in gradually refined;
(4) To use project management project You can not be abandoned.

2. Insists on stage review.

(1) early detection of errors. Most defects are injected prior to encoding, the lower the cost to repair defects sooner.
(2) the early detection of errors measures:

3. Strict product control.

Perform configuration management to ensure consistency between the work product.

4. The use of modern programming techniques.

  • The use of modern development methods, development practices to enhance the efficiency and quality of the software.

 5. The results should be clearly examined.

  • For the output stage of the project, the commitment between the various groups, outputs and commitment of everyone to be clear, to be verifiable. 

6. The development team should be concise.

(1) the efficiency of the difference between people up to 10 times or even more than 25 times, so use of the elite teams.
(2) using a variety of ways to enhance the quality and efficiency of communication:
  • Do not solve the problem by adding the progress of the human way
  • Not too much of the initial project staff
  • Provide high returns for high performance
  • Out of low performance by
  • Use of automated aids
  • The need to continue to improve software engineering practices recognized.
  • Identification, analysis and process improvement techniques, the establishment of mechanisms for continuous improvement.

 Three software lifecycle methodology: decompose complex software development and maintenance problems from the perspective of time.

Software Life Cycle: The entire life cycle model into a series of smaller steps, called phases. In contrast, a series of practical steps for a specific software product did, eventually retired from concept to development , called the product life cycle.

Software life cycle phases: requirements, analysis, design, implementation, post-delivery maintenance, decommissioning

Software maintenance costs are generally three times the cost of software development.

The cost of finding and fixing software:

Waterfall model of software design: modular design, implementation, compilation, unit testing, integration testing, system testing.
 
 size and complexity of the system increases
 the average cost of finding and fixing defects  increased 10 times.

  • Code Review: 1-2 minutes
  • Initial test: 10-20 minutes
  • Integration testing: 1 hour or more
  • System test: 10-40 hours
  • Product release to customers: greater price.

Note: The purpose of the test is not to repair the defect, but in order to evaluate the product

          The quality of a product is determined when it is developed

  • When compiling stage there are many defects in the testing phase there may be many flaws!
  • Defects in the testing phase and more, the more left in the final bugs in the program!
  • EWDijkstra not there a saying "program testing can only show the presence of errors, but can not show that there is no error

 


Software engineering paradigm

Three phase does not exist independently:
1. Plan

    the right time planning stage?
    Throughout the software life cycle always, there is no independent planning phase
2. Test (if you think someone will help you check, you will relax)
3. Document (complete, correct, up to date)

 

Software life cycle phases:

 

 

 

 

 

 

 

 Software process model (software engineering paradigms)

  • Order linear model (waterfall model)
  • Prototype model
  • Incremental model
  • Spiral Model
  • Member assembly model
  • Concurrent development model
  • Formal Methods Model
  • The fourth generation technology (4GT) 

Object-oriented software technology comparison with the conventional process

Traditional structured methodology disadvantages:
  • Software products can not solve the problem getting bigger and bigger scale.
  • Post-delivery maintenance can not meet the expectations of the second aspect.
  • Low productivity, can not quickly meet customer needs
  • The low level of software reuse
  • Software is still difficult to maintain
  • Facing the operator, or attribute-oriented, but not for both at the same time.

Traditional paradigm comparison with object-oriented paradigm:

Pattern and traditional object-oriented paradigm main differences:

 

 

 1. theory of software development

Software development practice are largely different, there are two reasons:
First, the software professionals are human and therefore make mistakes;
second, when the software needs of customers will change during development.

2. Case Study

为了缓解印第安纳州Winburg市区交通阻塞的状况,市长说服政府建立一个公共交通系统。将建立公共交通专用通道,鼓励通勤人员“停车换乘”,即将小汽车停在郊区的停车场,然后从该处乘公共汽车上下班,每乘一次花费1美元。
每辆公共汽车将设一个自动只接受1美元的收款机,乘客进入公共汽车时将1美元塞入进钞口,自动收款机中的传感器扫描该钞票,然后机器中的软件使用一个图像识别算法,确定该乘客是否确实在进钞孔中插入了一张真正的1美元钞票。
重要的是自动收款机要非常准确,因为一旦有随便一张纸就可骗过自动收款机的新闻传出,车费收入将直线下降为零,相反如果机器经常拒绝1美元真钞,乘客将不愿意坐公共汽车。另外,收款机必须速度快,如机器花费15秒钟才确认1美元真钞——这将使好几分钟只有少数乘客能登上汽车,乘客同样不愿意坐公共汽车。因此,对收款机软件的需求包括相应时间少于1秒钟并且平均准确度至少为98%。

第1幕:实现该软件的第1版
第2幕:要求确定1美元钞票有效地平均1s响应时间没有达到。需要10s才能响应。双精度-单精度。
第3幕:程序员修改完成之后,发现平均响应时间仍超过4.5s,没有接近规定的1s。问题在于图像识别算法。Luckly,刚发明了一个快速算法,成功 。
尾声:几年后,传感器陈旧了,需要一个新的模块替代它,硬件的改变意味着需要新的软件,需要重新设计与实现。

该小型实例的进化树生命周期模型

 

注意: 虚线方框表示实现没有完成


 

瀑布生命模型

 

 瀑布生命模型分析:

如果在设计期间发现了一个需求中的差错引起的差错,顺着虚线向上的箭头,软件开发人员可以回溯设计到分析并由此到需求,并在那里做必要的修改。然后,向下移到分析,改正规格说明文档以反应对需求的改动,并顺次纠正设计文档。设计工作现在可以在原来差错的地方继续进行。
瀑布生命周期模型无法显示事件的顺序。而进化树模型在每一幕的结尾都有一个基准,一套完整的软件制品。
 
为什么需要对一个软件产品做出那么多的改变?
第一,软件专业人员是人,因此会出错。
第二,一个软件产品是现实世界的一个模型,而现实世界是不断改变的
 

迭代和递增

  • 理想情况不存在,分析阶段散布在生命周期的各个阶段。
  • 考察一个软件制品的版本,制作第一版、第二版…接近满意的版本。从这个观点看,基本的过程是迭代的。迭代是软件工程的一个固有特性。(瀑布模型1970年首次提出,它是迭代的,但非递增,已经使用30年)
  • 开发现实世界软件的第二个方面是乔治.米勒指出:在任何时候,人类最多只能将精力集中在7桩事情上,然而,一个典型的软件制品远不止有7桩。例如一个编码制品很可能有远远超过7个变量,一个需求文档很可能远远多于7个需求。我们人类处理信息量的限制的一个办法是逐步求精。这是一个递增的过程。递增也是软件工程的一个固有特性。(已经使用45年。)
  • 迭代与递增相互结合使用,迭代—递增生命周期模型:
  • 将进化树模型与瀑布模型结合起来

递增五个核心工作流:
需求工作流、分析工作流、设计工作流、实现工作流、测试工作流。

递增图示

 

 

图说明了每个递增内的迭代以及在几乎每个迭代期间进行的对全部五个工作流的重复,尽管每次的比例有所改变

 

显示Winburg小型实例研究添加在迭代-递增生命周期模型之上的进化树模型

 

 


 

 生命周期的模型比较

 

Guess you like

Origin www.cnblogs.com/knis/p/12291458.html