Software Engineering. Introduction. Software Costs. Software is Expensive [Boehm] ... Columbus set sail for India. He ended up in the Bahamas...

Transcription

1 Software Engineering Introduction... Columbus set sail for India. He ended up in the Bahamas... The economies of ALL developed nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories, methods and tools for professional software development Software engineering expenditure represents a significant fraction of GNP in all developed countries G. Antoniol 2002 Software Engineering - Why 1 G. Antoniol 2002 Software Engineering - Why 2 Software is Expensive [Boehm] Software Costs 100 % Hardware Development Maintenance Sofware development is human intensive There is no cost to produce a copy of a given software Software is flexible and can be changed to adapt to user ever changing needs G. Antoniol 2002 Software Engineering - Why 3 G. Antoniol 2002 Software Engineering - Why 4

2 Late Costly Unreliable Many software projects are behind schedule and have heavy cost overruns An information system for a US company planned in 9 months and at a cost of $250000; after 2.5 years and $ the job was not done, it was estimated that another $ would be needed [Mcfarlan]. An information system for a US company planned in 9 months and at a cost of $250000; after 2. US Air Force command-and-control: contract $400000, renegotiated to $700000, to $ final cost $ [Boehm]. US defense survey: more than 70 % of all equipment failure were due to software. Failure of the Arianne 5 and an early Apollo flight were due to software failure, many banks lost millions of dollars due to software inaccuracy. G. Antoniol 2002 Software Engineering - Why 5 Failure Software failure are different from mechanical or electrical system failure. Mechanical systems develop some problem (due to age) that did not exist earlier. Software never wears out due to age. Errors are introduced during software production. When a software fails the bug was there from the beginning may be in the environment. G. Antoniol 2002 Software Engineering - Why 6 Software Program: the author is the user (e.g., no documentation or testing, no design). Programming system product: used by people other than the developer of the system. This is industrial software it cost about 10 times as much as a corresponding program. IEEE Software Definition Software is the collection of computer programs, procedures, rules and associated documentation and data. Software means: industrial quality software. Software is much more than the code G. Antoniol 2002 Software Engineering - Why 7 G. Antoniol 2002 Software Engineering - Why 8

3 Software Products Generic products Stand-alone systems which are produced by a development organization and sold on the open market to any customer Most software expenditure is on generic products but most development effort is on bespoke systems Bespoke (customized) products Systems which are commissioned by a specific customer and developed specially by some contractor Software product attributes Maintainability It should be possible for the software to evolve to meet changing requirements Dependability The software should not cause physical or economic damage in the event of failure Efficiency The software should not make wasteful use of system resources Usability Software should have an appropriate user interface and documentation G. Antoniol 2002 Software Engineering - Why 9 G. Antoniol 2002 Software Engineering - Why 10 Importance of product characteristics The relative importance of these characteristics depends on the product and the environment in which it is to be used In some cases, some attributes may dominate In safety-critical real-time systems, key attributes may be dependability and efficiency Costs tend to rise exponentially if very high levels of any one attribute are required Professional responsibility Software engineers should not just be concerned with technical considerations. They have wider ethical, social and professional responsibilities. No clear rights and wrongs about many of these issues. Code Of Ethics G. Antoniol 2002 Software Engineering - Why 11 G. Antoniol 2002 Software Engineering - Why 12

4 Ethical Issues Software Engineering [IEEE90] Confidentiality Competence Intellectual property rights Computer misuse Software Engineering is the systematic approach to the development, operation, maintenance and retirement of software. Software Engineering means applications of a systematic, disciplined, quantifiable approach to development, operation, maintenance of software. G. Antoniol 2002 Software Engineering - Why 13 G. Antoniol 2002 Software Engineering - Why 14 Notice It implies a process since it points to different phases It stresses the need of a systematic and disciplined approach It highlights the importance of quantification Software Engineering [Boehm] Software Engineering is the application of science and mathematics by which the capabilities of computer equipments are made useful to man via computer programs, procedures, and associated documentation. Empirical studies and empirical methods are related to the 3 mentioned aspects G. Antoniol 2002 Software Engineering - Why 15 G. Antoniol 2002 Software Engineering - Why 16

5 Software Engineering Deals with the economics of software systems during the entire system life. Provide methodologies for developing software: usable/useful to man in a repeatable way in an economic way Cost Schedule and Quality An engineering discipline is drive by practical parameters: cost schedule quality They are conflicting requirements! G. Antoniol 2002 Software Engineering - Why 17 G. Antoniol 2002 Software Engineering - Why 18 Cost Is the cost of used resources: manpower, hardware, software and support resources. Manpower is predominant, software is still labor intensive. The cost is expressed in terms of personmonth. To obtain the project cost multiply the number of person-month by the unit cost per person-month, this includes all the overheads. Schedule Product time to market tends to be reduced. The cycle time from concept to delivery should be small. Often the window of opportunity is small (e.g., financial applications). New keywords: Rapid Application Development, COTS, Framework, G. Antoniol 2002 Software Engineering - Why 19 G. Antoniol 2002 Software Engineering - Why 20

6 Quality Quality Factors Quality is not clearly understood, there are three dimensions: product operation product transition product revision Maintainability Flexibility Testability Product revision Product transition Portability Reusability Interoperability Product operations Correctness Reliability Efficiency Integrity Usability G. Antoniol 2002 Software Engineering - Why 21 G. Antoniol 2002 Software Engineering - Why 22 Product Operations Correctness: to which extent the program satisfies its specification. Reliability: how well the software meets its requirements. Efficiency: response time, memory usage... Usability: the effort to learn to operate with the system Integrity: ability to withstand attacks to its security Product Revision Maintainability: effort required to locate and fix errors in an operating program. Flexibility: effort required to modify an operational program. Testability: effort required to test, to ensure that the system actually does what it is supposed to do. G. Antoniol 2002 Software Engineering - Why 23 G. Antoniol 2002 Software Engineering - Why 24

7 Product Transition Portability: effort required to transfer the software from one configuration to other configurations. Reusability: is the extent to which parts of the software can be reused in other related applications Interoperability: effort required to couple the system with other systems. Quality Criteria Among many indicators a de facto standard is the reliability related measure of the number of defect per unit of size, i.e LOC defect tracking is a key activity best software practice reduce to less than 1 defect per KLOC Defect is a anything which is non compliant with system requirements. G. Antoniol 2002 Software Engineering - Why 25 G. Antoniol 2002 Software Engineering - Why 26 Consistency Problem High quality, low cost in a short time are the goals: How can we ensure a consistent quality with a consistent productivity (i.e., cost and schedule)? Engineering process model Specification - set out the requirements and constraints on the system Design - Produce a paper model of the system Manufacture - build the system Test - check the system meets the required specifications Install - deliver the system to the customer and ensure it is operational G. Antoniol 2002 Software Engineering - Why 27 G. Antoniol 2002 Software Engineering - Why 28

8 The Software Engineering Approach Software Process Peculiarity Normally, specifications are incomplete/anomalous Develop methods and procedures for software development that can scale up for large system and that can be used to consistently produce high quality software at low cost and with a small cycle time. Very blurred distinction between specification, design and manufacture No physical realization of the system for testing Software does not wear out - maintenance does not mean component replacement G. Antoniol 2002 Software Engineering - Why 29 G. Antoniol 2002 Software Engineering - Why 30 Process A process is a particular methods of doing Something generally involving a sequence of steps Software process: the method of developing software Predictability Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed: cost and schedule estimate quality estimate G. Antoniol 2002 Software Engineering - Why 31 G. Antoniol 2002 Software Engineering - Why 32

9 Predictability Predictions are based on the past history Prediction are only probabilistic Predictability is essential to ensure consistency across many projects Predictability is essential to ensure repeatability G. Antoniol 2002 Software Engineering - Why 33 Statistical Control A process is under statistical control if following the same process produces similar results Statistical control means that most projects will be within a bound around the expected value Property of interest Projects G. Antoniol 2002 Software Engineering - Why 34 Software Process A set of activities Software Process Resources A set of ordering constraints (among activities) activity are performed in accordance with ordering constraints Product Idea Software Process Product the desired result is obtained low cost and high quality software G. Antoniol 2002 Software Engineering - Why 35 G. Antoniol 2002 Software Engineering - Why 36

10 Process Key Properties It must scale up (handle large software projects) It must produce good quality software It must be cost effective It must deliver products on time It must be predictable It must be repeatable The Problem of Scale Developing a very large system requires very different set of methods compared to developing a small system. Methods for small systems generally do not scale up. Counting people in a room or in a theater or conducting a census G. Antoniol 2002 Software Engineering - Why 37 G. Antoniol 2002 Software Engineering - Why 38 A Phased Approach Separate developed product from development process. Divide the entire process in a sequence of phases. Monitor each phase with objective methods: you cannot control what you cannot measure [Tom DeMarco] Large Projects Technology and methodology to develop the system. A formal approach to project management. A phased development process: requirements analysis; software design; coding; testing; G. Antoniol 2002 Software Engineering - Why 39 G. Antoniol 2002 Software Engineering - Why 40

11 High Level View The Problem of Scale Formal Inception Elaboration Construction Transition Project management Informal Small Project Informal Large Project Development methods Formal G. Antoniol 2002 Software Engineering - Why 41 G. Antoniol 2002 Software Engineering - Why 42 Organizations and Processes There are many non-software engineering processes running in an organization: business processes training processes social processes they influence software production but do not concern software engineering G. Antoniol 2002 Software Engineering - Why 43 Development Process Activities directly related to the software production requirement capture, design, coding testing Components of the development process for a particular phase are frequently called methodologies G. Antoniol 2002 Software Engineering - Why 44

12 Software Process The process that deals with the technical and management issues of software development is called software process There must be at least: development activities project management activities Different people may perform different activities Process Project Product A software process specifies a method of developing software A software project is a development project in which the software process is used A software product is an outcome of a software project obtained by applying a software process G. Antoniol 2002 Software Engineering - Why 45 G. Antoniol 2002 Software Engineering - Why 46 Process Project Product - Again A software process specifies an abstract set of activities A software project is the actual act of executing the activities for some specific user need A software product is any product delivered during the software project Process Project Product Software Process Project Project Project 1 k n Product 1 Product 2 Product k Product n G. Antoniol 2002 Software Engineering - Why 47 G. Antoniol 2002 Software Engineering - Why 48

13 Process Instantiation Software process specifies a sequence of activity at abstract level (not project specific) A project implements, in a tailored fashion, the abstract software process The project plan is a detailed roadmap, for the given project, that specifies: the specific activities to perform when perform the activities how perform the activities G. Antoniol 2002 Software Engineering - Why 49 Component Software Processes We need to develop a software system We need manage, to keep under control the development process We must handle change requests at any arbitrary point in time Beyond these activities (processes) there are other activities that are non-central: business processes, training processes, etc. G. Antoniol 2002 Software Engineering - Why 50 Component Software Processes Process management process Product engineering processes: development process project management process software configuration (control) process Process Management Process A software process is a dynamic entity The software process must adapt to new tools, technologies The software process must adapt to our increased understanding about software development process management process aims to improve software the software process i.e., produce better software at lower costs HOW..? G. Antoniol 2002 Software Engineering - Why 51 G. Antoniol 2002 Software Engineering - Why 52

14 Component Software Processes Software Process Effort Distribution Requirements 10 % Product Engineering Processes Process Management Process Design 20 % Coding 20 % Development Process Project Management Process Software Configuration Management Process Testing 50 % G. Antoniol 2002 Software Engineering - Why 53 G. Antoniol 2002 Software Engineering - Why 54 Programmer Activities Writing programs 13 % Reading programs and manuals Job communication (e.g. meetings) Other (including parsonal) 16 % 32 % 39 % Lesson Learnt Coding covers only a fraction of development costs Development covers only a fraction of entire life span cost We must focus on maintenance and testing to ensure cost effectiveness develop for maintainability develop for testability G. Antoniol 2002 Software Engineering - Why 55 G. Antoniol 2002 Software Engineering - Why 56

15 Defects Defects are injected at every stage Defect prevention is a key activity Early defect removal is mandatory to ensure cost effectiveness Requirement analysys 20 % Design 30 % Coding 50 % G. Antoniol 2002 Software Engineering - Why 57 Defects Removal Costs Requirements Design Code Development Acceptance Operation Test Test G. Antoniol 2002 Software Engineering - Why 58 Defects Prevention Prevent defect from being introduced Use the development process to learn (from previous projects) so that methods of performing activities, processes can effectively be improved Quality Improvement Paradigm (QIP) Software process operate in a closed-loop: the process must learnt from past experiences: each project must feed information back to software process for self-improvement Improvement process Assessment of the software process Evaluation of a software process improvement proposal Software development/evolution is highly human intensive it is very difficult to evaluate a change without human involvment G. Antoniol 2002 Software Engineering - Why 59 G. Antoniol 2002 Software Engineering - Why 60

16 Empirical studies Evaluate processes and human based activities Evaluate the use of software products and tools Experimentation provides a systematic, quantifiable, controlled way of evaluating human based activities Research Methods [Basili] The scientific method: observe the world, build an observation based model The engineering method: study the current solutions, propose and evaluate changes The empirical method: a model is proposed and evaluated via case studies or experiments The analytical method: a formal theory is proposed and then compared with empirical observations G. Antoniol 2002 Software Engineering - Why 61 G. Antoniol 2002 Software Engineering - Why 62 Empirical Study Cost Different people are involved with different activities/processes Development, maintenance, evolution may be performed in different environment companies by different people We do not develop the same software several times Qualitative Research Paradigms Qualitative studies: studying object in their natural setting We accept that there is a range of different ways of interpretation Aiming at discovering the causes noticed by the subjects in the study Subject is the person taking part in an experiment in order to evaluate an object. G. Antoniol 2002 Software Engineering - Why 63 G. Antoniol 2002 Software Engineering - Why 64

17 Quantitative Research Paradigms Quantitative studies: quantifying a relationship or compare two or more groups Identify cause effect relationship Setting up a formal experiment Case studies Qualitative vs Quantitative A quantitative study may be launched to evaluate the reduction of defects discovered in system testing due to the adoption of a new testing tool suite A qualitative study may attempt to address the different source of variations (e.g., unit testing, test management, ) G. Antoniol 2002 Software Engineering - Why 65 G. Antoniol 2002 Software Engineering - Why 66 Empirical Strategies Setting up formal experiments Studying real projects - also said case studies Performing surveys (e.g., is interviews) Survey Often an investigation performed in retrospect a tool or a technique has been in use for a while [Pfleeger] Data are gathered via interviews Interviews are done taking a representative sampling of the population The survey generalization limited to the population from which the sample was taken G. Antoniol 2002 Software Engineering - Why 67 G. Antoniol 2002 Software Engineering - Why 68

18 Survey Purposes Descriptive: to enable assertion about some population What the distribution is - We are not interested in why the observed distribution exists Explanatory Making explanatory claim on the population - why certain programmer prefer Java? Explorative A pre-study to ensure that important issues are not foreseen G. Antoniol 2002 Software Engineering - Why 69 Case Study Monitoring projects, activities or assignments. Data is collected for a specific purpose The level of control is lower in a case study than in an experiment In a case study the state variables only assume one value which is governed by the actual project under study G. Antoniol 2002 Software Engineering - Why 70 Case Study Arrangements Comparison against a company baseline A sister project is chosen as baseline If the method can be applied to individual components, apply it at random to some components Notice that the projects are not drawn at random from the population of all projects Experiment Experiment are carried out in a laboratory environment Subjects are assigned to different treatments at random Goal: manipulate one or more variables control all the other at fixed levels The effect of the manipulation is measured Quasi-experiment: we can not randomly assign subjects to different treatments G. Antoniol 2002 Software Engineering - Why 71 G. Antoniol 2002 Software Engineering - Why 72

19 State Variable Example Application domain: telecommunication, database, operating systems Programming language: C, Java, COBOL Process: iterative, incremental, waterfall Testing coverage criterion: statement, functionality Programmer experience: less that 5 years, 5 to 10 years G. Antoniol 2002 Software Engineering - Why 73 Risk and Cost Desktop survey: the change proposal is evaluated off-line There is no real change in the process People are not involved Laboratory the change proposal is evaluated in a laboratory setting (off line) A limited part of the process is executed in a controlled manner Development projects: the change proposal is evaluated in the real environment e.g., in a pilot project G. Antoniol 2002 Software Engineering - Why 74 Variable, Subject, Treatment Independent variables Fixed level Process Dependent variable Theory Experiment Principle [Trochim] Cause Construct Experiment goal Cause - effect Construct Effect Construct Dependent variables, or covariates, or response variables Independent variables, or variates, or factors this are manipulated Treatment: the particular level of a factor Treatments are applied to a combination of objects and subjects Object: an artifact e.g., a design document Subjects: the people that apply the treatment Test of trials: a combination of treatment, object, subject G. Antoniol 2002 Software Engineering - Why 75 Observation Treatment Treatment Outcome Construct Outcome Experiment Independent Variable Operation Dependent Variable G. Antoniol 2002 Software Engineering - Why 76

20 Experiment Idea Experiment Process Experiment Definition Experiment Planning Experiment Operation Experimental Data Analysis and Interpretation Descriptive Statistics Data Set Reduction Analysis & Interpretation Presentation & Package Conclusions Hypothesis Testing Conclusions G. Antoniol 2002 Software Engineering - Why 77 G. Antoniol 2002 Software Engineering - Why 78