SOFTWARE ENGINEERING – I CSCS 300 – Fall 2009 Ms. Saira Anwar

SOFTWARE Definition Computer software is the product that software engineers design, build and support. Software is Most widely used in all fields Medical Telecommunication Military Industry etc instructionsData StructuresDocuments When executed provide desired features, functions and performance Enable to adequately manipulate information Describe operation and use of programs

DUAL ROLE OF A SOFTWARE A product itself Computing Potential Information transformer Managing, Producing, Acquiring, Modifying, Displaying Vehicle to deliver a product Control of computer Operating Systems Communication of information Networks Creation of programs Software tools and environments

TYPES OF SOFTWARE Generic software Stand-alone systems produced by a development organization and sold on the open market to any customer for example word processors, spreadsheets and games Customized software Systems commissioned by a particular customer. for example web sites, air-traffic control systems and software for managing the finances of large organizations

Some Software Characteristics Software is engineered or developed, not manufactured in the traditional sense. Software does not wear out in the same sense as hardware.

Some Software Characteristics In theory, software does not wear out at all. BUT, Hardware upgrades. Software upgrades.

Some Software Characteristics Thus, reality is more like this. Most serious corporations control and constrain changes Most software is custom built, and customer never really knows what she/he wants.

ENGINEERING Definition Implementation of a solution to a practical problem activity which aims at solving a problem completing a task (definition, design, and specification) Analysis, design, construction, verification, and management of technical (or social) entities.

11 WHAT IS SOFTWARE ENGINEERING? Engineering approach to develop software. Building Construction Analogy. Systematic collection of past experience: techniques, methodologies, guidelines.

SOFTWARE ENGINEERING Definition Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

WHY SOFTWARE ENGINEERING Organized, systematic, and controlled software development Software engineering is concerned with theories, methods and tools for professional software development Customer wants low cost and short time for software development

14 Why study software engineering? To acquire skills to develop large programs. Exponential growth in complexity and difficulty level with size.

15 Why study software engineering? Ability to solve complex programming problems: How to break large projects into smaller and manageable parts? Learn techniques of: specification, design, interface development, testing, project management, etc.

16 Why study software engineering? To acquire skills to be a better programmer: Higher Productivity Better Quality Programs

IMPORTANCE OF SOFTWARE ENGINEERING Software crisis Software quality

18 SOFTWARE CRISIS Software products: fail to meet user requirements. frequently crash. expensive. difficult to alter, debug, and enhance. often delivered late. use resources non-optimally.

19 FACTORS CONTRIBUTING TO THE SOFTWARE CRISIS Larger problems, Lack of adequate training in software engineering, Increasing skill shortage, Low productivity improvements.

DIFFERENCE Software Engineering Concerned with the practicalities of developing and delivering useful software A field of study deals with practicalities of software development Computer science Concerned with theory and fundamentals A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.

DIFFERENCE System engineering Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering Software engineering Part of system engineering Deals with software only

COMPARING SOFTWARE ENGINEERING AND RELATED FIELDS For further information, check this link oftware_engineering_and_related_fields

SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned. But the proof of the pudding is in the eating; not in the Recipe !

SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) As long as my software engineers(!) have access to the fastest and the most sophisticated computer environments and state-of-the-art software tools, I shouldn’t be too concerned. The environment is only one of the several factors that determine the quality of the end software product!

SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES) When my schedule slips, what I have to do is to start a fire-fighting operation: add more software specialists, those with higher skills and longer experience - they will bring the schedule back on the rails! (Mongolian Horde Concept) Unfortunately, software business does not entertain schedule compaction beyond a limit! Adding people to a late software projects Make it later

SOFTWARE MYTHS (CUSTOMER PERSPECTIVES) A general statement of objectives is sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized. Application requirements can never be stable; software can be and has to be made flexible enough to allow changes to be incorporated as they happen.

SOFTWARE MYTHS (DEVELOPER PERSPECTIVES) Once the software is demonstrated, the job is done. Usually, the problems just begin!

Until the software is coded and is available for testing, there is no way for assessing its quality. Usually, there are too many tiny bugs inserted at every stage that grow in size and complexity as they progress thru further stages! SOFTWARE MYTHS (DEVELOPER PERSPECTIVES)

The only deliverable for a software development project is the tested code. The code is only the externally visible component of the entire software complement! SOFTWARE MYTHS (DEVELOPER PERSPECTIVES)

SOFTWARE PRODUCT is a product designated for delivery to the user source codes object codes plans reports manuals documents test suites prototypes data test results

Software Myths Myth: It’s in the software. So, we can easily change it. Reality: Requirements changes are a major cause of software degradation. Myth: We can solve schedule problems by adding more programmers. Reality: Maybe. It increases coordination efforts and may slow things down. Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code. Reality: Incomplete up-front definition is the major cause of software project failures.

Software Myths Myth: Writing code is the major part of creating a software product. Reality: Coding may be as little as 10% of the effort, and % may occur after delivery.

Software Myths Myth: I can’t tell you how well we are doing until I get parts of it running. Reality: Formal reviews of various types both can give good information and are critical to success in large projects. Myth: The only deliverable that matters is working code. Reality: Documentation, test history, and program configuration are critical parts of the delivery. Myth: I am a (super) programmer. Let me program it, and I will get it done. Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.

BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Finding and fixing a software problem after delivery of the product is 100 times more expensive than defect removal during requirements and early design phases. 1

EFFORT TO REPAIR SOFTWARE (WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)

Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more. 2 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Maintenance costs twice what the development costs. 3 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Development and maintenance costs are primarily a function of the size. 4 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Variations in humans account for the greatest variations in productivity. 5 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

The ratio of software to hardware costs has gone from 15:85 in 1985 and continues to grow in favor of software as the dominant cost. 6 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

HARDWARE VS SOFTWARE COSTS

Only about 15% of the development effort is in coding. 7 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

DISTRIBUTION OF EFFORT ACROSS PHASES Testing Coding Design Analysis

Applications products cost three times as much per instruction as individual programs; system software products cost nine times as much. 8 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Walkthroughs catch 60% of the errors. 9 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

DISTRIBUTION OF ACTIVITIES IN DEFECT REMOVAL

20% modules 20% modules 80% cost 80% cost Many software processes obey a Pareto distribution. 10 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

Many software processes obey a Pareto distribution % modules 20% modules 80% errors 80% errors BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

20% modules 20% modules 80% cost to fix 80% cost to fix Many software processes obey a Pareto distribution. 10 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

20% modules 20% modules 80% exec time 80% exec time Many software processes obey a Pareto distribution. 10 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

20% tools 20% tools 80% use 80% use Many software processes obey a Pareto distribution. 10 BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS

54 SYMPTOM OF SOFTWARE CRISIS 10% of client/server apps are abandoned or restarted from scratch 20% of apps are significantly altered to avoid disaster 40% of apps are delivered significantly late Source: 3 year study of 70 large c/s apps 30 European firms. Compuware (12/95)

PROGRAMS VERSUS SOFTWARE PRODUCTS ProgramsSoftware Products Usually small in sizeLarge number of users Author himself is sole user Single developer Team of developers Well-designed interface Lacks proper user interface Lacks proper documentation Well documented & user- manual prepared Ad hoc development. Systematic development