Your SlideShare is downloading. ×
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Professional project writing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Professional project writing

562

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
562
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Chapter 16: The projectChapter 16: The project Introduction For this unit you are expected to undertake an individual software- engineering project and to submit a project report to London. You should take some care in selecting a project topic and preparing for this substantial task. To achieve good results in this unit you will need to devote substantial time to this project and ensure that you work on your project consistently over the year. In past years some students have failed their project because they started work on it too late or failed to keep work up throughout the year. There is no way that you can ‘rush’ the project at the last moment. You should also understand that the idea of the project is to demonstrate an understanding of the software engineering process and professional practices. It is not intended to be about producing computer programs for their own sake. In fact, you are not required to deliver a fully running computer program with your project. The crucial part of your project is the description of the development process which is a model-based task. You are merely required to implement parts of your system in order to demonstrate that the design you have created can actually be translated into program code, and to undertake some testing of the crucial parts. The time you devote to your project will be of benefit to you when it comes to sitting the examination. The experience of developing your own project will show through in the examination, and will provide you with important examples of how systems development works in practice. You will know what you are talking about. Indeed the problems, frustrations, moments of breakthrough, difficulties and joy you will feel undertaking this work are the same as those experienced by software engineers in their daily work. In a section below, I provide some ideas of possible projects that you might like to consider. You are, however, encouraged to develop your own project idea for small and medium scale software systems. In general, you should understand that we are looking for a system that allows you to carry out a software engineering process which leads to a model of a complete system. At the end of the project these models should be capable of being easily developed as software code. This should also include some small coded elements of the significant parts of the project – for example to demonstrate and test how a crucial algorithm is performed. Students coming to this unit are expected to have some experience of various package environments including databases and spreadsheets. You are also expected to have a general understanding of programming and some programming skills (through the units Elements of information and communication technologies and/or Introduction to Programming). While you will probably undertake some programming, and so develop these skills, you should understand that the main emphasis of this unit is not to teach you more programming, but rather to concentrate on the intellectual work that leads up to and surrounds the coding activity. Details on how to submit the project and the date by which the entire project must be in London are given in the booklet Completing and submitting coursework and projects which all students taking this unit 113
  • 2. Software engineering: theory and application should receive. This booklet is revised each year, and you should make sure that you have the most recent edition. The booklet contains the exact deadlines for each year, the forms required to accompany your project and details of how to submit the project. Overview The project, which counts for 40 per cent of the final mark, is intended to: • take you through the process of developing a sophisticated piece of software, tackling a realistic problem • provide practical demonstrations of the key issues discussed in the subject guide. It is when doing the project that you will come to realise the importance of good requirements analysis and design, the benefits of setting up a proper testing process and the problems of keeping to deadlines and managing projects • be an enjoyable experience where you can make the mistakes that you will learn from. In order to complete the project you are required to produce a number of documents. It is very important that you maintain coherence between the documents you create. In addition to these documents, you are expected to write a final project report. The main section of the final project report provides a summary of the lessons you learned, what went well and what you would do differently next time. You should note that the focus of the project is not on the system produced, but on the quality of the process undertaken, the coherence of the documents presented, and how successful the documents would be in developing a software system. One way to think of the project is as an attempt to produce a set of documents which could be sent to an outsourcing company to ask them to produce a system for you. Your aim is to produce a set of documents which would enable the outsourcer to understand what was needed, and go ahead and produce the complete software system. The project as a development process The aim of the project is to give you the experience of the processes and practices of software engineering. As such, we intend you to undertake the process of analysing and designing a software product, and submit to us the documents you used in this process. This means that the documents should be the practical documents you would use to develop the system. Before you hand in your project, you could of course go back over your individual documents again and edit them. However, although you could go back and change, for example, an initial system requirement so that they match exactly (and surprisingly) your final design, this is not what the examiners are looking for. We are much more interested in how you progressed through the various stages of your project than in the final result. In the past many students have achieved a poor mark in their project, because they have paid too much attention to one part of the process (usually coding the software) and far too little attention to the coherence of their development process overall. A project that has many problems throughout its development process may be rated as highly as one where everything went well. What is important is that the project documents114
  • 3. Chapter 16: The project demonstrate how problems faced were addressed. Examiners are much more interested in seeing a genuine learning effort that uses the methods and techniques of software engineering than a running system. Remember that even professionally produced software regularly fails – we are looking for the professional approach to software design. Examiners would be happy to see a page in the later stages of design which said something like ‘The initial user requirement for XYZ was unachievable as it conflicted with the other requirement for ABC. It is therefore decided that XYZ is to be dropped from the design.’ This is the kind of thing seen in real software engineering projects all the time, so why should your project be any different? When you write and edit your project, remember Brook’s comment (1995): ‘Most documentation fails in giving too little overview; the trees are described, the bark and leaves are commented, but there is no map of the forest. To write a useful prose description, stand way back and come in slowly’. It is essential that your documents form a coherent project in which the examiners can see how the individual development stages have been carried out and how they relate to the previous and the following stages. Finally, remember we are very unlikely to reward the ‘software hacker’ who works through the night to come up with a wonderful piece of software without bothering to undertake requirements analysis or design properly, by faking the testing, and by ignoring proper planning. Yes, this person might produce something which looks impressive, but do not expect marks for producing a system in a way that does not take into account requirements, and which is likely to be unreliable and dangerous.Choosing your development tool You are encouraged to make use of development tools in your project; however, this is not a formal requirement so do not feel you have to. You may want to use modelling tools, design tools etc. In addition you will need to produce small amounts of software to demonstrate how aspects of the design will operate. For this you may either want to choose a programming language, like for example Pascal, Visual Basic, C++ or Delphi. Alternatively, you may want to choose a spreadsheet or database package. Although programming languages offer the greatest flexibility, some application areas may be best suited to, for example, a database package. Your choice should depend on the kind of application you are designing and the development tool you have access to. If you choose the object- oriented development approach for your project you will probably want to use an object-oriented language to undertake any coding. Although the project does not require you to write the program code for a fully running system, you will have to do some programming of some of the important parts. It is essential that you start to acquire the necessary programming skills as soon as possible. The unit Elements of information and communication technologies and possibly Introduction to programming has given you an introduction to the component parts of a program. You should be able to use these concepts within the programming language you have chosen. You are not expected to write the code for a fully running and complete system. You must, however, deliver sufficient coding to demonstrate how a small number of complex elements of your design can be translated into code. As such you are only expected to produce programming stubs rather than a complete system. 115
  • 4. Software engineering: theory and application A programming stub is a small section of code which a developer uses to demonstrate a principle or idea, and to test that it works. A programming stub might implement a single Class, or even just one of a class’s methods, if that method undertakes complex processing (for example an Order class might have a method GetPrice() which calculates the prices by processing a range of inputs. You could produce a programme stub to test that you understand how this would work, and that your design is correct). This is not the same as pseudocode as a programming stub must be written in a programming language so that it can be tested. They are usually pretty short (at most a couple of pages in length) and implement the most difficult parts of the system (so the developer can test and verify the important parts of the system before we waste time on the easy parts). It is also usual to develop some kind of interface to interact with the programming stub (for example a way of reading a file of attributes, of calling the program stub with these attributes, and of displaying or saving the returned parameters). Examples of other things you might implement are: • some user interface screens, since these may be needed to produce your user manual • if you use a database you will need to provide most of the database schema • if you are using data files you will need to describe their format. Additionally, you should remember that it is very important that you explain any programming stubs etc. you provide. They should be written with sensible variable names, and plenty of comments in the code. You should describe how they would be used within the complete system, and how they relate to the design activity. Finally, you should provide details of what components require further implementation. You are required to provide a printed copy of the source code you produce as an appendix to your project. In addition, you should submit a disk containing executable versions of the parts of the system which have been coded. These do not necessarily need a user interface (you could just ask for input from the command line, or by reading a file), but must be relatively easy for the examiner to try. Those students who are very keen to implement a complete system rather than just programming stubs can do so. Such students should however remember that only a small proportion of the marks is allocated for the programming component of the project, and therefore it is not likely to drastically improve their marks and could damage their marks by diverting their attention from the important tasks. Reuse Reuse is an important part of software development, and you are encouraged to reuse code or models and patterns, and auto-generated code, to aid you in your development of the programming stubs. However, to avoid charges of plagiarism you must make it clear which elements of your project constitute reuse. All that we ask is that you indicate to us the pieces of code that you did not write (or alternatively highlight the pieces you did) and tell us where the code you are reusing came from (by referencing its source). You should do this on the source- code that you submit as part of your report; for example, why not put all your own code in bold or italic, or you could put comments into the code where the auto-generated or reused part starts and ends. This allows you to116
  • 5. Chapter 16: The project download small sections of code from the Internet and use them as long as you highlight to us that you are reusing the code. If you fail to do this you could be accused of plagiarism (cheating), rather than being rewarded for taking advantage of reuse.Suggested projects You are expected to choose your own project to work on. A suitable project will probably have most of the following characteristics: It will: • handle some real world data of non-trivial complexity • require a user-interface tailored to some defined user (who should not be you) • undertake some processing/calculation/selection on the data it contains. Conceptually a project does not have to be very big to present a real challenge – as the examples below show, a database type application tailored to some particular domain is a good starting point. Projects that do not contain a substantial software analysis and design component are not suitable. For example developing a computer game is not appropriate as it does not have specific user requirements (other than perhaps being enjoyable for users!). When choosing a topic, remember that you need a project that will enable you to demonstrate your understanding of the whole software engineering process. Below is a list of projects you may choose from if you wish:A personal data management system This would consist of a small database management system used to record personal information such as details of records and books, information about recipes and so on. There may be a diversity of information recorded, and the system should be easily used by people without a computer background.A photograph library sales system This records and retrieves information about photographs in a library and the worldwide sales of these photographs. It should support keyword classification and retrieval requests for different types of photographs. It should maintain details of fees received and due for each photograph that is published. Again, the system should be designed for use by people who are not familiar with computing aspects.An online recipe and meal planner This could compute the overall nutritional value of a meal, summarise the necessary ingredients, and estimate costs. It might also be able to suggest a meal given ‘I want to use up this corned beef’ or ‘I’m out of eggs and lettuce’.A personal organiser for a university lecturer This would schedule the lecturer’s teaching, send reminders when necessary (possibly through an e-mail system), perhaps co-ordinate with other lecturers’ (or even students’) calendars for scheduling meetings, and so on. Printing parts of the calendar on demand is a must. Questions that such an organiser should be able to answer include ‘What’s up for today?’ 117
  • 6. Software engineering: theory and application or ‘Let’s see next week at a glance’ or ‘What in the world was I doing last Tuesday?’ or ‘On what day of the week for the next four weeks is there an hour free starting at 10:00?’. A terminal reservation system for a computer terminal room This would be an automated sign-up sheet for a collection of terminals (and possibly other resources). People should be able to express preferences for various times. The system should include facilities for administrators to collect and print statistics on usage as well as a scheduling algorithm to ensure fair distribution of resources among users. It should be easy to change the scheduling algorithm. (Ignore the fact that you need to use a terminal to sign up for a terminal. For example, assume that one is reserved for this purpose.) An online holiday planning system for a busy department This allows staff to choose and book when they are on holiday. It might also need details such as who is taking over the person on holiday’s work, where they can be contacted etc, and maybe make sure that important people are not off at the same time. An online system for managing bookings This might be for a cruise liner or railway. Deliverables The deliverables are split into three sections. The first section involves planning how you will approach the software engineering project. The second section contains all the documents you produce in undertaking the project (the models etc). The third section asks you to assess your project critically, and reflect on the learning it has given you. Deliverables section 1: project description and planning This section is an important task as you need to ensure that you can complete all the necessary documents on time. You should not take it lightly, and should use project management techniques to help you plan. You should ensure that you produce a timetable for undertaking the project, including plenty of contingency time should things go wrong and including time off, holidays etc. It is important that you balance the demands of this project with the need to study the subject and relax. Remember that the project accounts for 40 per cent of your mark, and should therefore constitute no more than 40 per cent of the time you put to study software engineering. The project can expand to fill the time available, so make sure you limit this by planning your activity well and sticking to your timetable. Indeed, it is better to decide to cut your project down (for example by ignoring certain requirements) so that you can finish it than to hand in a half-completed project. If you need to do this you must explain why you took this decision in your document. It is essential that you stick to your timetable in order to avoid severe time pressure towards the end of the project and to get maximum benefit from the project. Remember that you will be marked on the entire development process and not only on the end product. If you start your project too late118
  • 7. Chapter 16: The project you will not have enough time to carry out all the stages that are part of software development. In no less than two pages you should summarise the project you propose to work on: • Give your system a name. • Describe what the system will do and who its users will be. What needs will your system satisfy? How will it help the users? • Outline the most important features of your system. • Describe the physical environment in which your system will be used including any other systems with which the new system will interface. • Are there any important performance goals for your system: time or space efficiency, security or reliability? On another two to three pages you should describe the software engineering process you intend to employ, and how this is relevant to the system you describe: • Outline the basic principle of the chosen approach (including references to relevant literature on this approach). You should also establish the software development paradigm you have chosen (i.e. structured or object-oriented). • Discuss why this process is suited to the problem previously described. • Provide a very detailed timetable for the activity you are going to undertake and a detailed plan of the documents you will be providing and how they will address the need for requirements analysis, design and elaboration, approaches to implementation, documentation of the system, and testing. You can use diagrams such as Gannt charts for this if you wish. • Consider any problems you might envisage encountering and how you intend to manage such risk. You can also use this section to plan how you will manage the development project and keep to your timetable.Deliverables section 2: the software engineering practice documents In the next section of your project you must provide documents which outline how the software engineering process was undertaken in terms of analysing the user’s requirements, undertaking design, elaborating that design, approaching implementation, documenting the system and undertaking testing. The format for this section depends on the software engineering processes you have decided to follow (as detailed in section 1). Examples of the documents you might produce for different software engineering processes: Pressman chapter 2 provides a good description of various software development processes and the types of documents which might be produced. Below we provide examples of the different sections which might be produced for projects following different development processes. 119
  • 8. Software engineering: theory and application For a project following the software development lifecycle the contents of the section may look like this: 1. Requirements analysis. (a) Introduction. (b) Functional requirements and conceptual model. (c) Non-functional requirements. (d) Hardware. 2. Detailed requirements analysis. 3. Design. 4. User manual and maintenance manual. 5. Coding of key algorithms and database schema. 6. Testing document. In contrast, a student trying to follow the Rapid Application Development approach (clearly without the team working elements) might have a document of this form (or similar): 1. Cycle 1 (a) Business modelling. (b) Data modelling. (c) Process modelling. (d) Stub application generation using Visual Basic. (e) Testing and turnover. 2. Cycle 2 (a) Further business modelling using feedback. (b) Further data modelling. (c) Further process modelling. (d) Application elaboration and changes. (e) Testing and turnover. 3. Cycle 3 4. User manual of the final system. Finally, a project which is following the spiral model might have the following sections (or similar): 1. Spiral 1 (a) Customer communication. (b) Planning documents – construction of task sets. (c) Risk analysis. (d) Engineering (including analysis and design) of tasks. (e) Construction and release of algorithms central to the problem and considered of high risk. Construction and release of prototype user interface. (f) Requirements planning. 2. Spiral 2 (a) Risk analysis. (b) Prototype 2 construction (including simulations of a small user interface). (c) Detailed requirements and requirements validation. (d) Development planning.120
  • 9. Chapter 16: The project 3. Spiral 3 (a) Risk analysis. (b) Prototype 3 construction (including simulation and benchmarking of core algorithms). (c) Design of the complete software product. (d) Validation of the design. (e) Test planning. 4. Spiral 4 (a) Risk analysis. (b) Further design activity to elaborate section 3(c). (c) Implementation of core algorithm code. (d) Unit testing. (e) Acceptance testing. 5. User documentation of system.Note that just because some of these projects have many more sections, itdoes not mean that they should be longer in length, nor involve morework. You should also try to avoid unnecessary repetition in yourdocuments. For example you do not need to include every test case youundertook.Note that each of these examples differs in some way from the waytextbooks describe the processes. This is expected as it is unlikely that aproject that is undertaken by one developer who has little experience willprecisely follow a formal software development project. You should decidewhich sections you need.Whatever form your documents take, they must include descriptions ofhow you undertook the following activities:You must document how you captured requirements and turned theseinto designThis should include some description of the need for the system and placethe system into context, briefly describing its functions and presenting arationale for the software system.Functional requirements – the conceptual modelYour documents should describe the functions that the system will perform(i.e. it should present the conceptual model of the requirements of yoursystem). This means that you will have to model your functionalrequirements applying (for example) levelled data flow diagrams, entity-relationship diagrams if you are following the structured approach, and youwill have to produce use-case diagrams and class diagrams if you opt forobject orientation.It is very important that you document your modelling processes verycarefully. You are expected to explain how they support the further analysisof your particular problem domain. However, keep in mind that you are notsupposed to give an explanation of how exactly certain modellingtechniques such as, for example, data flow diagrams work.Non-functional requirementsYou should state all non-functional requirements, such as technicalconstraints or security requirements, your system might have. 121
  • 10. Software engineering: theory and application Hardware If the system is to be implemented on special hardware, this hardware and its interfaces should be described. If off-the-shelf hardware is to be used, the minimal and optimal configuration on which the system may execute should be set out here. You must document how you approach the design of the system You must outline the top level decisions you have made, and how these decisions were broken down into components, how these components are linked, etc. The overall design within structural software development, for example, is concerned with determining the modules and how the modules are linked and interact with each other. For this purpose you would have to apply structured design and create structure charts from your data flow diagrams. The overall design within an object-oriented approach requires you to model interaction and object behaviour using sequence diagrams and statecharts. After this you will need to describe how you elaborated these designs, adding sufficient detail to them so that it can be used as a reference from which any competent software engineer can produce code, set up the testing process, and write a user manual and a system maintenance guide. The detailed design should include answers to all of the questions for as many levels as possible. The detailed design within structured development, for example, will have to provide the details of the algorithms used within the individual modules. The detailed design within an object-oriented approach involves the exact definition of classes (with their attributes and operations) and the messages sent between objects. You may want to use pseudocode (an outline of programming code) in order to represent the details required within detailed design. During the design process you should focus on the parts of the design that are essential to producing a core system. You only need to outline the extensions to a more complete system. Also, do not waste time and energy repeating the details for parts that have a similar structure. Instead you should give one design example and explain which parts (and why) follow the same or a similar design pattern. One of your major goals is to develop a model that is complete by the deadline. This is not expected to be the full system. It is essential that you review the entire design process to ensure that everything has been covered, that the parts of the documents hang together, and that the design can be related to the requirements. The user manual This document should be a self-contained description of how to use your system. A user manual should be a polished, professional piece of technical prose that a software company is proud to have accompanying one of their products. (Also, it is a handy accomplishment to show off at job interviews.) The document should have a structure that is evident both to someone reading it straight through and to someone looking for a particular topic or fact. A table of contents is required, and the organisation it reflects should be considered carefully. An index and appendices might also be helpful.122
  • 11. Chapter 16: The projectRemember, the document should be completely self-explanatory. Do notassume the reader has seen your functional specification. You may, ofcourse, edit in sections of prose from your previous documents. Do notdiscuss any implementation unless it directly affects the user’s interface tothe system.Your document ought to cover the list of topics below. The exact order inwhich you present material and whether certain topics are combinedshould be dictated by your particular project and your own style of writing.• Introduction: a concise statement of what your program does, possibly including motivation and philosophy.• How to use your system: an overall description of the style of user interaction, device constraints, and any arbitrary design choices you made that the user ought to know about.• Detailed system operations: an organised list of all the user commands and when they are appropriate. Some examples (preferably with screenshots) might be helpful. Also, it is often appropriate to divide the user manual into a novice section and an expert section.• Error recognition and handling: what are the errors that might occur, and how can they be handled?• An extended example: show exactly what the user may have to type or what buttons he might have to press (and why) and how the system responds (and why).• A list of known ‘features’ and deficiencies: everyone complains about how cryptic current computer manuals are. This is your chance to show us what a good manual looks like.Outline of the programming stubs/examples you have produced as partof your design activityYou do not need to implement the complete software; however, you doneed to produce some of the key algorithms – for example, you may needto implement a couple of classes or models to demonstrate how they wouldbe achieved. These should be included in your documents along with adescription of what they are for and how they work. You should alsohighlight any code-reuse, and ensure that the code is commented andconsistent with the design and requirements.A description of the testing you undertook as part of the softwareengineering processTesting is an important part of a software project. Testing needs toaccommodate both system verification and validation. The software teammust carefully plan the different testing stages, develop a schedule of whenthey are to be carried out, design the test cases that are needed andeventually collect and evaluate the test results. Accordingly, the softwareteam must document the order in which modules or classes are to beintegrated and the order in which the individual modules or classes are tobe tested in isolation. Testing and debugging methods must also be agreedupon, documented, and eventually carried out.The purpose of a testing document is to convince the management (in thiscase, the examiners) that a feasible testing approach has been designed andundertaken. You are expected to schedule several stages of your tests.Scheduling is required for unit testing, integration testing, and validation 123
  • 12. Software engineering: theory and application testing. You should note that the schedule of testing, and the tests undertaken, will vary depending on the software development process you have chosen. In documenting your testing you should include an introductory section that summarises how testing was undertaken. This should include a description of how testing was planned and undertaken in detail. Remember that this description is intended for several audiences. The document should be organised so that it is easy to find schedule summaries and monitoring plans. Your description of the testing should contain the following components: • a statement of the objectives and success criteria • an integration plan • a plan of the testing techniques and test cases used • a testing schedule • a summary of the test results and debugging procedures applied. These components are described in more detail below. Objectives and success criteria The testing document should contain a statement of the overall testing objectives and the objectives of the individual tests that are planned. Integration plan It is important to decide the order in which modules or classes are to be combined and therefore the order in which they will be tested individually. You must plan for individual module tests, the combination of modules during integration testing, and a validation test that tests the functionality of your system. The testing document should describe and justify your integration method. The ‘big bang’ method of integration is not acceptable, but many variants or combinations of top down and bottom up integration (or an appropriate alternative within an object-oriented approach) are acceptable if convincingly defended. Testing techniques and test cases You should design a plan to test all of the modules (or classes) of your system. Your testing document should state what kind of testing technique is applied to test the components of your system, and it should explain why a particular technique has been chosen. It is very important that you establish the test cases you will use. Keep in mind that a test case includes the test input and the expected output against which the actual test output will be compared. You do not need to carry out your tests for all components. However, you will want to employ some basic testing techniques to test the main algorithms within your system (those implemented as programming stubs). The purpose of this is that you demonstrate that you are able to select and employ some relevant testing techniques. Schedule The testing document should provide a schedule describing the dates of the different tests to be carried out within your chosen software engineering process. First, determine an order in which to perform integration and validation (functional) tests. This order should be used to determine the124
  • 13. Chapter 16: The project order in which the individual modules (components) are to be tested. Determine the dates by which tests are to be completed. Finally, you must define a monitoring procedure to ensure that tests are designed and carried out on schedule. There must also be a procedure for reporting and correcting bugs. Note that if you are following a evolutionary approach your schedule may include many cycles of activity. Test results and debugging procedures Finally, you should interpret the outcome of your tests and report on the errors that have been found and the action taken to locate and correct them.Deliverables section 3: the final project report The purpose of the final report is to give an overview and evaluation of your entire project. This is an important document for the markers as it is used to evaluate what you have learnt from your project and from the process you have chosen. The document should be around two pages long. The document provides an opportunity to step back and put things in perspective and appreciate how much you have accomplished. In your report you should cover the following issues. • What changed: You should discuss how well your project satisfied the users. Did it do what they wanted? What did you leave out and why? • The software process: Were you satisfied with the chosen approach? What problems did you encounter? Where did you break from the usual approach to the process? • Developing the system: Do you think your document could really be used to develop a software system? What is missing? What is going to be difficult for someone to follow? Note you will not lose marks for highlighting problems with your system. • Management: Compare the actual time spent on the project with your predicted times. Have your learned anything that will help you make better predictions next time? • Lessons learnt: Here you should list the things you have learnt from doing the project. • Final comments: If there is anything that you really want to get off your chest about the way you did the project that would be valuable for other students, you should put them into this section. Finally, on a separate set of pages you should include the following: • Bibliography: You should list the books and papers which you used to help you develop your system. These should not be the standard textbooks and can include manuals, web sites and journal articles. • Software used: List the software you used in developing your system. 125
  • 14. Software engineering: theory and application Marking the project: In marking the project the examiners will be looking explicitly for the following main elements: 1. The completeness and correctness of the report (around 50 per cent of the marks). In particular, they will ensure that you have chosen a relevant process, that you have followed your outlined process well with requirements being captured, design undertaken, the design elaborated, a user manual being written, a small amount of relevant programming stubs being produced which reflect the design, and that relevant and appropriate testing was undertaken. A project which is problematic can gain some marks for correctness by reflecting on the problems in the final report. 2. The coherence and structure of the report (around 30 per cent of the marks). Examiners will give marks on how coherent the development paradigm and process are, how well they are followed, and that the project holds together as a complete system. For example, marks will be lost if the data structures in the coding stubs are not related to the initial designs, ER diagrams or Class diagrams. 3. Sophistication (around 20 per cent). Examiners will award some marks for how sophisticated the project is – this is not simply in terms of how complex the problem addressed is, but also how sophisticated the process is, how well the techniques are applied and how well the document is written and presented.126

×