Introduc)on to So,ware Engineering

Transcription

1 Introduc)on to So,ware Engineering Prof. Robert B. France Dept. of Computer Science Colorado State University The sooner you start to code the longer it will take to complete the program Ray Carlson Robert B. France 1-1 Evolu)on of Programming Fi,ies- early six)es: Early programming concerned with pulng together instruc)ons to solve problems with well- known solu)ons Focus on expressing solu)on in programming language Programs wrimen by end- users Six)es: Growth in demand for so,ware led to users delega)ng programming tasks to programmers Focus on programming- in- the- small concerns Late six)es onwards: Increasing complexity of computer- based systems led to team- based development of so,ware The term so,ware engineering used to refer to the types of solu)ons needed to handle so,ware crisis Focus on programming- in- the- large concerns 2000 onwards: Increasing complexity, pervasiveness, and cri)cality of so,ware systems leads to calls for new genera)on of so,ware development techniques. Focus on quality aspects of so,ware Growing emphasis on engineering rathering than cra,ing so,ware) Robert B. France 1-2 Understanding the nature of so,ware development Are all so,ware systems the same? What makes so,ware development difficult? What gave rise to interest in engineering so,ware? What is so,ware engineering? What processes support disciplined so,ware development? Why should we care? Robert B. France 1-3 1

2 Many different types of so,ware Embedded systems Embedded so,ware interfaces with hardware or other so,ware systems (e.g., so,ware in automobiles, washing machines, cell phones) Distributed systems In a distributed system, so,ware is spread across a number of processors (e.g., communica)on systems, transporta)on monitoring systems) Real- )me systems The correctness of informa)on produced by real- )me systems is dependent on the )me taken to produce the informa)on (e.g., an)- lock braking systems, cruise- control systems, flight management systems). Business systems So,ware used to support business opera)ons (e.g., ERPs, payroll systems, order management systems). Reac)ve systems So,ware that affects its environment in response to changes in the environment (e.g., home climate control systems) Hybrid systems Smart Grid Systems Energy Modeling Systems Internet- based services Robert B. France 1-4 Different types, different concerns Developers of different types of so,ware face o,en must address different concerns What concerns does a developer of an online banking system for a major bank have to address? What concerns does a developers of an app for a mobile phones have to address? No one so,ware development technique will solve all so,ware problems There is no silver bullet (as yet!) Robert B. France 1-5 What makes so,ware development difficult? Novelty of applica)on Cannot rely on previous experience So,ware is intangible Hard to understand development effort Change is more difficult than it appears Developers make changes without fully understanding them Problem is not always well- defined Stakeholders may not have a clear idea of what they require from a system Desired quali)es may be at odds with each other Developers need to make trade- offs Robert B. France 1-6 2

3 What makes so,ware development difficult? (2) Development is currently labor- intensive Hand- cra,ing code for complex systems can be tedious and error- prone Untrained people can hack something together Quality problems are not always evident Robert B. France 1-7 Factors behind the emergence of so,ware engineering What contributed to this chronic so,ware crisis? Inability to predict )me, effort, and costs Inability to deliver quality so,ware Changes in the ra)o of hardware and so,ware costs Increasingly important role of maintenance Increased demand for more complex so,ware Robert B. France 1-8 The nature of the software development crisis is evolving Robert B. France 9 3

4 So,ware Engineering Defini)on SE is the applica)on of a systema'c, scien'fically- based approach by which the capabili)es of computers are made useful to humans via so,ware. Emphasizes both scien)fic and engineering aspects of SE. Robert B. France 1-10 Problem Solving View SE is the discipline of resolving problems with so,ware solu)ons. (B. Blum). Solving customers problems Developers should not presume they know what a customer needs Iden)fying and understanding the problem requires communica)on among so,ware engineers and stakeholders Robert B. France 1-11 Problem Solving Aids Method/technique: guidelines for carrying out a development ac)vity. Tool: an automated system that supports the applica)on of a method/technique Procedure: pre- selected methods and tools that, in concert, promote a certain problem solving approach. Robert B. France

5 The case for engineering so,ware So,ware systems are becoming more complex, more pervasive and more mission- cri)cal So,ware engineering techniques are needed because complex systems cannot be completely understood by one person Teamwork and co- ordina)on are required Key challenge: Dividing up the work (decomposi)on) and ensuring that the parts of the system work properly together (synthesis) The end- product that is produced must, at least, be of adequate quality Robert B. France 1-13 Major so,ware development phases System/Business engineers Concerned with understanding the context in which the so,ware system will fit So,ware Requirements Engineering Concerned with understanding the problem or opportunity the so,ware solu)on addresses So,ware Design Concerned with developing and analyzing a solu)on model that can be transformed to an implementa)on that best meets the so,ware requirements Implementa)on & Tes)ng Concerned with transforming a design to an implementa)on and tes)ng the implementa)on Robert B. France 1-14 Requirements Engineering Requirements gathering, analysis, and specifica)on Involves Defining the problem Requirements gathering Obtaining input from as many sources as possible Requirements analysis Organizing the informa)on Requirements specifica)on Wri)ng detailed instruc)ons about how the so,ware should behave 5

6 So,ware Design Design Deciding how the requirements should be sa)sfied using available technology Involves: So,ware architecture: Dividing the system into subsystems and deciding how the subsystems will interact Detailed design of the internals of a subsystem User interface design Design of databases Robert B. France 1-16 So,ware Development Stakeholders (Roles) Users Those who use the so,ware Customers Those who pay for the so,ware So,ware developers Architects Programmers testers Development Project Managers All of the above can be played by a single person Robert B. France 1-17 What is a Process and why do we need a systema)c process? A so,ware process is a sequence of steps required to develop or maintain so,ware (WaMs Humphrey) A process is a series of steps involving ac)vi)es, constraints, and resources that produce an intended output Good people + good process = lower risk of project failure Robert B. France P-18 6

7 Evolu)on of So,ware Process Models Code and Fix Model Hack )l it works! Waterfall model Focus on up- front ac)vi)es; code not produced un)l very late in development process Incremental/itera)ve agile processes design a limle, code a limle, adjust Project broken down into mini- projects (itera)ons) that each has a Requirements- Design- cod cycle Robert B. France P-19 Choosing a Model Choice depends on nature of project: Are requirements clearly defined and stable? Is there pressure to produce a working product quickly? Are the consequences of opera)onal errors serious? Robert B. France P-20 Radical vs. Conserva)ve Models More radical models suitable when: quick results are needed requirements are fuzzy or unstable More conserva)ve models suitable when: consequences of errors are very serious requirements are well- understood and stable Robert B. France P-21 7

8 The Unified Process: An example of an itera)ve incremental approach The Unified Process is an industry standard process UP is a process framework. It has to be tailored before use in a project Robert B. France 1-22 UP Basics Small steps, feedback and evolu)on Itera)ve, incremental, )me- boxed Risk- driven 2 weeks 2 weeks Robert B. France P-23 Key Prac)ces Deliver product in increments developed in itera)ons Itera)ons are carried out in a fixed )me Developers can choose to drop features but should not extend itera)on High risk and high value aspects tackled in early itera)ons Cohesive architecture implemented in early itera)ons Customers con)nuously engaged in evalua)on, feedback and requirements elicita)on Con)nuously verify quality; test- driven code development Model so,ware Robert B. France P-24 8

9 Mo)va)ng Time- boxing Work expands so as to fill the )me available for comple)on (Parkinson s Law) Forces priori)za)on of tasks and risks Gain confidence of customers Build team confidence/sa)sfac)on Robert B. France P-25 Itera)on Structure Robert B. France P-26 Phases Incep)on Early explora)on of problem to determine project feasibility What s the perceived business value? What are the risks? Elabora)on Requirements detailing (major requirements iden)fied) Itera)ve implementa)on of core architecture Construc)on Itera)ve development of remaining low- risk elements Prepare for deployment Transi)on Beta tests Deployment Robert B. France P-27 9

10 UP phases Note: The phases are not itera)ons Robert B. France 28 Examples of what can go wrong when bad so,ware is used Colorado human resource problem IRS document processing system Military mishaps DIA automated baggage system Therac- 25 machine SDI (Star Wars) Ariane Rocket Robert B. France 1-29 What is Quality? No definitive answer! Notion of quality differs across projects, products, and stakeholders. Customer: solves problems at an acceptable cost in terms of money paid and resources used User: easy to learn; efficient to use; helps get work done Developer: easy to design; easy to maintain; easy to reuse its parts QUALITY SOFTWARE Development manager: sells more and pleases customers while costing less to develop and maintain Robert B. France

11 Quality Objec)ves SeLng objec)ves for quality is a key engineering ac)vity You then design to meet the objec)ves Avoids over- engineering which wastes money Op)mizing is also some)mes necessary E.g. obtain the highest possible reliability using a fixed budget Robert B. France 1-31 Product Quality AMributes Evolvability (a.k.a. maintainability): Is the so,ware easy to extend? Is it easy to adapt? Dependability: Does the so,ware behave in a manner that does not jeopardize its cri)cal mission? Does it protect sensi)ve informa)on? Does it behave safely? So,ware is dependable if it is safe, secure, robust, and reliable Robert B. France 1-32 Product AMributes (2) Efficiency: Will the so,ware perform in a reasonable amount of )me and use a reasonable amount of resources? Usability: Is the so,ware easy to learn and use? Correctness: Does the so,ware behave as stated in its requirements specifica)on? A program is correct with respect to a wri?en specificaaon if it has all specified proper)es. Robustness: Does the so,ware behave well in situa)ons not covered in specifica)ons? A program is robust if it performs its func)on as best as it can even in situa)ons not covered in a specifica)on. Reliability: Does the so,ware produce the desired result consistently over a period of )me? Robert B. France

12 Process AMributes Visibility: Ac)vi)es provide clear indica)ons of progress. Understandability: Ac)vi)es and their order of execu)on are well- defined. Supportability: Automated support for ac)vi)es is available. Usability: Process is acceptable to and usable by developers. Robert B. France 1-34 Essence of SE Concerned with programming- in- the- large and programming- in- the- small issues. Complexity of problems and solu)ons requires team development. Central theme is controlling complexity. Robert B. France 1-35 Essence of SE (2) So,ware evolves (change is inevitable for useful systems). Efficiency of so,ware process is important. So,ware has to effec)vely support its direct and indirect users. Robert B. France

13 Physical vs. So,ware Engineering In SE cost of construc)on is incurred during development; manufacturing costs are compara)vely inexpensive. So,ware has no physical parts, thus reliability is determined by errors in design and construc)on. Robert B. France 1-37 Physical vs. So,ware Engineering (2) Visibility is low - difficult to visualize progress. So,ware is not con)nuous in nature. Small errors can have disastrous effects. Small changes in specifica)on do not o,en translate to small changes in implementa)on. Robert B. France 1-38 SE Findings So,ware development tasks are o,en devoted to maintaining exis)ng systems The later errors are iden)fied the more expensive they are to correct. Failure to define correct requirements account for the greatest number of errors. Robert B. France

14 SE Findings (2) Programming is less error prone than design. Adding manpower to a late project makes it later. As so,ware evolves its complexity increases unless it is properly maintained. Robert B. France 1-40 SE Myths So,ware development is primarily concerned with programming. So,ware change is easily accommodated because so,ware is flexible. A developer s task is finished when so,ware is delivered to customer. Success of a project is determined solely by product quality. Robert B. France 1-41 SE Myths (2) A developer need only show that a program is correct w.r.t. a specifica)on to validate its func)on. Use of state- of- the- art technology will solve all development problems. Robert B. France

15 SE Myths (3) All programmers are equal in ability. Developing and documen)ng standards will solve development problems. Development difficulty depends only on func)onal complexity. So,ware errors are unavoidable. Robert B. France