CSE 3902 Project: Design, Development, and
Documentation of Interactive Systems
This is a Junior-level (or advanced Sophomore) course on Professional Software Development. You will learn through hands-on activities, large team-based software development and processes. Our goals are to build a simple 2D platformer game. Not! Our goals are to craft high-quality software, understand the process of Agile software development, advanced tools for software development, testing plans and tools, and how to work in a small sized team (5-6 people). There will be a large amount of critiquing of code and interactive feedback. This will lead to refinement and improvement of your software (for future expansion and maintenance).
Grader: Ian Stitzlien (istitz -at- gmail.com)
Google Calendar for sprint planning sessions and feedback. Please pick a team when Ian can meet with your group. At the beginning of your weekly meetings would be good.
Google Calendar
Notes for class:
Official Syllabus
Reading Resources
C# and .NET
Coordinate Systems
Super Mario
XNA
Sprites
ALM
Team Rubrics (Word) (Pdf)
Software:
Groups
- Jason Sustar (.7)
- Jake Kiley (.21)
- Jacob Grealy (.1)
- James Balata (.4)
- Nate Niederkorn (.4)
Running Schedule
- Lecture 1 (W): Overview of class
- Lecture 2 (F): Demo of Visual Studio / C# language / arrays
- Lecture 3 (M): Presentation on C# Classes and interfaces (powerpoint)
- Lecture 4 (W): Presentation on Inheritance (powerpoint)
- Homework #1: Writing an interface and implementation for a Roaming Window
- Reading Assignment: Read Chapters 1 and 2 of Solid Code
- Lecture 5 (F): Group Formation, Requirements Gathering and other BS.
- Lecture 6 (W): Requirements / Agile
- Lecture 7 (F): Agile and sprints
- Lecture 8 (M): Colors and sprites
- Recap on Use Cases, English and specificity.
- Colors, Color spaces, transparency and blending
- Sprites
- Lecture 9 (W): The Sprite Engine
- Collect Use Case Rubrics
- PNG and transparency
- Crawfis Sprite Engine (aka XNA replacement)
- Lecture 10 (F): The Game Loop and Sprint 1
- Lecture 11 (M): Design Patterns and the v1 software
- Crawfis Sprite Engine v1
- Creational Design Patterns
- Read the following patterns in the Head First Design Patterns book:
- Factory Method (Chapter 4)
- Abstract Factory (Chapter 4)
- Singleton (Chapter 5)
- Builder (Appendix A - see also Design Patterns by Gamma, et. al.)
- Flyweight (
- Prototype (Appendix A - see also Design Patterns by Gamma, et. al.)
- Lecture 12 (W):
- Feedback on Tasks / Sprint1 / TFS
- Coordinate Frames
- Random Blog (all Software Sucks), but I care.
- Lecture 13 (F): Cameras
- Transformations
- Cameras
- Camera Controllers
- Lecture 14 (M): Quality Software Foundations
- Lecture 15 (W): Code Metrics continued
- Lecture 16 (F): Code Smells and Refactoring
October
- Lecture 17 (M): Sprint1and Sprint2
- Sprint1 recap
- Sprint2 Refactoring and Code Analysis
- Strategy and State Design Patterns
- Lecture 18 (W): Code Reviews
- Code Review demo in VS 2012 / TFS
- Formal Code Review meetings
- Groups, please consider submitting some of your code 3-4 classes for a class-wide review. It could be your best or your worst and we can talk about design decisions, security, etc.
- Code Reviews essential?
- I would add that it helps the team to know the various parts of the system better.
- Refactoring support in VS 2012.
- Forgot to demo Code Metrics in VS 2012, so will try to do that as well.
- Random Blog
- Lecture 19 (F): Code Smells and Refactoring continued
- Additional Code Smells
- Purists vs. Pragmatists
- Should we define Wiki smells?
- Technical Debt
- What is Refactoring?
- Why Refactor:
- Refactoring improves the design of software
- without refactoring, a design will "decay" as people make changes to a software system
- Refactoring makes software easier to understand
- because structure is improved, duplicated code is eliminated, etc.
- Refactoring helps you find bugs
- Refactoring promotes a deep understanding of the code at hand, and this understanding aids the programmer in finding bugs and anticipating potential bugs
- Refactoring helps you program faster
- because a good design enables progress
- CSE 2221 Example (RSS feed) (open with Programmer's Notepad)
- Initial Java
- Refactoring 1 (extract methods for long method)
- Refactoring 2 (remove duplicate code)
- Class discussions
- Lecture 20 (M): Out sick
- Lecture 20 (W): Sprint 2 and Sprint3
- Lecture 22 (F): Debugging in VS 2012
- Lecture 23 (M): Automating the Build Process with TFS
- Sprint3 status
- Use of the name Object
- Building in the cloud
- Collision Frameworks
- Lecture 24 (W): Switching to MonoGame (maybe?)
- Lecture 25 (F): More Design Patterns
- OO concept survey
- Observer design pattern
- Decorator design pattern
- Interfaces re dux
- Crawfis Collections
- Read the following patterns in the Head First Design Patterns book:
- Strategy
- State
- Observer
- Decorator
- Adaptor
- Facade
- Template Method
- You should have read (and understood) the first 10 chapters in this book by now, plus some of the Appendix.
- Reinforce your understanding using the following resources:
- Lecture 26 (M): Midterm review
- Survey results and discussion
- Midterm review
- Use Cases / tasks
- Tenants of source code control
- Design Patterns
- Code Smells
- Agile methodology
- Code Metrics
- Cohesion and Coupling
- Application of all of the above.
- Lecture 27 (W): Sprint3 and Sprint4
- Lecture 28 (F): Midterm review
- Lecture 29 (M): Midterm
- Lecture 30 (W): Unit Testing
- Sprint 4 specifications - Note: there are two due dates.
- Unit Testing - What it is and what it is not.
- There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.- C.A.R. Hoare
- Detestable (adjective): software that isn't testable. (Martin Fowler?)
- Testing Jargon
- MSDN video tutorial
- MSDN tutorials on Testing
- Manual Tests
- Automated Unit Testing
- UI Testing
- MSDN Practices and Patterns
- VS 2012 support - Note that Private Accessors have been deprecated (see below).
- Unit Testing Internal or Private methods
- There are some suggestions here, but pretty advanced.
- Here is an article on (not) testing private methods - I totally disagree and would state that if TDD is going to force you to have methods public, then do not use TDD.
- So, you will need to try to test internals and private through public API's.
- So, what should be made public for a desktop application? - It doesn't matter, make all classes public.
- What should be made public for a shared dll (class library)? - As little as possible: All interfaces and any factories needed to create concrete instances.
November
- Lecture 31 (F): No class
- Lecture 32 (M): Team Meetings
- Burndown Chart for Sprint4 due
- Code Review for Juggernauts
- Code Review for Excaliber
- Lecture 33 (W): Team Meetings
- Midterms handed back
- Code Review for InfiniteLoop
- Code Review for Goomba
- Lecture 34 (F): Team Meetings
- Code Review for J#.Nate
- Code Review for Luigi Bros.
- (M) Veterans Day
- Lecture 35 (W): Team Meetings
- Code Review for Juggernauts
- Code Review for Excaliber
- Lecture 36 (F): Team Meetings
- Lecture 37 (M): Sprint 4 due
- (W) Thanksgiving break
- (F) Thanksgiving break
- Lecture 38 (M): Data driven applications (also called Table-Driven or Metadata-Driven)
- Lecture 39 (W): Plug-in applications
- Lecture 40 (F): Final exam review
- Lecture (M): Last Lecture
- Sprint 5 due
- Sprint 5 Demos and play testing.
- Pizza
- Final Exam: December 10, 2012 from 4:00-6:00pm
![[cartoon: Father bug talking to son]](http://www.robelle.com/smugbook/bug.gif)
