All project milestones are due on Friday of the milestone week, preferably in print form.
If you are interested in doing a software engineering research project instead of a development project, please let me know. I will help you design your project and give you an analogous set of milestones suitable for a research project.
Software engineering not only embodies a set of key concepts and principles, it also entails a set of skills. Without proficiency in at least some of these skills, you cannot call yourself a software engineer. This course includes a project in order to help you get a taste of these skills as well as experience the key lessons of software engineering first-hand.
Few interesting programs can be built by a single person, so the project for this course is team-oriented. In addition to all the other skills and lessons that are to be conveyed, you will also be learning how to cooperate and communicate effectively.
In this project, you and your teammates will be defining a software product and seeing it through every stage of development. Because of the short span of this class, you are not expected to deliver a marketable product, but the result should be at least a compelling prototype that could serve as the basis for defining a real product or attracting venture capital. :)
You and your teammates have the flexibility--within certain parameters--to choose the product to develop and the features it provides. To provide some ``spiritual'' guidance, your product should attract the attention of the ``Small World Venture Capital'', which specializes in promoting unusual products that promote a better world through strong communities. They have special interests in software that are targeted to a large group's needs. I will personally function as the Technical Liason of SWVC, and each team will be coming to me to seek guidance about what they can do to have a better chance of attracting additional funding. Each team has considerable autonomy, however, in defining its product and managing its team. For example, you are responsible for choosing a product that is within your means to develop within the alloted time. From time to time I may sense opportunities in the marketplace and suggest small changes to improve our market position. I will consider the possibility of teams developing competing products.
As an alternative, you may pursue a software engineering research project. The project should involve building something, but being research it should also have a significant evaluation component - the application of an empirical device such as measurement, interviews, etc.
Here are some places to get inspiration (I can provide further details):
Communication is your biggest risk, since you probably have disparate schedules; this mutates into a coherence/consistency risk, amongst others. You've been warned. :)
Although each cycle focuses on resolving a certain class of risks, any previously unresolved risks should be monitored for realization or (preferably) elimination. Realization of unresolved risks requires a reprioritization.
For most cycles, there are six primary work products that must be incrementally refined and maintained:
If there were any money involved, there would also be a budget document. You may also want to keep supporting documents such as meeting notes and e-mails.
These work products are repeatedly augmented, refined, and changed. At no time is any document complete, unless the whole project is complete. It is impossible to know the future with certainty--and costly to to try--so knowledge is acquired as its cost to acquire drops and its cost to ignore rises.
Below are the milestones that denote the major cycles of product development, as somewhat arbitrarily predetermined by me. Do not be misled by the titles on the milestones. These are not the stages of a waterfall model that transform an input document to an output document. They are spirals that are focused on the resolution of a particular class of risks. The goal, then, it not production of documents, but resolution of risks and the successful production of a final product. The ``product'' is repeatedly defined and evaluated at increasing levels of detail. You should augment these major cycles with minor cycles as-needed to resolve individual risks, etc.
Also, these milestones are dates for you to deliver documents to me. It is expected that your actual work precedes the milestones by quite a bit. My grading of these documents will constitute the ``review and commitment'' parts of the cycle (although normally this would happen in a highly interactive and probing meeting); you are responsible for validation, which is a much more detailed activity than the review for commitment. You should maintain your four work products on the web, and hand in (on paper) the necessary portions of the products (with change marks, if necessary) for each milestone.
A milestone document should have roughly the following form:
All milestones are for the Friday of the named week. You do not have to wait until the last day to complete the work for a milestone. I recommend being about a week ahead, when possible. If you receive a substandard grade on a project, you can turn it in again the following week for a regrade. You can hand in via e-mail, and may point to a web page (e.g., in your project Wiki), although I like printed paper, frankly.
Agree on a product that you think will be attractive in the marketplace and will be affordable to build. Identify who your customers are and how you'll reach them. Identify the factors (risks) that may lead to the failure of the product. Construct a plan to resolve the most serious risks. The result should be a one to five page ``vision document'' for the product. It may be too early to address the schedule (more than what is here) or software.
If you want some guidance on vision statements, see Chapter 4, page 207
of Microsoft Secrets.
Based on the issues (e.g., risks) identified in the previous milestone, identify key tools, technologies, and skills that you will be depending on throughout the rest of the project. These tools and technologies should be complementary; they cannot be chosen only for their individual strengths. Moreover, they must be well-suited to the constraints and risks of the project (i.e., resolve the technology risks), such as cost and time, size of the team, etc. Do not focus only on what risks the technology resolves, but on the risks that the technology entails.
The tools and technologies you choose may influence your low-level
software process. For example, use of a modern IDE (integrated
development environment) with a modern code/document repository, etc.,
might encourage an XP (Extreme Programming) process.
Discover the actual needs of your customers. In essence, you are starting from a problem from the customer's point of view and elaborating that into a set of requirements for an improved or entirely new system. This process is complicated by the fact that you have no product to show your potential customers. Also, every potential customer will have his or her own ideas, which may conflict with the ideas of other. Moreover, your potential customers may have a different background than you, complicating the communication process. Do not lose track of the fact that you must not only satisfy the customers of your product, but also those who are supporting your project. The requirements should be recorded in a way that they are easily accessible and analyzable in future stages (e.g., pictures, scenarios, stories). Your methods should be documented. The requirements document you turn in need not provide the low-level data, however, only the results and key supporting data.
Requirements analysis and risk resolution. Through
analysis and review of the collected requirements, identify conflicts,
problems, etc., attempting to resolve them before they consume your
project. Because you are still at an early stage, there are many
options open in terms of resolving problems, including changes to the
vision, product, customer base, marketing, management, etc.
Define the product. Based on customer requirements, time constraints, and other factors, design and specify the best possible product. You may wish to construct a crude prototype, mock-ups, or crucial scenarios, or even a user manual. Use of the word product is meant to emphasize the external qualities of the software, that is how a user interacts with and perceives it, rather than its internal structure. In the water fall model, a product definition might be a user manual, although a scenario orientation is likely to produce a better understanding of feature interactions. For use by software designers, this manual might be expanded by detailed functional specifications.
Use whatever specification methods you feel appropriate to the risks being addressed. Some to consider are predicate logic, state machines, domain-oriented class diagrams, data flow diagrams, Z, Larch, OBJ, and scenarios. However, your particular circumstances may require you to invent your own notation, extend an existing one, and very probably use more than one notation. Maybe you just want a manual.
A very 'enactable' form of specification is testcases -- essentially inputs that correspond to the scenarios of your system, along with some infrastructure or method that an verify the outputs. This corresponds with XP's rule of "test first". These not only make the scenarios precise, but they also make testing your system against those scenarios precise. Depending on your risks, these scenarios might be 'system' scenarios or 'unit' scenarios (e.g., for critical units of your system).
Product design analysis and risk resolution. Although it is not cost-effective to exhaustively analyze a system, certain critical aspects of the system must be analyzed in order to ensure the appropriate software gets implemented and that it will have certain properties (such as liveness and fairness, as completely arbitrary and potentially inappropriate examples). Using risk analysis, identify these critical aspects and then analyze them for the identified risks.
PROCESS NOTE: Some projects, based on their risks, may benefit from a rapid prototype at this point. This might consist of a simple GUI with a fake back-end, stylized use of a competitor's product, by-hand emulation, prototyping of a "high risk" component, etc. If you have "customer" risks (e.g., buy-in), or "requirements" risks, you'll probably want to try out this prototype on your customers.
The structure of a software product often has little to do it with defining its function, but has everything to do with being able to implement, test, and enhance the software at a reasonable cost.
Looking ahead to week 7, propose a high-level architecture for your system, including major components, connectors, and rules for their composition. Review the product design and scenarios derived from customer requirements to make sure that the macro system structure is well understood.
Project replanning. Identify resources for developing the
product (e.g., libraries, platforms), identify risks for completion,
and plan secondary courses of action. Note that project planning may
force you to cut out inessential functionality or even redesign your
product in order to meet the deadlines.
Building on your software architecture, design your software with the following development properties in mind:
Together with your software architecture, the result is a design specification. It may be desirable to also specify the behaviors of the subcomponents, effectively ``dividing up'' your earlier requirements specification to the components of the design.
The design should be scrutinized in reviews. The final design should be documented at a level of detail deemed appropriate by your method. Some sort of architectural description with the interfaces of the major components and their relationships is expected. As always, a risk assessment is in order: May one module be much harder to build than the others? May a key design decision by widely distributed? What if a key component is not delivered on time? Appropriate courses of action should be planned.
Your design methods, principles, and rationale should be documented.
Verbal report to the project manager. Strict tracking of progress should be performed to identify problems as early as possible. Note that development can begin before week 8.
Testing should occur at the earliest possible time to expose problems before they are propagated. Already, requirements analysis, and design reviews have taken place to ensure the integrity of the conceptual aspects of the product. Moreover, you have designed your system to allow it to be tested incrementally. Testing continues throughout implementation, including:
At a minimum you should employ a functional testing approach, and take steps to ensure completeness of the testing, although as always, your testing should be risk-directed (both in what you test, how much, and how it is tested). Minimality is not essential. As usual, your methods and results should be appropriately documented (in what is often called a testing plan).
The product need not be completed this point, but the testing
infrastructure should be in place, and testing as appropriate to the
progress in the project should be taking place.
Install the product, train your users, and pray. A brief verbal
report will be given in class.
Prepare a demo for the manager and the venture capitalists. The success of this demo and the frankness of the postmortem will determine continued funding of your project.
The postmortem is an analysis of your project to determine success and (primarily) failure factors: What you did, what you would do the same, and what you would do differently next time? Quantitative, qualitative, and totally subjective measures (e.g., intuition) should be used. The focus is not on blame, but on improvement. Failure is inevitable whenever an ambitious project is undertaken. Failing to learn from it is not. It is recommended to use the description of Microsoft postmortems in Microsoft Secrets as a template for your own. A key element of a postmortem is restating the motivation and objectives for the project: a project is first judged successful relative to its initial objectives, although success is possible even if the original objectives were not met if there as considerable change in direction during the project. History has shown that these presentations go more smoothly if you have prepared the presentation, perhaps with slides.
Demos and Post-mortem presentations will take place during the time scheduled for the final. The time will be divided evenly among the teams (about 20 minutes, if the class isn't too large) plus time for responses from the project manager and a class postmortem. To provide context for the other students in the class, provide a description of your product, its rationale (cf. your vision statement), and a sketch of the relevant parts of your software development process and methods before getting into the details of the evaluation,
At the postmortem meeting, provide a hardcopy of your notes for the postmortem (e.g., overhead slides) and a copy of all your documents for the project (sans source code, which is too big). If all your documents are on the web, only a copy of the slides and is URL is necessary.