School of Computing and Information Technology
ISIT200 – Report and Formatting Guideline
DUE DATE: Friday Week 11 of session.
SUBMISSION IS VIA THE SESSION ISIT200 MOODLE SITE (No other submission, including email, will be accepted. It is your responsibility to ensure that the report is submitted by the due date.)
REQUIREMENTS FOR INDUSTRY PLACEMENT REPORT (for all BIT and BBIS students)
Students must submit, via the ISIT200 MOODLE site, a professional report presented as follows:
Heading
Description of Content
ISIT200 Coversheet
Download from MOODLE site and submit with registration.
Confirmation Email
Attach a copy of your confirmation email that you received when you submitted your registration form.
1. Work experience organisation
A
ief overview of the company/organisation and their IT management practices. Include an outline of where you fit into the organisation structure XXXXXXXXXXwords).
1. 1 Log
A log should be completed at the end of each week containing a summary of the tasks that were performed. You also need to ask yourself the question ‘What aspects of the BIT, BBIS or BICT degree have assisted you to do these tasks?’ Some ideas are: awareness of cu
ent IT issues, technical knowledge (eg: programming, web page development), problem solving skills, teamwork skills, communication skills (oral and/or written). This should be in the form of a three (3) column table with the following headings: Week Number; Tasks; Comments.
2. Degree Improvements
Suggest improvements to the BIT and BBIS course. Justify your answer with examples. (200 words).
2.1 Evaluation of Industry Placement
An evaluation of your placement with regard to its impact on you. For example, are you still committed to your career direction or have new avenues been opened to you? (500 words).
2.2 Tips and Suggestion
To assist in the preparation of other students about to undertake a placement and how to best maximise the placement in point form (500 words). A selection may be displayed on the Industry Placement website.
3. Reference
A SCANNED COPY of a reference, on the company/organisation letterhead with signature from your employer, which may refer to your work performance, but should include the length of time you were employed and the nature of the tasks that you ca
ied out. If a personal reference is unavailable we need a formal acknowledgement from the company/organisation of your attendance. It is your responsibility to obtain the reference letter from your employer upon completion of the placement.
4. Appendix
A list of companies/organisations you approached and the responses received.
5. Cu
iculum Vitae
A copy of your CV.
GRADE
Fail/Pass/Credit/Distinction and High Distinction grades are NOT given for this subject NOR will marks be allocated. You will receive a grade of either Satisfactory (S) or Unsatisfactory (U).
The grade will be recorded in ISIT200 MOODLE site.
Your report is not returned so please make sure you do NOT provide originals of important documents (eg: your references).
Furthermore, please note that this subject does not count in the calculation of weighted average marks.
Your report will be assessed by the Industry Placement Coordinator.
If you require an extension, you need to complete an Academic Consideration application as per Student Academic consideration policy www.uow.edu.au/about/policy/uow060110.html
ISIT200 - Industry Placement Report Requirements – Autumn 2014 – Version 1 - Page 1 of 2
Criteria
Marks
Feedback
Introduction and Functionality Statement
0.8/1
You introduction could benefit with some more technical background for your project, including the domain-driven design and microservices (e.g., what they are and why they have been used).
Your functionality statement is a good start, but you could incorporate more of a business perspective that identifies the value of the functionality to your business domain.
Architecture
0.8/1.5
You have included some details about the application structure in your diagram in terms of the microservices. However, your diagram seems to imply that the three microservices share a database, which is inco
ect.
The main purpose of this section is to explain the layered architecture (i.e., presentation (controller) layer, service/application layer, domain (model) layer and an infrastructure layer) and how your project packages align with these. However, you have not included this information. In future, you should provide a clear description of each layer in the context of each service, including visual aids like screenshots of your package structure.
The bulk of your source code is not runnable. You have included a smaller package to run, but this is a single service rather than two microservices as everything is included in the same package and runs on the same port. A key feature of microservices is that they’re independent.
UML Diagram and Domain Class Patterns
2.3/4
All attributes should be listed above the horizontal line in your UML diagram, as anything written below is typically interpreted as a method. Your first diagram does not follow standard UML notation. You should try to avoid this and stick to UML standards.
Some associations in your second diagram do not reflect the expectations of the business domain. For instance, a plane ticket does not board a flight. Your associations do not have to follow a linear path, so you should redesign them to more accurately reflect the business domain. You should implement your multiplicities in your code using annotations.
In future, you should try to include everything into one comprehensive diagram to better demonstrate the relationships across the business domain. Your diagrams should contain more domain model classes to better represent the complexity of your business domain. Additionally, you have not implemented some of your identified domain classes, which you should do try to do in future (unless you explicitly state it has not been implemented in your text).
You are cu
ently missing the Event and Domain Service domain design patterns. Additionally, you should provide more explanation as to why certain classes fall under certain patterns. For example, you could mention the immutability of attributes in value objects.
Data Ownership
0.7/1
Your data ownership table should identify which database data is stored in (e.g. flight service database). Additionally, your data ownership is oversimplified owing to your limited number of domain model classes.
Use Cases and REST Requests
2/3
Your use of a standard use case format is great; however, your use cases and your REST requests should be linked. You have not included enough use cases under your use cases heading (even based on your REST requests, CRUD of the same domain class is considered one use case in Task B). You were also required to include at least three use cases involving data transfer between your services.
The use of tables for your REST requests is a good idea. However, you have only included requests for cmd and not for Linux/MacOS.
README.md and Document Layout
1.3/1.5
You should try and include some headings in your README.md file. Additionally, your sample responses for the REST requests should be presented in the README.md file.
The layout of your documentations is great.
Total
7.9/12