Software Engineering

Architecture-driven Software Development

Richard F Schmidt

• Publisher: Morgan Kaufmann
• Year: 2013
• ISBN:
  9780124078789
• Topic: Computer Science
• Subtopic: Digital Media
• Index: Computer Science

Software Engineering: Architecture-driven Software Development is the first comprehensive guide to the underlying skills embodied in the IEEE's Software Engineering Body of Knowledge (SWEBOK) standard. Standards expert Richard Schmidt explains the traditional software engineering practices recognized for developing projects for government or corporate systems.

Software engineering education often lacks standardization, with many institutions focusing on implementation rather than design as it impacts product architecture. Many graduates join the workforce with incomplete skills, leading to software projects that either fail outright or run woefully over budget and behind schedule.

Additionally, software engineers need to understand system engineering and architecture—the hardware and peripherals their programs will run on. This issue will only grow in importance as more programs leverage parallel computing, requiring an understanding of the parallel capabilities of processors and hardware. This book gives both software developers and system engineers key insights into how their skillsets support and complement each other. With a focus on these key knowledge areas, Software Engineering offers a set of best practices that can be applied to any industry or domain involved in developing software products.

• A thorough, integrated compilation on the engineering of software products, addressing the majority of the standard knowledge areas and topics
• Offers best practices focused on those key skills common to many industries and domains that develop software
• Learn how software engineering relates to systems engineering for better communication with other engineering professionals within a project environment

Section 1

Software Engineering Fundamentals

Section 1. Software Engineering Fundamentals

Chapter 1 Introduction to Software Engineering

Chapter 2 Generic Software Development Framework

Chapter 3 Software Architecture

Chapter 4 Understanding the Software Project Environment

Chapter 5 Software Integrated Product and Process Development

Chapter 6 Impediments to Software Design

Section 1. Software Engineering Fundamentals

This section provides an overview of the software engineering discipline to acquaint readers with the lexicon used to describe software engineering principles, practices, and tasks. Fundamentally, software is a unique material from which software products are crafted. The distinctive characteristics of software as a fabrication material represent an enigma to software professional. The challenges associated with engineering and designing software products is investigated to diminish the confusion surrounding the various approaches to software engineering. Software engineering’s fundamental doctrine is established to provide a set of principles and practices against which the software engineering discipline can be founded.

Foremost, this section introduces a lexicon for discussing the application of sound software engineering techniques. The terminology inherent in this lexicon coalesce accepted nomenclatures from a variety of professions, particularly systems engineering, project management, and configuration management. This lexicon is intended to combat the myriad of illegitimate terms thrown about the software communities that enhance the confusion and difficulty associated with establishing a set of standard practices. It is essential for the software industry to stabilize the manner in which they discuss their professional practices with other engineering professionals, stakeholders, and customers. It is not prudent to speak an alien dialectal when attempting to illuminate technical challenges or the merits of design ingenuity.

Professor Fred Brooks addressed the confusion caused by the various software lexicons by discussing the Tower of Bable. His book The Mythical Man-Month: Essays on Software Engineering¹ identified the quagmire that erupted as a result of the ever-expanding software dialects. Since its first publication, the software culture had disseminated more programming languages, techniques, and methodologies in the shortest span of time than any other vocation in the history of humankind. This trend continues to disperse, diffuse, and magnify the communication barriers between conventional engineering professions and software artisans and engineering impressionists. Software engineering is a demanding occupation that can no longer afford to promote undisciplined techniques and methodologies. Software jargon and dialects must coalesce as a united lexicon based on established engineering terminology. The quagmire stemming from the variety of software languages and methodologies threatens to overwhelm the industrial and academic communities attempting to keep pace with the endless stream of new and provocative software strategies.

Therefore, this section patiently explores the influences that surround the development of a software product. These influences, or environmental variables, must be appreciated for a software engineering effort to be successful. Therefore, this section discusses the various technical and business motives that must be embraced by any approach to engineering software products. Fundamentally, it is essential to recognize that software products are intended to contribute to the financial prosperity of the businesses that adopt them, as well as the businesses that supply this unique merchandise.

A major category of software products is intended to make businesses more productive by automating routine, labor-intensive tasks. These software products reduce a business’s reliance on manual data gathering, analysis, and manipulation, especially where computational errors result in costly mistakes that could reduce the profitability of an enterprise. The companies that develop software products want to enjoy a beneficial compensation from the investment in the development of the software product. Consequently, it is in the interest of both the software developer and the businesses using the software to ensure that the software development project results in a proficient, user-friendly product that actually works properly. However, the success rate associated with software development projects has hovered between 25% and 30% throughout the two decades of the Standish Group’s Chaos reports.² Clearly, businesses are losing confidence in the software industry’s ability to successfully deliver a product on time and within budget that actually does what it is supposed to do. FAILURE! CHAOS! It does not seem to faze software professionals that their reputation is so disgracefully tarnished.

Never fear, because there is always another self-proclaimed software guru ready on the sideline with a new-fangled solution to software development. Another approach, excitingly new terminology, and a flourish of activity as desperate mavens leap aboard another bandwagon bound for somewhere. The software development industry is desperately seeking a solution that significantly offers to bring some credibility to their defense. Software specialists fail to embrace the fundamental principles and practices encouraged by other engineering disciplines because software is different than other products. How true! However, there may be some value from garnering those engineering practices that may have applicability to the engineering of software products.

This section provides six introductory chapters that set the stage for examining software engineering principles and practices. This material is based on my experiences applying systems engineering practices for the past two decades. My investigation into systems engineering was prompted by a 1989 congressional report entitled “Bugs in the Program.”³ The findings and recommendations of this repots included the following:

National Science Foundation should assure that computer science or software engineering curricula should expose students to systems engineering concepts throughout their education.

The Government’s present system for procuring software does not meet the Government’s needs and wastes resources. The application of “systems engineering” disciplines is needed to remedy the procurement system’s defects. … Software Development is a complex process that requires modern “systems engineering” techniques.

While the systems engineering discipline has promoted a cohesive set of practices for dealing with complex product development endeavors, they have been improperly adapted to the unique nature of software products. Section 2 presents the six practices associated with systems engineering. However, they have been acclimated to the challenges of software development.

Systems engineering principles and practices

Systems engineering is a discipline that melds interdisciplinary technical disciplines and project management practices to develop architectural design challenges associated with complex product development. It bounds the problem domain by focusing on the product operational environment while considering the full product life cycle. A typical system life cycle involves development, testing, manufacturing, distribution, training, operations, support, and disposal. The principles of systems engineering include:

1. A system represents a complex, human-made product that involves hardware, software, and human operators to work effectively. The system or product must be understood in terms of its complete set of life-cycle processes, which impact the feasibility of potential design solutions.

2. A product is a combination of interrelated parts organized into a complex whole.

3. A product is human-made (designed, manufactured, tested, operated, and sustained) for a specific, sometimes generalized, purpose. This eliminates “natural” or “biological” systems from consideration as a system of interest.

4. The effectiveness of the product in operation is a result of the application of system thinking, which attempts at understanding how parts influence, cooperate, and collaborate with one another within a collective whole. This necessitates understanding the effects of the operational environment on the performance of the product and its constituent parts.

5. A product involves a hierarchical arrangement of smaller, less complex components and parts. The design of a complex product cannot be derived without decomposing the problem space into manageable problems for which one or more technical solutions can be discriminated.

6. The system architecture represents the complete set of product life-cycle requirements and the product functional and physical configurations that provide its technical description.

7. The product is realized when the individual parts or components are fabricated (or procured), assembled, integrated, and tested.

These systems engineering principles can be easily adapted to a software product. The computing environment provides the hardware component and represents the major element of the operational environment. The software product is the focus of the software engineering effort, and it must be designed to be operated by end users. The set of software life-cycle processes differs slightly since software is not manufactured or fabricated, and its methods of replication, distribution, and training may vary significantly from a system-based product that involves hardware.

The practices associated with systems engineering were established in the early 1940s and have been proven to resolve large, complex system or product design ...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• A Note from the Author
• Preface
• Section 1: Software Engineering Fundamentals
• Section 2: Software Engineering Practices
• Section 3: Stages of Software Engineering Application
• Index