seminar starting a project
Download
Skip this Video
Download Presentation
Seminar Starting a Project

Loading in 2 Seconds...

play fullscreen
1 / 41

Seminar Starting a Project - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Seminar Starting a Project' - tess


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
seminar starting a project

SeminarStarting a Project

KhaledAlmotairi

Modified by

MajidAlgethami

get started
Get started
  • Establish project team
  • Choose topics in the problem area
  • Determine your limits
  • Prepare Gantt chart (timeline)
problem selection
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
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
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
heuristics
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
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
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
  • 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
Ideas:
  • an accident caused by a stray camel

http://www.saudigazette.com.sa/index.cfm?method=home.regcon&contentid=2009072244395

technical communications
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
Types of Technical Documents
  • Letters
  • Memos
  • Emails
  • Specification documents
  • Bids and proposals
  • Reports
letters
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

memos memorandum
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
emails
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)
specification documents
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
bids and proposals
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
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
writing style
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
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
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 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

abstract executive summary
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
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
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
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
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
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
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
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
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
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
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.
ad