Sharing this book helps too!
Some project courses give a product specification for students to implement while other courses let student choose what to implement. Some projects have actual external/internal clients while others let students develop a product for an assumed potential market. Whichever the case in your course, at least some of these tips can help you manage the requirements of your project.
This section is useful if your project course allows you to define your own project.
The hardships of the project will be much easier to bear (and the final result much more satisfying) if you build something that you all believe in. Do not choose something that will simply fulfil the course requirements with the least amount of effort. For example, if you are building a utility that will solve a problem for someone, you should be convinced that it is a real problem worth solving. If it is a game, you should feel like it is a fun game to play and many others will enjoy playing it.
For the same reason, do not opt to duplicate something that has been done before unless you plan to do it in a novel way or achieve a better outcome than the previous efforts.
Having chosen a product, continue to have faith in it. The battle is lost the moment you stop believing in your product; do not start a battle that is lost even before it is started.
The trouble with most good ideas you have is that many others had the same idea long before you. If you have very little experience in the chosen product domain, it is helpful to do an extensive examination of all similar products in the market. Well, at least Google around a bit before you declare your idea 'ground breaking' or 'novel'. However, do not plagiarise things from existing products.
Note that the lack of or low level of competition can be the sign of a good opportunity or of a bad product idea. Sometimes, there is a reason why nobody else is doing it.
Not many project courses allow students to build software for a specific customer, especially if the customer is a commercial entity. However, most will allow you to release the software to the public. In either case, having real people using your software and giving you feedback can be really motivating and useful at the same time.
If possible, choose to build something that you and your teammates can use so that you have some real users close at hand all the time. It is pretty hard to second guess user needs for a product that you cannot relate to, and the result would be rather inaccurate too.
While your course might not allow external clients, you might still be able to have internal clients from within the university. Check with professors in your university; most have software development needs that cannot be satisfied by their own research students.
It is helpful to have a grand vision for your product. For example, rather than 'just another foo', you can go for something like 'the most streamlined foo', 'the most versatile foo', or 'the best foo on the platform bar'. The course duration may not be long enough to achieve this grand vision entirely, but it is still good to have such a vision. However, you should also promise to deliver a version of your product that makes significant progress towards your grand vision and yet is 'doable' within the given time constraints. If you are targeting real users, this version should be useful by itself to at least a sub-section of those users.
The idea here is that you should contribute something useful towards your grand vision before the course ends, and hopefully you will be motivated to continue the project towards your grand vision even after the course. Did you know that many successful products have roots in class projects?.
Many students underestimate the benefits of a good product name. This is especially important if you plan a public release of the product. Here are some things to consider.
If the course requires you put in a proposal for approval, take note of the following:
Combining a multitude of good features does not automatically give you a good product, just as duct-taping a good camera to a good phone [http://tinyurl.com/cameraphonephoto] does not give you a good camera phone. Resist the temptation to make up a product by combining feature proposals from all team members. The vision for your product is the first thing you should settle because it dictates the features for your product. Defining a vision after deciding features is like shooting the arrow first and painting the target where it landed. It is very important that you are clear about the vision, scope and the target market for the product. These should be documented and made available to others in the team, instructor and any other stake holders.
Given the tight resource constraints of a student project, you cannot afford to be distracted by any feature that is not central to your product's vision. Ditch features that do not match the product vision, no matter how 'cool' or 'useful' they are.
Do not provide features because you think they 'can be given at zero cost'. There is no such thing. Every feature has some cost. Include a feature only if there is a better justification than "it costs nothing".
Some teammates might try to squeeze in their 'pet features' for their own enjoyment. Reject them gently but firmly; if 'password security' is not essential to your product vision, do not add it even if one team member claims he already has the code for it and it can be added in 'no time'.
Aim in one direction. Avoid having multiple 'main' features that pull in different directions. Choose other 'minor' features in a way that they strengthen this 'main' feature even more. One 'fully baked' feature is worth two 'half-baked' ones.
Do not feel compelled to implement all 'commonplace features' of similar products before you move to those exciting features that will differentiate your product. A product can survive with some 'glaring omissions' of common features if it has a strong 'unique' feature. Take note that the successful iPhone did not have many 'common' features such as 'SMS forwarding' when it was first released.
Categorise and order requirements based on criteria such as priority, urgency, cost, complexity, utility, risk, type of function and type of user. You won't have time to implement them all. In fact, there will not be enough time to do even the ones you thought you could. It is easier to make optimal keep-or-drop decisions if you already have your features categorised and ordered. Besides, having such a list can earn you extra credit because it shows how systematic you were in selecting features to implement.
Larger targets are easier to hit but harder to conquer. It is better to target your product for a well-identified small market (e.g. faculty members of own university) than a vaguely-defined but supposedly larger market (e.g. all office workers). To take this approach to an extreme, it is even acceptable to identify a single real user and cater for that person fully than trying to cater for an unknown market of an unknown number of users.
It is critically important that you use the users' perspective when deciding what features to include in a product. What is 'cool' to you may not be 'cool' to users. Do not choose 'technically challenging' yet 'harder to implement' features if there is no significant benefit to the user.
Get feedback from your client and from your supervisor. If you do not have a specific client, find a potential user who is willing to give you feedback. Force yourself to use the software; if you do not like it yourself, it is unlikely someone else will.
You can use requirements specifications or an early prototype as the basis for soliciting feedback. Another good strategy is to write the user manual very early and use that to get feedback.
Do not be afraid to change direction based on early feedback, when there is still enough time left. That is precisely why you need to get feedback early.
Plan to deliver a little bit more than what is generally expected or previously promised. This will delight the evaluator. Conversely, delivering even slightly less than previously promised creates a feeling of disappointment, even if what you managed to deliver is still good.
This section is especially useful if you are releasing your product to the public.
If you do a public release, try to spend some effort publicising your project among potential users. Note that most evaluators will not give extra marks for such efforts; but it is still worth doing. There are many websites, such as softpedia.com, cnet.com, and softsea.com that will host your software for others to download, rate your software, and even write reviews for your software. Here [http://tinyurl.com/synchsharpreview] is a sample review for a software product written by students. If your software is good, even popular tech blogs such as lifehacker.com and addictivetips.com will start publishing reviews, boosting your download count even more. Here [http://tinyurl.com/synchlessreview] is such a review for a software written by students. It is helpful to have a website for your product, and even your own domain name. You can easily buy a domain name for less than $10/year. There are many ways to create a website for free (e.g. using Google Sites). Project hosting environments such as Google Code Project Hosting (GCPH), too, will let you create a project website. For example, http://syncless.info is the home page of a sample student project hosted on GCPH.
Other ways to publicise your project:
It is not a good idea to throw your very first release at ALL your potential users. Releasing it gradually gives you more opportunities to refine your product to fit the market. For example, you can do an alpha release among your friends and get some friendly feedback. After that, refine the product and do a beta release to a small community such as posting in a public forum that you participate (but make sure the forum allows such posting, or you will be flamed for spamming). Next, refine it further before you go for a full public release. If time permits, and you are allowed by the course structure, do all these releases before the final project submission because the feedback you get from these releases will make your final submission all the better.
Carefully nurturing early adopters is important to a new product as it is important for a budding leader to nurture early followers [http://tinyurl.com/shirtlessdancing]. First of all, make sure they have a way to reach you. You can either build a 'give feedback' feature into the product or use an indirect mechanism such as Google Groups.
If possible, create a mechanism for current users to be notified about new releases. This way, you get a second shot at those who did not like the early release they tried. For example, you can build a 'check for updates' mechanism into the product, use the 'follow us on facebook/twitter' technique, or collect their email addresses so that you can email them about updates.
Any suggestions to improve this book? Any tips you would like to add? Any aspect of your project not covered by the book? Anything in the book that you don't agree with? Noticed any errors/omissions? Please use the link below to provide feedback, or send an email to damith[at]comp.nus.edu.sg
|
|
Sharing this book helps too! |
---| This page is from the free online book Practical Tips for Software-Intensive Student Projects V3.0, Jul 2010, Author: Damith C. Rajapakse |---