SOFTWARE ENGINEERING I CSCS 300 Fall 2009 Ms

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

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

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

TYPES OF SOFTWARE n Generic software n n n 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 n n Systems commissioned by a particular customer. for example web sites, air-traffic control systems and software for managing the

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

Some Software Characteristics n 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 n Definition n Implementation of a solution to a practical problem n activity n n n which aims at solving a problem completing a task (definition, design, and specification) Analysis, design, construction, verification, and management of technical (or social) entities.

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

SOFTWARE ENGINEERING n Definition n 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 n n n 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

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

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

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

IMPORTANCE OF SOFTWARE ENGINEERING n n Software crisis Software quality

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

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

DIFFERENCE n Software Engineering n Concerned with the practicalities of developing and delivering useful software n A field of study deals with practicalities of software n Computer science n Concerned with theory and fundamentals n A field of study deals with theories and practices of

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

COMPARING SOFTWARE ENGINEERING AND RELATED FIELDS n For further information, check this link n http: //en. wikipedia. org/wiki/Comparing_s 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!

(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) n n 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!

SOFTWARE MYTHS (DEVELOPER PERSPECTIVES) 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 PRODUCT is a product designated for delivery to the user documents source codes object codes reports manuals plans data test suites test results prototypes

Software Myths n 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 50 - 70% may n 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

BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS 1 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.

SOFTWARE (WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)

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

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

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

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

HARDWARE VS SOFTWARE COSTS

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

DISTRIBUTION OF EFFORT ACROSS PHASES Testing Coding Design Analysis

BOEHM’S TOP TEN INDUSTRIAL SOFTWARE METRICS 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

DISTRIBUTION OF ACTIVITIES IN DEFECT REMOVAL

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

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

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

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

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

SYMPTOM OF SOFTWARE CRISIS n n n 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) 54

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