Open Source VLSI design tools suitable for Final year BE Project works
VLSI design has become an important area for most of the ECE, EEE and CSE final year Projects. However,using commercial VLSI CAD is usually ends up in problems during project demonstration, since the environments used in Project centres/ Industry are rarely reproducible in academic institutions.
This article provides some insight on the most popular open-source CAD tools that can be used in the academic field.
Electic tool shows the best compatibility with different platforms, and also have plenty of design and check functions in a friendly user interface.
Magic tool, which has a long history in VLSI design, has the best technical support and documentation, and it provides both stable and development versions for different use. It is very attractive to the academic institute users.
Alliance tool, which can only run in Unix/Linux platforms, has the best usage stability and good balance in functions. But its popularity is limited by its strict operation system requirement. Even in Linux, it requires a re-compile with specific compiler. It also increases the complexity of the installation.
In conclusion, Electric tool is highly recommended for Windows users. Yet, in Unix/Linux
systems, Electric doesn’t have significant advantage as it does in Windows. Magic and Alliance are also competitive for their own features. Magic may be more suitable for education that focuses on software development and Alliance may be good for education that focuses on design skill. This comparison is hopefully useful for those who are looking for a suitable VLSI CAD tool for academic purposes.
Microcontroller
embedded.system
RESTFUL
Monday, December 20, 2010
Saturday, December 18, 2010
Zigbee What is it?
ZigBee is the set of specs built around the IEEE 802.15.4 wireless protocol. The IEEE is the Institute of Electrical and Electronics Engineers, a non-profit organization dedicated to furthering technology involving electronics and electronic devices. The 802 group is the section of the IEEE involved in network operations and technologies, including mid-sized networks and local networks. Group 15 deals specifically with wireless networking technologies, and includes the now ubiquitous 802.15.1 working group, which is also known as Bluetooth®. The standard itself is regulated by a group known as the ZigBee Alliance, with over 150 members worldwide.
Tuesday, December 14, 2010
Guide to Final year UG Projects
introduction
The project work is by far the most important single piece of work in the BE degree programme which provides the opportunity for the student to demonstrate his individualism and ablity, to plan and organize a large project and to put into practice some of the techniques which have been taught during the course. Whatever be level of academic achievement so far, students can put in to play their skills and innovation in project work. It can be the most satisfying piece of work of the career as a student.
The idea for your project might have been derived from a proposal of a member of staff or of your own, or perhaps from a combination of the two. Whatever be the case, we will look into each possibily and understand their strengths and weakness
Staff Proposals
When a student selects project proposed by members of staff he should discuss it, with the proposer as soon as possible . Note that not every project is suitable for every one. Some may only suit students with a very specific set of interests. Each proposal has to be understood clearly in order to make an informed choice.
Own Proposals
When a student decides on project title of his own, it is his responsibility to find a member of staff, who approves of the proposed programme of work and is willing to supervise it. He should first add his proposal to the Project database, then discuss it with prospective supervisors. The Project Coordinator will be happy to help and find a supervisor. But student cannot simply assume that one can be found in every case.
Methods to score high marks
It is important to understand the way a project will be assessed. A good project plan consists of background research and solid implementation scheme. An useful tip is to try to think of the project as an "investigation", rather than an effort to deliver a fully-functional "product". Proper evaluation of the project is thus crucial to obtain high scores.
The very best projects invariably have to cover some new ground, Example: Developing a complex application which does not exist now, or enhancing the capabilities of some available application or new methods to improve its utility, performance etc.
Project implementation, without literature survey may also be allowed, but you must appreciate that it is unlikely to gain high marks, regardless of how well it is done. Likewise, projects which are predominantly survey reports, unless they are backed up with experimentation, implementation, or theoretical analysis, can't fetch good scores.
Choosing the right project
The projects offered by staff may vary substantially in breadth, depth and degree of complexity. The most important thing is to shortlist a set of projects that are right for you . Some students are better suited to well-defined and relatively safe projects that provide scope for demonstrating proficiency with a low risk of failure. Other students are better advised to tackle harder, riskier projects that require a high degree of original input and/or technical problem solving skills. If you are looking to score high marks in your project and, particularly, if you are hoping to win project contests, or obtain "Distinguished Project" status for your work , you should shortlist projects with special care. The supervisors will be happy to offer advice on the suitability of a project, knowing your individual background, strengths and ambitions. Remember that it is much more important to balance ambition and your ability for making a good choice.
Final allotment
The allotment method requires you, to specify one preferred project and two extras. If you choose from the published proposals your first choice of project cannot be guaranteed since individual supervisors can only take responsibility for a limited number of projects. In some cases you may be allocated your first choice but another member of staff will be assigned to supervise it. Failing this, you will be allocated one of your other choices. It is important to appreciate the fact that the enthusiasm and interest of the supervisor is one key factor contributing to a successful project. Some students are disappointed when they do not get their preferred choice. However, you should bear in mind that it is much better to be supervised by an enthusiastic proposer of a `second choice' project, rather than by someone who has reluctantly agrees to supervise a `preferred choice' project on behalf of the original proposer.
Resources & backups
Students are permitted to develop software or hardware outside campus, provided that he can duplicate it here in College for the demonstration day.
If student requires non-standard resources, specific hardware or software or access to specific machines, he must make his own arrangements to bring and install the same.
Note that there is no excuse for failing to keep adequate backups on his standby computer. If he fails to protect his program or data or report, for whatever be the reasons he will simply lose marks. No period extensions are given at the end of the project to re-type a lost report, for example.
Meeting with Supervisors
Student must make sure that he arranges regular meetings with supervisor. The meetings may be brief, once project is under way but supervisor needs to know that work is progressing. If student needs to talk to supervisors between meetings and cannot locate them in their office, leave a note, or send mail, asking them to suggest a time when they will be available. When student goes to see supervisor (or second marker) he should have prepared a written list of points to discuss. student should take notes during the meeting so that he will not forget the advices given or the conclusions reached.
Project Report Format
understand its vital role :The project report is an extremely important aspect of the project. It helps you to show to others what you have achieved and should demonstrate that:
You understand the wider context of subject by relating your choice of project and the approach taken, to existing products or research.
You can apply the theoretical and practical techniques taught in the course to the problem you are addressing and understand their relevance to the wider scope of subject.
You are capable of objectively look at, your own work and make constructive suggestions for improvements or further work based on your experiences so far.
As a professional, you can explain your thinking and working processes clearly and concisely to third parties, who may not be a expert in the field in which you are working.
Most of the project assessors will not have time to follow the project throughout and will only have a short spells to listen to a presentation or see a demonstration. For this reason, they will rely heavily on the report to judge the project. You should appreciate that the external examiners, who play a crucial role in the final recommendation, have only the report to judge your project performance.
Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get your due worth, you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document.
Physical layout and formatting of the report is also important, and yet it is very often neglected. A tidy, well laid out and consistently formatted document makes far easier reading and is suggestive of a careful and professional attitude towards its preparation.
Remember that quantity does not automatically guarantee quality. A 150 page report is not twice as good as a 75-page one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are vital in programming. This will be rewarded appropriately. Try to ensure that your report contains the following elements.
Title page
This should include the project title and the name of the author of the report. You can also list the name of your internal guide. Refer university recomentations for details.
Abstract
The abstract is a very brief summary of the report's contents. It should be about half a page long. Someone unfamiliar with your project, should gain good idea of what the project is about when he reads the abstract alone and will know whether it is of interest to him.
Acknowledgements
It is necessery to thank those individuals who have particularly provided useful assistance, technical or otherwise, during preparation of your project. Your guide will obviously be pleased to be acknowledged as he or she would have invested quite a lot of time overseeing your progress.
Contents page
This should list the main chapters and (sub)sections of your report. Choose self-explanatory chapter and section titles and use double spacing for clarity. you should include page numbers indicating where each chapter/section begins. Try to avoid too many levels of sub headings - three levels is generally sufficient.
Introduction
This is one of the most important section of the report. It should begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by a even a curious reader. It should state briefly everything you aim to achieve, provide a clear summary of the project's background, relevance and main contributions. The introduction should set the scene for the project and should provide the reader with a summary of the key things to look out for . When detailing the contributions it is helpful to provide pointers to the section(s) of the report that provide the relevant technical details. The introduction itself should be largely non-technical. It is sometimes useful to state the main objectives of the project as part of the introduction.
Literature survey
The literature survey section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The background section can be included as part of the introduction but is usually better as a separate chapter, especially if the project involved significant amount of prior research. The published work may be in the form of research papers, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Your must acknowledge the sources of your material. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context.
Body of report
The central part of the report usually consists of three of four chapters detailing the technical work undertaken during the project. The structure of these chapters is highly project dependent. They can reflect the chronological development of the project, e.g. design, implementation, experimentation, optimization, evaluation etc., although this is not always the best approach for every case. However you choose to structure this part of the report, you should make it clear how you arrived at your chosen approach in preference to the other alternatives documented in the background. If you have built a new piece of software you should describe and justify the design of your program in detail. It should also document any interesting problems faced or features of, your implementation. Integration and testing are also important to discuss in some cases. You need to discuss the content of these sections thoroughly with your guide.
Evaluation
Simply building a system and documenting its design and functionality is not enough to gain high marks. It is extremely important that you evaluate what you have done both in absolute terms and in comparison with existing techniques, software, hardware etc. This might involve quantitative evaluation, for example based on numerical results, performance etc. or something more qualitative aspects, such as functionality, ease-of-use etc. At some point you should also evaluate the strengths and weaknesses of what you have done. Avoid statements like "The project has been a complete success and we have solved all the problems. It is important to understand that there is no such thing as a perfect project. Even the very best pieces of work have their limitations and you are expected to provide a proper critical appraisal of what you have done.
Conclusions and Future Work
The project's conclusions should list the things which have been learnt as a result of the work you have done. It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for doing the project better if you had a chance to do it again, turning the project deliverables into a more polished end product, or extending the project into a topic for an MPhil or PhD etc.
Bibliography
This consists of a list of all the books, articles, manuals etc. used in the project and referred to in the report. In the case of reports You should provide enough information to allow the reader to find the source. You should give the full title and author and should state where it is published, including full report issue number and date, and page numbers where necessary. In the case of a text book you should quote the name of the publisher as well as the author(s). A weakness of many reports is inadequate citation of a source of information. It's easy to get this right so there are no excuses.
Appendix
The appendices contain information which is peripheral to the main body of the report. Information typically included here are things like parts of the code, tables, proofs, test cases or any other material which would break up the theme of the text if it appeared in situ. You should try to bind all your material in a single volume if possible.
User Guide
For projects which result in a new piece of equipment/device you should provide a proper user guide clear instructions on how to use it. A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your system. Technical details of how the package works should be in the body of the report. Keep it concise and simple. The extensive use of diagrams illustrating the package in action prove particularly helpful. The user guide is sometimes included as a chapter in the main body of the report, but is often better in an appendix.
Program Listings
Complete program listings should not be part of the report except in specific cases .
Internal assesments
The initial assessment of the project will be undertaken by the guides. The assessment will then be completed by the assessment team which is made up by supervisors and some more teaching staff / researchers who are interested in the subject area. The team members will attend your presentation and agree on team mark. The team marks are later moderated to ensure that the marks are globally consistent. The projects are marked under the following headings:
Theoretical works
This component assesses the way you arrived at your initial project specification, and list of objectives. It particularly addresses the background research undertaken and the manner in which your approach and programme of work, fits in with the current state of the art. It is worth about 15% of the final mark.
General Competence
This assesses your overall approach to the project and your ability to overcome the inevitable complications which arise. The specific areas in which you will be assessed are management and organisation, reliability and punctuality, overall technical competence, and your individual contribution to the project. This part of the assessment is worth about 25% of the final mark.
Technical achievement
This assesses the main technical output from the project. It addresses specific issues such as the design, correctness, elegance, usability etc. of the final product and the significance of the work in relation to the state-of-the-art. It is worth about 30% of the final mark.
Report
This part of the assessment is worth about 30% of the final mark.
The Project Presentation and Demonstration
One of the most important skills which the individual project aims to assess is your ability to communicate your ideas and work. As part of the assessment you will be required to give a presentation and demonstration of your project to your assessment team. Each presentation will be time tabled for between 30 and 40 minutes (to be announced) including a demonstration, where appropriate and viva. Your supervisor and second marker will be part of the team but you should bear in mind that the majority members of the assessment panel, will not be familiar with your project; you should take this into account when planning your presentation. Your supervisor can help you to structure your talk and will be willing to go through it, with you beforehand. The presentation is not assessed separately but is a compulsory component of the project. The assessment team will not allocate any mark, for a project unless there had been a formal presentation. The objective of the presentation is to find out exactly what you have done and to ensure that you get due marks that is consistent with other projects. It is not designed as an opportunity to shoot you down!
Bear in mind, that if you develop any software or hardware on your own kit, then you have to duplicate this kit here in College. It is your responsibility to ensure that the project works on that kit or to bring your own items for the presentation.
The Prize Finalists Day
The top projects recommended by each assessment team will be reviewed shortly after the presentations and a shortlist of prize finalists may be drawn up. These "prize finalists" will be invited to re-present their work at a special celebration event open to the department, alumni and invited guests from industry. All finalists will receive a special award from the Department. At the end of the day there will be a vote for a "Best Presentation" award and the departmental project prizes will be decided some time afterwards on the basis of the presentations, reports and assessment team comments. The end-of-year Prizes will be distributed during important an occasion like "college day".
IMPORTANT: Before submission of report for final assessment, you should create a sub directory in the Project administration Computer system of your college which contains all your software, READMEs etc. and your project report (source files and pdf or postscript). Make sure this directory is readable! On the last page of your hard copy report you should print the directory path so that your project can be accessed electronically whenever needed. You can update this any time after submission of the report but a version of it should exist at the time of submission.
Pitfalls
Some of the most useful things to know about individual projects are the common pitfalls. Why do some projects go horribly wrong? Here are some of the common causes of failure:
Choosing/Starting the project too late. Submit your project request form on time and start the project as soon as you can. The longer you leave it the harder it is to get motivated, especially when all your friends seem to be flying ahead. You should aim to have completed a substantial part of the project 1 month ahead of practical exam starting date.
Failing to meet your supervisor regularly. If you arrange a meeting with your supervisor, turn up at the agreed time. If you are stuck for any reason and you have no meeting arranged, contact him or her immediately. You gain no sympathy from anyone if you lose contact with your supervisor and produce a poor project as a result. Your supervisor will be happy to help you but they can do nothing if they are unaware that your are having trouble.
Allowing too little time for the report. You should try to produce as much of your report as you can as you go along, even though you don't know in advance its exact structure. The last two weeks of the project should be dedicated to pulling together the material you have accumulated and producing a polished final product. You can spend time improving any implementation after you have submitted the report.
Failing to plan a fall-back position if the planned work is not completed on time. Try to plan your project in stages so that if things go wrong in a later stage you have a completed stage to fall back on.
Trying to satisfy an external customer at the expense of your grades. Do not let any outside interests interfere with your work. The guidance for your project should come from your supervisor, not your prospective employer.
Over/Under Ambition. Try to be realistic about what you can achieve in the time available. A good project requires a lot of input from you and should prove to be technically challenging throughout. At the same time, however, it is better to do a small job well than to fail on a big job . Your supervisor will advise you on his or her expectations of the project and this will help you to set your sights accordingly.
More important than the project is, however, your Theory exam revision.
The site under construction
introduction
The project work is by far the most important single piece of work in the BE degree programme which provides the opportunity for the student to demonstrate his individualism and ablity, to plan and organize a large project and to put into practice some of the techniques which have been taught during the course. Whatever be level of academic achievement so far, students can put in to play their skills and innovation in project work. It can be the most satisfying piece of work of the career as a student.
The idea for your project might have been derived from a proposal of a member of staff or of your own, or perhaps from a combination of the two. Whatever be the case, we will look into each possibily and understand their strengths and weakness
Staff Proposals
When a student selects project proposed by members of staff he should discuss it, with the proposer as soon as possible . Note that not every project is suitable for every one. Some may only suit students with a very specific set of interests. Each proposal has to be understood clearly in order to make an informed choice.
Own Proposals
When a student decides on project title of his own, it is his responsibility to find a member of staff, who approves of the proposed programme of work and is willing to supervise it. He should first add his proposal to the Project database, then discuss it with prospective supervisors. The Project Coordinator will be happy to help and find a supervisor. But student cannot simply assume that one can be found in every case.
Methods to score high marks
It is important to understand the way a project will be assessed. A good project plan consists of background research and solid implementation scheme. An useful tip is to try to think of the project as an "investigation", rather than an effort to deliver a fully-functional "product". Proper evaluation of the project is thus crucial to obtain high scores.
The very best projects invariably have to cover some new ground, Example: Developing a complex application which does not exist now, or enhancing the capabilities of some available application or new methods to improve its utility, performance etc.
Project implementation, without literature survey may also be allowed, but you must appreciate that it is unlikely to gain high marks, regardless of how well it is done. Likewise, projects which are predominantly survey reports, unless they are backed up with experimentation, implementation, or theoretical analysis, can't fetch good scores.
Choosing the right project
The projects offered by staff may vary substantially in breadth, depth and degree of complexity. The most important thing is to shortlist a set of projects that are right for you . Some students are better suited to well-defined and relatively safe projects that provide scope for demonstrating proficiency with a low risk of failure. Other students are better advised to tackle harder, riskier projects that require a high degree of original input and/or technical problem solving skills. If you are looking to score high marks in your project and, particularly, if you are hoping to win project contests, or obtain "Distinguished Project" status for your work , you should shortlist projects with special care. The supervisors will be happy to offer advice on the suitability of a project, knowing your individual background, strengths and ambitions. Remember that it is much more important to balance ambition and your ability for making a good choice.
Final allotment
The allotment method requires you, to specify one preferred project and two extras. If you choose from the published proposals your first choice of project cannot be guaranteed since individual supervisors can only take responsibility for a limited number of projects. In some cases you may be allocated your first choice but another member of staff will be assigned to supervise it. Failing this, you will be allocated one of your other choices. It is important to appreciate the fact that the enthusiasm and interest of the supervisor is one key factor contributing to a successful project. Some students are disappointed when they do not get their preferred choice. However, you should bear in mind that it is much better to be supervised by an enthusiastic proposer of a `second choice' project, rather than by someone who has reluctantly agrees to supervise a `preferred choice' project on behalf of the original proposer.
Resources & backups
Students are permitted to develop software or hardware outside campus, provided that he can duplicate it here in College for the demonstration day.
If student requires non-standard resources, specific hardware or software or access to specific machines, he must make his own arrangements to bring and install the same.
Note that there is no excuse for failing to keep adequate backups on his standby computer. If he fails to protect his program or data or report, for whatever be the reasons he will simply lose marks. No period extensions are given at the end of the project to re-type a lost report, for example.
Meeting with Supervisors
Student must make sure that he arranges regular meetings with supervisor. The meetings may be brief, once project is under way but supervisor needs to know that work is progressing. If student needs to talk to supervisors between meetings and cannot locate them in their office, leave a note, or send mail, asking them to suggest a time when they will be available. When student goes to see supervisor (or second marker) he should have prepared a written list of points to discuss. student should take notes during the meeting so that he will not forget the advices given or the conclusions reached.
Project Report Format
understand its vital role :The project report is an extremely important aspect of the project. It helps you to show to others what you have achieved and should demonstrate that:
You understand the wider context of subject by relating your choice of project and the approach taken, to existing products or research.
You can apply the theoretical and practical techniques taught in the course to the problem you are addressing and understand their relevance to the wider scope of subject.
You are capable of objectively look at, your own work and make constructive suggestions for improvements or further work based on your experiences so far.
As a professional, you can explain your thinking and working processes clearly and concisely to third parties, who may not be a expert in the field in which you are working.
Most of the project assessors will not have time to follow the project throughout and will only have a short spells to listen to a presentation or see a demonstration. For this reason, they will rely heavily on the report to judge the project. You should appreciate that the external examiners, who play a crucial role in the final recommendation, have only the report to judge your project performance.
Many students underestimate the importance of the report and make the mistake of thinking that top marks can be achieved simply for producing a good product. This is fundamentally not the case and many projects have been graded well below their potential because of an indifferent or poor write-up. In order to get your due worth, you should consider that the aim of the project is to produce a good report and that software, hardware, theory etc. that you developed during the project are merely a means to this end. Don't make the mistake of leaving the write-up to the last minute. Ideally you should produce the bulk of the report as you go along and use the last week or two to bring it together into a coherent document.
Physical layout and formatting of the report is also important, and yet it is very often neglected. A tidy, well laid out and consistently formatted document makes far easier reading and is suggestive of a careful and professional attitude towards its preparation.
Remember that quantity does not automatically guarantee quality. A 150 page report is not twice as good as a 75-page one. Conciseness, clarity and elegance are invaluable qualities in report writing, just as they are vital in programming. This will be rewarded appropriately. Try to ensure that your report contains the following elements.
Title page
This should include the project title and the name of the author of the report. You can also list the name of your internal guide. Refer university recomentations for details.
Abstract
The abstract is a very brief summary of the report's contents. It should be about half a page long. Someone unfamiliar with your project, should gain good idea of what the project is about when he reads the abstract alone and will know whether it is of interest to him.
Acknowledgements
It is necessery to thank those individuals who have particularly provided useful assistance, technical or otherwise, during preparation of your project. Your guide will obviously be pleased to be acknowledged as he or she would have invested quite a lot of time overseeing your progress.
Contents page
This should list the main chapters and (sub)sections of your report. Choose self-explanatory chapter and section titles and use double spacing for clarity. you should include page numbers indicating where each chapter/section begins. Try to avoid too many levels of sub headings - three levels is generally sufficient.
Introduction
This is one of the most important section of the report. It should begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by a even a curious reader. It should state briefly everything you aim to achieve, provide a clear summary of the project's background, relevance and main contributions. The introduction should set the scene for the project and should provide the reader with a summary of the key things to look out for . When detailing the contributions it is helpful to provide pointers to the section(s) of the report that provide the relevant technical details. The introduction itself should be largely non-technical. It is sometimes useful to state the main objectives of the project as part of the introduction.
Literature survey
The literature survey section of the report should set the project into context by relating it to existing published work which you read at the start of the project when your approach and methods were being considered. There are usually many ways of solving a given problem and you shouldn't just pick one at random. Describe and evaluate as many alternative approaches as possible. The background section can be included as part of the introduction but is usually better as a separate chapter, especially if the project involved significant amount of prior research. The published work may be in the form of research papers, articles, text books, technical manuals, or even existing software or hardware of which you have had hands-on experience. Your must acknowledge the sources of your material. You are expected to have seen and thought about other people's ideas; your contribution will be putting them into practice in some other context.
Body of report
The central part of the report usually consists of three of four chapters detailing the technical work undertaken during the project. The structure of these chapters is highly project dependent. They can reflect the chronological development of the project, e.g. design, implementation, experimentation, optimization, evaluation etc., although this is not always the best approach for every case. However you choose to structure this part of the report, you should make it clear how you arrived at your chosen approach in preference to the other alternatives documented in the background. If you have built a new piece of software you should describe and justify the design of your program in detail. It should also document any interesting problems faced or features of, your implementation. Integration and testing are also important to discuss in some cases. You need to discuss the content of these sections thoroughly with your guide.
Evaluation
Simply building a system and documenting its design and functionality is not enough to gain high marks. It is extremely important that you evaluate what you have done both in absolute terms and in comparison with existing techniques, software, hardware etc. This might involve quantitative evaluation, for example based on numerical results, performance etc. or something more qualitative aspects, such as functionality, ease-of-use etc. At some point you should also evaluate the strengths and weaknesses of what you have done. Avoid statements like "The project has been a complete success and we have solved all the problems. It is important to understand that there is no such thing as a perfect project. Even the very best pieces of work have their limitations and you are expected to provide a proper critical appraisal of what you have done.
Conclusions and Future Work
The project's conclusions should list the things which have been learnt as a result of the work you have done. It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for doing the project better if you had a chance to do it again, turning the project deliverables into a more polished end product, or extending the project into a topic for an MPhil or PhD etc.
Bibliography
This consists of a list of all the books, articles, manuals etc. used in the project and referred to in the report. In the case of reports You should provide enough information to allow the reader to find the source. You should give the full title and author and should state where it is published, including full report issue number and date, and page numbers where necessary. In the case of a text book you should quote the name of the publisher as well as the author(s). A weakness of many reports is inadequate citation of a source of information. It's easy to get this right so there are no excuses.
Appendix
The appendices contain information which is peripheral to the main body of the report. Information typically included here are things like parts of the code, tables, proofs, test cases or any other material which would break up the theme of the text if it appeared in situ. You should try to bind all your material in a single volume if possible.
User Guide
For projects which result in a new piece of equipment/device you should provide a proper user guide clear instructions on how to use it. A particularly useful approach is to treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all the features of your system. Technical details of how the package works should be in the body of the report. Keep it concise and simple. The extensive use of diagrams illustrating the package in action prove particularly helpful. The user guide is sometimes included as a chapter in the main body of the report, but is often better in an appendix.
Program Listings
Complete program listings should not be part of the report except in specific cases .
Internal assesments
The initial assessment of the project will be undertaken by the guides. The assessment will then be completed by the assessment team which is made up by supervisors and some more teaching staff / researchers who are interested in the subject area. The team members will attend your presentation and agree on team mark. The team marks are later moderated to ensure that the marks are globally consistent. The projects are marked under the following headings:
Theoretical works
This component assesses the way you arrived at your initial project specification, and list of objectives. It particularly addresses the background research undertaken and the manner in which your approach and programme of work, fits in with the current state of the art. It is worth about 15% of the final mark.
General Competence
This assesses your overall approach to the project and your ability to overcome the inevitable complications which arise. The specific areas in which you will be assessed are management and organisation, reliability and punctuality, overall technical competence, and your individual contribution to the project. This part of the assessment is worth about 25% of the final mark.
Technical achievement
This assesses the main technical output from the project. It addresses specific issues such as the design, correctness, elegance, usability etc. of the final product and the significance of the work in relation to the state-of-the-art. It is worth about 30% of the final mark.
Report
This part of the assessment is worth about 30% of the final mark.
The Project Presentation and Demonstration
One of the most important skills which the individual project aims to assess is your ability to communicate your ideas and work. As part of the assessment you will be required to give a presentation and demonstration of your project to your assessment team. Each presentation will be time tabled for between 30 and 40 minutes (to be announced) including a demonstration, where appropriate and viva. Your supervisor and second marker will be part of the team but you should bear in mind that the majority members of the assessment panel, will not be familiar with your project; you should take this into account when planning your presentation. Your supervisor can help you to structure your talk and will be willing to go through it, with you beforehand. The presentation is not assessed separately but is a compulsory component of the project. The assessment team will not allocate any mark, for a project unless there had been a formal presentation. The objective of the presentation is to find out exactly what you have done and to ensure that you get due marks that is consistent with other projects. It is not designed as an opportunity to shoot you down!
Bear in mind, that if you develop any software or hardware on your own kit, then you have to duplicate this kit here in College. It is your responsibility to ensure that the project works on that kit or to bring your own items for the presentation.
The Prize Finalists Day
The top projects recommended by each assessment team will be reviewed shortly after the presentations and a shortlist of prize finalists may be drawn up. These "prize finalists" will be invited to re-present their work at a special celebration event open to the department, alumni and invited guests from industry. All finalists will receive a special award from the Department. At the end of the day there will be a vote for a "Best Presentation" award and the departmental project prizes will be decided some time afterwards on the basis of the presentations, reports and assessment team comments. The end-of-year Prizes will be distributed during important an occasion like "college day".
IMPORTANT: Before submission of report for final assessment, you should create a sub directory in the Project administration Computer system of your college which contains all your software, READMEs etc. and your project report (source files and pdf or postscript). Make sure this directory is readable! On the last page of your hard copy report you should print the directory path so that your project can be accessed electronically whenever needed. You can update this any time after submission of the report but a version of it should exist at the time of submission.
Pitfalls
Some of the most useful things to know about individual projects are the common pitfalls. Why do some projects go horribly wrong? Here are some of the common causes of failure:
Choosing/Starting the project too late. Submit your project request form on time and start the project as soon as you can. The longer you leave it the harder it is to get motivated, especially when all your friends seem to be flying ahead. You should aim to have completed a substantial part of the project 1 month ahead of practical exam starting date.
Failing to meet your supervisor regularly. If you arrange a meeting with your supervisor, turn up at the agreed time. If you are stuck for any reason and you have no meeting arranged, contact him or her immediately. You gain no sympathy from anyone if you lose contact with your supervisor and produce a poor project as a result. Your supervisor will be happy to help you but they can do nothing if they are unaware that your are having trouble.
Allowing too little time for the report. You should try to produce as much of your report as you can as you go along, even though you don't know in advance its exact structure. The last two weeks of the project should be dedicated to pulling together the material you have accumulated and producing a polished final product. You can spend time improving any implementation after you have submitted the report.
Failing to plan a fall-back position if the planned work is not completed on time. Try to plan your project in stages so that if things go wrong in a later stage you have a completed stage to fall back on.
Trying to satisfy an external customer at the expense of your grades. Do not let any outside interests interfere with your work. The guidance for your project should come from your supervisor, not your prospective employer.
Over/Under Ambition. Try to be realistic about what you can achieve in the time available. A good project requires a lot of input from you and should prove to be technically challenging throughout. At the same time, however, it is better to do a small job well than to fail on a big job . Your supervisor will advise you on his or her expectations of the project and this will help you to set your sights accordingly.
More important than the project is, however, your Theory exam revision.
The site under construction
Subscribe to:
Posts (Atom)