seminar starting a project

Click here to load reader

Upload: tess

Post on 14-Feb-2016

37 views

Category:

Documents


1 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Seminar Week # 3

Khaled Almotairi

Modified byMajid AlgethamiSeminarStarting a Project

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

Problem selectionEvaluate 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 selectionRequires use of computer engineering prerequisites (courses) Can be built by students Requires use of other resources (faculty, library, computers, software)

Characteristics of good design practiceGood design practices enable difficult design problems to be solved.List criteria, requirements, and constraintsIdentify users and their tasksIdentify effects on the environmentGenerate multiple solutionsSelect optimal solutionsBest practiceList criteria, requirements, and constraintsHeuristics, Guidelines, Standards and SpecificationsHeuristicsA design heuristic is a general (and not necessarily actionable) rule-of-thumb based on experienceHeuristics lead to quick design solutions that often work well but may fail in some situationsGuidelinesA design guideline is a general rule based on experience and specific knowledge of the design problem that may be applied to a design solutionWe mean something more specific than heuristicsStandardA standard provides more direction about the acceptable solution space by stating technical requirements that must be satisfied by candidate designsStandards do not provide a complete solution, but do dictate a set of requirements that must be satisfied by a solutionSpecificationSpecification 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 exactlyIdeas:an accident caused by a stray camel

http://www.saudigazette.com.sa/index.cfm?method=home.regcon&contentid=2009072244395 Writing a Technical DocumentsTechnical CommunicationsWriting is perhaps the most important way in which you will convey your ideas to managers, other engineers, and customersYour communication skills will therefore determine how successful you are as an engineer, perhaps even more so than your technical expertise!Types of Technical DocumentsLettersMemosEmailsSpecification documentsBids and proposalsReports

Letters

http://3.bp.blogspot.com/-xKFIQ5eaKf8/UK-YPllUA7I/AAAAAAAAAEs/NiAruU9v9Lg/s1600/buslet.gif IntroductionBody:- Purpose of the letterDesired outcomeSome actions to takeClosing statementsMemos (memorandum)It means something to be rememberedA written communication between people within a company or an organizationIt can be forma or informal written communication

EmailsElectronic 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 printedIt can be formal or informalEmail is sent over the Internet, so it is unsecureDont send unencrypted email if it contains very sensitive (classified) documentsA company or an organization inspects any incoming or outgoing email (you will lose privacy) Specification DocumentsThe specification document is used by the engineer who design, build, or otherwise provide the productIt is basically a list of criteria or tests that determine the characteristics required of a desired product, component, process, or systemIt usually contains:Introduction and scope: the purpose of the product or serviceList of requirementsBids and ProposalsThey are offers from engineers to provide services.A bid is an offer to provide specified servicesA proposal typically suggests a means of meeting a need that has not been specified precisely and offers to provide the required serviceWhen accepted, they are part of legal contracts between the engineers and the clientsReportsReport formats vary according to their formality, purpose, and contentIt should be formal (or less formal) documentsIt can be:Journal/conference paperThesistechnical report, such as lab reportElements of Technical ReportsFront MatterFront coverTitle pageAbstract (or Executive summary)Key wordsContentsList of figuresList of tablesList of symbolsPrefaceAcknowledgmentsBodyIntroductionTheory and AnalysisExperimental ProceduresResults and DiscussionConclusion(s)Back MatterReferencesAppendixWriting StyleDepends on the audienceMore Lively Writing (usually preferred)First Person, Active Voice, Past/Present TenseMore Formal Writing Third Person, Passive Voice, Past/Present TenseNever use slang

27Writing MechanicsCheck SpellingCheck GrammarMinimize the use of AcronymsIf Acronyms are necessary, always define them at the first useNumber all equations, tables, and figuresAll tables and figures must have captions.All figures must have labeled axesAll quantities must have unitsWriting the Report: An ApproachDecide on a titleCreate a brief outline with only main section headingsCreate a more detailed outline with subheadingsCreate an executive summaryCreate the main body of textInsert tables, figures, references, and acknowledgements

The best method for presentation of technical reportsThe 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 title15% will read the abstract 4% will read also introductionthe surviving 1% will read the whole paperhttp://www.site.uottawa.ca/~ivan/presentstyle.pdf 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 abstractHere is the place for context, relation to prior work, general objective, and approach

Related workSome information on previous workPlace the most similar works to what you doHow your work is different from others

Theory and AnalysisBriefly describe the theory relevant to the workProvide design equationsInclude calculations and computer simulation results Provide values for all key parametersExperimental ProceduresDescribe Apparatus and MaterialsShow test setupsIf this section is well written, any electrical or computer engineer should be able to duplicate your results.

Results and DiscussionUse tables and graphsConsider moving large quantities of raw data, detailed derivations, or code to an appendixMethods of plotting which produce well delineated lines should be consideredResults should be critically compared to theoryConsider limitations in the theory and engineering tolerances

ConclusionSimilar to executive summaryRepeat the storyMust be conciseReinforces key ideas formed in discussionIncludes recommendations for future work, such as implementation of a design

Figures and TablesEvery figure must have a captionAll tables must have a titleFigure/tables are placed after they are mentioned in the text (all must be mentioned/discussed)Make figures/tables first, and then insert into the textPut the figure/table number beside its title, and put this in a standard locationDont start a sentence with an abbreviation: Figure vs. Fig.AcknowledgementsKeep track of those to be acknowledged-keep a diary so that you dont forget anyoneInclude: your sponsor, outside sources (companies or agencies), other departments on campus, individuals outside of your team who have helpedBe brief

ReferencesVarious formats have been developed. Pick one you like such as the IEEE Transactions formatDecide on a sequence, such as the order they appear in the textAlways 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. 25-31, Nov. 2004.[2] C. Dean, The Book of Earth-Shattering Research, Husky Press, Storrs, CT, 2005.