Скачать презентацию Software Engineering Introduction Software Engineering 2012 Department of Скачать презентацию Software Engineering Introduction Software Engineering 2012 Department of

e1ef40c513721c83b3b43f7a5a1c3fd0.ppt

  • Количество слайдов: 55

Software Engineering Introduction Software Engineering 2012 Department of Computer Science Ben-Gurion university Based on Software Engineering Introduction Software Engineering 2012 Department of Computer Science Ben-Gurion university Based on Presentation by Mira Balaban Department of Computer Science Ben-Gurion university Igor Potapov: http: //www. csc. liv. ac. uk/~igor/COMP 201 Ian Sommerville: http: //www. comp. lancs. ac. uk/computing/resources/Ian. S/SE 7/Presentations/index. html Alexander Borgida: http: //www. cs. rutgers. edu/~borgida/431/

What is software? Computer programs and associated documentation Software products may be developed for What is software? Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market Software products may be Generic - developed to be sold to a range of different customers Bespoke (custom) - developed for a single customer according to their specification 2 Software Engineering, 2012 Introduction

What is Engineering? Application of a systematic, disciplined, quantifiable approach to structures, machines, products, What is Engineering? Application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems, processes. 3 Software Engineering, 2012 Introduction

What is Software Engineering? Software Engineering is that form of engineering that applies • What is Software Engineering? Software Engineering is that form of engineering that applies • a systematic disciplined quantifiable approach • the principles of computer science, design, engineering, management, mathematics, psychology, sociology, and other disciplines as necessary • and sometimes just plain invention to creating, developing, operating and maintaining cost-effective, reliably correct, high-quality solutions to software problems [Definition by Berry 92] SE requires the identification of a problem, a computer to carry execute a software product, and a user environment (composed of people, tools, methodologies, etc. ) 4 Software Engineering, 2012 Introduction

Software Engineering - Motivation 5 Software Engineering, 2012 Introduction Software Engineering - Motivation 5 Software Engineering, 2012 Introduction

The task of software engineers? Software engineers should adopt a systematic and organised approach The task of software engineers? Software engineers should adopt a systematic and organised approach to their work use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available 6 Software Engineering, 2012 Introduction

Origin of Software Engineering? Software engineering deals with the development of high-quality software systems. Origin of Software Engineering? Software engineering deals with the development of high-quality software systems. Software engineering is abstract – no physical limitations: leads to unlimited complexity. Software engineering – coined in 1968: within discussion of software crisis. 7 Software Engineering, 2012 Introduction

What is the “software crisis”? Major projects are meaningfully late. Software costs more than What is the “software crisis”? Major projects are meaningfully late. Software costs more than predicted. Software is unreliable. Software is difficult to maintain. Poor performance. While hardware costs were decreasing, software costs were rising. requires techniques to control the complexity of large software systems. 8 Software Engineering, 2012 Introduction

Standish Group’s CHAOS 2009 Report Successful -projects delivered on time, on budget, with required Standish Group’s CHAOS 2009 Report Successful -projects delivered on time, on budget, with required features and functions. Challenged - late, over budget, and/or with less than the required features and functions. Failed - cancelled prior to completion or delivered and never used. 9 Software Engineering, 2012 Introduction

Why Software Engineering is Needed? Software development is hard ! Important to distinguish “easy” Why Software Engineering is Needed? Software development is hard ! Important to distinguish “easy” systems (one developer, one user, experimental use only) from “hard” systems (multiple developers, multiple users, products). Experience with “easy” systems is misleading: One person techniques do not scale up. Analogy with bridge building: Over a stream = easy, one person job. Over a big River … ? (the techniques do not scale) ` 10 Software Engineering, 2012 Introduction

Why is SE hard? real world problems: Requirements are not clear and “acceptability” is Why is SE hard? real world problems: Requirements are not clear and “acceptability” is defined by user satisfaction For example: “software to help people control nuclear reactors” As opposed to problems where there are pre-stated specifications (e. g. , “write a program to find the shortest path. . . ”), where it makes sense to talk about the correctness of a solution wicked problems: define and solve concurrently no unique definition or solution always room for improvement in def’n and sol’n new problem, not previously encountered many stakeholders, with different goals 11 Software Engineering, 2012 Introduction

Essential Difficulties of SE: [Brooks] COMPLEXITY: • software is more complex for its size Essential Difficulties of SE: [Brooks] COMPLEXITY: • software is more complex for its size than any other human construct; no two parts are alike (vs. car, microchips, . . . ); • science advances by simplifying, while software cannot ignore/simplify details of real world • CONFORMITY: • among {hardware, software, people, organizations} it is software which is chosen to bend or adapt because it is more malleable, last to arrive on the scene, usually one developed on site, . . . • CHANGEABILITY: • once delivered, most engineered products (hardware, cars, buildings) are rarely changed because the cost to change would be a large fraction of the cost to make. The (unfortunate) perception is that software is cheap to change. And pressure to change comes from successful use, and aging hardware platform. • INVISIBILITY: • since it has no physical reality, software is not properly visualizable with diagrams, etc. in the way in which houses, circuits, etc are. 12 Software Engineering, 2012 Introduction

Why Software Engineering Is Hard? The main problem is complexity Many sources, but size Why Software Engineering Is Hard? The main problem is complexity Many sources, but size is key: UNIX contains 4 million lines of code Windows 2000 contains 108 lines of code Software engineering is about managing this complexity. 13 Software Engineering, 2012 Introduction

What will (not) make a big difference: [Brooks 1987] • Minor • Ada or What will (not) make a big difference: [Brooks 1987] • Minor • Ada or Java or C# or Python or. . . • Object-Oriented Programming • Artificial Intelligence • Automatic Programming • Graphical programming • Program verification • Environments and tools • Workstations • Major • Buy vs build • Requirements refinement and prototyping • Incremental development • Great designers (Unix, Pascal, Smalltalk vs Cobol, PL/I. Ada, MS-DOS) 14 Software Engineering, 2012 Introduction

SE: Processes, Models, and Tools Processes: Systematic ways of organizing teams and tasks so SE: Processes, Models, and Tools Processes: Systematic ways of organizing teams and tasks so that there is a clear, traceable path from customer requirements to the final product (e. g. , Waterfall, Prototyping, Spiral, etc. ) Processes help organize and co-ordinate teams, prepare documentation, reduce bugs, manage risk, increase productivity, etc. Models: Well-defined formal or informal languages and techniques for organizing and communicating arguments and decisions about software. e. g: specification languages (Z, etc) design models (UML, etc) Models help stake-holders communicate: customers with developers, designers and developers, developers and testers etc. If they are formal, they also can help support automation Tools: Programs which automate or otherwise support software development tasks: e. g. , Eclipse, Make, CVS, etc. Tools increase productivity, quality and can reduce costs 15 Software Engineering, 2012 Introduction

What is a software process? A structured set of activities required to develop a What is a software process? A structured set of activities required to develop a software system Generic activities in all software processes are: Specification - what the system should do and its development constraints. Development - production of the software system Validation - checking that the software is what the customer wants. Evolution - changing the software in response to changing demands. 16 Software Engineering, 2012 Introduction

Software Engineering Activities 1. Problem statement • needs analysis • requirements specification: functional, non-functional Software Engineering Activities 1. Problem statement • needs analysis • requirements specification: functional, non-functional 2. Design • architectural • detailed • (communication, database) 3. Implementation Development • coding • testing: • module • integration • documentation Validation 4. Maintenance • corrective • adaptive • enhancement 17 Specification Evolution Software Engineering, 2012 Introduction

What is a software process model? An abstract representation of a process It presents What is a software process model? An abstract representation of a process It presents a description of a process from some particular perspective Examples of process perspectives: Workflow perspective represents inputs, outputs and dependencies. Data-flow perspective represents data transformation activities. Role/action perspective represents the roles/activities of the people involved in software process. Generic process models: Waterfall Separate and distinct phases of specification and development In practice applied for the design and implementation phase of software development Evolutionary development Specification, development and testing are interleaved Formal transformation A mathematical system model is formally transformed to an implementation Integration from reusable components 18 The system is assembled from existing components Software Engineering, 2012 Introduction

What is CASE ? (Computer-Aided Software Engineering) Software systems which are intended to provide What is CASE ? (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities, such as requirements analysis, system modelling, debugging and testing. Upper-CASE Tools to support the early process activities of requirements and design. Lower-CASE Tools to support activities such as programming, debugging and testing. 19 Software Engineering, 2012 Introduction

The costs of software engineering Roughly 60% of costs are development costs, 40% are The costs of software engineering 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 the requirements of system attributes such as performance and system reliability. Distribution of costs depends on the development model that is used. 20 Software Engineering, 2012 Introduction

The attributes of good software? The software should deliver the required functionality and performance The attributes of good software? The software should deliver the required functionality and performance to the user and should be maintainable, dependable, efficient and usable Maintainability Software must evolve to meet changing needs. Dependability Software must be trustworthy. Efficiency Software should not make wasteful use of system resources. Usability Software must be usable by the users for which it was designed. 21 Software Engineering, 2012 Introduction

Software engineering as a discipline within computer science Computer Science Software Engineering is concerned Software engineering as a discipline within computer science Computer Science Software Engineering is concerned with Ø theory Ø fundamentals Ø the practicalities of developing Ø delivering useful software Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering 22 Software Engineering, 2012 Introduction

What is the difference between software engineering and system engineering? Software engineering is part What is the difference between software engineering and system engineering? Software engineering is part of System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering System engineers are involved in system specification, architectural design, integration and deployment 23 Software Engineering, 2012 Introduction

What are the key challenges facing software engineering? Software engineering in the 21 st What are the key challenges facing software engineering? Software engineering in the 21 st century faces three key challenges: Heterogeneity Systems are distributed and include a mix of hardware and software. Legacy systems (old valuable systems) must be maintained, updated and integrated into new systems. Delivery There is an increasing pressure for faster delivery of software. Trust Software must be trusted by its naive users. 24 Software Engineering, 2012 Introduction

Professional and ethical responsibility (1) Software engineering involves wider responsibilities than simply the application Professional and ethical responsibility (1) Software engineering involves wider responsibilities than simply the application of technical skills. Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. Ethical behaviour is more than simply upholding the law. 25 Software Engineering, 2012 Introduction

Issues of professional responsibility (2) Confidentiality Engineers should normally respect the confidentiality of their Issues of professional responsibility (2) Confidentiality Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence 26 Engineers should not misrepresent their level of competence. They should not knowingly accept work which is out with their competence. Software Engineering, 2012 Introduction

Issues of professional responsibility (3) Intellectual property rights Engineers should be aware of local Issues of professional responsibility (3) Intellectual property rights Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse 27 Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses). Software Engineering, 2012 Introduction

ACM/IEEE Code of Ethics The professional societies in the US have cooperated to produce ACM/IEEE Code of Ethics The professional societies in the US have cooperated to produce a code of ethical practice. Members of these organisations sign up to the code of practice when they join. The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. 28 Software Engineering, 2012 Introduction

29 Software Engineering, 2012 Introduction 29 Software Engineering, 2012 Introduction

Code of ethics - principles 1. PUBLIC Software engineers shall act consistently with the Code of ethics - principles 1. PUBLIC Software engineers shall act consistently with the public interest. 2. CLIENT AND EMPLOYER Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. 3. PRODUCT Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 30 Software Engineering, 2012 Introduction

Code of ethics - principles 4. JUDGMENT Software engineers shall maintain integrity and independence Code of ethics - principles 4. JUDGMENT Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 31 Software Engineering, 2012 Introduction

Code of ethics - principles 7. COLLEAGUES Software engineers shall be fair to and Code of ethics - principles 7. COLLEAGUES Software engineers shall be fair to and supportive of their colleagues. 8. SELF Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. 32 Software Engineering, 2012 Introduction

Ethical dilemmas Disagreement in principle with the policies of senior management. 33 Your employer Ethical dilemmas Disagreement in principle with the policies of senior management. 33 Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. Participation in the development of military weapons systems or nuclear systems. Software Engineering, 2012 Introduction

Summary: Key points (1) Software engineering is an engineering discipline that is concerned with Summary: Key points (1) Software engineering is an engineering discipline that is concerned with all aspects of software production. Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, efficiency and usability. The software process consists of activities that are involved in developing software products. Basic activities are software specification, development, validation and evolution. Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines. 34 Software Engineering, 2012 Introduction

Summary: Key points (2) CASE tools are software systems which are designed to support Summary: Key points (2) CASE tools are software systems which are designed to support routine activities in the software process such as editing design diagrams, checking diagram consistency and keeping track of program tests which have been run. Software engineers have responsibilities to the engineering profession and society. They should not simply be concerned with technical issues. Professional societies publish codes of conduct which set out the standards of behaviour expected of their members. 35 Software Engineering, 2012 Introduction

The Software Process A structured set of activities required to develop a software system The Software Process A structured set of activities required to develop a software system Specification Analysis, design and implementation. Validation Evolution A software process model is an abstract representation of a process A general approach for organizing a project into activities; It presents a description of a process from some particular perspective An aid to thinking, not a rigid prescription of the way to do things 36 Software Engineering, 2012 Introduction

Waterfall Model • Inflexible partitioning of the project into distinct stages • Difficult to Waterfall Model • Inflexible partitioning of the project into distinct stages • Difficult to respond to changing customer requirements 37 Software Engineering, 2012 Introduction

Evolutionary development System requirements always evolve in the course of a project. Specification is Evolutionary development System requirements always evolve in the course of a project. Specification is evolved in conjunction with the software No complete specification in the system development contract 38 Software Engineering, 2012 Introduction

Incremental Development Incremental development is a staging and scheduling strategy in which various parts Incremental Development Incremental development is a staging and scheduling strategy in which various parts of the system are developed at different times or rates, and integrated as they are completed. The alternative strategy to incremental development is to develop the entire system with a “big bang” integration at the end. Using both incremental and iterative development 39 © Alistair Cockburn 2008 Software Engineering, 2012 Introduction

 Incremental Development – Version I דרישות אימות ניתוח אימות הנדסת מערכת ארכיטקטורה אימות Incremental Development – Version I דרישות אימות ניתוח אימות הנדסת מערכת ארכיטקטורה אימות תכן מפורט מימוש הקמת מימוש מבנה ) (build 1, 2, . . . , n מימוש שילוב בדיקות הפעלה מבצעית מסירה פרישה Introduction 2102 , Software Engineering • פיתוח • אחזקה 04

 Incremental Development – Version II מבנה 1 ניתוח מבנה 2 ניתוח תכן מבנה Incremental Development – Version II מבנה 1 ניתוח מבנה 2 ניתוח תכן מבנה n ניתוח תכן מימוש ושילוב מסירה מימוש ושילוב קבוצת ניתוח קבוצת תכן קבוצת מימוש מסירה Introduction תכן 2102 , Software Engineering 14

Iterative Development Iterative development is a rework scheduling strategy in which time is set Iterative Development Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The alternative strategy to iterative development is to plan to get everything right the first time. Using both incremental and iterative development 42 © Alistair Cockburn 2008 Software Engineering, 2012 Introduction

Iterative Development There are two particular, specialized rework strategies: Develop the system as well Iterative Development There are two particular, specialized rework strategies: Develop the system as well as possible, in the thinking that if it is done sufficiently well, the changes will be relatively minor and can be incorporated quickly Develop the least amount possible before sending out for evaluation, in the thinking that less work will be wasted when the new information arrives. Mona Liza example 43 Software Engineering, 2012 Introduction

Incremental means adding, iterative means reworking (by Alistair Cockburn) Incremental development is a staging Incremental means adding, iterative means reworking (by Alistair Cockburn) Incremental development is a staging and scheduling strategy in which the various parts of the system are developed at different times or rates and integrated as they are completed. The alternative is to develop the entire system with a big bang integration at the end. Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The alternative development is to get it right the first time (or at least declare that it is right!). Iterate Increment fundamentally means “change”. fundamentally means “add onto”. repeating the process on the same section of work repeating the process on a new section of work. repeat the process (, design, implement, evaluate), http: //www. stickyminds. com/Better. Software/magazine. asp? fn=cifea&id=108 44 Software Engineering, 2012 Introduction

Spiral model (Boehm 87) Objective setting Specific objectives for the phase are identified. Risk Spiral model (Boehm 87) Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. • Process is spiral - not a sequence of activities with backtracking. • A loop = phase in the process. • No fixed phases such as specification or design • loops are chosen depending on what is required. • Risks are explicitly assessed and resolved throughout the process. Planning The project is reviewed and the next phase of the spiral is planned. 45 Development and validation A development model for the system is chosen which can be any of the generic models. Software Engineering, 2012 Introduction

The (Rational) Unified Process Each cycle : Inception Establish the business case for the The (Rational) Unified Process Each cycle : Inception Establish the business case for the system. Elaboration Develop an understanding of the problem domain and the system architecture. Construction System design, programming and testing. Transition Deploy the system in its operating environment. • Picture taken from: http: //www. ibm. com/developerworks/webservices/library/ws-soa-term 2/ 46 Software Engineering, 2012 Introduction

Agile 47 Software Engineering, 2012 Introduction Agile 47 Software Engineering, 2012 Introduction

What is an Agile method? Focus on the code rather than the design. Based What is an Agile method? Focus on the code rather than the design. Based on an iterative approach to software development. Intended to deliver working software quickly. Evolve quickly to meet changing requirements. There are claims that agile methods are probably best suited to small/mediumsized business systems or PC products. More active customer involvement needed Considered People-based rather than Plan-based Several agile methods Extreme Programming (XP) most popular No single definition -Agile Manifesto (2001) closest to a definition Set of principles Developed by Agile Alliance 48 Software Engineering, 2012 Introduction

The players in the game are “People” Weak on: Consistency Discipline Following instructions Strong The players in the game are “People” Weak on: Consistency Discipline Following instructions Strong on: Communicating Looking around Copy / modifying Motivated by: Pride in work Pride in contributing Pride in accomplishment 49 Software Engineering, 2012 Introduction

Summary of Principles of agile methods 50 Software Engineering, 2012 Introduction Summary of Principles of agile methods 50 Software Engineering, 2012 Introduction

What are the Agile Methodologies? e. Xtreme Programming has received the most attention, but What are the Agile Methodologies? e. Xtreme Programming has received the most attention, but here is a list: XP SCRUM DSDM The Crystal Family ASD FDD d. X (agile RUP) q Open Source q Agile Modeling q Pragmatic Programming q q 51 Software Engineering, 2012 Introduction

e. Xtreme Programming Development and delivery of very small increments of functionality. Relies on e. Xtreme Programming Development and delivery of very small increments of functionality. Relies on constant code improvement, user involvement in the development team and pair wise programming. Emphasizes Test Driven Development (TDD) as part of the small development iterations. 52 Software Engineering, 2012 Introduction

Claimed Problems with agile methods It can be difficult to keep the interest of Claimed Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritising changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development. 53 Software Engineering, 2012 Introduction

Problems with incremental development (from a waterfall eye…) Management problems Contractual problems The normal Problems with incremental development (from a waterfall eye…) Management problems Contractual problems The normal contract may include a specification; without a specification, different forms of contract have to be used. Validation problems Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done. Without a specification, what is the system being tested against? Maintenance problems 54 Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements. Software Engineering, 2012 Introduction

SE Research Occasionally, a researcher gets an idea for a new approach that may SE Research Occasionally, a researcher gets an idea for a new approach that may seem ridiculous to others, who discount it. However, in any area of active research, it is dangerous to discount any approach that has a reason that it might work and that has not been specifically disproved. No one can know ahead of time whether or not the approach will work. If we discount an approach that would have worked, we are cutting ourselves off from a benefit. Ultimately, we cannot discount anything that might yield a solution, anything reasonable that has not been demonstrated not to have any impact on the process or the software. Academic Legitimacy of the Software Engineering Discipline (Daniel M. Berry) 55 Software Engineering, 2012 Introduction