Download Software Engineering Fundamentals: Principles and Practices and more Exams Biology in PDF only on Docsity!
SOFTWARE ENGINEERING
CH1 - CH6 WITH COMPLETE
VERIFIED SOLUTIONS
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). 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 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. 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 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. 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."
business criticality. Each of these process patterns defines a set of development activities: backlog, sprints, and demos. 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. 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. 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. 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. 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) 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. 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. 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. construction
- 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? 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. 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. 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." 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. 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
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. categories of computer software system software, application software, engineering/scientific software, embedded software, product-line software, web/mobile applications, artificial intelligence software 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. 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. 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). 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. 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. 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. 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.
