[Dedicated to the memory of Professor Phil Dorin, teacher, mentor and friend.]
From the online version of the LMU Bulletin:
Analysis, design, implementation, and presentation of a large-scale, individual project, demonstrating mastery of the computer science curriculum
|What this really means is, students will individually propose,
architect, design, build, and present a software project that is original, non-trivial, and
which makes full use of all topics encountered during their academic computer science career
at LMU. This list includes, but is not limited to:
In this course, the student will propose, design, construct, and present an entirely original non-trivial software project that demonstrates mastery of the various topics learned during the previous semester in CMSI 401. The idea of this course is to show you can successfully conceive of, design, implement, document, and present a medium-size software application; a further goal is to expose you to the concepts of the software engineering discipline, by class lecture and by actually doing.
Computer games are frequently presented, but they are by no means the only project ideas. Further, for
the last couple of years, this
individual senior project class has been expanded to allow students
to continue their group project development if desired, and beginning this year  the class also
introduces an aspect of combining multi-disciplines, with several CS project teams working with Electrical
and Mechanical Engineering majors to produce their resulting applications. Finally, for the last several
years, the course has also been involved with the Entrepreneurship program at LMU, to produce viable
products that can be taken to the market place; this expansion has even spawned several start-up companies.
Another goal of this course is to expose the students to two different software development methodologies, the Agile Method and the Capability Maturity Model, Integration®. Since both of these disciplines are currently used in industry, it is important for the student to have the experience of both philosophies. Either method (or perhaps one of several other methodologies) will be used for project development in this class.
A further goal of this laboratory course is to learn more about software project management. This topic includes being able to estimate such things as the amount of time a project will require for the various phases of its development, and the related cost associated with this time requirement.
You should produce a project which:
This course is open to Seniors in Computer Science who are preparing to graduate from LMU and have completed the CMSI 401 Software Engineering Laboratory course. The scale of the semester project, and the individual nature of its development, require all students to put forth significant effort. The overall learning outcome is five-fold:
What You'll Need for Success . . .
All students must:
Part of the class is for each student to make several oral presentations of a professional nature, including a slide show which is to be constructed with some sort of presentation software [such as Open Office Impress, Google Docs, Prezi, or even gasp Powerpoint].
|It is highly recommended that you have a good grasp of fundamentals of the concepts and implementing technologies required/applied for your project, in order to have the greatest chance of completing the design successfully. In other words, don't attempt to do a project using Apache if you don't know anything about Apache, or PSP if you don't know the language. This is a question of proper project "scope". I will work with you to try to ensure you don't over-reach (or under-reach) yourself by attempting a project which is too much (or too little) to complete in one semester.|
When You Finish This Course [Course Goals]. . .
At the successful completion of this course, students will:
There are three textbooks for this course. The first is required, and the others are recommended. Prices shown are as of when I last went and looked them up:
The Stephens book provides details that are useful for an object-oriented approach to software project development. It is structured in two parts; the first section describes the basic tasks you need to deliver software which is useful, fully functional, and provides user value. It covers the details of requirements, design, architecture, integration, testing, verification/validation, and close-out. Note, however, that although there is a focus on object oriented development, there is NOT a bias toward any particular software life cycle or development methodology. The second part of the book presents details and differences between several of the most widely-used software development life cycle models. Since we have focused on a lot of the first part during last semester's class, we will spend SOME time on section one, including required readings and homework assignments, with some classroom discussions of the material in these chapters, and possibly a quick quiz or two. It will be useful to you (and to your class participation grade) for you to do the reading. Further, all of the homework assignments made during the semester are selected problems from this book which apply to the software engineering discipline and which reinforce the concepts presented during class.
The UML book, although it is not required, is very useful for understanding and presenting design issues which are covered as part of your project. All student presentations will include detailed design diagrams which are expected to be in UML format. You will know how to design in UML when this course is over! Ve vill beat it into you! …and you vill enjoy it!
Finally, the Head First book, also not required, is a very down-to-earth explanation of all things Agile, including topics such as planning poker, sprints/iterations, burn-down graphs, and velocity. It also makes a very good desk reference for your careers later. And yes, this is the same book you used in CMSI 401 last semester.
Also Recommended . . .
There is a FREAKIN' HUGE number of books, papers, dissertations, monographs, and other types of publications covering issues related to the topics of software development and project management. Some are a bit dated by 2015 standards, but are still here because many of the concepts they present are still relevant. Here are several that are considered beneficial in no particular order:
A number of good web sites provide helpful information on the topics which are presented in the course. These are listed below (and are links when viewing this information on-line). Also, check out the Bibliography Page of this web for more information.
pair programmingeffectively. Also has good information about writing module tests from software specifications/requirements. Says to write the tests first, then write the code.
disciplinestuff. Over time this has become equated with
CMMI, a five-level system of software development processes. Most large corporations are now required to be at
CMMI level 3certification (or above) to even be considered for any software contracts. Government stuff frequently must be at level 5! Also note that CMMI does not necessarily mean that you can't do Agile development or TDD. They are not mutually exclusive…
Your final grade for the course will be weighted as shown in the following table. Note that the total project grade, which is itself a sum of parts, constitutes 80% of the total grade points available.
|Total Project Grade||80%|
|Project Poster Grade||5%|
|Homework and other assignments||10%|
Your final grade for the project itself will be weighted by deliverable sections as follows:
|Project Proposal Document/Presentation||5%|
|Requirements Specification Document||20%|
|Software/Database Design Description |
Software Development Plan Document
|Oral and Written Status Reports||10%|
|Design Review Presentation||15%|
|Final Product Delivery and Presentation||30%|
Final letter grades will be assigned based on the following scale:
|Percent||Letter||Rating and Achievement|
|91 - 100%||A- / A||Professional work, outstanding effort; hairy-chested, steely-eyed, killer engineer|
|81 - 90%||B- / B / B+||Above-average work; shows extra effort and interest|
|71 - 80%||C- / C / C+||Satisfactory entry-level work; expected with reasonable effort|
|61 - 70%||D||Substandard work; minimal effort shown|
|60 or less||F||Thank you for playing; see you next semester|
Class participation evaluations will be assigned based on the following (somewhat subjective) scale:
|Class Participation Criteria||Value|
|Absent without prior notification/agreement of professor||0|
|Present, demonstrates minimal preparation.|
Knows basic reading facts, but does not show evidence of trying to interpret or analyze them; demonstrates little/sporadic class involvement.
Also includes absent with prior notification/agreement of professor
Basically, you're in the chair, the points are there
|Demonstrates excellent preparation to readings and other material.|
Offers analysis, synthesis, and evaluation; puts together pieces of the discussion to develop new approaches that take the class further.
Poster evaluations are basically a trinary assignment. If you turn one in as required, you will get the 5%; if you don't, you'll get 0%. The exception is if you turn in a poster that has spelling or grammar errors, and you fail to make any of the specified corrections before it is presented. Points will be deducted, since these are intended to be displayed on the hallowed walls of Doolan and are intended to mimic what you will do when you are out in the job world and present posters at conferences. Thus, evaluations will be assigned based on the following criteria:
|Poster Criterion||Value Assigned|
|No poster submitted||0%|
|Poster submitted, but contains spelling/grammar errors||3%|
|Poster submitted, and everything looks good||5%|
Note that for Spring 2019 the poster is not optional, since the final presentations will be done as a poster session. You will need to have a poster to display and talk to during the presentations, so that you'll have a visual to stand next to.
An incomplete will be granted only when the student requesting the incomplete has completed at least 80% of the coursework, and has at least a B average in the course work completed. This is LMU policy, not mine!
All work is evaluated for both technical merit and quality of written and/or oral presentation.
Written reports with multiple spelling errors and/or grammatical errors will likely be given back
ungraded. Remember this course fulfills your
requirement and act accordingly. Find yourself a good spelling and grammar checker, or a trusted
human editor, if you have difficulty with the rules of standard English language usage. Another
excellent resource is the Learning Resources
Center, located on the south side of Daum Hall. The center takes appointments, and also
allows drop-in consultation sessions, and they have a number of good benefits. Call (310) 338-2847
to schedule an appointment. (For those that don't know, Daum Hall is the building where the LMU
Security and Parking office used to be. LRC is on the other side of the building from that.)
FAIR WARNING!!! FAIR WARNING!!! FAIR WARNING!!! FAIR WARNING!!!
In this class, documentation which is *not* of professional quality is no longer acceptable. Spelling, grammar, and internal document consistency all count and will cost you big-time if not correct! I will not hesitate to knock off a full letter grade on an otherwise perfect assignment or deliverable if there are spelling or grammar errors, or if the font or style is inconsistent between sections of your documentation.
There are a number of English Grammar mistakes which are commonly made; you should know the
difference between such things as
there. Mis-uses of this type will count points off on your
written assignments. BE AWARE that spelling checkers frequently miss this type
of error, and sometimes grammar checkers do as well – READ THROUGH YOUR WORK CAREFULLY, then
RE-READ IT AGAIN to make sure there are no errors of this type! Check the
Grammar Hints and
Helpers page from the
Class Pages pull down menu for more insight and information.
In addition, coding style will play a large part in determining the grade on the code for the project. It is inherent on the student to properly structure, comment, and indent, to select proper names for variables, and to not "hard-code" values (no magic numbers). Further, it is YOUR RESPONSIBILITY to check your code into your repository (GIT or something else) on a regular basis. I need to see your progress during the semester. Waiting until the last week of the semester and then only checking all your code in at the end will cost you a letter grade for your project.
Last but CERTAINLY not least, PUT SOMETHING MEANINGFUL IN A README.MD FILE IN YOUR PROJECT REPO! Remember that this file shows up on the main page of the repo, so have something GOOD in there to show off at interviews and for people who randomly find your repo for your project using Internet searches. DO YOURSELF PROUD and do a good job on this.
FAIR WARNING!!! FAIR WARNING!!! FAIR WARNING!!! FAIR WARNING!!!
indivitualprojects. Some of you are continuing with your group 401 projects from the Fall, and some of you are working on collaborative projects with other departments. To facilitate these situations, there will be some flexibility in the documentation requirements. I will try, wherever possible, to balance an appropriate amount of documentation to meet the needs of the
writing flagcomponent for the course WITHOUT having you do needless duplicitous work for which there is no added value. The requirements presented here are based on the more traditional approach to having and documenting an
Software Development Documentation . . .
When you get out into the work world, you will (often) find yourself producing documentation. Such is life – however, the Software Engineering Institute (SEI) has a standardized set of documents which you'll use parts of to make a 'notebook' of design documents. [Update note: The SEI has moved the CMMI products, services, and descriptions to a a new website. There are also lots of CMMI-related links and training materials on the original site.]
|In the past, the documentation was kept in an actual physical
notebook, called, by turns, the
Software Development Folder, the
Software Development Notebook, or sometimes the
Development Library. In the modern development environment, all that stuff is kept on line. Softcopies are encouraged, and are much easier (and less expensive!) to update and keep current to accurately reflect the project state. Thus, in keeping with more modern practices, this semester you may elect to keep your documentation on line in a
soft copyformat. The one caveat to this is it must be accessible to the instructor for grading and commenting purposes (no duh!).
However you decide to keep your information, it is collected periodically during the semester to check project progress (this is part of the
deliverablesystem). It is handed back at the following week's class meeting for hard copy, or notification will be provided at the completion of grading for soft copy. Notebook content and formatting, along with a handy template for the table of contents, is provided on the course documents page for your convenience.
You are expected to use some sort of word processing software or on-line tool to create your project
documentation. Any tool you like, or with which you are familiar, is fine. The use of LaTeX is often
recommended if you are producing hard-copy documents, since it is an industry and academic standard;
however, you are free to use whatever application you like for this purpose. Note: You must follow
numbered outline format for all documents, wherever it is possible to do so. This
format will be explained in class.
You will need to keep your project in a configuration managed repository. Usually here at LMU, that means using Github. Make sure that your git is accessible to the instructor so that it can be graded. Also, don't wait until the last week or two of class to check in your code; doing so will cause a lower grade, since the code is expected to be visible all during the semester to observe the development of your project. Finally, either make your project public, or add the instructor to it as a contributor, so that it is visible!
Examinations and Assignments . . .
There is no mid-term exam and no final exam for this course; instead, the final project presentation serves the purpose of a final exam, and the deliverables replace tests during the semester. The final presentation is done (as I'm sure you all know) in front of as many faculty, alumni, and selected invitees from industry as can attend, as well as family and friends of the students. Grades for the course are assigned according to the weighting factors shown in the tables above. Additionally, other professors will be invited to all of the presentations, not just the final presentation, and will be welcome to provide questions and comments about your project designs and make suggestions to enhance your presentations.
There will be several written assignments from the text and other sources. Normally, textbook assignments are handed in (or made available) at the start of class on the due date. Deviation from this process requires prior consent of the instructor. "I left my homework at home" is no longer a valid reason for late work. You're grown-ups now, and can be responsible for remembering what you need to remember. Every effort is made to ensure assignments, required deliverables, and due dates are prominently posted on these pages; it is your responsibility to make sure you know what is due and when it is due.
You may turn assignments in late, but they will be reduced in grade by one letter for each
day they are late.
class day; an
A+ homework due on Thursday which is not turned in
until the following Tuesday will get a failing grade, unless prior arrangements are made.
Academic dishonesty will be treated as an extremely serious matter with severe consequences that can
range from receiving no credit for assignments/tests, failing the class, to expulsion. It is never
permissible to turn in any work that has not been authored by the student, such as work that has been
copied from another student or copied from a source (including the Internet) without properly
acknowledging the source. It is your responsibility to make sure that your work meets the standard
set forth in the
Academic Honesty Policy
Cheating on assignments, plagiarism, falsification of data, and other similar or related violations of LMU standards of honesty and integrity ARE NOT TOLERATED. Any student or students who commit such offences will receive a failing grade for that assignment, possibly a failing grade for the course, and conceivably further disciplinary action. It is acceptable to use code from textbooks, friends, coworkers, or other sources, as long as the source of the code is cited/acknowledged in all reports and source file headers.
This does not mean that collaboration is discouraged; in fact, the "pair programming" paradigm is encouraged. However, this does mean that exact duplicates of reviews and write-ups turned in by more than one student as individual work, or uncited copying from the Internet or any other source, will not be allowed. Such a situation will be dealt with in the manner outlined above. In short, if you are responsible for your own work, do your own work.
Repeat: failure to follow this simple guideline will result in a failing grade on that assignment, likely failing grade in the course, and quite possibly further disciplinary action.
Students with special needs who require reasonable modifications, special assistance, or accommodations in this course should promptly direct their request to the Disability Support Services (DSS) Office. Any student who currently has a documented disability (ADHD, Autism Spectrum Disorder, Learning, Physical, or Psychiatric) needing academic accommodations should contact the DSS Office (Daum Hall 2nd floor, 310-338-4216) as early in the semester as possible. All discussions will remain confidential. Please visit http://www.lmu.edu/dss for additional information.
As an LMU Lion, by the Lion's code, you are pledged to join the discourse of the academy with honesty of voice and integrity of scholarship and to show respect for staff, professors, and other students.
The following LMU documents are available to reference:
Disruptive Behavior, and/or intentionally or recklessly interfering with normal University life, activities, processes or University-sponsored activities including, but not limited to: studying; teaching; research; classroom instruction; campus or residential life; University administration; judicial proceedings; or fire, police or emergency services.[see the student policies website]
Disruptive behavior which is persistent or significantly interferes with classroom activities may be subject to disciplinary action. A student may be referred to the Office of Student Judicial Affairs if their behavior constitutes a violation of the conduct code.
For more information on this or any other conduct issues, please refer to the Student Codes and Policies page on the Student Affairs Division Home Page. The Lion's Code, Student Conduct Code, Honor Code and Process, and information on many other policies are available from that link.
Electronic Devices: Without being totalitarian about it, because I forget sometimes myself, but I would prefer that you turn off your cell phone ringer during class. Cell phone ring tones and text message tones can become disruptive. If you have a laptop, I don't mind if you want to IM with your friends or surf the Internet during class time, but be aware that will not be accepted as a valid excuse if you are called on and don't know what we're talking about – this could be a contributing factor for a low class participation grade for that day, but it's really up to you to decide. Just please keep the volume off so that you don't disturb others.
To report an emergency or suspicious activity, contact the LMU Department of Public Safety by phone (x222 or 310-338-2893) or at the nearest emergency call box. In the event of an evacuation, follow the evacuation signage throughout the building to the designated safe refuge area where you will receive further instruction from Public Safety or a Building Captain. For more safety information and preparedness tips, visit http://www.lmu.edu/emergency.
I have office hours on Mondays and Wednesdays from noon to 4 PM, and on Tuesdays and Thursdays from 4:15 to 6:15 PM. That's 1200 to 1600 and 1615 to 1815 in 24-hour time format. Also, if my door is open, you are welcome to stop in without an appointment. I use the appointment system to make sure that if someone wants/needs one-on-one time, it is available.
In addition, you can set up appointments at my You Can Book Me site. Just visit the page and click on any available slot (which isn't lined out), Then enter your information in the window fields. We will both get a confirmation e-mail, which is my notification that you'll be coming in. Easy, huh!? NOTE: be sure to enter YOUR e-mail address in the place provided, NOT MY e-mail address. The tool notifies me automatically, but YOU won't get a notification unless you enter *YOUR* e-mail address. OK? OK…
I'm also on slack in both the LMUCS and LMU CS TAs workspaces.
I am also always available by e-mail at either of the following addresses:
I check email at both these addresses at least twice a day, usually three times a day. In addition I am frequently on line for G-mail IM sessions after 8:30, PM at the above address..
YOU SHOULD CHECK YOUR LION EMAIL ADDRESS OF RECORD. I will start by sending all
email blasts to everyone's
lion.lmu.edu email addresses. If you specifically provide
me with a preferred alternative email to use I will be happy to oblige. I create a distribution list
to which I send all general communications, so it is important for me to have an email address
which you will check on a regular basis.