CIS 642 - Fall 2026

CIS 642 - Software Engineering Project I (Fall 2026)

Previous Versions

Class Times & Location: MWF 9:30am-11:20am DUF 1092

Instructor Contact Information

Nathan Bean (nhbean AT ksu DOT edu)

• Office: DUE 2216
• Phone: (785)483-9264 (Call/Text)
• Website: https://nathanhbean.com
• Office Hours: WU 2:00pm-3:30pm or by appointment

Russell Feldhausen (russfeld AT ksu DOT edu)

• Office: DUE 2213, but I mostly work remotely from Kansas City, MO
• Phone: (785) 292-3121 (Call/Text)
• Website: https://russfeld.me
• Virtual Office Hours: By appointment via Zoom. Book time to meet with me

Preferred Methods of Communication:

• Chat: Quick questions via MS Teams are the preferred means of communication.   Questions whose answers may benefit the class I would encourage you to post in the course Team, as this keeps a public history your classmates can review. More personal questions should be direct messaged to me.
• Email: For questions outside of this course, emailing the instructor(s) directly is preferred.
• Phone/Text: 785-483-9264 (Nathan Bean Call/Text) or 785-292-3121 (Russell Feldhausen Call/Text)

Prerequisites

• CIS 308
• CIS 501

Students may enroll in CIS courses only if they have earned a grade of C or better for each prerequisite to these courses.

Course Overview

The first semester of a two-semester capstone course. Current practices of software development, requirements, design, prototyping, measures and evaluation. Specification, design, and prototyping of a software system.

Course Description

You will be creating professional-grade software to tackle a real-world application that will be released as an open-source project to the public. This includes:

• Starting from an existing code base. Very rarely will you have the luxury of starting a real-world project from scratch. Almost always, you’ll have to start from an existing program, framework, or API specification, and adapt it to your customers’ needs. Existing code bases are often poorly or incorrectly documented, under- or completely non-tested, and full of spaghetti code.
• Working as a team. You will very likely never work on a solo project in industry - modern software engineering involves teams of tens if not hundreds of programmers, plus many non-technical contributors as well. Good software development therefore involves tools and strategies to minimize code collisions and endure productive and healthy working relationships.
• Working directly with customers to understand what the software needs to do and how it can be most useful to them. This includes usability design and testing, feature negotiation, and human relations.
• Documenting the software as you develop it in a way that supports future maintenance and feature additions.
• Creating test frameworks or applying validation frameworks to ensure your code does exactly what it is intended to do without any errors.
• Refactoring spaghetti code and poor designs for greater efficiency and maintainability.
• Using prototypes to explore new feature ideas for usability and functionality.
• Employing a staged design, testing, and deployment process to ensure that only the highest-quality, functional, and well-tested code ever appears in front of regular users.

This bulleted list captures the course objectives - by the completion of the course you will need to have demonstrated mastery of each point through developing your software engineering project to earn an A.

Major Course Topics

• Software Engineering
• Requirements Gathering
• Feature Estimating
• Testing and Verification
• Continuous Deployment
• Waterfall Development Model
• Agile Development Models

Course Structure

This course is primarily a project course – you will be grouped into teams by the instructor and assigned a specific, real-world software application to develop. Each project also comes with real-world customers who will provide guidance and design priorities, judge usability, negotiate development schedules, and determine how well your software meets their needs. Your projects will be released as open-source projects and hosted on a public Github repository. You should realize that this project will be one of the criteria by which your future employers will judge your suitability, as well as the recommendations of both your instructor and customers.

Lectures, Readings, Class Discussions, and Activities

While the core focus of this course is learning by doing, carrying out the principles of good software engineering while creating or expanding upon an open-source software project to meet society’s needs, understanding the process begins with studying engineering practices. This will be done through video lectures, assigned readings, class discussions, and other class activities.

Software Projects

Software projects will cover a wide range of uses as well as base technologies/development languages. The instructor will endeavor to match you to a project in your interest area, but this will not always be possible. In all cases, these are real-world projects that will go on to be used by hundreds or thousands of real-world users. Good design is essential and serves to support both these eventual users and to build your reputation as a software engineer.

Software project development will proceed using an Agile methodology with a two-week iterative development cycle. At the end of each cycle, you will release a tagged prototype version of your software using Git’s tagging functionality. This prototype will be graded for: 1) code quality – focusing on readability, maintainability, and efficiency, 2) documentation – focused on accuracy and coverage, 3) testing/verification processes – focused on depth and correctness of coverage.

You will conduct a stand-up meeting, a sprint review meeting, or a sprint planning meeting (or any combination of the above) during the assigned class period. As such, it is vital to the success of your project that you attend these meetings!

Development Teams

You will be assigned to a development team of 3-4 students. Each student is expected to contribute to all aspects of the development process. This means that you will not have a documentation guru or a testing guru who only writes documentation or tests. Every member should carry part of the responsibility for writing code, tests, and documentation, as well as working with customers. However, you can divide duties in such a way for a specific design iteration – but by the end of the project each member should have contributed equally in each area.

Every two weeks you will have a formal review and planning meeting with some or all of your customers, at which point they will evaluate your iteration’s prototype for how well it meets their needs. This meeting will be scheduled during the course lab time to facilitate coordination of schedules. It is a mark of respect and professionalism to be on-time, well-prepared, and well groomed for these meetings. Missing a meeting (with the exception of emergency circumstances) will result in an automatic lowering of your grade by a full letter (1 on a 4-point scale). The customers’ evaluations, along with a survey of how well they felt the team interacted with them during the design iteration, will be the basis of your customer relation grade. This grade will be adjusted by the instructors if the team members arrive late, are ill-prepared, appear in inappropriate attire (for these meetings, you should be in business casual).

Process Fidelity

Each team will also be responsible for making adequate usage of the many tools developed to enhance and expedite the software development process. At a minimum, the development team should be using 1) a code repository to manage the sharing of team code (Git publicly hosted through GitHub or the departmental GitLab server is required) 2) a feature planning and bug tracking system like GitHub or GitLab issues, and 3) a documentation wiki (Use the Github or GitLab built-in Wiki). Each of these is a tool you should be using throughout the development cycle, not simply something you throw data into right before your next meeting. You will be graded on how regularly and effectively you utilize these tools.

In addition, Agile software development utilizes a set of artifacts – physical and visual representations of the project’s goals and progress. These help teams and managers quickly assess what needs to be done on a project and how far along the process is. Your team will also need to make appropriate and regular use of these artifacts, including: 1) velocity chart, and 2) burn-down chart.

Grading

This course uses a different approach to grading than you are probably used to, criterion grading. In criterion grading, there is no concept of a ‘partial score’; instead your work is either acceptable (and you earn full points), or unacceptable (and you earn no points). This is reflective of industry practice - if you fail in your job, you will get fired.

Each activity you are tasked with is worth a certain number of points, and the guidelines for what is acceptable will be spelled out in the assignment description, so read them carefully!

In addition, exceptional work may be rewarded with a bonus of 5% of the points set for the assignment.

Grades will be issued on a 4-point scale, with 4=A and 0=F. Grades will be issued for each category according to this breakdown:

Each category is equally important for your preparation for becoming a software engineer - remember, it isn’t only about writing good code, it’s about making that code useful to society!

Late Work

Late work is considered unacceptable, and as such will result in no points earned on the assignment. As Seniors you should have developed sufficient time management and planning skills to keep on top of your due dates.

For your sprints, remember that in your sprint planning, you are setting your commitments by what you add to your sprint backlog - don’t overcommit! At the same time, you need to be making enough progress to keep your customer happy while ensuring your software is of sufficient quality and adequately documented and tested.

Dress Policy

As indicated in the customer relations section, students are expected to wear at a minimum business professional attire for the bi-weekly review and planning meetings with their customers. For other meetings with customers. Career and Employment Services publishes guides to professional and casual attire for men and women on their site (https://www.k-state.edu/careercenter/students/apply_interview/attire/dresstoimpress.html). These will be used as the grading rubric within this area, so be sure to familiarize yourself with the expectations!

For obtaining inexpensive business wear options, there are many opportunities available to you:

• CES offers the career closet every Monday-Friday, 8am - 5pm at the Berney Family Welcome center to find gently-used professional wear. Students can typically take up to three articles. Monetary donations will go to the Manhattan Emergency Shelter.
• Several thrift stores in Manhattan carry business professional and casual attire at affordable prices (listed by proximity to campus):
  • The Encore Shop, 611 Poyntz Avenue
  • Goodwill, 421 E. Poyntz Avenue
  • Grand Old Trunk, 1304 Pillsbury Drive

Subject to Change

The details in this document are not set in stone – there may need to be adjustments made throughout the semester. If this occurs, changes will be posted to the K-State online page and emailed to student’s K-State email addresses.

Standard Syllabus Statements

Netiquette

Online communication is inherently different than in-person communication. When speaking in person, many times we can take advantage of the context and body language of the person speaking to better understand what the speaker means, not just what is said. This information is not present when communicating online, so we must be much more careful about what we say and how we say it in order to get our meaning across.

Here are a few general rules to help us all communicate online in this course, especially while using tools such as Canvas or Discord:

• Use a clear and meaningful subject line to announce your topic. Subject lines such as “Question” or “Problem” are not helpful. Subjects such as “Logic Question in Project 5, Part 1 in Java” or “Unexpected Exception when Opening Text File in Python” give plenty of information about your topic.
• Use only one topic per message. If you have multiple topics, post multiple messages so each one can be discussed independently.
• Be thorough, concise, and to the point. Ideally, each message should be a page or less.
• Include exact error messages, code snippets, or screenshots, as well as any previous steps taken to fix the problem. It is much easier to solve a problem when the exact error message or screenshot is provided. If we know what you’ve tried so far, we can get to the root cause of the issue more quickly.
• Consider carefully what you write before you post it. Once a message is posted, it becomes part of the permanent record of the course and can easily be found by others.
• If you are lost, don’t know an answer, or don’t understand something, speak up! Email and Canvas both allow you to send a message privately to the instructors, so other students won’t see that you asked a question. Don’t be afraid to ask questions anytime, as you can choose to do so without any fear of being identified by your fellow students.
• Class discussions are confidential. Do not share information from the course with anyone outside of the course without explicit permission.
• Do not quote entire message chains; only include the relevant parts. When replying to a previous message, only quote the relevant lines in your response.
• Do not use all caps. It makes it look like you are shouting. Use appropriate text markup (bold, italics, etc.) to highlight a point if needed.
• No feigning surprise. If someone asks a question, saying things like “I can’t believe you don’t know that!” are not helpful, and only serve to make that person feel bad.
• No “well-actually’s.” If someone makes a statement that is not entirely correct, resist the urge to offer a “well, actually…” correction, especially if it is not relevant to the discussion. If you can help solve their problem, feel free to provide correct information, but don’t post a correction just for the sake of being correct.
• Do not correct someone’s grammar or spelling. Again, it is not helpful, and only serves to make that person feel bad. If there is a genuine mistake that may affect the meaning of the post, please contact the person privately or let the instructors know privately so it can be resolved.
• Avoid subtle -isms and microaggressions. Avoid comments that could make others feel uncomfortable based on their personal identity. See the syllabus section on Diversity and Inclusion above for more information on this topic. If a comment makes you uncomfortable, please contact the instructor.
• Avoid sarcasm, flaming, advertisements, lingo, trolling, doxxing, and other bad online habits. They have no place in an academic environment. Tasteful humor is fine, but sarcasm can be misunderstood.

As a participant in course discussions, you should also strive to honor the diversity of your classmates by adhering to the K-State Principles of Community.

SafeZone Ally

I am part of the SafeZone community network of trained K-State faculty/staff/students who are available to listen and support you. As a SafeZone Ally, I can help you connect with resources on campus to address problems you face that interfere with your academic success, particularly issues of sexual violence, hateful acts, or concerns faced by individuals due to sexual orientation/gender identity. My goal is to help you be successful and to maintain a safe and equitable campus.

Copyright Notice

©2021 The materials in this online course fall under the protection of all intellectual property, copyright and trademark laws of the U.S. The digital materials included here come with the legal permissions and releases of the copyright holders. These course materials should be used for educational purposes only; the contents should not be distributed electronically or otherwise beyond the confines of this online course. The URLs listed here do not suggest endorsement of either the site owners or the contents found at the sites. Likewise, mentioned brands (products and services) do not suggest endorsement. Students own copyright to what they create.

Original content in the course textbook at https://textbooks.cs.ksu.edu/cis642-643/ is licensed under a Creative Commons BY-SA license by Nathan Bean unless otherwise stated.