Information Technology Projects
Spring 2005

Introduction

Description

Information Technology Projects (Projects) offers students real-world experience understanding and solving information technology software and system problems. The course involves a set of projects at clients such as local corporations and other institutions. We organize students in teams of about four. Each team undertakes one IT project that lasts the semester.
In the classroom we study IT project management and software engineering. The project issues addressed include requirements gathering, project specification, consulting project management, technology planning and training, task allocation, effort estimation and communicating to management. The software engineering issues include the software maturity model, the software life cycle, choosing development models, software standardization, and technology trends.

Course Particulars

Course home page: www.cs.nyu.edu/artg/itp/Spring2005/index.html
Update history in 2005:  1/18, 1/21
Time: Most Thursdays, 5:00 to 8:00 PM (with advanced notice you may leave for a 7 PM class), plus about 8 hours per week interning for your client
Place: WWH 402
Number: G22.3812-001
Email beacon: G22_3812_001_sp05@cs.nyu.edu
Credits: 3

Professor Particulars

Professor: Arthur Goldberg
Email: artg <at> cs.nyu.edu
Office: WWH, 251 Mercer St., Room 409
Home page: www.cs.nyu.edu/artg
Office hours:  3 PM to 4 PM on Tuesdays and Thursdays or by appointment--please schedule by email

Projects

Introduction

We recruit local corporations and other institutions to provide interesting projects. We will select projects that teach students about technologically important systems. We seek problems that involve widely used technologies of growing influence. These technologies include the Internet, the World Wide Web, Intranets, Java, and databases. We will consider projects involving other important technical areas of mutual interest to students and clients. To increase the resources available to students, we also try to obtain projects that use technologies that are available in our campus computing environment.
We seek projects early in their development, so student can experience the full software project life cycle.
We divide the course into two sections, 1) requirements gathering and analysis, and 2) prototype implementation and documentation.  Prof. Goldberg and the team meets with the client at the beginning of the project, after the analysis phase, and at the end of the project.  During the requirements gathering and analysis phase each team studies the client's business goals for our project and selects an appropriate software and hardware strategy for efficiently meeting the goals.  In the transition meeting the team presents their findings and a plan and schedule for prototyping the best design.  During the prototype implementation and documentation phase team members build a prototype that they can present at the demo show at the end of the semester.

Clients for Spring 2005

Bank of America
Citigroup
Morgan Stanley
New York Academy of Medicine

Client Role

In exchange for our assistance, clients provide adequate resources for students to learn and to succeed on the project. Typically, the provides facilities, such as computers, software and office space for students to make significant progress during the course. Sometimes, NYU provides such resources. A client technical project manager will spend about one half a day a week supervising students. Interactions with clients may provide opportunities for full-time employment following the course. Many students have obtained jobs during the last 6 years. Some clients will be paying significant money to NYU in recognition of the accomplishments we achieve in the course.

Team Composition

Students will participate in teams composed of CS and "MS in IS" students. At the first class meeting each student will rank each proposed project's desirability on a scale from 1 to 10. Prof. Goldberg will assign students to teams by the second class. He will try to maximize the class's total satisfaction, assign students to projects for which they're skilled, and allocate students to each team. Each expertise and talent will support the other, so CS students with relatively modest management and/or English experience can feel comfortable, as should MS in IS students with less technical experience.
Sometimes we or a client breaks a project into 2 person tasks so team members can progress fairly independently.

Student Admission

In the Spring of 2005, the Projects course can accommodate 16 to 20 students in 4 to 5 projects. 

Skills

To be productive on a project a student must possess sufficient technical and/or managerial skills. These skills can be obtained by academic training and/or experience.
As the set of skills cannot be precisely specified, interested students should contact Prof. Arthur Goldberg (artg <at> cs.nyu.edu) for permission to register. Email a resume or short biography.

Registration Logistics

Admitted students will be emailed a 4-digit access code. Register for the course as "Advanced Laboratory in Information Systems" (G22.3812). Stern-based MSIS students should follow through with their usual registration procedures for Courant courses; Courant-based students may call TorchTone (995-4747) and register.

Potential Conflict-of-Interest

Students who work must consider whether participating in a project--and interning for a Projects course client--will involve a conflict-of-interest with their employer. Prof. Goldberg has checked, and none of our clients consider it a conflict if a student intern works elsewhere, as long as the employer does not compete with the client. Students should obtain their employer's approval to intern, if they feel it is necessary.

Non-disclosure

At some clients, students will access proprietary information protected as trade secrets. Student interns at these clients may be asked to sign a legal document called a non-disclosure which promises that they will not communicate trade secrets learned at work outside the client. If you indicate interest in a particular project, we assume that you're willing to sign a non-disclosure for that client. Prof. Goldberg will sign the non-disclosure too. Students who work should obtain their employer's authorization to sign the non-disclosure, if they feel permission is necessary.

Schedule

Projects, like all graduate CS courses at NYU, demands significant effort. Doing a good job requires about 10 hours of participation a week; doing a great job probably requires more.

Weekly schedule

We meet as a class about 8 out of 14 weeks. The tentative semester schedule is below. Class attendance is mandatory, as class meetings include technical and operational lectures by both students and Prof. Goldberg.
Most clients are corporations which work "regular business hours". Projects involve coordination among students, and between students and the client. Students and clients are strongly urged to arrange a mutually convenient weekday on which students will meet and intern weekly at the client site. Some clients may work weekends and/or evenings, and may be able to schedule the regular meeting outside of business hours.

Students who are full-time employees

Some students who work full-time want to take Projects. They may do so.
Students unable to spend time at client sites during "regular business hours" should apply for projects whose regular meetings occur outside of business hours or at NYU. Prof. Goldberg will attempt to assign them accordingly. However, no student can be guaranteed assignment to a project that is scheduled outside regular business hours.
Resources for running special individual projects are not available.

Semester project schedule

To complete the projects during our 14 week semester, Projects is scheduled tightly. The Spring 2005 schedule follows:
By Jan. 19: Prospective clients submit project proposals. Proposals will be published on the course's web site to advertise the course to students.

Jan. 20: At the first class, students learn about the course and all available projects.  If the course has space for MSCS students, they are admitted on a first come first serve basis.

Jan. 24, noon: Students rank projects.  The projects which really excite the students get staffed. In past years, Prof. Goldberg has been able to assign 95% of students to projects that they rank 9 or 10 out of 10.  A copy of the sheet is at http://www.cs.nyu.edu/artg/itp/Spring2005/ranking.html

Jan. 20: Students assigned to projects by Prof. Goldberg.  Students notified by email.  Staffed and un-staffed clients are notified.

Jan. 20 to 24:  Liaisons schedule 3 hour kickoff meetings at clients.  One student, designated the liaison, is responsible for scheduling the kickoff meeting and for scheduling a mutually convenient weekly time at which the client's project manager(s) and the student team can meet and intern together at the client's site. The meeting should be scheduled as early as possible.

Jan. 20 to Feb. 1:  We hold a 3 hour kickoff meeting at each client. The student team and Prof. Goldberg meet the client's authorizing and project manager(s), and any other members of the client's team who wish to participate.  The client explains the set of projects we will pursue in much greater detail than the proposal. Together, we select a mutually satisfactory subset of projects to pursue.  Each student leaves with the beginnings of a clear understanding of the project they will intern on.  Prof. Goldberg assigns each student a software topic to talk about at their technical lecture.

Project interning: Kickoff meeting through May 5: Each team interns for about 12 weeks with their client. Students meet weekly with their project manager. Prof. Goldberg supervises and teaches the class at a weekly meeting at NYU. We study software engineering, technology, project management and presentation skills.

March 21 to 25: We hold a 3 hour transition meeting at which we transition from an analysis and planning phase to a prototyping phase at each client.  The student team and Prof. Goldberg meet with the client's project manager(s). We evaluate the project's progress and set clear goals for the rest of the work. Students present a Project Plan. Example plans will be made available by Professor Goldberg.

May 5, 5 to 8 PM: At our "DemoShow" at NYU all teams present their results to all clients, interested faculty and other students.

May 6 to May 12: At a 2 hour wrap-up meeting at the end of the semester the team and Prof. Goldberg meet with the client's authorizing and project manager(s) at the client. Students present their results and hand-off their results to clients.

Class Meeting Schedule


Week

Date

Topic / Reading

Description

1

Jan. 20

Information Technology Projects: Introduction and Logistics / Handouts

Course goals: Software project planning and execution: business analysis and requirements gathering; development planning and scheduling: software life-cycle.  Description of all projects and clients, review course description, handout student questionnaire and project selection form.  Course grading. 

2

Jan. 27

Project Analysis

Understanding and describing business objectives: tactical and strategic goals, ROI; collecting and analyzing requirements, good questions to ask, individual research; use case analysis; UML; GDD.
Progress reports, kickoff meeting goals, agenda and preparation. 
Team assignments, liaison responsibilities;  Teamwork and problem solving skills.

3

Feb. 3

No class: kickoff meeting week


4

Feb. 10

No class: kickoff meeting week


5

Feb. 17

Project Analysis Continued,  Transition meeting  preparation, Project Plan, Reqirements Gathering / RD, chap 10, 14, SPSG, Chap 7, 8  [photocopy provided]

Business requirements gathering, Features and specifications, Project management, Risk management 
What to do with requirements: managing expectations; 
Analysis to development transition meeting format and goals; review sample project plan and outline

6

Feb. 24

System architecture and design, progress report / CC2 Section 3.5 and Chapter 5; Individual preparation / CC2 Chapter 33
Teamwork / RD Chapter 12
Some thoughts on how to make presentations

Individual preparation: tuning technical skills; testing theories; risk-reward of guessing 
What makes a good architecture? Interface design, specification, definition and implementation; 
Present sample progress report; democratic programming teams

7

March 3

Student presentations: Project progress reports

Half of students, some from each team, discuss project progress. 
Professor: Project problem-solving; communications, understanding roles and skills.

8

March 10

TBD



March 17

No class: spring recess.


9

March 24

No class: transition meeting week


10

March 31

Large scale software engineering, changing organizations / Humphrey, Weinberg

CMM, Weinberg change model.

11

April 7

No class


12

April 14

Writing correct code - Reviewing Code / Gries, the science of programming; extreme programming doctrine, Weinberg, McConnell and Humphrey on code review, Capers Jones, example code

What is 'correct' code? Approaches to making code correct: 
Good design; avoiding bugs; invariants; correctness proofs; the individual psychology of programming--cognitive dissonance; testing: unit test, JUnit, extreme programming, demonstrate a code inspection

Software quality guidelines; inspection reviewer form

13

April 21

Student presentations: Code review

Student presentations.  Half of students, some from each team, review code.  (For code reviews, programmers distribute code and architecture and functionality overview to class by April 18.  Reviewers take home code and look for errors.  Reviewers return feedback error forms to Professor by April 20). 
Programmer presents code, team members and professor offer feedback.

14

April 28

DemoShow planning and preparation

Demoshow presentation: demo content, other communication tools: poster, handout; preparation and resource needs, invitees, presentation style.


May 5 

DemoShow

Demonstrate project accomplishments to the public.

Texts

Required

[RD] Steve C McConnell, Rapid Development: Taming Wild Software Schedules, 647 pages (July 1996), Microsoft Press; ISBN: 1556159005.
[CC2] Steve C McConnell, Code Complete: A Practical Handbook of Software Construction, 2nd edition, 2004, Microsoft Press; ISBN:0-7356-1967-0

Recommended

[MTSP] Watts S. Humphrey, Managing the Software Process, 494 pages (May 1989), Addison-Wesley Pub Co; ISBN: 0201180952
[SPSG] Steve M. McConnell, Software Project Survival Guide, 250 pages (November 1997), Microsoft Press; ISBN: 1572316217

Interesting

Patrick J. Lynch, Sarah Horton, Web Style Guide: Basic Design Principles for Creating Web Sites, Yale University Press (March 1, 1999), ISBN: 0300076754.
Alan Cooper, Robert M. Reimann, About Face 2.0: The Essentials of Interaction Design, Wiley; 1st edition (March 17, 2003), ISBN: 0764526413.
Capers Jones, Software Assessments, Benchmarks, and Best Practices, Addison-Wesley Pub Co; 1st edition (April 28, 2000), ISBN: 0201485427.
[DP] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch (Designer), Design Patterns: Elements of Reusable Object-Oriented Software, 395 pages 1 edition (October 1995), Addison-Wesley Pub Co; ISBN: 0201633612
Watts S. Humphrey, A Discipline for Software Engineering (SEI Series in Software Engineering), 789 pages (January 1995), Addison-Wesley Pub Co; ISBN: 0201546108

Student Responsibilities and Evaluation

Responsibilities

Each student is primarily responsible for interning on their project, making progress toward its goal, and transferring their results to the client at the end of the semester.
Each student will make a presentation to the class: either a project progress report or a code review.  Each student will summarize the project at the DemoShow.
Students must attend the kick-off, transition and wrap-up meetings.  Students shall prepare for the meetings and participate in these meetings.

Grading

Student evaluation, totaling 110 points,  is distributed as below. 


Activity or component

Points

Total points

Two presentations (Progress report or code review, and DemoShow)

8 points each

16

Three meetings: Kick-off, transition and wrap-up (evaluated on preparation and constructive participation) 

10 points each 

30

Emailed progress reports (evaluated on participation)

8 points

8

Contribution to Project Plan report (evaluated on content, responsiveness to assignment)

10 points

10

Contribution to demo show preparation, handout and/or poster

5 points

5

Contribution to final wrap-up report (evaluated on content)

8 points

8

Code review participation

5 points

5

Class participation

8 points

8

Subjective overall effort in the project

10 points

10

Subjective overall accomplishment in the project

10 points

10

Course Resources

Whenever possible, clients will provide computing resources. In addition, the CS department will try to provide computing when needed.  Please ask me if you need software, extra disk space, access to a computer, or another resource.

Communications

Email and the email beacon

All students and client supervisors must read and respond to Internet email daily. All students should join the G22_3812_001_sp05@cs.nyu.edu class mailing list, by filling on the form on the mailing list web page, http://www.cs.nyu.edu/mailman/listinfo/g22_3812_001_sp05
Each project will form its own email group. Join that too.

Project liaison

Each project  needs a team liaison responsible for organizing interaction with the client. The liaison's job includes

If you want to be your team's liaison, please volunteer.

Progress report
Each student must send your project email group a weekly email progress report on Thursday before class. A progress report is the best way for people who are involved in the project but do not participate in regular meetings (like me and the authorizing managers) to track the project's progress.  It is an excellent habit.  Many of the best run software organizations track team member progress with simple reports like these.

Spend 5-15 minutes composing the progress report (so if you devote 8 hours per week to the class the report takes at most 3% of class time). Writing the report will help you evaluate how you're doing. The report contains:

Here is an example of a fine report:

1. Description of the week's goal(s)
· Prepare the Transition Meeting Report in the following sections:
a) Draft detailed designs
b) Development plan
c) Serious open issues
· Working on the mockups for the entire system
2. Description of progress toward the goal(s)
· Finalizing the Transition Meeting Report
· Finalizing the GUI mockups
3. Description of the next week's goal(s)
· Present the report on the Transition Meeting
· Demo the proposed GUI
4. Description of obstacle(s) making progress difficult
Confused about GUI design.
5. List of ways, if any, Prof. Goldberg could help
Recommend a GUI design book. Cancel the assignment :-)



This document and associated materials were authored or compiled by Arthur Goldberg. This compilation and supporting electronic teaching materials may be freely used for non-commercial use provided any electronic or print version includes this notice. All rights reserved. Copyright Arthur P. Goldberg, 1996 through 2005.
tronic or print version includes this notice. All rights reserved. Copyright Arthur P. Goldberg, 1996 through 2005.
hrough 2005.

rogress difficult
Confused about GUI design.
5. List of ways, if any, Prof. Goldberg could help
Recommend a GUI design book. Cancel the assignment :-)



This document and associated materials were authored or compiled by Arthur Goldberg. This compilation and supporting electronic teaching materials may be freely used for non-commercial use provided any electronic or print version includes this notice. All rights reserved. Copyright Arthur P. Goldberg, 1996 through 2005.
tronic or print version includes this notice. All rights reserved. Copyright Arthur P. Goldberg, 1996 through 2005.
hrough 2005.