Syllabus for

Software Engineering Solutions

COSC 381

(M/W, 5:30-6:45, PH520)

Instructor: Matt Evett ; Dept. Computer Science; Pray Harrold 512
Tel: 734-487-1227
e-mail: mevett _AT_SIGN_ emich.edu;
online: canvas.emich.edu
Office Hours: MW 12:00-2:45 (face-to-face or via Skype) or by appointment.
You may drop by at times other than office hours, but in that case I cannot guarantee that I'll be able to see you. The best way to contact me is by e-mail.
Prerequisite: COSC 211 and 231.

Textbooks:

Course Summary: Overview of software engineering as a discipline, and its application to deriving solutions to novel problems. Introduction to software life-cycle models, phases of the waterfall and agile development processes, version control, testing, UML, basic HCI, and project management.  Students will complete at least three projects in which they design and implement a software solution to a problem specified by “real-world” clients as simulated by case studies. There will homework and lab assignments, as well as a midterm and final examination.

 

Student Learning Outcomes:

 

1: Explain and use the primary aspects of software engineering.

1.1: Explain the role of a software engineer and software engineering in the development of software solutions.

1.2: Apply to multiple case studies a contemporary analysis and design approach, such as object-oriented analysis and design.

1.3: Analyze and compare various software development life-cycle methods that include requirements analysis, design, implementation, testing and maintenance. Describe the relationships between the life-cycle phases and processes.

1.4: Describe and compare alternative software process standards and processes (e.g. waterfall, incremental, spiral, prototyping, empirical, test-driven, and agile methods)

1.5: Explain the roles and responsibilities in a software team, and management issues of teams.

2: Demonstrate the use of software engineering techniques to model solutions to case studies that provide only informal problem specification.

2.1: Brainstorm alternative solutions, select from alternatives, and create designs and appropriate documentation using UML class and sequence diagrams and other appropriate methods for the problem domain. 

2.2: Analyze and create a requirements specification using scenarios, use cases, and use case diagrams from a set of customer needs.

3: Develop clear, concise, and sufficiently formal life-cycle artifacts including requirements, design, implementation, and test documentation for software systems.

3.1: Explain the motivation for defining sufficiently explicit requirements.

3.2: Use software models in the Unified Modeling Language (UML) to express and analyze software requirements, and designs, and guide implementation

4: Explain the value of construction technologies such as version control and design tools to assist the software development practice.  Use these tools to develop a software system.

4.1: Explain the purpose of version control and its application for managing software design or code artifacts.

4.2: Use software tools (such as ArgoUML,Dia, etc.) to create design artifacts, including UML diagrams.

4.3: Use version control in a team-based development of a software system.

5: Explain software design concepts and develop a software system using these concepts.

5.1: Describe concepts and strategies in software design including architectural design, detailed design, and user interface design.

5.2: Create UML class diagrams that represent a problem domain from a requirement specification.

5.3: Create UML sequence diagrams to express class behavior.

5.4: Evaluate alternative designs at an introductory level through reviews (e.g. review of class diagrams).

5.5: Describe and exemplify several design patterns (factories, functors, iterators, decorators, dependency injection, observers, etc).

6: Explain testing and quality assurance strategies.  Demonstrate the use of testing tools.

6.1: Distinguish between program validation and verification.

6.2: Distinguish among the different types and levels of testing (unit, integration, systems, acceptance, regression, black box, white box, end-to-end).

6.3: Describe test-driven design.

6.4: Develop and use a testing suite with an integrated testing tool (e.g. JUnit, Jasmine, Karma, EclEmma, etc.) for a software system under development.

Course Calendar:

The dates below are tentative. Actual due dates are always and exclusively found via Canvas.
 

Date Topics
9/4 Introduction
9/9, 11 Software Engineering Methodologies (waterfall, agile, etc.). Example of Spotify's agile development.
9/16 (on-line), 18

Software Engineering Methodologies (scrums, code reviews, burndown charts, pair development, etc.)

Code repositories and version control. Git and Github.

9/23, 25 Git and GitHub
9/30, 10/2 Collaboration tools (e.g. Discord and Trello). Use the user story to develop initial task list.
10/7, 9 Techniques for defining software designs. Presented with a case study that presents a problem to be solved, develop the design of a sofware solution.
10/14, 16 Testing, JUnit. Validation and verification strategies. Build to the Test.
10/21, 23 End-to-end testing. GUI testing.
10/28, 30 Testing. Advanced debugging tools.
11/4, 6 Developing easily readable code (naming, functional decomposition, using comments)
11/11, 13 Developing easily readable code (formatting, error handling, successive refinement and refactoring)
11/18, 20 On-line classes Project Management (Maven, make, etc.)
11/25, Thanksgiving Design patterns (factories, etc.)
12/2, 4 Design patterns (MVC, etc.)
12/9, 11 Contributing to open source projects (e.g. Tensorflow, Keras, Apache MXNet, etc.)
12/16, 7:30PM Final Exam, 7:30PM, PH520

Grading Policy:

The final course grade will be a weighted average of the grades received in each of the following categories, as specified: Assignments 60%, Midterm exam 20%, Final exam 20%. Participation will be measured by the quality and frequency of your interactions on threaded discussions.

Tardiness Policy: Programming and other homework assignments will be due at the beginning of class. After that, assignments will be accepted through the start of the next scheduled class, but will suffer a full grade penalty. E.g., if a late programming assignment is worthy of an 'A', I will mark it a 'B'. Assignments more than one class late will not be accepted, and will receive a grade of 'F'. Missed assignments, and exams shall only be excused by a doctor's written note, verifying that the student was medically indisposed to participate on that day.

Grading of Programs: Programs shall be submitted to the online "dropbox" corresponding to each assignment and will consist of a zip file of the source code or of an Eclipse project directory. The zip file should also contain a file named "README.txt", a simple text file, containing any directions I might need to run your program, as well as a description of any known bugs in the program. Grading of programming assignments will reflect three factors, weighted as shown.

  1. (60%) Correctness -- does the program run correctly?
  2. (20%) Style -- does the code adhere to class documentation standards? Is the code indented properly? Are the variable names mneumonic? How well has the student followed the basic formatting characteristics for the language?
  3. (20%) Design -- is the program adequately decomposed (i.e., are the functions and procedures small enough to be comprehensible)? Are the class and structure definitions well chosen? How well has the student taken advantage of the language's capabilities?

Announcements and the Web Page:

Students should view Canvas regularly for announcements regarding programming assignments, readings, etc. I update Canvas frequently!

The EMU Library Is Here to Help!

The Halle Library provides excellent resources for writing and research (incuding avoiding plagiarism). You can get more information on this at this link: https://docs.google.com/document/d/1KaCkdV59k2eo7GepHnrimPOhPcXONdXe6hh2A2KJjmE/edit

Cheating policy:

Students are required to attend to the University policy on academic dishonesty outlined in Section X (Special Disciplinary Provisions Governing Acts of Academic Dishonesty) of EMU's Student Conduct Code (see the full policy at http://catalog.emich.edu/content.php?catoid=3&navoid=259#9j). Academic Dishonesty is defined in Section V of the Student Conduct Code and Judicial Structure of the EMU Board Policy Manual (http://www.emich.edu/policies/policy.php?id=124&term=dishonesty.) In addition, collaboration among students in solving programming and homework assignments is forbidden. If I receive programs or homework assignments that are substantially equivalent, or which are not the original work of the student submitting the material, I will not hesitate to punish all involved parties to the fullest extent, up to and including assignment of a failing grade for the course, and referral to the Office of Judicial Student Services for possible punitive action at the University level, which may include expulsion from the University. In addition, the University and the Computer Science Department maintain policies regarding proper behavior on its computer systems. Failure to adhere to these policies can result in loss of computer privileges, and possible legal action.