Unformatted text preview:

CPS211 Lecture: Course Intro; Introduction to Software Engineeringlast revised July 23, 2008Objectives:1. To introduce the course requirements and procedures.2. To set programming in the larger context of software development/engineering.3. To introduce the Software Engineering Code of Ethics4. To introduce basic terms/concepts of SE5. To introduce the software lifecycle Materials: 1. Syllabus2. Software Engineering Code of Ethics (online)3. Projectable of “Tree Swing” 4. Projectable of text page 3055. Projectable of requirements for AddressBook and ATM example systems6. Term project requirements (Handout)I. Preliminaries - About this CourseA. Writing exercise - When you purchase a product - any product, software or otherwise - how do you evaluate the quality of what you have purchased - i.e. what do you look for, in general, as marks of quality?Discuss class answersB. Distribute, go over syllabus. C. This course is a continuation of CPS112; but it will differ from CPS112 in some important ways.1. In CS112, a great deal of your mental energy was invested in learning about programming, and more specifically in learning how to program in Java.2. While programming in Java is part of the content of this course too, we want to step back from programming per se to set it in the broader context of problem solving.a) It turns out that much the same issues arise in any sort of problem solving - whether it be the creation of a piece of software, or the creation of some other engineered artifact, or the design of a curriculum in education, or the development of a business plan, or ...1b) In this course, we are specifically concerned with software development - an entire process of which programming is just one part. Software development is the process of producing a software product that will fulfill some real need for someone. c) However, since the basic process is similar whenever one is involved in designing a quality solution to a problem someone has - software or otherwise, the basic approach we will take is broadly applicable to any sort of problem solving. 3. Some of you may wind up developing software professionally, while others will not. However, an understanding of the issues involved in software development is not just important for practicioners. It is perhaps useful at this point to think a bit about the spectrum of things people with a CS background actually do.a) Some, of course, do develop software in a variety of settings - whether embedded systems (e.g. the software that controls many of the systems in a modern car) or moderate sized systems (like web sites) or huge systems (like those that control the telelphone network etc.)b) Others are involved in research. Often, this research finds practical application in software systems.c) There is a growing recognition of the need to develop people with cross-disciplinary understanding - i.e. people who understand not only computing, but also some field where computing is important. In fact, whole new cross-disciplinary areas like this are emerging - e.g. bioinformatics.d) Even a person who simply uses software - or helps others do so - can benefit from some understanding of what goes into producing software.4. The guiding principle in the content of this course comes from the title of a talk I heard at the OOPSLA Educator’s Symposium in 1999: “Teaching Design: the rest is SMOP” 2II. Fundamental Issues; The Idea of Software EngineeringA. Developing quality software is not easy.1. Software systems are among the most complex systems ever attempted by humanity. There is still much to be learned about how to do this well.2. Most large-scale software projects exhibit one or more of the following problems to an unacceptable degree:a) The software is delivered late.b) The budget is exceeded.c) The software contains undetected errors. (Note: these are commonly called "bugs". Edgar Dijkstra has pointed out that calling them bugs rather than errors is a way of avoiding taking responsibility for them.)d) The software is difficult to maintain/modify - fixing one error often introduces two more.e) The software does not really meet the user's needs.f) The software is hard or confusing to use.3. While quality is an issue with any product of human design, it is a particular issue with software. We do not expect bridges or buildings to collapse - but we are not surprised when a piece of software “crashes”. We would be unhappy if we had to shut off and restart our car in the middle of an interstate, but we get used to the idea of periodically rebooting a computer ... B. The discipline that arose to address these problems in a systematic way has come to be called software engineering. Its goals are to:1. Produce software that meets the needs of users2. Produce correct software on time and on budget.3. Produce software that can be maintained and modified to keep abreast of changing needs. For software that is used over a period of years, the cost of keeping it current in the face of changing needs often exceeds the cost of originally developing it.3Meeting these goals is not easy, and probably never will be, because the complexity of modern software makes its development one of the greatest intellectual challenges ever faced by humanity. However, applying known principles can help.C. Software Engineering compared/contrasted with more traditional engineering professions.1. Software is certainly not like physical engineered artifacts. How? (ASK CLASS)a) For most physical artifacts, the bulk of the cost is in the manufacturing, not the design. For example, if one builds a bridge and then attempts to build another just like it, the second bridge costs almost as much to build as the first. However, “manufacturing” software is cheap - the cost of producing a new copy (say on a CD) is miniscule.b) Most physical artifacts are costly to change once they have been produced; but making changes to a piece of software is often a matter of editing and recompiling. (Of course, making correct changes is not necessarily easy!).c) Physical artifacts wear out and need to be maintained or ultimately replaced - but software never wears out.d) It is often possible to tell, by looking closely at a physical artifact, that it is defective. Faults in software are often much less obvious until they manifest themselves in some sort of error.e) A key difference is reflected in the existence of the “open source” movement. Open


View Full Document

Gordon CPS 211 - Course Intro

Download Course Intro
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Course Intro and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Course Intro 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?