1. Module 1 Introduction to Software Engineering Badariah Solemon 2010 CSEB233 Fundamentals of Software Engineering

2. Objectives To define SE-related terminologies: ‘software’, ‘software engineering’, etc. To explain several software application domain. To describe the four Polya’s essence of SE practices. To explain the seven Hooker’s SE principles. To describe several software myths. Badariah Solemon 2010

3. What is ‘software’? Software is: – (1) instructions (computer programs) that when executed provide desired features, function, and performance; – (2) data structures that enable the programs to adequately manipulate information; and – (3) documentation that describes the operation and use of the programs. Badariah Solemon 2010

4. Example Software Badariah Solemon 2010

5. Software … Is developed or engineered, it is not manufactured in the classical sense. – How things are manufactured? – How software are developed or engineered? Software doesn't "wear out" but it deteriorates because of errors do occur in software due to errors in requirements, design, construction or through out the development process. Most software continues to be custom-built, although the industry is moving toward component-based construction. Badariah Solemon 2010

6. Wear vs. Deterioration Badariah Solemon 2010

7. Software Application Domain  System software  Application software  Engineering/scientific software  Embedded software  Product-line software  Web applications (WebApps)  AI software Badariah Solemon 2010

8. Software Application Domain Matrix DomainCharacteristicExample Software System Software Generally, programs written to service other programs Heavy interaction with computer hardware Heavy usage by multiple users Concurrent operation that requires scheduling Resource sharing and sophisticated process management Complex data structures Multiple external interfaces OS – MS Windows, Linux Ubuntu Drivers – printer driver Networking software - wireless networking software Telecommunication software – messaging system such as sms, mms Compilers – Borland C++, Turbo C Application Software Point-of-sale (POS) Badariah Solemon 2010

9. Software Application Domain Matrix (cnt’d) DomainCharacteristicExample Software Engineering/Scientific Software Flight simulator Embedded Software Software to control robots’ movement Production-line Software Ms Word WebApps Uniten Online Application System AI Software Expert system – Diagnostic Medical expert system Badariah Solemon 2010

10. New Software Domain  Open world computing—pervasive, distributed computing  Ubiquitous computing—wireless networks  Netsourcing—the Web as a computing engine  Open source—”free” source code open to the computing community (a blessing, but also a potential curse!)  Data mining  Grid computing  Cognitive machines  Software for nanotechnologies Badariah Solemon 2010

11. The realities..  software must be adapted to meet the needs of new computing environments or technology.  software must be enhanced to implement new business requirements.  software must be extended to make it interoperable with other more modern systems or databases.  software must be re-architected to make it viable within a network environment. Badariah Solemon 2010

12. What is ‘Software Engineering’? IEEE: – (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. – (2) The study of approaches as in (1). Badariah Solemon 2010

13. SE realities … SE is a join effort should be made to understand the problem before a software solution is developed. Design, which is a crucial activity. Software should exhibit high quality. Software should be maintainable. Badariah Solemon 2010

14. Layers in SE a “quality” focus process model methods tools Badariah Solemon 2010

15. Layer: Process Model Software process is a collection of activities, actions, and tasks that are performed to develop or maintain a software product. Framework activities: – generic activities that are applicable to all software projects, regardless of their size or complexity. Umbrella activities: – complementary activities applied throughout a software project and help manage and control progress, quality, change, and risk. process model Badariah Solemon 2010

16. Essential SE Practices Polya suggests: 1.Understand the problem (communication and modeling). 2.Plan a solution (planning and design). 3.Carry out the plan (construction and deployment). 4.Examine the result for accuracy (testing and quality assurance). Badariah Solemon 2010

17. Understand the problem Who has a stake in the solution to the problem? That is, who are the stakeholders? What are the unknowns? What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? Badariah Solemon 2010

18. Plan a solution Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? Has a similar problem been solved? If so, are elements of the solution reusable? Can subproblems be defined? If so, are solutions readily apparent for the subproblems? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? Badariah Solemon 2010

19. Carry out the plan Does the solution conform to the plan? Is source code traceable to the design model? Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm? Badariah Solemon 2010

20. Examine the result for accuracy Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? Badariah Solemon 2010

21. Hooker’s General SE Principles 1.The Reason It All Exists 2.KISS (Keep It Simple, Stupid!) 3.Maintain the Vision 4.What You Produce, Others Will Consume 5.Be Open to the Future 6.Plan Ahead for Reuse 7.Think! Badariah Solemon 2010

22. 1.The Reason It All Exists software exists to provide value to its users and all decision should be made with this in mind. Badariah Solemon 2010

23. 2.KISS There are many factors to consider in any design effort. Thus, all software design should be as simple as possible but not simpler to ease understanding and maintenance of the software/system. Badariah Solemon 2010

24. 3.Maintain the Vision because a clear vision is essential to the success of a software project. Compromising the architectural vision of a software systems weakens and break even well- designed systems. Badariah Solemon 2010

25. 4.What You Produce, Others Will Consume Consume - (use, maintain, document or depend on) So, always specify, design, and implement knowing others will have to understand what you are doing. Badariah Solemon 2010

26. 5.Be Open to the Future True “industrial-strength” software systems must endure long lifetime. Hence, design the software systems: – to solve the general problem (not just the specific one), – to be ready to adapt to changes (in hardware, computing platform etc), and – to be reused. Badariah Solemon 2010

27. 6.Plan Ahead for Reuse because reuse reduces the cost and increases the value of the reused components and the systems into which they are incorporated. Badariah Solemon 2010

28. 7.Think Because when you think about something (placing clear, complete thought before action), you are more likely to do it right (more importantly, the first time). Badariah Solemon 2010

29. Software Myths Software myths – erroneous beliefs about software and the process that is used to build it. Misleading attitudes that have caused serious problems for managers and practitioners. Classifications of software myths: – Management myths – Customer myths – Practitioner myths Badariah Solemon 2010

30. Management Myth Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Reality: – The book of standards may exist, but is it used? Are practitioners’ aware of its existence? Does it reflect modern SE practices? Is it complete? Is it adaptable? Badariah Solemon 2010

31. Customer Myth Myth: Software requirements continually change, but change can be easily accommodated because software is flexible. Reality: – The impact of change varies with the time at which it is introduced. The cost of impact of changes in early stage of software project is relative small. However, changes introduced at a later development stage may requires a lot of resources and major design modification. Badariah Solemon 2010

32. Practitioner Myth Myth: “Once we write the program and get it work, our job is done.” Reality: – Some once said the “the sooner you begin ‘writing code’, the longer it’ll take you to get done.” Badariah Solemon 2010

33. Summary You have learned about: – Definitions of software and software engineering. – Software deteriorates but never wear out. – Several software application domain – system software, engineering/scientific software, AI software, embedded software, etc. – The Polya’s essence of SE practices – understand the problem, plan a solution, execute the plan and examine the result for accuracy. – SE principles - The Reason It All Exists; KISS (Keep It Simple, Stupid!); Maintain the Vision; What You Produce, Others Will Consume ; Be Open to the Future; Plan Ahead for Reuse; Think! – Software myths have caused serious problems for the software industry. Badariah Solemon 2010

34. References and credit: Contents in the slides are adopted from the book and the slides that accompanied the book by R.S. Pressman, Software Engineering: A Practitioner’s Approach, 7th. Edition, McGraw Hill, 2009. Badariah Solemon 2010