1. 1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed feisal@uwi.tt Ph: 662-2002 x3156

2. 2 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering This course is examined by coursework (40%) and by examination (60%) There will be three projects, the first one will be an individual project and the rest done in groups. Groups are to be 3-4 students. There are no lab exercises. Demonstrators are Jason Yuk Lee and Jason Cox

3. 3 EE29B Feisal Mohammed What is Software Engineering? The IEEE Computer Society defines software engineering as: 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 study of approaches as above.

4. 4 EE29B Feisal Mohammed Problem solving (Analysis) We typically solve a problem by analysing it, that is by breaking it down into pieces. Problem 1 4 3 2 1 4 3 2

5. 5 EE29B Feisal Mohammed Problem solving (Synthesis) Once we have analysed the problem, we must construct our solution from components that address the problem's various aspects Solution 1 4 3 2 1 4 3 2

6. 6 EE29B Feisal Mohammed How are software projects different? Invisibility No physical presence Flexibility After all it's software Complexity no physical constraints

7. 7 EE29B Feisal Mohammed The Software Iceberg The Product What the customers see Compilers, Operating Systems, Utilities DBMS CASE Configuration Management Code Data Definitions Databases Specifications Plans Standards & Procedures Manuals Simulators Development Systems Automatic test Equipment

8. 8 EE29B Feisal Mohammed Key Issues facing Software Developers Unfulfilled demand Increasing complexity Greater customer expectations Rapid obsolescence Increasing competition Shorter product cycle times Producing more with less Evolving methods and tools

9. 9 EE29B Feisal Mohammed Do projects ever fail? 15% of all projects never deliver a useful product 20% of large projects ( 25 or more work- years) failed to deliver Most common reported cause was sociological

10. 10 EE29B Feisal Mohammed Terminology for describing “bugs” A fault occurs when a human makes a mistake, called an error in performing some software activity. A failure is a departure from the systems required behaviour It can be discovered before or after system delivery or during operation and maintenance. Since requirements documents can contain faults, failures can exist even though the system is performing as specified!

11. 11 EE29B Feisal Mohammed What does project failure mean? Late delivery? No delivery at all? Not delivering what was agreed to or what was announced? Over budget? Not meeting revenue expectations? Quality below expectations?

12. 12 EE29B Feisal Mohammed Some reasons projects fail Not understanding what the product must do Uncontrolled changes Optimistic thinking Insufficient resources Lack of disciplined development Confusion about what needs to be done Ineffective teamwork Failure to consider business needs

13. 13 EE29B Feisal Mohammed Some reasons products fail Price Mature market Lack essential capabilities Difficult to use Unreliable Poor developer reputations Poor product support

14. 14 EE29B Feisal Mohammed Some reasons projects succeed Good understanding of the problem to solve Good planning and execution Extraordinary effort and commitment by individuals Luck

15. 15 EE29B Feisal Mohammed Some reasons products succeed Satisfy an unfulfilled need Novelty Value Marketing strategy

16. 16 EE29B Feisal Mohammed What is good software? Quality of the product? Quality of the process? Quality in the context of the Business Environment?

17. 17 EE29B Feisal Mohammed Quality of the product Correctness Reliability Efficiency Integrity Usability Maintainability Testability Flexibility Portability Reuseability Interoperability

18. 18 EE29B Feisal Mohammed Quality of the process Where and when are we likely to find a particular kind of fault? How can we find faults earlier in the development process? How can we build in fault tolerance so that we can minimize the likelihood that a fault will become a failure? Are there alternative activities that can make our process more effective or efficient at assuring quality?

19. 19 EE29B Feisal Mohammed Quality in the context of the business environment A view in terms of the products and services being provided by the business in which the software is embedded. That is, we look at the business value. This can be as simple as Return On Investment (ROI) or some more elaborate measure.

20. 20 EE29B Feisal Mohammed Who does software engineering? Customer Sponsors system development Developer Builds system User Uses system Needs Software system

21. 21 EE29B Feisal Mohammed Systems Approach Activities and Objects Relationships and the System Boundary Consider nested systems and system interrelationships

22. 22 EE29B Feisal Mohammed Activities and Objects Distinguish between activities and objects An activity is something that happens in a system. The elements involved in the activities are called the objects or entities.

23. 23 EE29B Feisal Mohammed Relationships and the System Boundary A system is defined as a collection of things: a set of entities, a set of activities, a description of the relationships among entities and activities, and a definition of the boundary of the system. Examples: the human respiratory system, a paycheck production system

24. 24 EE29B Feisal Mohammed Nested systems It is possible for one system to exist within another system, e.g. sensor system One can have various functions of the sensors nested within each other.

25. 25 EE29B Feisal Mohammed An analogy of software engineering Determining and analysing requirements Producing and documenting the design Detailed specifications Identifying and designing components Requirements analysis and definition System design Program design

26. 26 EE29B Feisal Mohammed Analogy... Building components Testing components Integrating components Making final modifications Continuing maintenance Writing programs Unit testing Integration testing System testing System delivery Maintenance