Gerard ORegan - Concise guide to formal methods - theory, fundamentals and industry applica

Concise guide to formal methods - theory, fundamentals and industry applica — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Concise guide to formal methods - theory, fundamentals and industry applica" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

1234567...97

Springer International Publishing AG 2017

Gerard O'Regan Concise Guide to Formal Methods Undergraduate Topics in Computer Science

1. Software Engineering

Gerard ORegan 1

(1)

SQC Consulting, Mallow, County Cork, Ireland

Gerard ORegan

Email:

Key Topics

• Standish chaos report
• Software life cycles
• Waterfall model
• Spiral model
• Rational Unified Process
• Agile development
• Software inspections
• Software testing
• Project management

1.1 Introduction

The approach to software development in the 1950s and 1960s has been described as the Mongolian Hordes Approach by Brooks [ The method or lack of method was characterized by the use of a large number of inexperienced programmers to fix a problem rather than solving it with a team of skilled programmers (i.e. throwing people at a problem). The view of software development at that time was characterized by:

The completed code will always be full of defects.

The coding should be finished quickly to correct these defects.

Design as you code approach.

This philosophy accepted defeat in software development and suggested that irrespective of a solid engineering approach, that the completed software would always contain lots of defects, and that it therefore made sense to code as quickly as possible, and then to identify the defects that were present, so as to correct them as quickly as possible to solve a problem.

In the late 1960s, it was clear that the existing approaches to software development were deeply flawed, and that there was an urgent need for change. The NATO Science Committee organized two famous conferences to discuss critical issues in software development [Bux:75], with the first conference held at Garmisch, Germany, in 1968, and it was followed by a second conference in Rome in 1969.

Over fifty people from eleven countries attended the Garmisch conference, including Edsger Dijkstra, who did important theoretical work on formal specification and verification. The NATO conferences highlighted problems that existed in the software sector in the late 1960s, and the term software crisis was coined to refer to these. There were problems with budget and schedule overruns, as well as the quality and reliability of the delivered software.

The conference led to the birth of software engineering as a discipline in its own right, and the realization that programming is quite distinct from science and mathematics. Programmers are like engineers in that they build software products, and they therefore need education in traditional engineering as well as the latest technologies. The education of a classical engineer includes product design and mathematics. However, often computer science education has placed an emphasis on the latest technologies, rather than the important engineering foundations of designing and building high-quality products that are safe for the public to use.

Programmers therefore need to learn the key engineering skills to enable them to build products that are safe for the public to use. This includes a solid foundation on design, and on the mathematics required for building safe software products. Mathematics plays an important role in classical engineering, and it is also potentially useful in supporting software engineers in the delivery of high-quality software products in specialized domains such as safety critical systems. Several mathematical approaches to assist software engineers are described in [].

There are parallels between the software crisis of the late 1960s and the crisis with bridge construction in the nineteenth century. Several bridges collapsed, or were delivered late or over budget, due to the fact that people involved in their design and construction did not have the required engineering knowledge. This led to bridges that were poorly designed and constructed, and this led to their collapse and loss of life, as well as endangering the lives of the public.

This led to legislation requiring engineers to be licensed by the Professional Engineering Association prior to practicing as engineers. This organization specified a core body of knowledge that the engineer is required to possess, and the licensing body verifies that the engineer has the required qualifications and experience. This helps to ensure that only personnel competent to design and build products actually do so. Engineers have a professional responsibility to ensure that the products are properly built and are safe for the public to use.

The Standish group has conducted research (Fig. However, the comparison between 1995 and 2009 suggests that there have been some improvements with a greater percentage of projects being delivered successfully, and a reduction in the percentage of projects being cancelled.

Fig. 1.1

Standish reportresults of 1995 and 2009 survey

Fred Brooks argues that software is inherently complex, and that there is no silver bullet that will resolve all of the problems associated with software development such as schedule or budget overruns []. Poor software quality can lead to defects in the software that may adversely impact the customer, and even lead to loss of life. It is therefore essential that software development organizations place sufficient emphasis on quality throughout the software development life cycle.

The Y2K problem was caused by a two-digit representation of dates, and it required major rework to enable legacy software to function for the new millennium. Clearly, well-designed programs would have hidden the representation of the date, which would have required minimal changes for year 2000 compliance. Instead, companies spent vast sums of money to rectify the problem.

The quality of software produced by some companies is impressive. These models focus on improving the effectiveness of the management, engineering and organization practices related to software engineering, and in introducing best practice in software engineering. The disciplined use of the mature software processes by the software engineers enables high-quality software to be consistently produced.

The next section examines the nature of software engineering, and there is a more detailed account in the companion book Concise Guide to Software Engineering [].

1.2 What Is Software Engineering?

Software engineering involves the multi-person construction of multi-version programs. The IEEE 610.12 definition is:

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software, and the study of such approaches.

Software engineering includes:

1. Methodologies to design, develop and test software to meet customers needs.
2. Software is engineered. That is, the software products are properly designed, developed and tested in accordance with engineering principles.
3. Quality and safety are properly addressed.
4. Mathematics may be employed to assist with the design and verification of software products. The level of mathematics employed will depend on the safety critical nature of the product. Systematic peer reviews and rigorous testing will often be sufficient to build quality into the software, with heavy mathematical techniques reserved for safety and security critical software .

Next page

1234567...97

Light

Font size:

↓

↑

Georgia Tahoma Arial Verdana

Reset

Interval:

↓

↑

Bookmark:

Make

Similar books «Concise guide to formal methods - theory, fundamentals and industry applica»

Look at similar books to Concise guide to formal methods - theory, fundamentals and industry applica. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.

Tom ORegan

Australian Television Culture

Michael Cothren

Fundamentals of Art History

Révész

Introduction to Formal Languages

Zhe Hou

Fundamentals of Logic and Computation: With Practical Automated Reasoning and Verification

A. Y. Khinchin

Mathematical Methods in the Theory of Queuing

Marieke Huisman

Formal Methods: 24th International Symposium, FM 2021, Virtual Event, November 20–26, 2021, Proceedings

Gerard ORegan

Guide to Discrete Mathematics: An Accessible Introduction to the History, Theory, Logic and Applications (Texts in Computer Science)

ORegan

Guide to Discrete Mathematics An Accessible Introduction to the History, Theory, Logic and Applications

Gerard ORegan

Introduction to Software Quality

Gerard O’Regan

Guide to Discrete Mathematics

Gerard O’Regan

Concise Guide to Software Engineering

György E. Révész

Introduction to Formal Languages

Discussion, reviews of the book Concise guide to formal methods - theory, fundamentals and industry applica and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.