Personal tools
You are here: Home Courses CS350 Intro. to Software Engineering, Spring 08

CS350 Intro. to SE Spring 08


  • Final exam on May 28th 11:00 AM-1:00 PM
  • May 9th: No more reduced safehome implementation.  Instead, a sample program is given for your reference.  See the project section
  • Feb 8thCS 350 BBS at NOAH is available now.  All class attendants are encouraged to write questions or comments on the class at the BBS.

Administrative Information

Office: 2434 (located at the east wing)



Office hour: Tues & Thr 17:00-18:30

(reservation e-mail would be preferred)

  • Teaching assistants:

Yunho Kim

Office: 2438 (located at the east wing)


Phone: 042-869-3583

Office hour: Wed 4:00-7:00 PM

(reservation e-mail would be preferred)

Chan-Hee Yi

Office:  1430 (located at the east wing)


Phone: 042-869-5579

Office hour: Tues 1:00-4:00 PM

(reservation e-mail would be preferred)

  • Lecture hours: MWF 11:00 AM - 12:10 PM
  • Lecture room: 2112 (a.k.a the 2nd lecture room)
  • Grading: HW & projects: 40%, Pop-up quiz & attendance: 20%, Midterm exam: 20%, Final exam: 20%
    • Late HW is accepted with 20% penalty in 1 day, 40% penalty in 3 days. HW will not be accepted after that.
  • Note: The official language in the class is English. All students should submit homeworks and project in English.

Course Material

- “ Fundamentals of Software Engineering 2nd ed” by C.Ghezzi, M.Jazayeri, and D.Mandrioli. Prentice Hall

- “ Applying UML and Patterns 3rd ed” by C.Larman. Prentice Hall

- “ UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd ed” by M. Fowler and K.Scott. Addison Wesley

- “ Code Complete 2nd ed” by S.McConnell. Microsoft press.

- "Model-based testing" at Wikipedia

  • Internet Resource

- SEPA home page (multiple choice quiz and summary for each chapter)

- Argo UML (open source UML tool)

- Telelogic Rhapsody (commercial UML tool)

- UML Tutorial

Course Schedule

Wk 1-2: The Software Process

- Feb 13th: General introduction to the class

- Feb 15th :  “Intro. To SE (1/2)”

- Feb 18th:  "Intro. to SE (2/2)"

- Feb 20th: No class

- Feb 22th: "Ch1. Intro. to SE"

- Feb 27th: "Ch2. A generic view of process"

- Feb 29th: "Ch3. Process models"

- Mar 3rd: Ch4. Agile Development

- Mar 5th: Ch 5. Software Engineering Practice

- Mar 7th: Ch 7. Requirements engineering

- Mar 10th: Telelogic DOORS

- Mar 12- Mar 21: Unified Modeling Language & Telelogic Rhapsody

- Mar 18th: Ch 8. Analysis Modeling (1/2)

- Mar 24th, Mar 26th: Ch 8. Analysis Modeling (2/2)

- Mar 28th: Ch9. Design Engineering

- April 7th: Ch10. Architectural Design

-April 14th: Ch11. Component Design

- April 16th: Analysis model review

- April 21th: Re-engineering home service robots for improved software reliability : a case study (slide)

- April 23rd: Ch14. Testing Tactics

Supplementary matierial: Software Unit Test Coverage and Adequacy
H ZHU, PAV HALL, JHR MAY - ACM Computing Surveys, 1997 

- May 9th: Guideline for Safehome Implementation

- May 14th, 16th: Ch15. Product Metrics

- May 19th - 23rd: Advanced verification methods


  1. Summary of “No silver bullet: essence and accidents of software engineering” Computer, 20(4):10-19, April 1987
  2. Summary of "No silver bullet: Software Engineering Reloaded" IEEE Software Jan/Feb 2008.  Due Mar 24th

Project: SafeHome in SEPA 6th ed

  • SafeHome dialog
  • Page list for safehome in SEPA
  • You can download DOORS, requirements management and traceability tool, and its manuals
    • Install guide
    • Zip password is given on Mar 10th class
    • Each team has two DOORS IDs, TeamN-1 and TeamN-2 where N is your team number.
      • Initial password is not set.  After first login, create your own passwd.
  • We use SEPA as a main requirement source.  You have to read SEPA carefully to understand system requirements, etc. 
    • Note that SEPA's description of SafeHome is not complete.  Therefore, you have to make your own assumptions about unclear points, which must be explicitly stated
    • Post your questions regarding SafeHome project into the CS350 BBS to share the questions and answers with all classmates.  Sending e-mail regarding the SafeHome proj to me or TAs is not encouraged.
    • Each team should provide a "who did what" list to show how each team member contributed to the project for project progress
  • Team assignments
    1. 박지영, 이재송, 최재영
    2. 이수현, 조재영, 조종기, 조준영
    3. 구지성, 김으뜸, 안다비, 이명경
    4. 권세중, 원강희, 이상영, 이지은
    5. 김근우, 박다혜, 오은수
  • Mar 21st:  Due of complete requirement specifications
    • Make a systematic requirement specification of SafeHome using DOORS
    • Should provide both hardcopy and DOORS file
  • Apr 15th:  Due of complete use-case diagram, use-case description, sequence diagram, and activity diagrams (swinlane diagram)
    • You are welcome to add more diagrams or pictures if they help describe the SafeHome's requirements clearly.
    • Presentation of analysis model on Apr 16th & 18th (in English)
      • Each team has 20 minutes to present their design
      • Demonstrate concrete traceability
    • Presentation movies

If you cannot play the movies uploaded, follows the instruction in this link.

  • Apr 28th: Due of class diagram, CRC cards, state diagram, and lessons learned
    • Presentation of design model on Apr 30th & May 2nd
      •  Each team has 20 minutes to present their design
    • You are welcome to add additional materials such as architecture or component design, if they can explain your design more clearly
    • Demonstrate concrete traceability
  • May 9th: Due of peer review of design document of other teams.  See sample review of team5
  • June 4th  : Due of implementation and testing stages

    • safehome.jar contains all device emulator classes as well as a demo source code.  Run "jar safehome.jar" for demonstration.
      • You should download and place camera1.jpg in the same directory of safehome.jar.  If you open two cameras, download caemra2.jpg, too.
    • A sample program which consists of a dumb CP in C, one camera in Java and one camera display in Java your implementation reference.
    • Your code should contain full document/comments.  For example
      • Purpose, description, usage/example, authorship, revision history, precondition/postcondition, known/fixed bugs, parameter/return values, exceptions, references, etc
      • You should use javadoc  to automate code document generation. Doxygen is recommend for C files.
    • Test process that you undertake should be described, e.g, how you performs unit tests, integration tests, regressions tests, top-dwon tests, botton-up tests, etc.   Test cases should described, too.
      • Design test cases for unit test first, then start implementation if possible.
      • Mapping between implementation and your design should be explicitly described.
  • June 6th 10:00 AM - 12:00 PM Final presentation
Document Actions