Characteristics of Software Engineering

There is a set of characteristics that is not only common to every engineering discipline, but is so predominant and critical that they can be used to describe the underpinnings of engineering. It is these underpinnings that should be viewed as desirable characteristics of software engineers.

Thus they have influenced the development of software engineering and the contents of this
volume:

1. Engineers proceed by making a series of decisions, carefully evaluating options, and choosing an approach at each decision-point that is appropriate for the current task in the current context. Appropriateness can be judged by tradeoff analysis, which balances costs against benefits.
2. Engineers measure things, and when appropriate, work quantitatively; they calibrate and validate their measurements; and they use approximations based on experience and empirical data.
3. Engineers emphasize the use of a disciplined process when creating a design and can operate effectively as part of a team in doing so.
4. Engineers can have multiple roles: research, development, design, production, testing,construction, operations, management, and others such as sales, consulting, and teaching.
5. Engineers use tools to apply processes systematically. Therefore, the choice and use of appropriate tools is key to engineering.
6. Engineers, via their professional societies, advance by the development and validation of principles, standards, and best practices.
7. Engineers reuse designs and design artifacts.
   

It should be noted that while the term engineer and engineering will be used extensively in the following sections, this document is about the design, development and implementation of undergraduate software engineering curricula. It must be acknowledged that much of the work in this document is based on the work of numerous individuals and groups that have advanced the state of computer science and information technology, and have developed programs that help prepare graduates to practice software development in a professional manner.

Software Engineering in Colleges

The study and practice of software engineering is influenced both by its roots in computer science and its emergence as an engineering discipline. A significant amount of current software engineering research is conducted within the context of computer science and computing departments or colleges. Similarly, software engineering degree programs are being developed by such academic units as well as within engineering colleges.

Thus, the discipline of software engineering can be seen as an engineering field with a stronger connection to its underlying computer science discipline than the more traditional engineering fields. In the process of constructing this volume, particular attention has been paid to incorporating the practices of engineering into the development of software, so as to distinguish this curriculum from computer science curricula. To prepare for the more detailed development of these ideas, this section examines the engineering methodology and how it applies to software development.

We must also point out that although there are strong similarities between software engineering and more traditional engineering, there are also some differences (not necessarily to the detriment of software engineering):

• Foundations are primarily in computer science, not in natural sciences.
• The focus is on discrete rather than continuous mathematics.
• The concentration is on abstract/logical entities instead of concrete/physical artifacts.
• There is no “manufacturing” phase in the traditional sense.
• Software “maintenance” primarily refers to continued development, or evolution, and not to conventional wear and tear.
  
  

Nature and Challanges of Software Engineering

A common misconception about software engineering is that it is primarily about rocessoriented activities (i.e., requirements, design, quality assurance, process improvement, and project management). In this view, competency in software engineering can be achieved by acquiring a strong engineering background, a familiarity with a software development process and a minimal computing background, including experience using one or more programming languages.

Such a background is, in fact, quite insufficient; the misconception that leads to such thinking is based on an incomplete view of the nature and challenges of software engineering.In the historical development of computing, computer scientists produced software and electrical engineers produced the hardware on which the software runs. As the size, complexity,and critical importance of software grew, so did the need to ensure that software performs as intended.

By the early 1970’s, it was apparent that proper software development practices required more than just the underlying principles of computer science; they need both the analytical and descriptive tools developed within computer science and the rigor that the engineering disciplines bring to the reliability and trustworthiness of the artifacts they engineer.


Software engineering thus is different in character from other engineering disciplines, due to both the intangible nature of software and to the discrete nature of software operation. It seeks to integrate the principles of mathematics and computer science with the engineering practices developed to produce tangible, physical artifacts. Drawing on computing and mathematics as foundations, software engineering seeks to develop systematic models and reliable techniques for producing high-quality software; and these concerns extend all the way from theory and principles to the development practices that are most visible to those outside of the discipline.

While it is not expected that every software engineer will have deep expertise in all of aspects of computing, a general understanding of their relevance and some expertise in particular aspects are a necessity.

Software Engineering Priciples

Over the years, numerous definitions of the discipline of Software Engineering have been presented. For the purpose of this document, we highlight the following definitions:

• "The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines".
• "Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems."
• "The application of a systematic, disciplined, quantifiable approach to the development,operation, and maintenance of software" [IEEE 1990].
  

There are aspects of each of these definitions that contribute to the perspective of software engineering used in the construction of this volume. One particularly important aspect is that software engineering builds on computer science and mathematics. But, in the engineering tradition, it goes beyond this technical basis to draw upon a broader range of disciplines.

These definitions clearly state that software engineering is about creating high-quality software in a systematic, controlled, and efficient manner. Consequently, there are important emphases on analysis and evaluation, specification, design, and evolution of software. In addition, there are issues related to management and quality, to novelty and creativity, to standards, to individual skills, and to teamwork and professional practice that play a vital role in software engineering.

Software Engineering Dicipline

Since the dawn of computing in the 1940s, the applications and uses of computers have grown at a staggering rate. Software plays a central role in almost all aspects of daily life: in government,banking and finance, education, transportation, entertainment, medicine, agriculture, and law.


The number, size, and application domains of computer programs have grown dramatically; as a result, hundreds of billions are being spent on software development, and the livelihood and lives of most people depend on the effectiveness of this development. Software products have helped us to be more efficient and productive. They make us more effective problem solvers, and they provide us with an environment for work and play that is often safer, more flexible, and less confining. Despite these successes, there are serious problems in the cost, timeliness, and quality of many software products. The reasons for these problems are many and include the following:

• Software products are among the most complex of man-made systems, and software by its very nature has intrinsic, essential properties (e.g., complexity, invisibility,and changeability) that are not easily addressed.
• Programming techniques and processes that worked effectively for an individual or a small team to develop modest-sized programs do not scale-up well to the development of large,complex systems (i.e., systems with millions of lines of code, requiring years of work, by hundreds of software developers).
• The pace of change in computer and software technology drives the demand for new and evolved software products. This situation has created customer expectations and competitive forces that strain our ability to produce quality of software within acceptable development schedules.
  

It has been over thirty-five years since the first organized, formal discussion of software engineering as a discipline took place at the 1968 NATO Conference on Software Engineering [Naur 1969]. The term “software engineering” is now widely used in industry, government, and academia: hundreds of thousands of computing professionals go by the title “software engineer”; numerous publications, groups and organizations, and professional conferences use the term software engineering in their names; and there are many educational courses and programs on software engineering.

However, there are still disagreements and differences of opinion about the meaning of the term. The following definitions provide several views of the meaning and nature of software engineering. Nevertheless, they all possess a common thread, which states, or strongly implies that software engineering is more than just coding - it includes quality, schedule and economics, and the knowledge and application of principles and discipline.

Future of Software

Continuing the trend-watching of Technology 2001, which discussed the technologies that could well define the computing and communications environment that lies ahead, The Future of Software assembles the observations of leading computer scientists, strategists, and planners in both business and academia, this time tackling software development.

Despite the extraordinary advances during the past few years in computing power, Derek Leebaert and the other contributors see as the biggest challenge for the future the development of software that can fully exploit the the computer's ever-increasing capabilities. Each author addresses the particular aspect of software that is his or her specialty, examining how various developments and applications will transform the way we think about and use comptuters as we enter the next millennium.

The topics include the history and evolution of software, the future of software and how it will change the way we live, software standardization, work group computing, computer supported collaboration, end-user programming, natural language and natural- intelligence capabilities and limitations, the Japanese software industry, software and the law, and the coordination of knowledge.

Software Visualization

In the past decade, high quality interfaces have become standard in a growing number of areas such as games and CD-ROM-based encyclopedias. Yet the overwhelming majority of programmers edit their code using a single font within a single window and view code execution via the hand insertion of print statements.

Software Visualization (SV) redresses this imbalance by using typography, graphics, and animation techniques to show program code, data, and control flow. This book describes the history of SV, techniques and frameworks for its construction, its use in education and program debugging, and recent attempts to evaluate its effectiveness. In making programming a multimedia experience, SV leaves programmers and computer science researchers free to explore more interesting issues and to tackle more challenging problems.

Software Abstractions

In Software Abstractions Daniel Jackson introduces a new approach to software design that draws on traditional formal methods but exploits automated tools to find flaws as early as possible. This approach--which Jackson calls "lightweight formal methods" or "agile modeling"--takes from formal specification the idea of a precise and expressive notation based on a tiny core of simple and robust concepts but replaces conventional analysis based on theorem proving with a fully automated analysis that gives designers immediate feedback. Jackson has developed Alloy, a language that captures the essence of software abstractions simply and succinctly, using a minimal toolkit of mathematical notions. The designer can use automated analysis not only to correct errors but also to make models that are more precise and elegant. This approach, Jackson says, can rescue designers from "the tarpit of implementation technologies" and return them to thinking deeply about underlying concepts.

Software Abstractions introduces the key elements of the approach: a logic, which provides the building blocks of the language; a language, which adds a small amount of syntax to the logic for structuring descriptions; and an analysis, a form of constraint solving that offers both simulation (generating sample states and executions) and checking (finding counterexamples to claimed properties). The book uses Alloy as a vehicle because of its simplicity and tool support, but the book's lessons are mostly language-independent, and could also be applied in the context of other modeling languages.

Mobile Software for internet

Speaking of mobile browsers, their small screens raise the issues of multimodal
user interfaces and personalization. With the General Packet Radio Service
or ‘‘GPRS,’’ rolled out across the world in late 2001, it became possible for
a mobile user to simultaneously speak and listen in a voice connection while
using text screens delivered via a Web connection. As an engineer, you’ll have
to decide when it makes sense to talk to the user, listen to the user, print out a
screen of options to the user, and ask the user to highlight and click to choose
from that screen of options. For example, when booking an airline flight it is
much more convenient to speak the departure and arrival cities than to choose
from a menu of thousands of airports worldwide. But if there are ten options
for making the connection you don’t want to wait for the computer to read
out those ten and you don’t want to have to hold all the facts about those ten
options in your mind. It would be more convenient for the travel service to
send you a Web page with the ten options printed and scrollable.

On the personalization front, consider the corporate ‘‘knowledge sharing’’ or
‘‘knowledge management’’ system. Initially, workers are happy simply to have
this kind of system in place. But after a few years, the system becomes so filled
with that it is dificult to find anything relevant. Given an organization in
which 1,000 documents are generated every day, wouldn’t it be nice to have a
computer system smart enough to figure out which three are likely to be most
interesting to you? And display the titles on the three lines of your phone’s
display?

A more interesting challenge is presented by asking the question, ‘‘Can a
computer help me be all that I can be?’’ Engineers often build things that are
easy to engineer. Fifty years after the development of television, we started
building high-definition television (HDTV). Could engineers build a higher
resolution standard? Absolutely. Did consumers care? So far it seems that not
too many do care.

software engineering for internet

A twelve-year-old can build a nice Web application using the tools that came
standard with any Linux or Windows machine. Thus it is worth asking ourselves,
‘‘What is challenging, interesting, and inspiring about Internet-based
applications?’’

There are some easy-to-identify technology-related challenges. For example,
in many situations it would be more convenient to interact with an information
system by talking and listening. You’re in the bathtub reading New Yorker.
You want to know whether there are any early morning appointments on
your calendar that would prevent you from staying in the tub and finishing
an interesting article. You’ve bought a new DVD player. You could read the
manual and master the remote control. But in a dark room, wouldn’t it be
easier if you could simply ask the house or the machine to ‘‘back up thirty
seconds’’? You’re driving in your car and curious to know the population of
Thailand and the country’s size relative to the state of California; voice is your
only option.

There are some easy-to-identify missing features in typical Web-based applications.
For example, shareable and portable sessions. You can use the Internet
to share your photos. You can use the Internet to share your music. You can
use the Internet to share your documents. The one thing that you can’t typically
share on the Internet is your experience of using the Internet. Suppose
that you’re surfing a travel site, planning a trip for yourself and three friends.
Wouldn’t it be nice if your companions could see what you’re looking at,
page-by-page, and speak comments into a shared voice-session?

If everyone has the same brand of computer and special software, this is easy enough. But
shareable sessions ought to be a built-in feature of sites that are usable from
any browser. The same infrastructure could be used to make sessions portable.
You could start browsing on a desktop computer with a big screen and finish
your session in a taxi on a mobile phone.

Designing of Software Engineering

Software engineering (SE) is a very young field of study. The first computer science department (in the United States) was established in just 1962 (Rice and Rosen 2002) and it wasn’t until after a NATO conference on the “software crisis” in 1968 that the term “software engineering” came into common use (Naur and Randall 1969; Bauer 1972), and the first degree program for software engineers in the United States wasn’t established until 1978 at Texas Christian University.

Software engineering is more than just “coding,” it is applying “a tematic,disciplined,quantifiable approach to the development, operation,and maintenance of software” (IEEE 1990); it is also the engineering of software to meet some goal, and to see that the constructed software operates over time and that it is maintained during its expected life.

Such definitions of software engineering have led the way to a plethora of processes, paradigms, techniques, and methodologies, all with the goal of helping to make the process of engineering correct software repeatable and addressing the concerns raised at the 1968 NATO conference on the “software crisis,” where it was recognized that software was routinely late,over budget, and simply wrong. To enumerate a list of such processes,paradigms, techniques, and methodologies here would be too arduous,but for the most part it, is generally accepted that the construction or engineering of software involves:

· Need
· Craftsman
· Compensation

In other words, some individual or group in need of software obtains that software product from a programmer or group for some amount of compensation.This is nothing more, really, than the law of supply and demand,which has been tested throughout human civilization. Following such law,if there is no “need,” then there is no one to compensate the craftsman for their product, and hence no product.

Principles of software engineering

As such, nearly all defined processes for software engineering include some role for the end-user or defining-user in a software engineering process (such as requirements engineering (IEEE 1990) or “use cases” and “actors” in the Rational Unified Process (Jacobson, Booch, and Rumbaugh 1999)). Further, software engineering is concerned with the principles behind effectively organizing the team of engineers that craft the software, and also with how that craftsmanship is accomplished, in relation to:

1. Designing the software (its architecture, modules, and interactions)
2. Programming, or coding, the designed software
3. Testing the software against design and need
4. Documenting that which is designed, programmed, and tested
5. Managing those that design, program, test, and document

Through the short history of rationalizing the process by which software engineering is, or should be, accomplished, the members of the SE community have reached a fairly common understanding of what software engineering is, and how software engineering should be done. It is the apparent departure of free and open source software (F/OSS) from this understanding (or belief in that understanding), combined with the success (or perceived success) of many F/OSS projects, that has attracted the attention of many in the research community. In this section, anumber of authors have been selected to bring to the foreground specificobservations from various F/OSS projects.

Current trends in software engineering

Software engineering is a young discipline, and is still developing. The directions in which software engineering is developing include:

Aspects

Aspects help software engineers deal with quality attributes by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates.

Agile

Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of this method believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance[citation needed]. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes[citation needed]. Related concepts include Extreme Programming and Lean software development.

Experimental

Experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from the experiments, and in devising laws and theories from this data. Proponents of this method advocate that the nature of software is such that we can advance the knowledge on software through experiments only[citation needed].

Model-driven

Model Driven Software Development uses (both textual and graphical) models as primary development artifacts. By means of model transformation and code generation a part or complete applications are generated.

Software Product Lines

Software Product Lines is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process.

The Future of Software Engineering conference (FOSE), held at ICSE 2000, documented the state of the art of SE in 2000 and listed many problems to be solved over the next decade. The FOSE tracks at the ICSE 2000 and the ICSE 2007 conferences also help identify the state of the art in software engineering.