An Introduction to Software Engineering What is software

An Introduction to Software Engineering

What is software? n n n Computer programs and associated documentation such as requirements, design models and user manuals. Software products may be developed for a particular customer or may be developed for a general market. Software products may be n n Generic - developed to be sold to a range of different customers e. g. PC software such as Excel or Word. Bespoke (custom) - developed for a single customer according to their specification.

What is Software? n n n Software is developed or engineered, it is not manufactured in the classical sense. Software doesn't "wear out. " Although the industry is moving toward component-based construction, most software continues to be custom-built. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3

What is Software? Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4

Wear vs. Deterioration These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5

What is software engineering? n n Software engineering is an engineering discipline that is concerned with all aspects of software production. Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.

What is the difference between software engineering and computer science? n Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

What is the difference between software engineering and system engineering? n n System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. System engineers are involved in system specification, architectural design, integration and deployment.

What are the costs of software engineering? n n n Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability. Distribution of costs depends on the development model that is used.

What are software engineering methods? n n Structured approaches to software development which include system models, notations, rules, design advice and process guidance. Model descriptions n n Rules n n Constraints applied to system models; Recommendations n n Descriptions of graphical models which should be produced; Advice on good design practice; Process guidance n What activities to follow.

What is CASE (Computer-Aided Software Engineering) n n n Software systems that are intended to provide automated support for software process activities. CASE systems are often used for method support. Upper-CASE n n Tools to support the early process activities of requirements and design; Lower-CASE n Tools to support later activities such as programming, debugging and testing.

What are the attributes of good software? n n The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Maintainability n n Dependability n n Software must be trustworthy; Efficiency n n Software must evolve to meet changing needs; Software should not make wasteful use of system resources; Acceptability n Software must accepted by the users for which it was designed. This means it must be understandable,

Software Applications n system software n application software engineering/scientific software embedded software Web. Apps (Web applications) AI software product-line software n n n set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13

Software—New Categories n Open world computing n n the rapid growth of wireless networking may soon lead to true pervasive, distributed computing. The challenge for soft-ware engineers will be to develop systems and application software that will allow mobile devices, personal computers, and enterprise systems to communicate across vast networks. Pervasive computing (also called ubiquitous computing) is the growing trend towards embedding microprocessors in everyday objects so they can communicate information. The words pervasive and ubiquitous mean "existing everywhere. " Pervasive computing devices are completely connected and constantly available Netsourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) 14

Legacy Software n n Legacy software systems. . . were 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. legacy applications and data are those that have been inherited from languages, platforms, and techniques earlier than current technology Why must it change? n n software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment. 15

Characteristics of Web. Apps - I n n n Network intensiveness. A Web. App resides on a network and must serve the needs of a diverse community of clients. Concurrency. A large number of users may access the Web. App at one time. Unpredictable load. The number of users of the Web. App may vary by orders of magnitude from day to day. Performance. If a Web. App user must wait too long (for access, for server-side processing, for client-side formatting and display), he or she may decide to go elsewhere. Availability. Although expectation of 100 percent availability is unreasonable, users of popular Web. Apps often demand access on a “ 24/7/365” basis. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 16

Characteristics of Web. Apps - II n n n . Data driven. The primary function of many Web. Apps is to use hypermedia to present text, graphics, audio, and video content to the end-user. Content sensitive. The quality and visual nature of content remains an important determinant of the quality of a Web. App. Continuous evolution. Unlike conventional application software that evolves over a series of planned, Web applications evolve continuously. Immediacy. Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, Web. Apps often exhibit a time to market that can be a matter of a few days or weeks. Security. Because Web. Apps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application. Aesthetics. An undeniable part of the appeal of a Web. App is its look and feel. When an application has been designed to market or sell products or ideas, aesthetics may have as much to do with success 17 as technical design.

A Layered Technology tools methods process model a “quality” focus Software Engineering These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 18

n n Software engineering is a layered technology. Referring to Figure any engineering approach (including software engineering) must rest on an organizational commitment to quality. Total quality management, Six Sigma, and similar philosophies foster a continuous process improvement culture, and it is this culture that ultimately leads to the development of increasingly more effective approaches to software engineering. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19

n n n 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 include communication, requirements analysis, design modeling, program construction, testing, and support. Software engineering tools provide automated or semi automated support for the process and the methods. A system for the support of software development, called computer-aided software engineering, is established. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 20

The Software Process n A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. n n n 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 design model). A task focuses on a small, but well-defined objective (e. g. , conducting a unit test) that produces a tangible outcome 21

A Process Framework Process framework Framework activities Umbrella Activities These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 22

Framework Activities n n n Communication Planning Modeling n n n Construction n Analysis of requirements Design Code generation Testing Deployment These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23

Framework Activities… n Communication. n 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. n Planning. n 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. n Modeling. A software engineer creating models to better understand software requirements and the design that will achieve those requirements. n Construction. n This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code. 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. n These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 24

Umbrella Activities n Umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include n n n n Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management 25

n n n n Software project tracking and control—allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule. Risk management—assesses risks that may affect the outcome of the project or the quality of the product. Software quality assurance—defines and conducts the activities required to ensure software quality. Technical reviews—assesses software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity. Measurement—defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities. Software configuration management—manages the effects of change throughout the software process. Reusability management—defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components. Work product preparation and production—encompasses the activities required to create work products such as models, documents, logs, forms, and lists. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26

Adapting a Process Model n n n n n the overall flow of activities, actions, and tasks and the interdependencies among them the degree to which actions and tasks are defined within each framework activity the degree to which work products are identified and required the manner which quality assurance activities are applied the manner in which project tracking and control activities are applied the overall degree of detail and rigor with which the process is described the degree to which the customer and other stakeholders are involved with the project the level of autonomy given to the software team the degree to which team organization and roles are prescribed These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27

The Essence of Practice n Polya suggests: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance). These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 28

Understand the Problem n n Who has a stake in the solution to the problem? That is, who are the stakeholders? What are the unknowns? What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29

Plan the Solution n n Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? Has a similar problem been solved? If so, are elements of the solution reusable? Can subproblems be defined? If so, are solutions readily apparent for the subproblems? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 30

Carry Out the Plan n n Does the solution conform to the plan? Is source code traceable to the design model? Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31

Examine the Result n n Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 32

Hooker’s General Principles n n n n 1: The Reason It All Exists 2: KISS (Keep It Simple, Stupid!) 3: Maintain the Vision 4: What You Produce, Others Will Consume 5: Be Open to the Future 6: Plan Ahead for Reuse 7: Think! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (Mc. Graw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33