Information Technology Projects
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 include project specification, consulting project management,
technology planning and training, and communicating to management. The
software engineering issues include the software maturity model, the software
life cycle, software standardization, and technology trends.
Professor: Arthur Goldberg
Course home page: http://www.cs.nyu.edu/artg/itp/Fall2002/index.html
Update history in 2002:
Time: Most Thursdays, 5:00 to 8:00 PM (with advanced notice
you may leave for a 7 PM class), plus about one day a week at your client
Place: WWH 402
Email beacon: G22_3812_001_fa02@cs.nyu.edu
Office: WWH, 251 Mercer, Room 409
Home page: www.cs.nyu.edu/artg
Office hour: By appointment, schedule by email
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
We divide the course into two sections, requirements gathering and
analysis, and 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 Fall 2002
Adolescent Care Center at Mount Sinai School of Medicine
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
Some clients will be paying significant money to NYU in recognition
of the accomplishments we achieve in the course.
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 some CS and some MS in IS 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 clients break projects into 2 person tasks so team members
can progress fairly independently.
In the Fall of 2002, the Projects course can accommodate at most 16 students
in 4 projects.
To be productive on a project a student must possess sufficient technical
and/or managerial skills. These skills can be obtained by academic training
As the set of skills cannot be precisely specified, interested students
should contact Prof. Arthur Goldberg (email@example.com) for permission to
register. Email a resume or short biography.
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)
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.
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.
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 requires more.
We meet as a class about 9 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 Fall 2002 schedule follows:
By Sep. 5: Prospective clients submit project proposals. Proposals
will be published on NYU's Web to advertise the course to students.
Sep. 5: At the first class, students learn about all projects.
Sep. 9, 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
Sep. 12: Students assigned to projects by Prof. Goldberg.
Students notified by email. Staffed and unstaffed clients are notified.
Sep. 13 to 16: 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.
Sep. 16 to 25: 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). 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 Dec. 19: 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.
Week of Oct. 21: 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 an analysis and
prototyping plan. Example plans will be made available by professor Goldberg.
Dec 19: At our "DemoShow" at NYU all teams present their results
to all clients, interested faculty and other students.
Dec. 13 to 20: 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
||Topic / Reading
||Information Technology Projects: Introduction and Logistics / Handouts
||Course goals: Software project planning and execution: business analysis
and requirements gathering; development planning and scheduling: software
lifecycle. Description of all projects and clients, review course
description, handout student questionnaire and project selection form.
||Project Analysis / UML summary
||Understanding and describing business objectives: switching costs,
standardization, infrastructure, ROI; collecting and analyzing requirements,
good questions to ask, individual research; use case analysis; UML.
Progress reports, kickoff meeting goals, agenda and preparation.
PROBABLY: Team assignments, liaison responsibilities;
Teamwork and problem solving skills.
||No class: kickoff meeting week
||Project Analysis Continued / [RD, chap 10, 14, SPSG, Chap 7, 8]
Transition meeting / Sample transition reports
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
||System architecture and design, progress report / TBD, Weinberg "programming
Individual preparation /
|Individual preparation: tuning technical skills; testing theories;
risk-reward of guessing
What makes a good architecture? Interface design, specification, definition
Present sample progress report; democratic programming teams
||Student presentations: Project progress reports
||Half of students, some from each team, discuss project progress.
Professor: Project problem-solving; communications, understanding roles
||No class: transition meeting week
||Large scale software engineering, changing organizations / Humphrey,
||CMM, Weinberg change model
||Writing correct code - Reviewing Code / Gries, the science of programming;
extreme programming doctrine, Weinberg, McConnell and Humphrey on code
review, example code
||What is 'correct' code? approaches to making code correct:
Good design; avoiding bugs; invariants; correctness proofs; the individual
psychology of programming--cognative dissonance; testing: unit test, JUnit,
extreme programming, demonstrate a code inspection
||TBD, possibly troubleshooting / Polya, "how to solve it"
||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 14-Nov. Reviewers take home
code and look for errors. Reviewers return feedback error forms to
Professor by 19-Nov).
Programmer presents code, team members and professor offer feedback.
||No class, Thanksgiving recess
||DemoShow planning and preparation
||Demoshow presentation: demo content, other communication tools: poster,
handout; preparation and resource needs, invitees, presentation style.
||Demonstrate project accomplishments to the public.
||Dec 13 to 20
||Wrap-up meeting week
[RD] Steve C McConnell, Rapid Development: Taming Wild Software Schedules,
pages (July 1996), Microsoft Press; ISBN: 1556159005
[MTSP] Watts S. Humphrey, Managing the Software Process,
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
Required for Vindigo project: Performance Analysis for Java Websites,
by Stacy Joines, Ruth Willenborg, Ken Hygh, ISBN: 0201844540.
[CC] Steve C McConnell, Code Complete: A Practical Handbook of Software
Construction, 857 pages (May 1993), Microsoft Press; ISBN: 1556154844
[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;
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
Each student is primarily responsible for interning on their project, making
progress towards its goal, and transferring their results to the client
at the end of the semester.
Each student will make a presentations 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.
Student evaluation is distributed as follows:
in-class presentations (Progress report or code review, and DemoShow)
meetings: Kick-off, transition and wrap-up (evaluated on preparation and
progress reports (evaluated on participation)
to analysis to development transition meeting report (evaluated on content,
responsiveness to assignment)
to demo show handout and/or poster
|Contribution to final wrap-up report (evaluated on content)
overall accomplishment in the project, including class participation
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
Email and the email beacon
All students and client supervisors must read and respond to Internet email
All students should join the G22_3812_001_fa02@cs.nyu.edu
class mailing list, by filling on the form
on the mailing list web page. Each project will form its own
email group. Join that too.
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.
Schedule initial and final meetings with team, client and Prof. Goldberg.
Schedule first couple meetings between client and team.
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
Here is an example of a fine report:
Description of the week's goal(s)
Description of progress towards the goal(s)
Description of the next week's goal(s)
Description of obstacle(s) making progress difficult
List of ways, if any, Prof. Goldberg could help progress
1. Description of the week's goal(s)
· Prepare the Transition Meeting Report in the following
a) Draft detailed designs
b) Development plan
c) Serious open issues
· Working on the mockups for the entire system
2. Description of progress towards 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.
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 2002.