CPSC 333 --- Lecture 1 --- Monday, Jan 8, 1996 Course Goals: - Study software development cycle from the perspective of a developer of software (rather than a manager or customer, for example) --- with emphasis on activities not studied in CPSC 231, 233, 331 - Learn some techniques for requirements specification, architectural design, and testing - This may be *similar to* methods and techniques used in industry after you graduate, and they should also be useful in later courses --- especially CPSC 451, but also (possibly, and I hope not only) CPSC 461 and CPSC 481 - Both "informal methods" and (to a lesser extent) "formal methods" for software development will be introduced - *If time permits:* Object-oriented development will be discussed as well Beyond the Scope of this Course: - Study of software development from other perspectives (eg, managers; customers/clients) - A study of a "complete" development cycle, or "alternative" development methods -Interface and performance requirements -Real time systems ... are all important, but won't be covered (because of lack of time). However, methods for specifying these additional requirements, and these other development methods, are *similar to* and often *extensions of* the methods/tools you'll see in CPSC 333. Administrative Information: Lecturers and Office Hours - Note material on course information sheet Labs --- are scheduled to start the week after next Assessment - Note material on course information sheet - Additional information will be posted to the course newsgroup, cpsc.courses.cpsc333, and will be announced in the next class Recommended References 1. Software Engineering. A Beginner's Guide OR Software Engineering. A Practitioner's Approach, 3rd Edn --- both by Roger Pressman OR: Online lecture notes, in ~eberly/CPSC333/Lectures 2. Software Development with Z --- J. B. Wordsworth I suggest that you should *only* purchase Pressman's book(s) after you've looked at the online notes and decided they aren't adequate. If you want a good reference for software engineering that you can use in the future, then it's probably worthwhile to invest in the more expensive (and more complete) book, "A Practitioner's Approach," instead of the "Beginner's Guide" When I discuss the specification language "Z" I will be using reference #2 as a guide. However, it isn't clear at this point how much time will be spent on Z in the lectures. Other Sources of Information: - various books on reserve in library - email: to eberly - course newsgroup: cpsc.courses.cpsc333 - directory ~eberly/CPSC333 Prerequisites: CPSC 331, plus... A logic course will be helpful but isn't currently a requirement. We intend to use lab time for "reviews" of logic Introduction to Software Engineering Software Engineering is ...the establishment and use of *sound engineering principles* in order to obtain *economically* software that is *reliable* and works *efficiently* on real machines ...early definition by Fritz Bauer Motivated by problems/circumstances of "Programming in the Large": - a statement of requirements is *not* available initially - typically, no single person understands requirements - worse yet: requirements will *change* as development proceeds - most common type of error found by users after software is delivered is currently *not* programmer, clerical, or design errors --- but involves a problem in or misunderstanding of software requirements - cost of correcting errors increases *drastically* as development proceeds --- the *best* time to find and correct an error is "as soon as possible" - testing *is* known to be effective in detection of errors --- provided that tests are designed and conducted in a "rational" way - the cost of using and maintaining software is typically much greater than the cost of developing the software in the first place - maintenance extends over years; the people who developed the software in the first place are generally unavailable to the people responsible for maintaining it CONSEQUENCE: A "rational" process that includes requirements analysis and specification *and* testing phases will "pay off" in the long run, even though this may *increase* the cost of and time for software "development" Software Development Activities "Definition" - Systems Analysis: System's functions are defined well enough for functions to be allocated to different system components --- generally including software, hardware, people, database,... --- *not* covered in CPSC 333 - Software Project Planning: Risks are analyzed, resources allocated, costs estimated, and work tasks and schedules defined --- *not* covered in CPSC 333 - Requirements Analysis and Specification: Software's functions are established in consultation with system users, and are documented for use in later stages --- covered in CPSC 333 "Development" --- *can* be broken down into - Software Design: System functions are separated into modules, interfaces are defined, and flows of control established. Algorithms and data structures are selected. --- covered in CPSC 333 - Implementation and Unit Testing: Modules are coded and tested individually. --- unit testing covered in CPSC 333; implementation (programming) is covered in other courses. - Integration and System Testing: Modules are combined into progressively larger subsystems. Integration and other "system" testing is performed. --- covered in CPSC 333 "(Operation and) Maintenance" - Activities include correction of errors, and changes to deal with "environmental" changes and to enhance the functionality of the testing after it's first been delivered. --- *not* covered in CPSC 333 Software Engineering Paradigms There's more than one way to "schedule" these activities. TWO IMPORTANT EXAMPLES: - Classic "Waterfall" Model - "essentially" sequential: Ideally, requirements analysis and specification is conducted until "complete." Design is then conducted, followed by implementation, testing... - some backtracking is to be expected - *NOT* a good choice if requirements aren't reasonably well understood --- or easy to discover --- at the beginning - easy to plan for and manage --- can be useful for extremely large projects involving modification of an existing system or development of a system similar to others developed in the past - Prototyping Model - more useful if requirements aren't understood in advance - repeat: - "estimate" requirements as well as possible - QUICKLY develop a model of the system --- possibly a pen-and-paper model, possibly a (semi-)working system thrown together by any means possible - show model to the people requesting/planning to use the system to be developed - use their comments to improve estimate of requirements until: requirements are understood well enough to begin development - THEN: Model requirements carefully, and proceed essentially as you would when using the "Waterfall" model - DANGERS: It's tempting to try to turn the "quick and dirty" system into the system to be delivered, rather than starting "from scratch". "Customers" may insist on this, thinking that this would be easy to do. However, the system that's been "thrown together by any means possible" will likely be extremely difficult to *maintain* Informal Methods and Formal Methods --- Why Show you Both? - Informal methods are "relatively" widely used: These are the methods your employers may expect you to be familiar with. They're generally based on *pictures* that are easy to understand, and that can be shown to "customers" to get feedback *In my opinion* because they're based on pictures, these methods are inherently limited and imprecise --- so they are *NOT* always sufficient for development, especially when correctness and reliability of the system are critical - Formal methods are (arguably) less mature, and not as widely used. Based on set theory and logic, they can be used to specify *some* kinds of requirements more precisely than is possible (or, at least, easy) using informal methods It is also possible to *prove* that specifications and programs have desirable properties (or that they're related as they should be) if (some) formal methods are used. This *IS NOT* possible when (only) informal methods are used for development. Some "existing" systems have been "specified" using formal methods, so that the specifications can be studied in this way. This has led to detection (and correction) of system problems that were missed when the systems were originally developed! Finally, *some* governments and agencies are now insisting that formal methods be used, or that systems be "validated" in ways that are only possible via use of formal methods