To: ECE 480 Class
From: E. Goodman
Date: September 3, 2008
Re: Request for Proposals
In serving the customer for your design product, you must address the following basic questions, to whatever extent they are relevant to your project:
1. What experiments and/or background research need to be conducted to characterize the principal hardware and software components of the product or system you are designing, possibly with real-time constraints or deadlines?
1.1. How should we assess our customer's needs? To whom should we be talking to assess the needs/interest of the ultimate user?
1.2. What design constraints must be considered?
1.3. What criteria should be used to judge the feasibility of a design?
1.4. What criteria should be used to rank the feasible designs, and what is their relative importance?
1.5. Does each of a set (usually at least 8-10) of conceptual designs/variations meet the feasibility criteria?
1.6. What trade-off studies need to be conducted?
1.7. Which feasible conceptual design should be taken into detailed design and prototyping?
1.8. How should we assess and manage risks?
1.9. How should we go about developing models for system sensors, actuators, interfaces, and other principal system-level components?
1.10. How should we validate these models?
1.11. Keeping in mind that a product or system might be contained on a single IC or may involve a wide-area communication network, what are the fundamental issues involved in trying to control processes or operate systems at different interconnection distances?
1.12. What are the principal issues involved in hardware-software co-design for this project?
1.13. How might we decide between or combine a top-down product development strategy with a bottom-up experimental approach?
2. What are the issues, advantages, and requirements of developing software components using particular high-level languages? What compilers, cross-compilers, libraries, device drivers, and other support are available? Is there support from implementing real-time behavior? Can a PC-based development tool, such as LabVIEW, be used to demonstrate proof of concept before committing to a specific embedded controller?
3. What is the life-cycle model this project, system, or software? Your model should minimally contain:
3.1. Project phases
3.2. Project reviews and demonstrations
3.3. Identification of deliverables
3.4. Feasibility decision matrix and selection matrix
3.5. Development of a detailed specification
3.6. Process to evaluate success against the original design specifications
Your customer has provided you with a problem description and requirements at some level of detail, either in writing or verbally. You will interact with the customer (and your facilitator) iteratively to develop a final proposal that meets the customer's needs.
A proposal will be developed by each design team. The proposals must include all of the requirements listed in this section. The proposal should be written at a level that the customer will understand. In general, you can assume the reader (i.e., customer) has a general engineering background, but not necessarily in ECE or the specific areas of ECE of your proposed product or system. The proposal has three primary sections, including technical section, project management section and cost section.
Technical Section
Each proposal must identify the customer needs/requirements (1-2 pages) that its design team plans to address. This should be developed as a needs analysis. The sources of information to determine needs include the customer and/or potential consumer as well as codes/standards that may impose constraints on the design. Some generic design needs or constraints include: function, performance, delivery date, quantity, environmental conditions (including electromagnetic interference generation and susceptibility), safety, quality, energy consumption, reliability, maintenance, electrical loading, size, weight, spatial constraints, aesthetics, packaging, personnel, service life, operating instructions, human factors, health issues, regulations, shelf-life storage, operating costs, initial prototyping costs, unit costs in production, production setup costs. Several of these may be relevant to your project, and you might identify others specific to your project. These requirements/constraints then map into a design specification.
The next section is the background section that describes previous work on this project or system (if appropriate), shortcomings of similar products or systems designed in the past or currently on the market, and/or description of the functionality or theory of operation of the product/system or critical components in the product/system. This is the section where you educate or provide necessary information to the readers so they can understand the technical aspects of the rest of the proposal.
Based on interactions with and information from the customer, each team must develop a product design specification (typically 2-4 pages). The design specification is often organized based on design parameters, which translate customer's words into engineering terms useful to a design team, such as constraints that must be satisfied. The specification should list a set of design parameters (criteria). For each design parameter, a short description of its characteristics specific to the product must be provided, either qualitatively or quantitatively. Criteria should be classified into two types -- those that must be satisfied (and, sometimes, to what degree) for a design to be feasible, and those to be used to rate the desirability of feasible designs. The importance of each parameter to the project/customer should be evaluated on a scale of 1-5, with 5 being very important.
The next section should describe (only briefly) the set of conceptual designs considered (each should be described fully in the engineering notebook of the team member who came up with it). It should then show a decision matrix with a column for each design, and the feasibility criteria down the rows. In the full proposal (but not necessarily in the preproposal), the matrix should be completely filled in, thereby identifying which designs are feasible, and will be further ranked in the next matrix. The determinations should first be made by each student individually, then discussed by the team and with the customer to be certain that no critical criterion has been omitted. The feasible designs (only) should appear in a second decision matrix with a row for each criterion used to select the best design, also showing the value assigned to each design for each criterion. A column of weights for the criteria could appear as a second column, for example. Then the total points for each design can be calculated (in the bottom row) by summing each rating times the corresponding weight, arriving at the total for that design. (In the preproposal, only the criteria to be used and preliminary weights assigned for importance of each need to be included… the feasible conceptual designs may not yet be determined.) The discussion should indicate which conceptual design has been selected for detailed design and prototyping. Once design criteria and weights have been agreed upon, each student should first proceed INDEPENDENTLY to rate each design’s feasibility, and the team then combine these ratings and discuss them to arrive at a consensus regarding which designs are feasible. Then each member should rank each FEASIBLE design in the second matrix independently, then the team combine the ratings and discuss significant differences. It IS reasonable to conduct this evaluation iteratively, revising the weights if the results do not make sense in the light of good engineering judgment. However, that should NOT mean that "intangibles" or life-cycle considerations have no effect on the overall evaluation. The final decision as to the design to proceed with should be consistent with the evaluation process – but it is perfectly acceptable to revise that process in a way that reflects growing understanding of the problem to be solved. [NOTE: for the PREPROPOSAL, you need only list and discuss the criteria to be used to decide feasibility and rate desirability of the various conceptual designs. You should describe one or more leading design candidates so far. You do not need to complete the matrices and decision process until handing in the FINAL proposal.]
Next, the proposals need to identify what tasks will be undertaken and what outcomes are expected with respect to the proposed design solution. The proposals must describe, at a high-level, the principal features of the proposed hardware-software system, the hardware and software modules to be developed, and the software tools, computing platforms, and experimental apparatus to be used. All proposals must contain high-level graphical models of proposed system structure (e.g., architectural block diagram). Specifically, your proposal needs to include figures/diagrams that help to define your proposed design solution. Included in this section is a description of how the product or system will be built and tested. The test plan should be detailed enough so that it describes what tests will be performed to determine if the design specification is achieved.
A preliminary risk analysis (one page) must be documented. Based on the design parameters, create a set of risk items and estimate the degree of risk associated with each. This is only a preliminary examination, in part to force the team to consider options and consequences. For high-risk items, you may want to do a feasibility study early in your design process. Rate each item as low, moderate or high risk.
Project
Management Section
All proposals must contain a project management plan that describes the personnel and their organization/tasks, the facilities/resources to be used, and a project schedule. [Note: for the PREPROPOSAL, the Gantt chart (project management plan) need not yet be complete. You should be working on a rough draft of it by the time you submit your preproposal. You will submit the completed project plan (Gantt chart) electronically to Goodman at the same time you submit your final proposal.]
In the personnel subsection, the technical tasks to complete the project will be partitioned among the team members. Do this partitioning so that each team member can make an identifiable technical contribution. (If this technical contribution is not clear and well-defined, the person’s grade will suffer.) The tasks should be organized so that each person can start working on his/her portion of the project immediately -- i.e., doing bottom-up experiments, finding, learning about and testing specific chips and parts, etc. In fact, each team member should organize a plan for his/her technical task(s) so that they evolve those task(s) from an initial idea, to hardware or software that works but is not optimized, then to a final hardware or software component/subsystem that is optimized and working in the overall project. Hence, each team member should have a technical task or tasks, and a timeline with clearly indicated deliverables. (You are developing your task breakdowns and plans in your engineering notebook, right???)
The next subsection in the project management plan needs to demonstrate that you have the resources or facilities to complete the design project. This section will list the hardware and software to be used on the project. For any hardware or software not readily available in the ECE 480 laboratory you need to describe how this software or hardware will be obtained.
Next in the project management section is the proposed schedule (i.e., timeline) for completing all required work, including all reports, presentations, and demonstrations. In general this subsection describes the sequence and timeline of the various tasks in the project. Equally or more important in the timeline and project plan is the coordination and integration of the various technical tasks into a working final product. This coordination and integration also needs to be clearly described in this subsection of the proposal. A Gantt chart is a required part of this section, prepared using the MS Project software available in the lab, showing how the project is divided into technical tasks, who is responsible for each task, a timeline for each task (including also non-technical deliverables), and the timeline of integration. This section also needs to list the deliverables that you will have done for the demonstrations on Week 9, 12 and 15 of the semester. I will talk about using MS Project in a lecture in September, and my overheads will be on the web pages. An overview of these types of charts is also given in the document "Graphical Project Planning Techniques: An Overview of Gantt, PERT and CPM charts" prepared by D. Grover. This document is available on the course web pages as one of reading assignments. When the Gantt chart is viewed in “tracking Gantt” mode, it MUST show a reasonable critical path – that is, the tasks on which any slippage in planned completion time will delay the successful completion of the project must show up on the critical path. Careful choice of task structure and of task dependencies is needed for this to work well and to be a real tool for project management. In particular, you should use the default “finish-to-start” constraints almost always, rather than “start on (date)” or “finish no later than (date)” types of constraints. You can set planned task durations so that the plan shows all deliverables completed on or before the dates they are due. An example: If you can’t really start phase 2 of some task before phase 1 is completed, show phase 2 depending on phase 1 in a finish-to-start dependency. If you can start phase 2 before phase 1 is done, but can’t complete it until some length of time after phase 1 is completed, then you should probably be breaking down both phase 1 and phase 2 into phases 1a & b and phases 2a & b, and then showing that 2a can start when 1a is completed, but that 2b can’t start until 1b is completed. That’s the general idea of how to get a good definition of tasks so the critical path planning can actually do you some good. I will be looking at the Gantt charts (to be submitted to me electronically as .mpp files) to see that whether the plans -- and particularly, the critical paths -- are satisfactory or not. If not, I will require that you revise and resubmit them, for a lower point score.
Cost Section
The last major section is the budget. The various expenses for the design project need to be itemized and justified. The maximum budget that will be provided by the ECE Department for each project is normally $500. Some projects may have additional funding from other sources; Goodman or your facilitator will inform if your budget extends beyond $500. Pizza and Pepsi are not allowable costs. (Note that all components must be ordered through the ECE Shop, or they must give you advance authorization to purchase parts yourself – otherwise, there will be NO reimbursement for purchases you make.)
Additional
Proposal Information
The proposal must be no more than fifteen typed pages, which includes the cover page. The cover page must include the project title, design team number and facilitator name, document type (i.e., Pre-Proposal or Final Proposal), names of all design-team members, current date, and a short executive summary (see notes from class lectures re content of executive summary) of what the proposed project involves—i.e., purpose/goals and expected results/impact. Be sure to number all pages after the cover page. The remaining pages of the proposal should expand on the executive summary.
Your proposal should contain the following main sections:
Cover page (including executive summary),
Table of Contents;
Introduction (e.g., overview of the problem, customer needs/requirements);
Background (e.g., preliminary research by the team, results from previous projects, related work by other engineers, etc.);
Objectives or Design Specification (e.g., mission statement, list of objectives, product design specification (including identification of design criteria and limits to be used in matrices below));
FAST Diagram (as taught in Quality Function Deployment lecture) [Note: in final proposal, but does NOT need to be included in preproposal before covered in class.]
Conceptual Design Descriptions (words, numbers, components, schematics, drawings, or other brief descriptions);
Ranking of Conceptual Designs, including a feasibility matrix and a selection matrix, with explanation of the importance factors and non-obvious ratings assigned;
Proposed Design Solution (including design methodology, appropriate diagrams or figures, and build and test plan -- evaluation plan -- how will you know that your design team has been successful?)
Risk Analysis (preliminary risk analysis with statement of concerns/challenges)
Project Management Plan (including personnel & tasks, facilities/resources, schedule);
Budget,
References (list of references used in preparing proposal, book, articles, web sites, etc.)
Pay special attention to the following aspects of your proposal content and/or style:
1. Include a table of contents page.
2. Include
a section called References that lists literature consulted (referring to
articles read, reports referenced, web sites, library references, etc.)
3. Label
each figure and table
4. Include diagrams of hardware and software systems showing components and functionality. Review your presentation of design criteria and need/risk analyses to be sure they are complete and consistent.
5. Review the formatting used in the document to be sure it is consistent (e.g., spacing, font type/size, etc.).
6. Review your management/summary section to be sure that you have identified how you will evaluate the results of your project -- how you will determine success.
As each design team plans its activities (as part of preparing Gantt chart), it is important to keep in mind the following activities and milestones that may not all be relevant to your project, but that may impact the availability of your time to work on your project:
1. First version of your design team's web page in place by the beginning of Week 4.
2. Design teams give oral presentations describing their project to their facilitator, in their regular meeting, by the end of Week 4 at the latest.
3.
Preproposals are due
to facilitator at your meeting in Week 4. Submit the pre-proposal electronically
as an attached MS Word file by
4. Preproposals will be reviewed by your facilitator and returned at your next meeting (in Week 5). You should do a “dry run” of your oral proposal presentation for your facilitator in Week 5.
5.
Final proposals are due no later than
6. Design teams give an oral presentation of their proposal during Week 6 (schedule to be announced).
7.
Design teams prepare the first written progress
report due on Friday, Week 9, at
8. Design teams deliver a demonstration of progress during Week 9.
9. Each design team gives a technical talk on some assigned aspect of their project during weeks 11-13 (schedule to be announced).
10. Applications notes are due from each individual to the facilitator at your meeting in Week 11.
11. Design teams deliver a second demonstration of progress for the facilitator, during Week 12.
12. Design teams prepare the second written progress report, due during Week 12. (Submit electronically to facilitator.)
13.
Design issues paper due Friday, Week 12, to
Goodman, on paper, in class or by
14. A variety of assessments, course evaluations, departmental evaluation, etc., are performed in class during week 14.
15. Professional Self-Assessment Report is due from each individual on Monday of Week 14, to facilitator. Final reports are due to Goodman and facilitator electronically by 4:30pm Wednesday, December 3, and will be provided to external judges on Thursday.
16. Final oral presentations and posters are due on Friday of Week 15 (at Design Day). Prepare two identical posters. Give one to your sponsor after Design Day, or if not possible, bring both back to the lab. One must be mailed to sponsor and the other left in lab for ultimate display in the hall.
17. Final project demonstrations for Goodman and facilitator, if project is not fully demonstrable at Design Day on Friday, will be Thursday of Week 15 at times to be scheduled, in the Laboratory. All other demos will be during Design Day on Friday, in the MSU Union. External judges from industry will judge projects, including final oral presentation, for awarding of Prism Venture Partners Prizes, a Best Poster Prize, the Provost’s Prize, and other awards.
18. All final deliverables, including two copies of a CD-ROM containing all materials submitted by individuals and teams, including all documentation, are due at your team's oral presentation time on Friday of Week 15, the last day of classes.
19.
All materials to be returned to ECE Shop must be
turned by