Khaled Almotairi Modified by Majid Algethami Seminar Starting a Project

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

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

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)

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

List criteria, requirements, and constraints

Heuristics, Guidelines, Standards and Specifications

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

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

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

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

Ideas: an accident caused by a stray camel d=home.regcon&contentid=

Writing a Technical Documents

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!

Types of Technical Documents Letters Memos s Specification documents Bids and proposals Reports

Letters Introduction Body: - Purpose of the letter -Desired outcome -Some actions to take Closing statements

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

s 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 is sent over the Internet, so it is unsecure Don’t send unencrypted if it contains very sensitive (classified) documents A company or an organization inspects any incoming or outgoing (you will lose privacy)

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: 1. Introduction and scope: the purpose of the product or service 2. List of requirements

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

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

Elements of Technical Reports Front MatterFront cover Title page Abstract (or Executive summary) Key words Contents List of figures List of tables List of symbols Preface Acknowledgments BodyIntroduction Theory and Analysis Experimental Procedures Results and Discussion Conclusion(s) Back MatterReferences Appendix

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

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

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

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

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

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

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

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

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.

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

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

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.

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

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

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