1 / 41

Seminar Starting a Project

Seminar Starting a Project. Khaled Almotairi Modified by Majid Algethami. Get started. Establish project team Choose topics in the problem area Determine your limits Prepare Gantt chart (timeline) . Problem selection. Evaluate topics

tess
Download Presentation

Seminar Starting a Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SeminarStarting a Project KhaledAlmotairi Modified by MajidAlgethami

  2. Get started • Establish project team • Choose topics in the problem area • Determine your limits • Prepare Gantt chart (timeline)

  3. Problem selection • Evaluate topics • Do a literature survey on problem area and topics • Determine existing solutions • Set your objectives and goals • Identify realistic design constraints

  4. Desirable criteria for topic selection • Requires use of computer engineering prerequisites (courses) • Can be built by students • Requires use of other resources (faculty, library, computers, software)

  5. Characteristics of good design practice Good design practices enable difficult design problems to be solved. • List criteria, requirements, and constraints • Identify users and their tasks • Identify effects on the environment • Generate multiple solutions • Select optimal solutions • Best practice

  6. List criteria, requirements, and constraints

  7. Heuristics, Guidelines, Standards and Specifications

  8. Heuristics • A design heuristic is a general (and not necessarily actionable) rule-of-thumb based on experience • Heuristics lead to quick design solutions that often work well but may fail in some situations

  9. Guidelines • A design guideline is a general rule based on experience and specific knowledge of the design problem that may be applied to a design solution • We mean something more specific than heuristics

  10. Standard • A standard provides more direction about the acceptable solution space by stating technical requirements that must be satisfied by candidate designs • Standards do not provide a complete solution, but do dictate a set of requirements that must be satisfied by a solution

  11. Specification • Specification refers to a description of a solution which provides all of the details. • Using a specification, an engineer should be able to reproduce a design exactly

  12. Ideas: • an accident caused by a stray camel http://www.saudigazette.com.sa/index.cfm?method=home.regcon&contentid=2009072244395

  13. Writing a Technical Documents

  14. Technical Communications • Writing is perhaps the most important way in which you will convey your ideas to managers, other engineers, and customers • Your communication skills will therefore determine how successful you are as an engineer, perhaps even more so than your technical expertise!

  15. Types of Technical Documents • Letters • Memos • Emails • Specification documents • Bids and proposals • Reports

  16. Letters Introduction • Body: • - Purpose of the letter • Desired outcome • Some actions to take Closing statements http://3.bp.blogspot.com/-xKFIQ5eaKf8/UK-YPllUA7I/AAAAAAAAAEs/NiAruU9v9Lg/s1600/buslet.gif

  17. Memos (memorandum) • It means something to be remembered • A written communication between people within a company or an organization • It can be forma or informal written communication

  18. Emails • Electronic mail is sent and received using computing devices and a network (e.g., the Internet) • It is like a memo that has not yet been printed • It can be formal or informal • Email is sent over the Internet, so it is unsecure • Don’t send unencrypted email if it contains very sensitive (classified) documents • A company or an organization inspects any incoming or outgoing email (you will lose privacy)

  19. Specification Documents • The specification document is used by the engineer who design, build, or otherwise provide the product • It is basically a list of criteria or tests that determine the characteristics required of a desired product, component, process, or system • It usually contains: • Introduction and scope: the purpose of the product or service • List of requirements

  20. Bids and Proposals • They are offers from engineers to provide services. • A bid is an offer to provide specified services • A proposal typically suggests a means of meeting a need that has not been specified precisely and offers to provide the required service • When accepted, they are part of legal contracts between the engineers and the clients

  21. Reports • Report formats vary according to their formality, purpose, and content • It should be formal (or less formal) documents • It can be: • Journal/conference paper • Thesis • technical report, such as lab report

  22. Elements of Technical Reports

  23. Writing Style • Depends on the audience • More Lively Writing (usually preferred) • First Person, Active Voice, Past/Present Tense • More Formal Writing • Third Person, Passive Voice, Past/Present Tense • Never use slang

  24. Writing Mechanics • Check Spelling • Check Grammar • Minimize the use of Acronyms • If Acronyms are necessary, always define them at the first use • Number all equations, tables, and figures • All tables and figures must have captions. • All figures must have labeled axes • All quantities must have units

  25. Writing the Report: An Approach • Decide on a title • Create a brief outline with only main section headings • Create a more detailed outline with subheadings • Create an executive summary • Create the main body of text • Insert tables, figures, references, and acknowledgements

  26. The best method for presentation of technical reports • The main key to the successful presentation is to repeat your ‘story’ four times: • Title (10 words) • Abstract (100 words) • Introduction (1000 words) • in the text (10,000 words) • Estimations show that • 80% will see only title • 15% will read the abstract • 4% will read also introduction • the surviving 1% will read the whole paper http://www.site.uottawa.ca/~ivan/presentstyle.pdf

  27. Abstract (Executive Summary) • Repeat the story of the title (What) • Why the work was done (Why) • How it was done (How) • Key results, with numbers as appropriate, conclusions, recommendations

  28. Introduction • This is not a substitute for the report, and so does not echo the abstract • Here is the place for context, relation to prior work, general objective, and approach

  29. Related work • Some information on previous work • Place the most similar works to what you do • How your work is different from others

  30. Theory and Analysis • Briefly describe the theory relevant to the work • Provide design equations • Include calculations and computer simulation results • Provide values for all key parameters

  31. Experimental Procedures • Describe Apparatus and Materials • Show test setups • If this section is well written, any electrical or computer engineer should be able to duplicate your results.

  32. Results and Discussion • Use tables and graphs • Consider moving large quantities of raw data, detailed derivations, or code to an appendix • Methods of plotting which produce well delineated lines should be considered • Results should be critically compared to theory • Consider limitations in the theory and engineering tolerances

  33. Conclusion • Similar to executive summary • Repeat the story • Must be concise • Reinforces key ideas formed in discussion • Includes recommendations for future work, such as implementation of a design

  34. Figures and Tables • Every figure must have a caption • All tables must have a title • Figure/tables are placed after they are mentioned in the text (all must be mentioned/discussed) • Make figures/tables first, and then insert into the text • Put the figure/table number beside its title, and put this in a standard location • Don’t start a sentence with an abbreviation: Figure vs. Fig.

  35. Acknowledgements • Keep track of those to be acknowledged-keep a diary so that you don’t forget anyone • Include: your sponsor, outside sources (companies or agencies), other departments on campus, individuals outside of your team who have helped • Be brief

  36. References • Various formats have been developed. Pick one you like such as the IEEE Transactions format • Decide on a sequence, such as the order they appear in the text • Always give full references such that others may find the item

  37. References (examples) • [1] A. Student and B. Professor, “Very Important Project,” in Journal of Irreproducable Research, vol. 13, no. 9, pp. 25-31, Nov. 2004. • [2] C. Dean, The Book of Earth-Shattering Research, Husky Press, Storrs, CT, 2005.

More Related