1. ICS 201- Introduction to Software Engineering

2. How important is Software? Billions spent annually on software. Billions spent annually on software. Is used by practically every business: email, spreadsheets, word processing, databases, presentation tools. Is used by practically every business: email, spreadsheets, word processing, databases, presentation tools. Is used in designing many products:airplanes, cars, buildings, drugs.. Is used in designing many products:airplanes, cars, buildings, drugs.. Is an essential part of many products: pacemakers, MRI, ultrasound, planes, cars Is an essential part of many products: pacemakers, MRI, ultrasound, planes, cars

3. Examples of Software.. Bar-code scanners: 10-50,000 lines Bar-code scanners: 10-50,000 lines 4-speed transmission: 20,000 lines 4-speed transmission: 20,000 lines Cell-phone: 30,000 lines Cell-phone: 30,000 lines ATM network: 600,000 lines ATM network: 600,000 lines B-2 Stealth Bomber: 3,500,000 lines B-2 Stealth Bomber: 3,500,000 lines

4. Engineering …. Putting scientific knowledge to practical use. Putting scientific knowledge to practical use. Building things while conforming to constraints. (budget, time, quality and performance standards) Building things while conforming to constraints. (budget, time, quality and performance standards) Relies on underlying science, but is concerned with the process used to achieve results. Relies on underlying science, but is concerned with the process used to achieve results.

5. Software Engineering … Term coined at 1968 NATO conference. Term coined at 1968 NATO conference. Involves the full life-cycle of software. Involves the full life-cycle of software. Money plays a role. Money plays a role. Multiple people are required. Multiple people are required. GOAL: production of quality software, delivered on time,within budget, satisfying users ’ needs GOAL: production of quality software, delivered on time,within budget, satisfying users ’ needs

6. Definition of Software Engineering The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. IEEE Standard 610.12

7. Why is Software Hard? Lots of lines of code Lots of lines of code Complexity Complexity Lots of people Lots of people Changeability Changeability Invisible Invisible Money and time are major factors Money and time are major factors

8. What Can Go Wrong? Designer-client communications break down Designer-client communications break down Poor Quality Poor Quality –reduced functionality, unreliable, unsafe, inflexible, undocumented Development time and costs are underestimated Development time and costs are underestimated

9. Software Engineering is NOT just Programming! ICS 102 program Software Engineering well-defined tasks part of work is defining the task! few constraints outside constraints are key developer = user lots of developers Required (developer != user) write-once, never read write, read, re-write, read, re-write,... developer = modifier developer !=  Modifier lifetime of one semester lifetime of years

10. Software Life Cycle Requirements Analysis Design Implementation Verification Maintenance Specification Determine Customer Needs (what) State Customer Needs (what) Design a solution (How) Implement a solution (How) Show solution meets specification Keep solution working

11. Waterfall Model with Iterations  The drawback of the waterfall model is the difficulty of accommodating change after the process is underway. Having some level of iteration is clearly necessary.

12. Requirements & Specification Determine exactly what the customer and user want Determine exactly what the customer and user want Develop a contract with the customer Develop a contract with the customer Specifies what the software product is to do Specifies what the software product is to do Difficulties Difficulties – client asks for wrong product – client is computer/software illiterate – specifications are ambiguous, inconsistent, incomplete

13. Design High-level: decompose software into modules with interfaces High-level: decompose software into modules with interfaces Detailed: develop module specifications (select algorithms and data types) Detailed: develop module specifications (select algorithms and data types) Maintain a record of design decisions and traceability Maintain a record of design decisions and traceability Specifies how the software product is to do its tasks Specifies how the software product is to do its tasks Difficulties: Difficulties: – Miscommunication between module designers – Design may be inconsistent, incomplete, ambiguous

14. Implementation & Integration Implement modules; verify that they meet their specifications Implement modules; verify that they meet their specifications Combine modules according to the design Combine modules according to the design Specifies how the software product does its tasks Specifies how the software product does its tasks Difficulties Difficulties – module interaction errors – order of integration may influence quality and productivity

15. Operation and Maintenance Maintain software during/after user operation Maintain software during/after user operation Determine whether the product still functions correctly Determine whether the product still functions correctly Difficulties Difficulties – rigid design – lack of documentation – personnel turnover

16. Risk Most Problems In Software Development Arise Because Of Risk Most Problems In Software Development Arise Because Of Risk Things Happen During Development That Were Not Anticipated Things Happen During Development That Were Not Anticipated Software Engineers Are Not Malicious Software Engineers Are Not Malicious Problems That Arise Are Things Like: Problems That Arise Are Things Like: –Insufficient Computer Time –Inadequate Software Tools –Critical Staff Leave The Project –Wrong Requirements –Incorrect Design –Expected New Equipment (Hardware Or Software) Fails To Arrive –Ambiguous Documents –Projected Schedule Unachievable –Project Cost Estimates Incorrect Goal - Risk Reduction Goal - Risk Reduction

17. Significant Risk Area Personnel - People Vary A Lot Personnel - People Vary A Lot Schedules And Budgets - How Long Will It Take To Build The System? Schedules And Budgets - How Long Will It Take To Build The System? Developing Software Functions - Wrong Functionality Developed: Developing Software Functions - Wrong Functionality Developed: –Developer Does Not Understand Application –Inadequate Requirements Analysis Requirements Stability: Requirements Stability: –Customers Think Software Is Flexible So Requests Changes Quality Of External Components: Quality Of External Components: –Compiler, Operating System, Or Other Support Software Has Bugs Hardware Slower Than Expected Hardware Slower Than Expected Late Delivery Of Equipment Late Delivery Of Equipment BUT, THE MOST SIGNIFICANT RISK: BUT, THE MOST SIGNIFICANT RISK: –Programming is Hard – Software Engineer Does Not Understand The Development Problems

18. Some Risk Reduction Techniques Prototyping: Prototyping: –Build A Piece Of The Application In The Risk Area Simulation: Simulation: –Simulate The Situation Benchmarking: Benchmarking: –Try Out Things That Might Be Bottlenecks References: References: –See If Others Have Done It Before User Questionnaires: User Questionnaires: –Ask Users About Their Requirements

19. Software Qualities External vs. Internal qualities External vs. Internal qualities – external qualities are visible to the user reliability, efficiency, usability reliability, efficiency, usability – Internal qualities are the concern of developers they help developers achieve external qualities they help developers achieve external qualities verifiability, maintainability, extensibility, evolvability, adaptability verifiability, maintainability, extensibility, evolvability, adaptability Product vs. Process qualities Product vs. Process qualities – product qualities concern the developed artifacts maintainability, understandability, performance maintainability, understandability, performance – process qualities deal with the development activity products are developed through process products are developed through process maintainability, productivity, timeliness maintainability, productivity, timeliness

20. Some Software Qualities Correctness Correctness – established w.r.t. the requirements specification Reliability Reliability – probability that software will operate as expected over a given period of time Robustness Robustness – “reasonable” behavior in unforeseen circumstances Usability Usability – ability of end-users to easily use software Understandability Understandability – ability of developers to easily understand produced artifacts Performance Performance – equated with efficiency

21. Some Software Qualities Evolvability Evolvability – ability to add or modify functionality Reusability Reusability – ability to construct new software from existing pieces Interoperability Interoperability – ability of software (sub)systems to cooperate with others Scalability Scalability – ability of a software system to grow in size while maintaining its properties and qualities Heterogeneity Heterogeneity – ability to compose a system from pieces developed in multiple programming languages, on multiple platforms, by multiple developers, etc. Portability Portability – ability to execute in new environments with minimal effort

22. Software Engineering “Axioms” Adding developers to a project will likely result in further delays and accumulated costs Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering Basic tension of software engineering – better, cheaper, faster — pick any two! – functionality, scalability, performance — pick any two! The longer a fault exists in software The longer a fault exists in software – the more costly it is to detect and correct – the less likely it is to be properly corrected Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design – detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more

23. Object- Oriented Software Development Object-oriented software development is quit different form the traditional water fall model. The analysis and design phase tend to be intermixed instead of being separate, sequential activities. That involve in 1- Discover classes 2- Determine the behavior of each class 3- Describe the relationships between the classes

24. 1- Discover classes: A simple rule for finding classes is to look for nouns in the task description. For example, suppose your job is to print an invoice. Obvious classes that come to mind are Invoice, Item, and Customer. Object- Oriented Software Development(cont.)

25. 2-Determine the behavior of each class: you need to find out what methods each object needs to carry out to solve the programming problem. A simple rule for finding these methods is to look for verbs in the task description, and then match the verbs to the appropriate objects for example, in the invoice program, some class needs to compute the amount due An excellent way to carry out this task is the use of CRC(Classes, Responsibilities, Collaborators). For example, suppose you decide that an invoice should compute the amount due, Then you write compute amount due on an index card with the title Invoice. Object- Oriented Software Development(cont.)

26. CRC cards(Classes, Responsibilities, Collaborators) CRC cards(Classes, Responsibilities, Collaborators) CRC cards (Classes, Responsibilities, Collaborators) 3- Relationships between classes Use UML( Unified Modeling Language) to record class relationships, attributes, and methods. Some of these relations -inheritance(“is”), aggregation(“has”), and dependency(“uses”)

27. UML uses ----> and arrow with an open triangle pointing to the superclass. In the UML notation aggregation is denoted by a line with a diamond. The diamond is placed toward the aggregating class an is – a and a has-a Compartments for attributes and Methods UML(Unified Modeling Language) Dependency relationship The invoice depend on customer Invoice has items Inheritance car is a vehicle Aggregation Car has Tire