EECS 448

EECS 448
Software Engineering I

Spring 2004

1136 Learned
11:00- 12:20 Tuesday/Thursday

.	Instructor	Assistant
Name	Douglas Niehaus	Deepti Mandava
Email	niehaus@eecs.ku.edu	mandava@ku.edu
Home Page	www.ittc.ku.edu/~niehaus	None
Office	254 Nichols (Primary) 3046 Eaton	TBD
Phone	Nichols: 864-7785 Eaton: 864-7367	None
Office Hours	Eaton: Tu: 2:30-4, Th:9:30-11 Nichols: by appointment	TBD

Books and Additional References

Required Text	Object-Oriented ad Clssical Software Engineering Stephen R. Schach McGraw-Hill ISBN: 0-07-239559-1
Suggested Text	No Single Additional Reference Seems a BEst Choice
Additional Resources	UNIX Manuals and Manual Pages WWW references on Linux, GNU Tools, and Python Any of many books on C and C++ Programming Any of many books on UNIX Tools (emacs, make, perl, etc.) WWW surfing and searching for references, tools, and examples

Course Objectives

The objective of this course is to address a range of issues associated with the design and implementation of software systems. The emphasis is on the software engineering aspects of the problem, many of which do not arise in the context of typical university course software projects. One fundamental challenge of this course is to give the student an initial experience of what writing software professionally is like, and most importantly, how writing software in a professional setting is different from writing it in most university courses. The fundamental challenge is one of scale in several dimensions, including: size, time, and group size.

Size

software written in most university courses contain hundreds or thousands of lines of code divided into at most a few files. Software projects in industry often contain tens of thousands, hundreds of thousands, or millions, of lines of code. Large scale software is often divided into hundreds of files in tens of directories. The significantly larger scale of industrial software brings with it a need for programming techniques that are simply not present in typical course projects.

Time

Mst univeristy course programming projects ahve a due date of from one to three weeks. Many software developers in industry work on the same project for several years. Working on a project over a long period of time requires the developer to deveote considerable effort to be consistent with respect to design and implementation issues across the entire period. This issue is not relevant when the entire project is finished in two weeks. The primary method by which programmers maintain consistency over time is through documentation that can be used for reference and comparision.

Group Size

Most courses require students to work alone. While some software developed professionally is done by individuals, the vast majority of industrial software development is done by groups of people. Working in groups presents a number of challenges not present when working alone. Further, working in groups of 3 or 4 is considerably more challenging than working in pairs. Conflicts over design, implmentation and scheduling must be managed effectively. There is a considerable social dimension to maintaining coordination among group members, ensuring that methods and assumptions embodied in code written by each group member are compatible with those embodied in the code written by all other group members.

Students whose only experience are the traditional individual class programming projects often have a difficult period at the beginning of their first professional programming job as a result of the considerable difference between school and professional practice with respect to these and other aspects of software development. Employers are often dismayed by the ineffectiveness of new graduates, and express frustration at the length of time it often takes for a new graduate to become an effective software development group member. One purpose of this class is to reduce the degree of difficulty experienced, as well as reducing the duration of the difficult period.

The course will address sets of tools and practices which have been developed to aid programmers programming for real projects in real situations, as well as the doctrine and procedures associated with the classical software engineering stages: requirements, specification, design, implementation, and maintenance. Since many aspects of software engineering doctrine are expressed at an abstract level, the class will also provide an opportunity to see how the abstract ideas are put into practice by applying them to the semester project within the software development environment supported by the department Linux systems. The semester length of the project will provide experience with a longer time scale.

A vitally important aspect of the class will thus be the work done by each student within the project groups which will work together throughout the semester. The semester project is a real software engineering problem, one for which real users desire a solution, and one for which no solution currently exists. It will thus require the design, implementation, and documentation of new software and/or significant extensions to existing software systems.

Even more significant, since this will be the first time a previously unsolved project has been encountered by students who have only programmed within the context of lower level EECS programming classes. The most realistic aspect of a realistic project is that there is no single correct answer. In a real project the software engineer's role is to become an expert in the application area and design a successful solution. An important implication of the realistic nature of the project is that the instructor does not know exactly how the software should be designed or exactly what it should do. Studnets will be working on a new problem, a real problem, and that means that no one knows the answer. The student's job, that of every software engineer, is to design a succesful answer to the problem.

Topic Outline

The following is a rough outline of the topics the class will cover, and the chapters in the textbook discussing those topics. Note, however, that the lectures will not cover every part of every chapter, and some lecture materials will not appear in the book. As a general principle, the student will be responsible for the topics covered in lectures, and for topics covered in the book which are specifically assigned by the instructor.

Introduction and Overview (Chap 1-4)
Development Environment (Supplementary Materials)
Requirements and Specification (Chaps 10,11)
Software Design (Chaps 6-7,12-13)
Implementation and Integration (Chaps 14,15)
Validation, Testing, Debugging (Chaps 6 and supplementary materials)

Class Attendance and Office Hours

Many concepts can only be understood over time and after repeated discussion. The key idea here is discussion, which means you must actively participate. To do that, you have to be in class. It is tempting to look at the general nature of the subjects addressed by the class and think that you can just read the book and need not come to class. Tempting but wrong. The ideas underlying software engineering are very simple, but extremely hard to apply in practice. The only way to learn is to keep trying, and that means to participating in the process. You should feel free to ask questions in class, but more than that you should force yourself to ask questions if that is what it takes. You will not achieve a full understanding of the subject unless you do. Asking questions is difficult, but it is also the single most important skill of a software engineer.

That means that you must either ask question in class or come to office hours. Come to my office and discuss your questions about class, about the projects, about the connection of the subject to other parts of computer science and engineering, or to talk about what it is like to do software for a living. Your active participation in these types of discussions is the primary goal of the class because only active participation will give you the experience you require to be an effective software engineer.

Grading

The course grade will be determined by the student's performance on the midterm, class participation, and on the software projects. One way to thnk about how classroom participation helps determine your grade is to imagine that you are near a numeric border between letter grades; either above or below. Participating in class will give you "lift" in this situation; either to rise above the border, or to avoid sinking below it.

Written Test	30%
Projects	70% GP01: 20% GP2: 25% GP3: 25%

Special Needs

Any student in this course who has a disability that necessitates accommodation should contact the instructor as soon as possible to discuss the appropriate accommodations necessary to complete the course requirements.