CSE 322: Software Reliability Engineering Topics covered: Course outline and schedule Introduction, Motivation and Basic Concepts.
Published byModified over 4 years ago
Presentation on theme: "CSE 322: Software Reliability Engineering Topics covered: Course outline and schedule Introduction, Motivation and Basic Concepts."— Presentation transcript:
CSE 322: Software Reliability Engineering Topics covered: Course outline and schedule Introduction, Motivation and Basic Concepts
General information CSE 300: Software Reliability Engineering Instructor: Swapna S. Gokhale Phone : 6-2772. Email : firstname.lastname@example.org Office : ITEB 237 Lecture time: Mon/Fri 10:30-11:45 am. Office hours: By appointment (I will hang around for a few minutes at the end of each class). Web page: http://www.engr.uconn.edu/~ssg/cse300.html (Lecture notes, general announcements, reference papers will be posted on the web page)
Course goals Appreciation for software reliability engineering Dependability concepts and models Various state-of-the-art reliability assessment techniques for a software system starting from the design phase: Software reliability growth models. Techniques for prediction Software metrics and software reliability. Software reliability models with repair Architecture-based software reliability analysis Software architecture styles Optimal software release criteria Study research papers, and implement the described techniques. Critique research papers, identify open research problems and suggest solutions.
Expected learning outcomes Develop experience and expertise in the use of state-of- the-art techniques used for the reliability assessment of software systems. Learn how general software packages such as S-plus, MATLAB can be used to implement techniques for software reliability assessment. Acquire familiarity with specialized software reliability assessment tools. Skills to understand, analyze, critique research papers.
Textbooks No required text book. Reference text books: Handbook of Software Reliability Engineering, M. R. Lyu, Editor, McGraw-Hill, New York, 1996. Lecture notes will be prepared from several papers, some of these papers will be posted on the web.
Course topics Dependability concepts and models Software reliability growth models Predictive analysis techniques Software metrics and reliability Architecture-based reliability analysis Software reliability models with explicit fault repair Optimal software release times
Grading system Midterm #1 : 25% Presentation, term paper, project : 25% Final : 50% Mid term and final will be take home.
Paper presentation, term paper and project Divided into groups of 2-3 8-10 papers will be identified. Each group will be expected to: Select a paper. Read the paper and understand the technique described. Present the technique to the class. Summarize the technique in a 1-2 page paper. Questions will be provided to the students, answers to which should be included in the term paper. Implement the technique described in the paper using language/package of your choice. Additional I/O requirements may be specified. Demonstrate the implementation.
Course topics and exams calendar Week #11 (Nov. 6): 19. Nov. 6: Software metrics and reliability Nov. 10: No class Week #12 (Nov. 13): Nov. 13: Project overview 20. Nov. 17: Software metrics and reliability Week #13 (Nov. 20) Thanksgiving break. Week #14: (Nov. 27) -- Group paper presentations Week #15: (Dec. 4) -- Group paper presentations -- Final exam (take home)
Grading policy Refer to the University policy regarding Student Conduct (Plagiarism, etc.) If you have any conflict with the exam date, please see me in advance for an alternative arrangement. Project grading: At the end of the semester, each one of you will be asked to provide feedback about your team member Your final project grade will take into consideration, the feedback provided by your team member.
Attendance policy Attendance not mandatory. Attending classes helps! Lecture notes on the web will provide an outline, detailed notes will be provided in the class.
Feedback Please provide informal feedback early and often, before the formal review process.