This is the first of two projects that you will complete as a team in CIS 422. The primary purposes of this first project are to give you some practice in working as a team to produce a complete software system with a deadline. You will also get some practice using existing components and tools to accelerate your development by minimizing the amount of new code that you must write.
I have attempted to make the first project technically easy, so most of the issues you will face will be non-technical - how to divide up and coordinate the work, how to work together and not hate each other, how to avoid catastrophe if one person gets sick or flakes out, etc. The project is small, but the deadline is tight.
You will construct a tool for building graphical maps of web sites represented as directed graphs in which documents are nodes and links are directed edges. The input of your tool is a web site. The output of your tool is a graphical depiction of the web site, in a form that will be useful to a maintainer of that site. At a minimum, the graphical representation of the site should
When you are done, your project should be a high-quality freeware tool that can be distributed in source form over the internet. It must include full documentation, including installation and configuration instructions and examples.
This handout is not a complete statement of requirements for your product, because it is your job to complete the requirements. There are many open issues for your to resolve. Here are a few things to think about:
These issues barely scratch the surface. The bottom line is: Build a tool that people will want to use, and that they will be able to use easily. I predict that you will find deciding what to build a good deal harder than building it. You should identify objectives, alternatives, and constraints for your project, as well as you are able, and begin to identify risks and the ways you will obtain more information to assess and control those risks.
Your first task is to organize a development team. You will need a mix of skills to succeed. You should try to form a team with
You must assign responsibilities to team members. It is not a good strategy to simply share all responsibilities. Although all team members should contribute to some extent to every aspect of the project, it is essential to have one person with central responsibility for each major part of the task. Among the responsibilities to be assigned include:
The mapping of people to roles is not necessarily one-to-one. For example, it is common in small teams for the user documentation and user interface roles to be combined. You may wish to identify additional roles. You may also want to spell out responsibilities more clearly, e.g., shall the user documentation or technical documentation person be in charge of the final presentation?
The person with ultimate responsibility for one of these functions does not have to do the whole job alone. For example, the system architect does not design the whole system alone, and the product build manager does not do all the implementation; they are managers of different aspects of the project.
Risk control is an important part of project management. One of the largest risks to any software project is the loss of a key person. Therefore, while it is important that a single person be ultimately responsible for each role, it is a very good idea to assign a "backup" for each role also. The backup person assigns the main person responsible for a role, and should be knowledgeable enough about that role to take over responsibility if the primary person is lost or unable to fulfill his responsibility. The backup role is also an opportunity for "cross-training" in preparation to take a lead role in a later project.
When you have formed your team, prepare a document and presentation briefly describing your product concept, as if you were proposing it to management within your company. Your product concept should address at least the following issues:
For whom are you building this product? Describe your users and their needs. How do you envision them using your product?
What tools already exist, or will soon exist, which provide services similar to your product? What are their good points and weaknesses?
What will be the unique advantages of your product over others, for your target users? In other words, how will you differentiate your product from the competition?
Can you produce a winning product with the given resources, especially the tight deadline? You may wish to comment on your technical approach and your management approach. Suppose you are pitching to the CEO of your company. Why should he have confidence risking $50,000 dollars (the approximate cost of 5 technical personnel for 1 month) for you to develop the web mapper?
The cheapest, most dependable and least risky software components are those you don't build. You can find graph layout and display components, web spiders, and other nifty things freely available on the web. I strongly suggest you take advantage of them. On the other hand, you must do so in a way that is legal and ethical, and while I won't set an upper bound on how much of your project code can be reused, you must certainly provide some "value added" and not merely repackage software available elsewhere.
To be legal, you must obey all copyright restrictions in software you use. Beware that a document or file need not contain an explicit copyright statement to be protected by copyright law; you have a right to copy or reuse something only if the author has specifically granted you that right.
Your product must be freely distributable under the Gnu copyleft agreement. In some cases this may mean that you cannot make use of some software which is otherwise perfect. In other cases it may mean that your product will depend on other software packages that you cannot directly distribute. (Be careful of such dependencies, especially on commercial software, as they can make your product more difficult to install and use.)
To be ethical, you must clearly document the original source of all software and other documents. Every source file must contain header comments clearly identifying its author(s). Derivative work (e.g., code written by you but adapted from a book) must clearly cite each source used in its creation. Falsely identifying yourself as the author of something that is actually someone else's work, or failing to properly cite a reference on which you based part of your work, is plagiarism and will be dealt with very severely.
It is entirely possible to follow these guidelines, making only legal and ethical use of other people's work, and still to avoid most of the design and coding that would be required if you built this project "from scratch."
In addition to forming your team, you should be working on the issues that will be in your product concept document due at the end of week 2. Browse the web looking for products (freeware, shareware, and commercial) that do something related to the web mapper. What is the competition? Are there "market niches" for your product? Look also for useful components that you can reuse.
You are going to need at least a couple of intense team meetings to agree on your product concept, in addition to more individual research. Think seriously about the feasibility issues: How is your team going to divide up the work and tackle the problems? Produce the product concept document and present it to the class on Friday.
Delivery is just two weeks off, and deadlines that looked easy before are starting to get scary. Don't panic. Do make a plan that includes early production of a running prototype (no matter how lame, it just needs to work) and frequent revisions. Make contingency plans for the failure of anything that isn't already running. You really, really want a running prototype before class Friday of this week, so that you are ready to discuss any remaining problems.
It's crunch time. You're on a daily build-and-smoke schedule now. You have an agreed meeting time each day for putting together everyone's pieces and testing the current system version. The build-master is sweating bullets, but she has it under control so that, if it all blows up on Thursday, the Wednesday build is still good to go. You use the scheduled lecture times for intense reviews of documents and outstanding design issues. On Friday you declare victory and turn in your project by e-mailing the instructor and teaching assistant a URL at which the whole thing can be downloaded.
There's still one more chore. You need to present and/or demonstrate your project in class Monday or Wednesday (presentation slots will be chosen randomly). You will also participate in the class discussion. How did your approach to the project differ from Bob's group? Did you encounter some of the same problems? What seemed to work, and what didn't?