CS 460: Software Engineering

Instructor:

Joe Michael Kniss
Ferris 301G
277-2967
jmk (at) cs.unm.edu
Office Hours: MWF 11am-12:30pm

Info:

Official class web page:
www.cs.unm.edu/~jmk/cs460

Class Blog:
unm-cs460.blogspot.com

Text:

Bruegge and Dutoit. Object-Oriented Software Engineering Using UML, Patters, and Java. Prentice Hall. ISBN 0-13-0471100

Also good reading (but not required)

Frederick Brooks, Mythical Man-Month, Essays on Software Engineering , Addison Wesley Professional, ISBN 0201835959

Edward Yourdon, Death March , Prentice Hall, ISBN 013143635X

Recommended Design Books

Gamma, Helm, Johnson, and Vlissides, Design Patterns , Elements of Reusable Object-Oriented Software, Addison Wesley, ISBN-13: 978-0201633610. (AKA: Gang of four book)

Scott Meyers, Effective C++, Addison Wesley, ISBN-13:978-0-321-33487-9.

Scott Meyers, More Effective C++, Addison Wesley, ISBN-13:978-0-201-63371-9.

Josh Bloch, Effective Java, Prentice Hall, ISBN-13:978-0201310054.

Andrei Alexandrescu, Modern C++ Design, Addison Wesley, ISBN-13:978-0201704310. (Primer for Generic Programming Methods)

Course Objectives:

This course will cover the software development process from a top-down point of view. Students will gain experience in project development beginning with concept proposal, specification, implementation, and maintenance in a team setting.

Grading:

In-class participation: 15%
Midterm & Final exam: 15%
Individual assignments: 20%
Group Project: 50%

Policies:

This is an upper-division class. Students are expected to conduct themselves as adults and professionals. Because this class involves extensive group work, students must keep up and support their team.

Attendance   Attendance is the responsibility of the student. I will not be taking role. However, since a substantial proportion of this class involves group interaction, participation in class will factor into the final grade.

Cheating   Cheating will not be tolerated! This includes copying homeworks, plagiarism, sharing information during tests, and "free-riding" in the group project. A first offense will result in a 0 for the assignment/test. Repeat offenses will result in an "F" for the class and potential University action.

Group Work The bulk of this class will involve a team project. There will be instances of personality conflicts and interpersonal tension. Part of the experience will be developing skills to deal with these issues in a professional manner. Students should attempt to resolve conflicts within the group before involving the instructor. Failure to do so can affect both the individual grades of those involved as well as the overall group grade.

Individual Work All students are required to maintain a blog. One can be created at Blogger. This will serve as a journal of class and assignment activities. If you would like, the blog can be password protected so that only the instructor may see it. A substantial portion of your grade will be based on this blog. An "A" blog will have on average three entries per week, "B" two, and so on.

Schedule:

Business Consultation!!!

The Deliverables:

• Project and Docs (Delivered as a team)
  Rationale: These deliverables show that you understand the important aspects of software development and design. They will be used to compute your group grade, and offer you insight w.r.t. how well the team applied a design process. If you were diligent in tracking development, documenting your code, etc... this part should be a simple matter of organizing your wiki and packaging your output. If you "slacked", you might find that there are significant holes in your deliverables. Remember always: It is obvious if you payed attention to detail.
  
  Deliver:
  1. Working demonstration of project and source.
  2. User documentation. Be sure this is appropriate for your target users.
  3. Developer documentation. Include: source/API documentation, development process summary, coding standards, identify common and unique {design patterns, data structures, algorithms} used, and highlight {unfinished, unstable, or untested} functionality.
  4. Requirements/User Stories/Use Cases/Tasks, finished and remaining (future features too). Be sure traceability is maintained: e.g. IDs, dates, origin, developer, test/acceptance criteria.
  5. A polished 10min presentation for NM Angels (given on May 13).
  6. Evaluation (see below)
  
  
• Self Evaluation (Delivered by individuals via email to professor)
  Rationale: Self evaluations serve two important roles in your professional life: 1) They allow you to assess your contributions, strengths and weaknesses, and ideally serve as a tool to help you continue progressing as engineers/scientists/professionals. 2) They document your performance for others. Self evaluations should make it obvious to (for example) your boss that you not only should retain your job, but deserve a raise! Did I mention that evidence is king? A good self evaluation is terse; summarizing (hopefully quantitatively) performance in key areas (which vary depending on your position/project/field). Even if you are not explicitly asked to rate your performance (e.g."I demonstrated excellence in [area of evaluation here]" or "My performance in [area of eval] is an area that needs improvement."), don't miss an opportunity to give those evaluating you a good reason to respect your objectivity and recognize your achievement. Back up everything with evidence, make it easy to verify.
  Mid-term Evaluations are used by the instructor (and often bosses/organizations) to establish a baseline and measure your "delta" (improvement) throughout the course. Here is how they were graded initially: 1) Was it on-time (A) or early (A+), this criteria mattered most! 2) did it contain (and to what degree) the evaluation criteria we (as a class) developed? 3) Did it cover "Areas for improvement"? (I am challenging you to "self-eval" your self eval: In on time? Did you cover our criteria, did you even record what they were? Were you objective about your weaknesses?) The "Areas for improvement" will be looked at again when evaluating your final grade... did you pay any attention and make improvements? The most common issues with individual evals: 1) Easy to read and assess? Was it well organized and to the point? Places that required justification or extra prose caught my attention. 2) Did it offer an assessment of your performance in each area? Did you compute your own grade? (you should have!) 3) Did you back-up your statements (evidence), or "justify" them with prose (excuses, vague/unverifiable/general statements)? Thank you, and congratulations to those of you who demanded feedback on the midterm evals!
  
  Criteria for Self Evaluation Ideally, each point below should be a sub-heading with assessments for each (sub-item) and a quantitative summary of the point (based on concrete evidence). You are still free to determine the structure your self evaluation, make it organized and easy for the Instructor to assess. The (sub-items) are suggested assessment items, not necessarily a comprehensive list! (NOTE: "suggested but not necessarily comprehensive" means that I may not have thought of everything that matters, NOT pick whatever you like...)
  Note If you are writing paragraphs, you are probably doing it "wrong". State {what,how-much} you {contributed,understood,improved} for each item, rate how well you did it, and reference the appropriate {documents,code,summaries} that demonstrate each item. Each sub-heading should summarize the itemized scores (think weighted-average).
  
  
  • Design (Comprehension of Principles & Process, adherence/discipline from Concept to Completion)
  • Testing (Unit and System, application of test-first development)
  • Writing (consider your proposal, first self eval, blog, and contributions to project docs)
  • Speaking (consider project pitch, participation in meetings, presentation and/or your roll in developing the presentation & training the speaker)
  • Professional Development this semester and going forward. (Consider: Self directed? Iterate solutions? Responsible? Resourceful? Dynamic? Areas needing Improvement?)
    Question: "what do you mean by: Iterate Solutions?" Answer: Were you willing to tear down and redo modules/code/algorithms to improve the project? For example, many groups did "spikes" to understand a problem or debug a tricky module; this is a good example of iteration! Many of you had to rethink your target language, iterate on user-interface and aesthetics, etc...
  • Skill (Programing, Tools and APIs, Abstract/Reusable code)
  • Contributions and Achievements (obviously!!)
• Group Evaluation (Include your evaluation of the group in your personal Self Eval, AND prepare a Group Eval as a team)
  • Attendance (of individuals, and ability to coordinate as a team)
  • Division of Labor (roles, contributions, quality, timeliness)
  • Meeting performance (preparation, quality, topicality, timely, etc..)
    Question: "Is that with you {prof,hats} or with each other?" Answer: Yes, both! Did you meet with anybody else? What did you capture about these meetings (agendas, notes, minutes, attendees)? If the meetings went well, what exactly were the outcomes? ...We worked hard to make our meetings meaningful and productive, you should have a bounty of evidence here.
  • Professionalism (of individuals and team)
  • Communication (within the team, with the "hats", with the world)
  • Design, Development, Testing, and Tracking of project.
  
  
• Evidence
  As you cover the criteria above, remember that evidence is king. Point me at specific documents, blog entries, code, etc... to prove your point. You might also consider computing or deriving quantitative metrics (I wrote 30% of the code that gets used, modified 1000 lines of code, and 2000 lines of documentation,...). Be sure to identify how you computed these statistics so that one might reproduce those figures. Linking to external sources (your blog, team wiki) is encouraged. If you feel that the evaluation is getting too long, summarize and attach the details/evidence/links as an appendix. If you have questions, ASK!
  
  StatSvn provides a lot of valuable information on contributions, overlap, work behaviors. I highly recommend you utilize this tool.
  
  I recommend that, as a group, you consider developing scripts or researching tools that automatically compute the quantitative metrics you need for the self and group evaluations... How would a computer science professional attack this problem?
  
  
• Based on the deliverables above, what grade do you deserve?
  
  
• Frequently Asked Questions:
  • Why did you return my eval saying "prove it"???
    That is a very common question. Here's the reply you probably got: "I *will verify* all of these criteria and happily consider any additional criteria you identify when I compute your grade. The consequence of this is: 1) if you don't tell me how to assess your measure of yourself then I will do my best, so it's in your interest to make sure I don't miss a contribution. 2) if you make me hunt and peck for the evidence of your performance it could take hours to pull together (much longer than it will for you because I don't have access to your brain!); making me unhappy since I've been telling the class "EVIDENCE" for weeks, thus you unwittingly provide "evidence" that you did not follow the guidelines for this assignment."
    
    
  • How should I structure the evaluation?
    Keep it simple, organized, and to the point. Structure helps, long paragraphs make it hard to quantify your performance AND take too long to write.
    Here is an exsample, as I would structure it, with (notes in parens):

        1.0 Class Requirements and Guidelines  ( <-- this is a sub-section, bold)
          Score: A+ ( <-- this is the score based on items below)
    
          1.1 Followed guidelines for personal blog: Demonstrated excellent progress throughout the course.
              [Blog can be viewed at http://yourclassblog.com].   ( <-- EVIDENCE!! )
              Requirement: 3 entries/week. Achievement: 3 entries/week. TotalEntries: 54. ( <-- sumarize when you can ) 
              Score: A+  ( <--- score this item)
          1.2 ... 
          (the rest of the course requirements should enumerated, rated, and referenced)
          
        2.0 Design
         Score: 9/10 ( <-- Note use of numerical score, Prof will convert to numbers anyay... )
    
         2.1 Comprehension of Principles and Process:  ( <-- This item was further broken down, easy to read! )
                Captured detailed notes on "design principles" [blogentry1,..]  ( <-- EVIDENCE, notes on design ) 
                Investigated and documented the "XP process" [blogentry2, wikientry1, ...] ( <-- EV, notes on process )
               Score: 10/10  
         2.2 Discipline: As team leader I enforced and applied the design process regularly, 
                details of this can be seen in [wiki-group-notes1,...] ( <-- EV, showing process was applied throughout)
               Score: 8/10
         (Any other design criteria that you excelled at? ADD THEM! A++)
           

    Item 1.0, you might notice, is not listed in the "Criteria for Self Evaluation" above. However: 1) you can tailor the eval if it makes sense to do so, 2) it sure does make sense to demonstrate that you covered the grading criteria on the original syllabus!
    Remember: This evaluation should really be a "matter of fact", and not require too much time. Put together a straight-forward outline, and then assess yourself. Note that most blogs and wikis have a "search feature", how handy? I have only recieved a few advance evals, the only real problem I see is individuals (so far...) making this harder than it needs to be. You should try to write as little as possible, you already captured this stuff! (...ideally) A good eval makes it nearly impossible to refute (challenge) your performance, "Just look at the evidence." If you do need to explain something, make it very easy to understand your point. "Less is more."
    
    
  • Oh no! We didn't do test first, what should I say?
    Allow me to answer your question with a question, or two.. Can you think of something to say about "test-first development?" In what way was your development guided by constraints/criteria/data that you knew about in advance? You might need to think about this (my apologies)... You may not have explicitly done test first, but I know there were aspects of development that you had the acceptance criteria (concretely, in detail) before hand, and you knew the code worked because it passed/worked with the criteria... Give me something here people! This seems to be the sticky point with just about everyone. Did you write something against a published spec? (this is the test criteria) Did you have to make it work with existing data? (your code passed when it worked with the test data) I know, I know, it's hard to believe, you didn't/don't realize that you do this very important development process often... When you think about what it was that qualified, think about how easy/hard it was to complete the module... Seems almost trivial when you know the test in advance... yes/no? Remember the good old days of CS351? You knew your grade based on how well your code passed the spec, the tests were well defined. I will hand your self eval right back if you "punt" on this one: Either think and show this in your work OR show double evidence that you did not or could not do test-first. That's an exclusive-or.
    
    
  • How should the Deliverables be delivered?
    A package for the group deliverables is best. A tar ball, zipped folder, the ilk. Make sure it hangs together (stands on its own, with no need for volatile external dependencies). It's a terrific archive for you too. Don't email me a giant file, put it somewhere *safe* that I can get to.
    Note your self eval should be emailed to the Prof.
  • Is pointing at the wiki for documentation enough?
    See the previous answer on group deliverables... Note, a good wiki should have a "booking" mechanism, i.e. some easy way to produce a "stand-alone" document. Either way, I need an archival (non-volatile) copy of your output.
  • Is linking to the wiki enough for evidence?
    • Point (link) where appropriate, but if anything is *derived* I need to be able to reproduce it.
    • A common problem is lack of specificity; if you are providing evidence for something, don't show me a giant list of "stuff", point me at something that is "necessary and sufficient" to prove your point (not too much, just enough). I'll not be happy if I have to dig through a huge file or list of unrelated things to find the one thing you meant to show.
    • The appendix can be long, so you would be *safer* to copy evidence there, rather than hope things stay completely static till I get grades done.
    • If you have LOTS of evidence, say for Iterate Solutions, it would be nice to show how one function/module changed over time ([rev1] [revN] [diff]), include the commands that reproduce this illustration of iteration, and then reference the other functions/modules (I can easily verify the rest from here).
    • Summary Don't over do it but be specific.
  • An appendix will be part of the group eval? or separate and pertaining to the whole archive?
    You should have an appendix with your self eval AND an appendix with your group's eval. An appendix documents things specific to the eval it is attached to. Think of it like the References section of a technical document.