University of Michigan-Dearborn [http://www.umd.umich.edu] Winter, 1997
Department of Computer and Information Science (313) 436-9145
http://www.engin.umd.umich.edu/~engweb/CIS/cis-homepage.html 134 ELB
Professor Ken Modesitt Office Hrs: 3:30
MW+appt.
http://www.cis.umd.umich.edu/netforum/cis375w97/a/1 Modesitt@umich.edu
COMPUTER AND INFORMATION SCIENCE 375
INTRODUCTION TO SOFTWARE ENGINEERING
4:30 p.m. - 6:00 p.m. MW
1211 Mardigian Library (Distance Learning Classroom)
Texts:
Classical and Object-Oriented Software Engineering (3rd Edition) by Stephen Schach,
Irwin, 1996. (Required)
Software Engineering: A Practitioner's Approach (4th Edition). by Roger Pressman,
McGraw-Hill, 1997. (Optional)
Course Description [Also see official one on CIS home page]
This course presents an in-depth treatment of many software engineering topics including:
software engineering paradigms, requirements specification, functional design, object-
oriented design, software verification, and maintenance. Comprehensive discussion of
human-computer interaction and user interface design. 3 hours credit.
Prerequisite: CIS 350 -- Data Structures and Algorithm Analysis
Goals
"Build useful and reliable software more quickly and cheaply -- faster, cheaper, better!"
The objectives of this course, upon completion, are to:
1. possess positive interdependent -- collaborative team -- skills
2. add skills missing from earlier courses, where the back-end of the software lifecycle was
emphasized
3. gain an appreciation of why the object-oriented paradigm is gaining favor, and also
understand
the importance of knowing/using classical methodologies
4. introduce front-end skills (needs assessment, customer interaction, estimation, analysis,
design, analysis-to-design)
5. have extensive hands-on CASE experiences
6. demonstrate the vital importance of frequent customer interaction
7. exercise communication skills extensively, esp. when presenting new material to class!
8. emphasize the many aspects of software quality
9. practice time management skills
10. make extensive use of library resources, including the Internet
11. develop deliverable products which add real value to real customers
12. MAKE MISTAKES AND LEARN FROM THEM!
Cognitive Domain [A more detailed listing uses Bloom's taxonomy*]
1. Knowledge
- The student will be able to define, recognize, and recall concepts related to software
engineering. See attached list for a partial set of terms from the text and other sources.
- The student will be aware of existing products which address the above concepts and
other productivity tools.
2. Comprehension
- The student will be able to compare and contrast major concepts related to software
engineering, esp. as they compare to programming and computer and information science.
3. Application
- The student will be able to apply methodologies and existing tools for the modern
Software Life Cycle (SWLC), including the Software Development Life Cycle (SDLC).
4. Analysis
- The student will be able to analyze a customer's need, and the proposed solutions,
designs, quality, implementation, testing procedures, and documentation of their own and
others.
5. Synthesis
- The student will be able to construct a useful requirements analysis, design, testing
procedure, maintainable code product, and management plan for a customer's problem.
6. Evaluation
- The student will be able to evaluate various student products, including analyses, designs,
testing procedures, implementations, problems, applications, physical products,
professional articles, commercial products, and performance of teammates.
* Bloom, B., et.al., (eds) Taxonomy of Educational Objectives, Handbook I Cognitive
Domain. David McKay, New York, 1956. [See attached]
Affective Domain
- The student will communicate, formally and informally via oral and written means, to
peers and the instructor, at least. There may be similar communication with an external
customer.
- The student will actively participate as a member of a variety of different teams with
different roles, e.g., design, programming, quality assurance, project management.
Non-Goals!!
Professor "reading" text to students
Methodology
1. Syllabus (see attached)
2. Homework, quizzes, examinations, logbook
3. Presentations by instructor, students, and invited guests
4. Projects
individual
collaborative efforts using teams (to reflect the "real-world" of software
development)
5. Resources
PEOPLE: peers, instructors (course plus others), CIS Professional Advisory Board
members, CIS 200 class (for contracting out coding), CIS 495 class (for being
contracted by)
TOOLS: programming languages, computer equipment, Internet, WWW,
Computer-Aided Software Engineering (CASE) tools, Knowledge-based systems
(KBS), computer-based learning systems, Desktop Video Conferencing (DVC)
OTHER: books, journals, popular magazines, vendor literature, library (Computer
Selects on CD-ROM), video tapes, professional organizations (ACM Special
Interest Group on Software Engineering -- SIGSOFT, Software Engineering
Institute -- SEI, Software Productivity Consortium, IEEE, etc.)
6. Record of this class (netforum URL on first page)
Style of Course
The intention of this course is to provide excellent learning opportunities for you, not for
me to "teach." Your learning is considerably more important than my teaching!
Consequently, this will not be a lecture-based course (only 5% retention by students).
Software engineering (and new material in general) is best learned by doing (75% retention
rate), so you will involved in LOTS of doing this term. There is even a higher retention
rate when teaching others (80%), so you will also be helping your fellow students (and
professor) learn. Considerable use will be made of "just-in-time" learning when you are
involved in the various projects. You will also be doing a sizable amount of technical
reading, since I do not plan to "read to you."
This course will also be very much of a project-oriented course involving considerable
teamwork, just as in industry. The days of the "Lone Ranger" guru have been gone for
several decades in most places. Specific attention will be devoted to teams and how they
interact. Why? Because it has been shown, time after time, that the single biggest factor for
software productivity is the way in which a team collaborates. So you will know all of
your classmates quite well before long! Several of these projects, if not most, will be ones
on which you have input.
Finally, you will note that ethics and professionalism do not have a "day" devoted to them
in the syllabus. That is because these issues will permeate the course. There is a
discussion data base on the CIS home page to which all of you will contribute. Such
issues will not be "academic" ones to you by the end of the course -- you will be practicing
them on a weekly basis.
Evaluation
Continual for both professor and student with built-in checkpoints.
Student
homework exams/quizzes projects final course (% of total)
10% 15% 60% 15% 90.0 - 100 = A
80.0 - 89.9 = B
70.0 - 79.9 = C
60.0 - 69.9 = D
<60.0 = E
Quizzes: Usually prior to a chapter (in-class, open notes, closed book)
Normally given prior to classroom discussion: really a "pre-quiz"
Exams and final: may include take-home component as well as in-class one.
Professor
mid-course and end of term using free-form, MECCA model, UM-D form
Late Grading Policy
On-time One class day late Two > Two
Full-credit 80% 50% 0%
Attendance Policy
I assume you are here to learn by whatever legitimate means you can. I am here to help
you to the best of my ability. If you do not come to class, I am much less likely to be able
to help. Positive attitudes toward attendance and the classroom are desirable.
The Learner's Responsibility
" In any classroom, the final responsibility for learning rests squarely on the learner. It can
never be otherwise. We who are in faculty or administrative roles have the obligation to try
to provide the best possible environment for learning. We can try to motivate, try to
encourage, and try to assist, but we cannot learn for the student. Let us be equally candid
on another point. If a student failure occurs, the quick response all too frequently is to
blame those who try to help -- a president, a dean, the staff, or the faculty. This search for
a scapegoat blurs the essential idea that the learner is a partner in the educational experience
and bears the ultimate responsibility for success or failure." [Dr. Harold L. Enarson,
Former President, Ohio State University]