SOFTWARE ENGINEERING CH1 - CH6

software engineering

(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). It is a process, set of methods, and an array of tools. Software engineers build and support software, and virtually everyone in the industrialized world uses it either directly or indirectly. A concerted effort should be made to understand the problem before a software solution is developed; design becomes a pivotal activity; and software should exhibit high quality and be maintainable.

scrum

(the name is derived from an activity that occurs during a rugby match) An agile software development method conceived by Jeff Sutherland and his team in the early 1990s. Principles are consistent with the agile manifesto and are used to guide development activities within a process that incorporates the following framework activities: requirements, analysis, design, evolution, and delivery. Within each framework activity, work tasks occur within a process pattern called a sprint. The work conducted within a sprint (the number of sprints required for each framework activity will vary depending on product complexity and size) is adapted to the problem at hand and is defined and often modified in real time.

system software

A collection of programs written to service other programs. Some (e.g., compilers, editors, and file management utilities) process complex, but determinate, information structures. Other systems applications (e.g., operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data.

backlog

A prioritized list of project requirements or features that provide business value for the customer. Items can be added at any time (this is how changes are introduced). The product manager assesses this and updates priorities as required.

software process

A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. An activity strives to achieve a broad objective (e.g., communication with stakeholders) and is applied regardless of the application domain, size of the project, complexity of the effort, or degree of rigor with which software engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome. In the context of software engineering, a process is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work (the software team) to pick and choose the appropriate set of work actions and tasks.

traits of successful software engineers

A sense of individual responsibility that implies a drive to deliver on her promises to peers, stakeholders, and her management and that she will do what needs to be done, when it needs to be done in an overriding effort to achieve a successful outcome. An acute awareness of the needs of other members of his team, of the stakeholders that have requested a software solution to an existing problem, and the managers who have overall control over the project that will achieve that solution. Able to observe the environment in which people work and adapt his behavior to both the environment and the people themselves. Brutally honest. If she sees a flawed design, she points out the flaws in a constructive but honest manner. If asked to distort facts about schedule, features, performance, or other product or project characteristics she opts to be realistic and truthful. Exhibits resilience under pressure. Software engineering is always on the edge of chaos. Pressure (and the chaos that can result) comes in many forms—changes in requirements and priorities, demanding stakeholders or peers, an unrealistic or overbearing manager. Manage the pressure so that performance does not suffer. Heightened sense of fairness. She gladly shares credit with her colleagues. She tries to avoid conflicts of interest and never acts to sabotage the work of others. Exhibits attention to detail. This does not imply an obsession with perfection, but it does suggest that he carefully considers the technical decisions he makes on a daily basis against broader criteria (e.g., performance, cost, quality) that have been established for the product and the project. Pragmatic. She recognizes that software engineering is not a religion in which dogmatic rules must be followed, but rather a discipline that can be adapted based on the circumstances at hand.

software

Affects nearly every aspect of our lives and has become pervasive in our commerce, our culture, and our everyday activities. As a product, it delivers the computing potential embodied by computer hardware or by a network of computers that are accessible by local hardware. It is an information transformer—producing, managing, acquiring, modifying, displaying, or transmitting information. As the vehicle used to deliver the product, it acts as the basis for the control of the computer (operating systems), the communication of information (networks), and the creation and control of other programs (software tools and environments).

planning

Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a "map" that helps guide the team as it makes the journey. The map—called a software project plan—defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule.

XP process model

Beck defines a set of five values that establish a foundation for all work performed as part of extreme programming (XP)—communication, simplicity, feedback, courage, and respect. Each of these values is used as a driver for specific XP activities, actions, and tasks. Extreme Programming uses an object-oriented approach as its preferred development paradigm and encompasses a set of rules and practices that occur within the context of four framework activities: planning, design, coding, and testing.

communication

Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders). The intent is to understand stakeholders' objectives for the project and to gather requirements that help define software features and functions.

engineering / scientific software

Broad array of "number-crunching programs that range from astronomy to volcanology, from automotive stress analysis to orbital dynamics, and from computer-aided design to molecular biology, from genetic analysis to meteorology.

sprints

Consist of work units that are required to achieve a requirement defined in the backlog that must be fit into a predefined time-box 10 (typically 30 days). Changes (e.g., backlog work items) are not introduced during the sprint. Hence, the sprint allows team members to work in a short-term, but stable environment.

demos

Deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the customer. It is important to note that it may not contain all planned functionality, but rather those functions that can be delivered within the time-box that was established.

process flow

Describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time. Linear: executes each of the five framework activities in sequence, beginning with communication and culminating with deployment Iterative: repeats one or more of the activities before proceeding to the next Evolutionary: executes the activities in a "circular" manner. Each circuit through the five activities leads to a more complete version of the software Parallel: executes one or more activities in parallel with other activities (e.g., modeling for one aspect of the software might be executed in parallel with construction of another aspect)

product-line software

Designed to provide a specific capability for use by many different customers. Product-line software can focus on a limited and esoteric marketplace (e.g., inventory control products) or address mass consumer.

scrum meeting process

Emphasizes the use of a set of software process patterns that have proven effective for projects with tight timelines, changing requirements, and business criticality. Each of these process patterns defines a set of development activities: backlog, sprints, and demos.

cloud computing

Encompasses an infrastructure or "ecosystem" that enables any user, anywhere, to use a computing device to share computing resources on a broad scale. Computing devices reside outside the cloud and have access to a variety of resources within the cloud. These resources encompass applications, platforms, and infrastructure. In its simplest form, an external computing device accesses the cloud via a Web browser or analogous software. The cloud provides access to data that resides with databases and other data structures. In addition, devices can access executable applications that can be used in lieu of apps that reside on the computing device. The implementation of cloud computing requires the development of an architecture that encompasses front-end and back-end services. The cloud architecture can be segmented to provide access at a variety of different levels from full public access to private cloud architectures accessible only to those with authorization.

generic process framework

Establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. Defines five framework activities— communication, planning, modeling, construction, and deployment. In addition, a set of umbrella activities—project tracking and control, risk management, quality assurance, configuration management, technical reviews, and others—are applied throughout the process. Each iteration produces a software increment that provides stakeholders with a subset of overall software features and functionality. As each increment is produced, the software becomes more and more complete.

legacy software

Hundreds of thousands of computer programs fall into one of the seven broad application domains. Some of these are state-of-the-art software—just released to individuals, industry, and government. Other programs are older, in some cases much older, and are often referred to as this. The focus of continuous attention and concern since the 1960s, Dayani-Fard and his colleagues describe it in the following way: "... developed decades ago and have been continually modified to meet changes in business requirements and computing platforms. The proliferation of such systems is causing headaches for large organizations who find them costly to maintain and risky to evolve." Liu and his colleagues extend this description by noting that "many remain supportive to core business functions and are 'indispensable' to the business." Characterized by longevity and business criticality; sometimes poor quality, inextensible designs, convoluted code, poor or nonexistent documentation, test cases and results that were never archived, a poorly managed change history.

legacy software evolution

If the legacy software meets the needs of its users and runs reliably, it isn't broken and does not need to be fixed. However, as time passes, legacy systems often evolve for one or more of the following reasons: • The software must be adapted to meet the needs of new computing environments or technology. • The software must be enhanced to implement new business requirements. • The software must be extended to make it interoperable with other more modern systems or databases. • The software must be re-architected to make it viable within a evolving computing environment. The goal of modern software engineering is to "devise methodologies that are founded on the notion of evolution;" that is, the notion that software systems continually change, new software systems are built from the old ones, and . . . all must interoperate and cooperate with each other."

definition of software

Instructions (computer programs) that when executed provide desired features, function, and performance. Data structures that enable the programs to adequately manipulate information. Descriptive information in both hard copy and virtual forms that describes the operation and use of the programs

team toxicity

Jackman defines five factors that "foster a potentially toxic team environment": (1) a frenzied work atmosphere, (2) high frustration that causes friction among team members, (3) a "fragmented or poorly coordinated" software process, (4) an unclear definition of roles on the software team, and (5) "continuous and repeated exposure to failure."

artificial intelligence software

Makes use of nonnumerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Applications within this area include robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving, and game playing.

why software is eating the world

More and more major businesses and industries are being run on software and delivered as online services — from movies to agriculture to national defense. All of the technology required to transform industries through software finally works and can be widely delivered at global scale. On the back end, software programming tools and Internet-based services make it easy to launch new global software-powered start-ups in many industries. With lower start-up costs and a vastly expanded market for online services, the result is a global economy that for the first time will be fully digitally wired. Today, the world's largest bookseller, Amazon, is a software company — its core capability is its amazing software engine for selling virtually everything online, no retail stores necessary. Today's dominant music companies are software companies, too: Apple's iTunes, Spotify and Pandora. Today's fastest growing entertainment companies are videogame makers — again, software — with the industry growing to $60 billion from $30 billion five years ago. And the fastest growing major videogame company is Zynga (maker of games including FarmVille), which delivers its games entirely online. Meanwhile, traditional videogame powerhouses like Electronic Arts and Nintendo have seen revenues stagnate and fall. The best new movie production company in many decades, Pixar, was a software company. Disney — Disney! — had to buy Pixar, a software company, to remain relevant in animated movies.Photography, of course, was eaten by software long ago. It's virtually impossible to buy a mobile phone that doesn't include a software-powered camera, and photos are uploaded automatically to the Internet for permanent archiving and global sharing. Companies like Shutterfly, Snapfish and Flickr have stepped into Kodak's place. Software is also eating much of the value chain of industries that are widely viewed as primarily existing in the physical world. In today's cars, software runs the engines, controls safety features, entertains passengers, guides drivers to destinations and connects each car to mobile, satellite and GPS networks. Today's leading real-world retailer, Wal-Mart, uses software to power its logistics and distribution capabilities, which it has used to crush its competition. Likewise for FedEx, which is best thought of as a software network that happens to have trucks, planes and distribution hubs attached. Instead of constantly questioning their valuations, let's seek to understand how the new generation of technology companies are doing what they do, what the broader consequences are for businesses and the economy and what we can collectively do to expand the number of innovative new software companies created in the U.S. and around the world.

practitioner's myths

Myths that are still believed by software practitioners have been fostered by over 60 years of programming culture. During the early days, programming was viewed as an art form. Old ways and attitudes die hard. Myth: Once we write the program and get it to work, our job is done. // Reality: Industry data indicate that between 60-80% of all effort expended on software will be expended after it is delivered to the customer for the first time. Myth: Until I get the program "running" I have no way of assessing its quality. // Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project— the technical review. Software reviews are a "quality filter" that have been found to be more effective than testing for finding certain classes of software defects. Myth: The only deliverable work product for a successful project is the working program. // Reality: A working program is only one part of a software configuration that includes many elements. A variety of work products (e.g., models, documents, plans) provide a foundation for successful engineering and, more important, guidance for software support. Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. // Reality: Software engineering is not about creating documents. It is about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times.

software engineering using the cloud

Provides a mechanism for access to all software engineering work products, artifacts, and project-related information. It runs everywhere and removes the device dependency that was once a constraint for many software projects. It allows members of a software team to conduct platform- independent, low-risk trials of new software tools and to provide feedback on those tools. It provides new avenues for distribution and testing of beta software. It provides the potential for improved approaches to content and configuration management. In essence, information dispersion speeds up and broadens dramatically. That changes the software engineering dynamic and can have a profound impact on the human aspects of software engineering. But this is not without risk. The cloud is dispersed over many servers and the architecture and services are often outside the control of a software team. As a consequence, there are multiple points of failure, presenting reliability and security risks. As the number of services provided by the cloud grows, the relative complexity of the software development environment also grows. Does each of these services play well with other services, possibly provided by other vendors? This presents an interoperability risk for cloud services. Finally, if the cloud becomes the development environment, services must stress usability and performance. These attributes sometime conflict with security, privacy, and reliability.

embedded software

Resides within a product or system and is used to implement and control features and functions for the end user and for the system itself. Can perform limited and esoteric functions (e.g., key pad control for a microwave oven) or provide significant function and control capability (e.g., digital functions in an automobile such as fuel control, dashboard displays, and braking systems).

SCRUM meeting

Short (typically 15-minute) meetings held daily. Three key questions are asked and answered by all team members. A team leader, called a Scrum master, leads the meeting and assesses the responses from each person. The Scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily meetings lead to "knowledge socialization" and thereby promote a self-organizing team structure.

software vs hardware

Software has one fundamental characteristic that makes it considerably different from hardware: software doesn't "wear out." When a hardware component wears out, it is replaced by a spare part. There are no software spare parts. Every software failure indicates an error in design or in the process through which design was translated into machine executable code. Therefore, the software maintenance tasks that accommodate requests for change involve considerably more complexity than hardware maintenance.

software curve

Software is not susceptible to environmental maladies. In theory, therefore, the failure rate curve for software should take the form of the "idealized curve." Undiscovered defects will cause high failure rates early in the life of a program. However, these are corrected and the curve flattens. Software doesn't wear out, but it does deteriorate! As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike. Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again. Slowly, the minimum failure rate level begins to rise—the software deteriorates due to change.

application software

Stand-alone programs that solve a specific business need. Applications in this area process business or technical data in a way that facilitates business operations or management/technical decision making.

hardware curve

The "bathtub curve" indicates that hardware exhibits relatively high failure rates early in its life (these failures are often attributable to design or manufacturing defects); defects are corrected and the failure rate drops to a steady-state level for some period of time. As time passes, however, the failure rate rises again as hardware components suffer from the cumulative effects of dust, vibration, abuse, temperature extremes, and many other environmental maladies.

software engineering layers

The bedrock that supports software engineering is a quality focus. The foundation for software engineering is the process layer. The software engineering process is the glue that holds the technology layers together and enables rational and timely development of computer software. Process defines a framework that must be established for effective delivery of software engineering technology. The software process forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (models, documents, data, reports, forms, etc.) are produced, milestones are established, quality is ensured, and change is properly managed. Software engineering methods provide the technical how-to's for building software. Methods encompass a broad array of tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. Software engineering tools provide automated or semi-automated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called computer-aided software engineering, is established.

computer software

The product that software professionals build and then support over the long term. It encompasses programs that execute within a computer of any size and architecture, content that is presented as the computer programs execute, and descriptive information in both hard copy and virtual forms that encompass virtually any electronic media.

deployment

The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation.

web / mobile applications

This network-centric software category spans a wide array of applications and encompasses both browser-based apps and software that resides on mobile devices.

construction

What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code.

modeling

You create a "sketch" of the thing so that you'll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you're going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements.

well-understood requirements

general principles The Reason It All Exists (provide value to users) Keep It Simple, Stupid (all design should be as simple as possible) Maintain the Vision (essential to success of a software project) What You Produce, Others Will Consume (always specify, implement, and design knowing someone else will have to understand what you're doing) Be Open to the Future (never design yourself into a corner) Plan Ahead for Reuse (reduces cost and increases value) Think (place clear, complete thought before action)

categories of computer software

system software, application software, engineering/scientific software, embedded software, product-line software, web/mobile applications, artificial intelligence software

SCRUM key questions

• What did you do since the last team meeting? • What obstacles are you encountering? • What do you plan to accomplish by the next team meeting?