Software Engineering: An Introduction

1. Software Engineering:An Introduction Object-Oriented Software EngineeringCS350

2. Software Engineering • The application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches

3. Software Engineering • Emergence as a profession • Early 1980s: Software engineering had emerged as a bonafide profession • Role of women • 1940s, 1950s, and 1960s: Grace Hopper, Jamie Fenton and many other unsung women filled many programming jobs during the first several decades of software engineering • Today: fewer women work in software engineering than in other profesions • Why?

4. Software Engineering • Processes • Have become a big part of SE • Hailed for their potential to improve software and sharply criticized for their potential to constrict programmers • Cost of hardware • Computers are now more numerous and more powerful • Market can support large projects to create commercial off the shelf software • Cheap machines allow each programmer to have a terminal capable of fairly rapid compilation • Can use techniques such as garbage collection • Organizations use commercial off the shelf software instead of employing programmers for large custom software projects

5. The Pioneering Era • New computers were coming out almost every year or two • Software people had to rewrite all their programs to run on these new machines • “Machine room”: Jobs were run by … • Signing up for machine time or by operational staff • Using punched cards for and waiting for results to come back

6. The Pioneering Era • The idea of management by schedule was non-existent • Making predictions was almost impossible • Computer hardware was application-specific • Scientific and business tasks needed different machines • The notion of reuse flourished

7. 1945 to 1965: The Origins • The term software engineering first appeared in the late 1950s and early 1960s • Programmers have always known about civil, electrical, and computer engineering and debated what engineering might mean for software

8. 1965 to 1985: The Software Crisis • Spurred by the so-called software crisis of the 1960s, 1970s, and 1980s • Many software projects ran over budget and schedule • Some projects caused property damage • A few projects caused loss of life

9. 1965 to 1985: Cost and Budget Overruns • Example: OS/360 operating system • Decade-long project from the 1960s eventually produced one of the most complex software systems at the time • One of the first large (1000 programmers) software projects • Fred Brooks (The Mythical Man Month) claims he made a mistake of not developing a coherent architecture before starting development

10. 1965 to 1985: Property Damage • Software defects can cause property damage • Poor software security allows hackers to steal identities, costing time, money, and reputations

11. 1965 to 1985: Life and Death • Software defects can kill • Example: Therac 25 incident

12. 1965 to 1985: • Main source of SE difficulties is a lack of specialization • There is a need for a "normal practice" of software engineering, a prerequisite if software engineering is to become an engineering science (Michael Jackson, "Engineering and Software Engineering" in The Future of Software Engineering, Springer Verlag 2010; Michael Jackson, Problem Frames: Analyzing and Structuring Software Development Problems; Addison-Wesley, 2001)

13. 1985 to 1989: No Silver Bullet • For decades, solving the software crisis meant producing software tools • But the cost of owning/maintaining software in the 1980s was double developing the software • By 1995, half of surveyed development projects were operational, but not successful

14. 1985 to 1989: Software projects • Every new technology and practice was trumpeted as a silver • Tools, discipline, formal methods, process, and professionalism were touted as silver bullets

15. 1985 to 1989: Tools • Structured programming • Object-oriented programming • CASE tools • Ada • Documentation • Standards

16. 1985 to 1989: Discipline • Was the software crisis due to the lack of discipline of programmers? • Your thoughts?

17. 1985 to 1989: Formal methods • If formal engineering methodologies were applied to software development • Then production of software could bee as predictable as other branches of engineering • Think programs correctness

18. 1985 to 1989: Process • Capability Maturity Model: • Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process. • Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted. • Defined - the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions). • Managed - the process is quantitatively managed in accordance with agreed-upon metrics. • Optimizing - process management includes deliberate process optimization/improvement.

19. 1985 to 1989: Professionalism • Code of ethics • Licenses • Professionalism.

20. 1985 to 1989: • No Silver Bullet article (Fred Brooks, 1986) • No individual technology or practice would ever make a 10-fold improvement in productivity within 10 years • Eventually, almost everyone accepted that no silver bullet would ever be found • Does no silver bullet mean that software engineering failed? • Brooks says, “We will surely make substantial progress over the next 40 years; an order of magnitude over 40 years is hardly magical ...”.

21. 1985 to 1989: • It could be said that there are, in fact, a range of silver bullets today, including • Lightweight methodologies • Spreadsheet calculators • Customized browsers • In-site search engines • Database report generators • Integrated design-test coding-editors with memory/differences/undo • Specialty shops

22. 1990 to 1999: Prominence of the Internet • The rise of the Internet led to a demand for … • Illustrations • Maps • Photographs • Simple animation • Issues: • Widespread network connections led to the growth & prevention of international computer viruses • Vast proliferation of spam e-mail became a major design issue in e-mail systems • Keyword-search systems evolved into web-based search engines • Human natural-language translation systems were needed

23. 2000 to Present: Lightweight Methodologies • Expanding demand for software in many smaller organizations meant the need for inexpensive software • Rapid-prototyping evolved to entire lightweight methodologies • Extreme Programming (XP) • Very large software systems still used heavily-documented methodologies • Smaller systems had a simpler, faster alternative approach

24. Current Trends • Aspects: Help software engineers deal with quality attributes by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates.

25. Current Trends • Agile: Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of this method believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes. Related concepts include extreme programming, scrum, and lean software development.

26. Current Trends • Experimental: experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from the experiments, and in devising laws and theories from this data. Proponents of this method advocate that the nature of software is such that we can advance the knowledge on software through experiments only.

27. Current Trends • Model-driven: model driven design develops textual and graphical models as primary design artifacts. Development tools are available that use model transformation and code generation to generate well-organized code fragments that serve as a basis for producing complete applications.

28. Current Trends • Software product lines : software product lines is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process.

29. Software engineering today • The profession is trying to define its boundary and content. The Software Engineering Body of Knowledge SWEBOK has been tabled as an ISO standard during 2006 (ISO/IEC TR 19759). • In 2006, Money Magazine and Salary.com rated software engineering as the best job in America in terms of growth, pay, stress levels, flexibility in hours and working environment, creativity, and how easy it is to enter and advance in the field.

30. Ethical considerations • Software engineering ethics is a large field. In some ways it began as an unrealistic attempt to define bugs as unethical. More recently it has been defined as the application of both computer science and engineering philosophy, principles, and practices to the design and development of software systems. Due to this engineering focus and the increased use of software in mission critical and human critical systems, where failure can result in large losses of capital but more importantly lives such as the Therac-25 system, many ethical codes have been developed by a number of societies, associations and organizations. These entities, such as the ACM, IEEE, APEGBC and Institute for Certification of Computing Professionals (ICCP) have formal codes of ethics. Adherence to the code of ethics is required as a condition of membership or certification. According to the ICCP, violation of the code can result in revocation of the certificate. Also, all engineering societies require conformance to their ethical codes; violation of the code results in the revocation of the license to practice engineering in the society's jurisdiction. • These codes of ethics usually have much in common. They typically relate the need to act consistently with the client's interest, employer's interest, and most importantly the public's interest. They also outline the need to act with professionalism and to promote an ethical approach to the profession. • A Software Engineering Code of Ethics has been approved by the ACM and the IEEE-CS as the standard for teaching and practicing software engineering.

31. Examples of Codes of Conduct • The following are examples of Codes of conduct for Professional Engineers. These 2 have been chosen because both jurisdictions have a designation for Professional Software Engineers. • Association of Professional Engineers and Geo-scientists of British Columbia (APEGBC): All members in the association's code of Ethics must ensure that government, the public can rely on BC's professional engineers and Geo-scientists to act at all times with fairness, courtesy and good faith to their employers, employee and customers, and to uphold the truth, honesty and trustworthiness, and to safe guard human life and the environment. This is just one of the many ways in which BC’s Professional Engineers and Professional Geo-scientists maintain their competitive edge in today’s global marketplace. • Association of Professional Engineers, Geo-scientists and Geophysicists of Alberta(APEGGA): Different with British Columbia, the Alberta Government granted self governance to engineers, Geo-scientists and geophysicists. All members in the APEGGA have to accept legal and ethical responsibility for the work and to hold the interest of the public and society. The APEGGA is a standards guideline of professional practice to uphold the protection of public interest for engineering, Geo-scientists and geophysics in Alberta.

32. Opinions on ethics • Bill Joy argued that "better software" can only enable its privileged end users, make reality more power-pointy as opposed to more humane, and ultimately run away with itself so that "the future doesn't need us." He openly questioned the goals of software engineering in this respect, asking why it isn't trying to be more ethical rather than more efficient. In his book Code and Other Laws of Cyberspace, Lawrence Lessig argues that computer code can regulate conduct in much the same way as the legal code. Lessig and Joy urge people to think about the consequences of the software being developed, not only in a functional way, but also in how it affects the public and society as a whole. • Overall, due to the youth of software engineering, many of the ethical codes and values have been borrowed from other fields, such as mechanical and civil engineering. However, there are many ethical questions that even these, much older, disciplines have not encountered. Questions about the ethical impact of internet applications, which have a global reach, have never been encountered until recently and other ethical questions are still to be encountered. This means the ethical codes for software engineering are a work in progress, that will change and update as more questions arise.

33. Professional responsibilities in developing software • Who's Responsible? • The developers work with clients and users to define system requirements. Once the system is built if any accidents occur, such as economical harm or other, who is responsible? • If an independent QA team does integration testing and does not discover a critical fault in the system, who is ethically responsible for damage caused by that fault?

34. Responsibilities for Engineering and Geo-science Software • Developing software is a highly risky proposition. The software development process is a complex undertaking consisting of specifying, designing, implementing, and testing. Any small mistake or fault will cause unlimited damage to society. Professional Members contribute to the success of software development projects. However, Association of Professional Engineering and Geo-science is primarily concerned with their responsibility for minimizing the risk of failure and protecting the public interest

35. Systems Engineering • Systems engineers deal primarily with the overall system requirements and design, including hardware and human issues. They are often concerned with partitioning functionality to hardware, software or human operators. Therefore, the output of the systems engineering process serves as an input to the software engineering process.

36. Engineering process • The definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself.