Introduction Software engineering
- 1. Jennifer ‘Jannah’ Contreras (LECTURER) E-MAIL: jen_beng2012@yahoo.com
- 2. Learning Outcomes Understand Software Engineering • Define computer science and software engineering and how the two are different. • Be familiar with the importance of software engineering. • Be familiar with disciplines that are related to software engineering. • Understand the role of a software engineer. • Be familiar with the various software engineering principles and concepts 2 At the end of this lesson, Students will be able to:
- 3. Software Engineering • The economies of ALL developed nations are dependent on software. More and more systems are software controlled
- 4. What is Software? • Computer programs and associated documentation such as requirements, design models and user manuals. • Software products may be developed for a particular customer or may be developed for a general market. • Software products may be – Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word. – Bespoke (custom) - developed for a single customer according to their specification. • New software can be created by developing new programs, configuring generic software systems or reusing existing software.
- 5. What is Engineering? • Engineering is … – The application of scientific principles and methods to the construction of useful structures & machines • Examples – Mechanical engineering – Computer engineering – Civil engineering – Chemical engineering – Electrical engineering – Nuclear engineering – Aeronautical engineering
- 6. What is Software Engineering? • Software engineering is an engineering discipline that is concerned with all aspects of software production. • Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available.
- 8. Software Engineering Definition (IEEE) • Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software
- 9. Software Engineering • Method: refers to a formal procedure; a formal “recipe” for accomplishing a goal that is typically independent of the tools used • Tool: an instrument or automated system for accomplishing something in a better way • Procedure: a combination of tools and techniques to produce a product • Paradigm: philosophy or approach for building a product (e.g., OO vs structured approaches)
- 10. What does a Software Engineer do? Software engineers should adopt a systematic and organised approach to all aspects of software development. use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available Understand and communicate processes for improved software development within their organization Be effective team members and/or leaders. Can be very technical or more managerial depending on organizational need.
- 11. Where Does the SW Engineer Fit in? • Computer science: focusing on computer hardware, compilers, operating systems, and programming languages • Software engineering: a discipline that uses computer and software technologies as a problem-solving tools Where Does the Software Engineer Fit In?
- 12. Where Does the SW Engineer Fit in? (continued) • Relationship between computer science and software engineering
- 13. Software Engineering ≠ Software Programming • Software programming – Single developer – “Toy” applications – Short lifespan – Single or few stakeholders • Architect = Developer = Manager = Tester = Customer = User – One-of-a-kind systems – Built from scratch – Minimal maintenance
- 14. Software Engineering ≠ Software Programming • Software engineering – Teams of developers with multiple roles – Complex systems – Indefinite lifespan – Numerous stakeholders • Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User – System families – Reuse to amortize costs – Maintenance accounts for 60%-80% of overall development costs
- 15. Why Is Software Engineering Important? • It is very expensive and horrendous to design software systems that do not work or that include bugs a errors and run wrongly. • The developing entity of such a software system could get bankrupt and loose business. • Such a software developer could be involved in legal cases in court that cost them a huge amount of money.
- 16. Related disciplines to software engineering include the following: • Web Engineering • Programming Languages • Operating Systems • Database Management Systems • Artificial Intelligence • Theoretical Models • Management Science • Systems Engineering
- 17. Web Engineering • Web Engineering is a recent and new discipline for development of web-based systems. It has emerged lately to address a process and a systematic approach to development of high quality web-based systems.
- 18. Web Engineering • Web engineering objective is to establish and use of sound scientific, engineering and management principles and disciplined and systematic approaches to the successful development, deployment and maintenance of high quality Web- based systems and applications.
- 19. Programming Languages • Programming languages are used by the software programmers to develop the code of the software systems and hence, they are the central tools used in software development. • Programming languages affect the quality and efficiency of the product. The software process and software engineering principles also affect the development of programming languages.
- 20. Operating System • Operating Systems are examples of software systems and therefore they were the first instances of software that needed to be engineered. • The development of these operating systems follows the software engineering process. The operating systems strongly affect and influence software engineering.
- 21. Database Management System • Database Management Systems are large software systems. Database management systems influence and are influenced by software engineering. • Some of the new ideas learned through the development of database management systems are the discovery of new design techniques such as data independence, which is an example of separation of concern (separation of specification from implementation).
- 22. Artificial Intelligence • Artificial intelligence systems are very complex software systems. • They are built with only a vague notion of how the system is going to work. • Artificial intelligence systems use new software engineering techniques in dealing with specifications, verification, and reasoning in the presence of uncertainty.
- 23. Theoretical Models • Theoretical models discipline is concerned with the development of a number of models. • These models are used as tools and models in software engineering. • An example of these models is the finite state machines (used as techniques for software specifications and as models for software design and structure).
- 24. Management Science • Technical Management and Personnel Management of software projects is an essential part of the software engineering. • Technical management includes project estimation, project scheduling, human resource planning, task decomposition and assignment, and project tracking. • The personnel management involves hiring personnel, motivating people, and assigning the right people to the right tasks.
- 25. Systems Engineering • System Engineering is the field concerned with studying complex systems. • Since software engineering is concerned with the studying of complex software system it becomes a sub-field of systems engineering. • System engineering tries to discover common theories that apply to diverse commercial, industrial, business, military and other systems.
- 26. 1.4 Who Does Software Engineering? (continued) • Participants (stakeholders) in a software development project
- 27. 1.5 System Approach • Hardware, software, interaction with people • Identify activities and objects • Define the system boundary • Consider nested systems, systems interrelationship
- 28. 1.5 System Approach The Element of a System • Activities and objects – An activity is an event initiated by a trigger – Objects or entities are the elements involved in the activities • Relationships and the system boundaries – A relationship defines the interaction among entities and activities – System boundaries determine the origin of input and destinations of the output
- 29. 1.5 System Approach The Element of a System (continued) • A computer system must also be clearly described: System definition of a paycheck production
- 30. 1.5 System Approach Interrelated Systems • Some systems are dependent to other systems – The interdependencies may be complex • It is possible for one system to exist inside another system • If the boundary definitions are detailed, building a larger system from the smaller ones is relatively easy
- 31. 1.6 Engineering Approach Building a System • Requirement analysis and definition • System design • Program design • Writing the programs • Unit testing • Integration testing • System testing • System delivery • Maintenance
- 32. 1.7 Members of the Development Team • Requirement analysts: work with the customers to identify and document the requirements • Designers: generate a system-level description of what the system us supposed to do • Programmers: write lines of code to implement the design • Testers: catch faults • Trainers: show users how to use the system • Maintenance team: fix faults that show up later • Librarians: prepare and store documents such as software requirements • Configuration management team: maintain correspondence among various artifacts
- 33. 1.7 Members of the Development Team (continued) • Typical roles played by the members of a development team
- 34. What are the key challenges facing software engineering? • Heterogeneity, delivery and trust. • Heterogeneity – Developing techniques for building software that can cope with heterogeneous platforms and execution environments; • Delivery – Developing techniques that lead to faster delivery of software; • Trust – Developing techniques that demonstrate that software can be trusted by its users.
- 35. Professional and ethical responsibility • Software engineering involves wider responsibilities than simply the application of technical skills. • Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. • Ethical behaviour is more than simply upholding the law.
- 36. Issues of professional responsibility • Confidentiality – Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. • Competence – Engineers should not misrepresent their level of competence. They should not knowingly accept work which is outwith their competence.
- 37. Issues of professional responsibility • Intellectual property rights – Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. • Computer misuse – Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).
- 38. ACM/IEEE Code of Ethics • The professional societies in the US have cooperated to produce a code of ethical practice. • Members of these organisations sign up to the code of practice when they join. • The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.
- 39. Code of ethics - preamble • Preamble – The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. – Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:
- 40. Code of ethics - principles • PUBLIC – Software engineers shall act consistently with the public interest. • CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. • PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
- 41. Code of ethics - principles • JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment. • MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. • PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
- 42. Code of ethics - principles • COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues. • SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
- 43. Ethical dilemmas • Disagreement in principle with the policies of senior management. • Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system. • Participation in the development of military weapons systems or nuclear systems.
- 44. How Has Software Engineering Changed? The Nature of the Change • Before 1970s – Single processors: mainframes – Designed in one of two ways • as a transformation: input was converted to output • as a transaction: input determined which function should be performed • After 1970s – Run on multiple systems – Perform multi-functions
- 45. How Has SE Changed? Wasserman's Seven Key Factors 1. Critically of time-to-market 2. Shifts in the economics of computing 3. Availability of powerful desktop computing 4. Extensive local- and wide-area networking 5. Availability and adoption of object-oriented technology 6. Graphical user interfaces 7. Unpredictability of the waterfall model of software development
- 46. How Has SE Changed? Wasserman's Seven Key Factors (continued) The key factors that have changed the software development
- 47. How Has SE Changed? Wasserman's Discipline of Software Engineering • Abstractions • Analysis and design methods and notations • User interface prototyping • Software architecture • Software process • Reuse • Measurement • Tools and integrated environments
- 48. How Has SE Changed? Software Architecture • A system’s architecture describes the system in terms of a set of architectural units and relationships between these units • Architectural decomposition techniques – Modular decomposition – Data-oriented decomposition – Event-driven decomposition – Outside-in-design decomposition – Object-oriented decomposition
- 49. How Has SE Changed? Software Process • Many variations • Different types of software need different processes – Enterprise-wide applications need a great deal of control – Departmental applications can take advantage of rapid development
- 50. How Has SE Changed? Software Reuse • Commonalities between applications may allow reusing artifacts from previous developments – Improve productivity – Reduce costs • Potential concerns – It may be faster to build a smaller application than searching for reusable components – Generalized components take more time to build – Must clarify who will be responsible for maintaining reusable components – Generality vs specificity: always a conflict
- 52. REFERENCES • Henry Petroski, Design Paradigms: Case Histories of Error and Judgement in Engineering