Tuesday, April 21, 2015

Unit 8: Managing ICT Projects Unit 7: Using Database Software (Exam) UNIT 9 WEBSITE DESIGN AND MANAGEMENT A2 class notes pass papers


Applied ICT
Key Stage 5 students have the option to follow the AS and A2 Edexcel Applied ICT course.

WHAT WILL I STUDY?
Students of the Edexcel GCE in Applied ICT will learn how to use appropriate ICT tools and techniques to carry out investigations, handle data, solve problems and manage projects. The AS qualification develops students’ communication and decision-making skills, while the A2 level introduces students to key aspects of the ICT practitioner role

Title of course: Edexcel AS Applied ICT
Entry Requirements: BTEC Level 2 in ICT, GCSE ICT C or above or equivalent
What is Edexcel AS Applied ICT? All Edexcel GCE qualifications in Applied ICT are designed to give learners broad skills, knowledge and understanding of the ICT sector. In particular, they will encourage learners to develop:

• A broad range of ICT skills and knowledge of the uses of ICT in vocational contexts, as a basis for progression into further learning in ICT-related fields, including progression from AS to A2
• Knowledge and understanding of the components, functions and applications of information systems within a range of organizations
• An understanding of the main principles of solving problems using ICT and development of the skills necessary to apply this understanding. In addition, Advanced GCE specifications encourage learners to:
• Apply their knowledge and understanding of ICT and use skills (e.g. planning, research, evaluation, problem solving) in vocational contexts
• Develop an understanding of the impact of information systems on organizations’ personnel, policies and practices
• Develop project management skills and an understanding of the need to work with others. What can I do at the end of the course? This qualification supports progression into further education, training or employment. Appropriate further education might be:
• A BTEC Higher National in Computing
• A BTEC Foundation Degree in Computing
• A degree in computing, IT or related fields. The qualification is not designed to prepare learners for direct entry into employment. How the applied course will delivered?
All Single Award Advanced GCE qualifications in this suite comprise six equally-weighted units and contain an Advanced Subsidiary subset of three AS units.
The AS is the first half of a GCE course and contributes 50 per cent of the total Advanced GCE marks. The A2, the second half of the Advanced GCE, comprises the other 50 per cent of the total Advanced GCE marks. The guided learning hours for the three-unit Advanced Subsidiary GCE (Single Award) are 180. The guided learning hours for the six-unit Advanced GCE (Single Award) are 360.



Year 1
Unit 1: The Information Age (application to use: FrontPage)
We are living in an age in which an enormous amount of information (television broadcasts, text messages, photographs, news reports and emails) is produced, communicated and stored in digital format every day. The pace of development is very fast. In this unit, you will learn about the information communication technologies that enable people to access and exchange information and to carry out transactions anytime, anywhere. This unit is internally assessed.
• Online Services: Looking at the different Online Services that is available on the Internet e.g. emails, education e-commerce etc
• Life in the Information Age: This will look at how people lives are affected by the Information Age e.g. Working Styles, Communication, Banking and Shopping etc.
• The digital Divide: Looks at how technology affects society and the difference between countries in respect with technology. This topic also looks at ways to bridge the gap of the digital divide e.g. Political, Social
• E-book: This topic looks at how to create an E-book to report you finding of the Information Age. A choice of application could be used for this e.g. FrontPage, Word, and PowerPoint etc. Topic for

Unit 2: The Digital Economy (application to use: Database AND FrontPage)
Paperless transactions are hallmarks of the digital economy. In the global e-marketplace, transactional websites are the interface between e-enabled customers and organisations, allowing them to do business with one another anytime, anywhere. Enhanced connectivity underpins the growth of the digital economy. In this unit, you will investigate how organisations are responding to the pressures of the e-marketplace. This unit is internally assessed.
• Information in modern organisation: This topic looks at how diferent organisations uses ICT
• Doing business on the web: Looking at how Transitional website does business on the web
• Running a transitional Website: what is involved in running a Transitional website, looking at how information is flowed and the process leading to an online purchases
• E-customers: This looks at the shop front, ways in which the transitional website uses to attract and retain customers
• Designing the back office database: creating an Organization Chart showing how the transitional website works
• Building and using a database: Build a relational database and creating Queries and Reports
• Data and the Law: Looking at the different laws that have come into place as well as the risk to PERSONAL DATA on the Internet

Unit 3: The Knowledge Worker (applications: Spreadsheets)
In this Information Age computers and communications technology provide many of us with access to vast quantities of information. As ICT users, we need to make judgements about sources and accuracy of information and be able to select and manipulate information to support sound decision making. In this unit, you will learn about making informed decisions using the knowledge available to you. This unit is externally assessed.
• Collecting information: You need to be able to collect information and predict outcomes from the said data
• Analyzing information: Being able to study a scenario and Identify and understand the problems
• Using and reefing a Model: When given a skeleton Model is able to import data and refine the model using the given Scenario

Year 2
Unit 7: Using Database Software (Exam)
In this unit you will develop your knowledge of, and skills in using, databases further. You will learn the principles of data modelling and sound database design, and will use relational database software to build working database systems capable of storing large quantities of data and of handling both routine and one-off requests for information. This unit is externally assessed.
In this unit you will develop your knowledge of, and skills in using, databases further.
• You will learn the principles of data modelling and sound database design
• Relational database software to build working database systems capable of storing large quantities of data and of handling both routine and one-of requests for information.

Unit 8: Managing ICT Projects
This unit will introduce you to some formal project management tools and methods and give you an opportunity to use specialist software to plan and monitor projects.
You will be able to put into practice what you have learnt by setting up and running a small-scale software project. You will have to draw on the knowledge and skills you have learned throughout the course in order to plan for and produce the required software product. This unit is internally assessed.
• This unit will introduce you to some formal project management tools and methods
• Give you an opportunity to use specialist software to plan and monitor projects.
• Setting up and running a small-scale software project

Unit 10: Using Multimedia Software
In this unit you will increase your understanding of the features and possibilities of these and other tools so that you can combine them to produce well-designed multimedia products that communicate your ideas effectively. This unit is internally assessed.
• Your work for this unit will culminate in the design, development and testing of an interactive multimedia product for a specified target audience.
• You will establish the functional requirements of the product at the outset and carry out formative evaluation and testing throughout its development. You will learn the importance of seeking and making use of feedback from others to help you in your work.
• The summative evaluation of your work for this unit will include a self-assessment of your current skill level and an indication of what else you need to know or be able to do in order to further
UNIT 9 WEBSITE DESIGN AND MANAGEMENT A2
UNIT 10 MULTIMEDIA TECHNOLOGY A2
UNIT 11 APPLICATION SOFTWARE DEVELOPMENT A2
UNIT 12 VISUAL PROGRAMMING A2
UNIT 14 IMPLEMENTING a BUSINESS SOLUTION

WHAT ARE THE OPPORTUNITIES AFTER A LEVEL?

The specification has been developed for students who wish to progress to higher education or to the world of work, where understanding how ICT can be used in society and organisations, and the implications of its use, will be a valuable asset.
This booklet will give you advice on preparing for these A2 coursework units. A2 

UNIT 8 DATABASE DEVELOPMENT A2 UNIT 8 DATABASE DEVELOPMENT
This unit is meant to demonstrate your understanding of the importance of database technology and develop database skills. It will show your knowledge of database technology and modelling concepts.
You will need to demonstrate skills such as normalisation to 3NF, relational database structures, querying databases and the development of a relational database model. You will have to design, implement, test and document a database solution to a problem of your choice. You must show evidence of project management skills. The documentation you present in your portfolio should have a professional feel to it and should demonstrate an appropriate style for work at this level. 

YOUR COURSEWORK PORTFOLIO SHOULD BE BOUND APPROPRIATELY.
In this Unit you must produce a working relational database system which you have designed to meet your user’s specified requirements. It is strongly recommended that your portfolio should be presented using the following format and headings: Candidate Record Sheet This document should be signed by both you and your teacher. Contents Page If you choose to include a contents page with accurate page numbers it will significantly enhance your work. It will demonstrate a style commonly found in reports of this nature. Working database system
 The project should begin by you giving an in depth description of the current system as it exists. This should set the scene for the work that is to follow. Before you can build a new system, you must thoroughly understand how the current system works. This section should describe in detail what the current system does and what problems it contains. (It is possible to show this using DFD (symbols are listed on Page 84 of the specification) which display the context and overviews of the current system.) Users Needs Based on your investigation of the current system, a clear statement of users’ needs should be listed. As far as possible these should be quantitative.

Examples of users needs: ƒ The system should produce a report for all customers who are more that 60 days overdue in their payments. ƒ The system should be able to list all customers who live in Lisburn and are under 21 years of age. ƒ The system should list all the appointments for all employees for each working day. ƒ The system should allow new users details to be entered. ƒ It will be possible to find out a complete customer order history from this system. ƒ It will be possible to find out details of an order if an order code is input 

A2 UNIT 8 DATABASE DEVELOPMENT Examples of user’s needs that should avoided include: ƒ The system will be fast ƒ The system will find a record in 10 seconds ƒ
The system will be user friendly ƒ The system will use macros to print out reports ƒ The system will use complex queries to …. ƒ The system will use tables to hold data or similar non-quantitative objectives or objectives that use technical language. Remember these objectives are a ‘wish list’ of what the user wants and so should be expressed in non-technical lay-persons language. The reason for producing the users requirements in a quantitative list is that it will allow, in the evaluation section (later), you to comment on whether the requirements were met (or not). Project Plan This is a plan that you should set out at the beginning of your work. It will be a programme of activities and resources you will use within a timeframe over the life time of the project design. You should use a recognised project management tool to document this. An example of a project management tool would be a GANTT chart (examples of GANTT charts can be found on the exemplar paper 7 Investigating Systems (a synoptic unit)).
See CCEA website at http://www.rewardinglearning.com/development/qualifications/gce/docs/suppo rtdocs/appliedict_unit7_exemplar_paper.pdf Other Gantt chart examples can be found at: http://www.ganttchart.com/. It is also possible to use EXCEL as a project management tool – see http://office.microsoft.com/en-ca/assistance/HA010346051033.aspx 

A2 UNIT 8 DATABASE DEVELOPMENT Design specification This section of your report should show ‘bottom up’ data modelling activities you have carried out to produce your database design. ƒ Data Normalisation This will include listing all your data and applying a bottom up process known as data normalisation. You should apply the normalisation process up to 3NF only.
 See http://www.doc.mmu.ac.uk/STAFF/P.Quick/normal4.ppt ƒ
Entity Relationship modelling This section of your report should show ‘top down’ data modelling activities you have carried out to produce your database design. See http://db.grussell.org/section004.html It is important to emphasise here that you must develop and name your entities and also name the relationships between them. Both of these activities are known as logical design models. These data modelling processes are used to produce the same physical model i.e. a model that will include tables and relationships. Output Design This section will include the design of your final physical model. Processes This section will include the processes that your system will use to achieve the user requirements. It will describe how data is manipulated to produce output. Implementation This is final evidence that your system has been finished and is working. You will need to produce annotated screen dumps of your application i.e. screen dumps on which you describe what is going on. Only code you have written yourself should be annotated and included. (Please do NOT include pages of code which has been produced by the code generator!)

A2 UNIT 8 DATABASE DEVELOPMENT User Documentation This is a separate document which you will produce for a naïve user to allow them to use the system. This naïve user will be assumed to have no knowledge of your system. This naïve user should NOT be able to amend or have access to raw data. For some advice on this see http://www.klariti.com/technical-writing/User-Guides-Tutorial.shtml You must also provide evidence that THREE users have tested your system using your user guide. You must also evaluate how your system meets its original objectives. This could be evidenced by a signed questionnaire. Technical Documentation This is a separate document which you will produce to allow a TECHNICAL user to maintain or upgrade the system. Technical Documentation is written for people will maintain the system once it is installed and being used. Remember - All systems evolve. This means that the user will need the system to do things better, faster or even in a different way. Some things may have even been overlooked or forgotten. The user will only realise that improvements need to be made once they start using the system. Maintaining the system means keeping it running well and doing what the user needs it to do. Technical guides may use technical language and system diagrams if they are needed. Examine http://en.wikipedia.org/wiki/Technical_communication A technical Guide may include the following: ƒ Technical details such as the type of system being used – technical details such as type of computer system, RAM, printer etc. ƒ Explanations may include o how to load the software, upgrade a sub-system, make a user interface, add fields, validate and verify data, amend the database structure, fault find etc. o How to produce a query or report. o How to edit a macro or change some code. ƒ You may also put in a FAQ section or contact details (email support address, web site support address, telephone support line numbers.)

A2 UNIT 8 DATABASE DEVELOPMENT You must also provide evidence that THREE users have tested your system using your technical guide. You must also evaluate how your system meets its original objectives. This could be evidenced by a signed questionnaire. Test Documentation You should provide a comprehensive test plan with evidence that testing has been carried out. Test plans should include evidence of: ƒ Navigation ƒ Data capture ƒ Data manipulation ƒ Data output ƒ Reports produced Evaluation This section is where you describe your solution and reflect on how it meets the quantitative user requirements specified at the beginning. It should comment on the data modelling and this section should also report on future improvements. You must also mention how your time management skills were used as well as the interaction between yourself and the user while you developed your data models. There should be evidence of discussion of your project plan and the use of project management tools. Statements such as ƒ ‘My user wanted the following requirements …(the list)….’ which is then followed by an in depth discussion of these requirements is good practice. Remember – it may not have been possible to satisfy all users’ requirements – why? – maybe this something for future consideration? ƒ You should concentrate on your initial project management plan – did everything go according to plan – do you deliver when you said you would?– if not? - why not? – did things take longer than expected? – why? – were there any unforeseen events that slowed the project ?– what were they and how did you cope or catch up? ƒ You should reflect on the future of the project – are there any enhancements that you could add later – give reasons for them. ƒ Statements such as ‘I thought I did well. There were no real problems at all’ should be avoided – it is unrealistic to expect everything to run smoothly. ƒ Statements such as ‘Everything was fine, but if I had to do it again I’d do it differently’ should also be avoided. It’s contradictory.

A2 UNIT 9 WEBSITE DESIGN AND MANAGEMENT 
This unit allows you to demonstrate your skills in developing and designing websites using appropriate tools. You will demonstrate your knowledge about performance issues, how you’ve used a range of media and how you have developed interactive features. You should show evidence of advanced and or dynamic content on both your website presentation and management. You should show evidence of developing, testing, documenting, maintaining and evaluating websites. You should show evidence of project management techniques. The documentation you present in your portfolio should have a professional feel to it and should demonstrate an appropriate style for work at this level. YOUR COURSEWORK PORTFOLIO SHOULD BE BOUND APPROPRIATELY. 

In this Unit you must produce ƒ a project plan that describes how you will manage your time and resources and how you will schedule the activities involved. ƒ
 A professional website that fully meets the needs of client - a business or official organisation. It is strongly recommended that your portfolio should be presented using the following format and headings: Candidate Record Sheet This document should be signed by both you and your teacher. Contents Page If you choose to include a contents page with accurate page numbers it will significantly enhance your work. It will demonstrate a style commonly found in reports of this nature. Feasibility of the project There should be a detailed investigation of the clients’ current business and you should investigate your clients’ requirements for the website. It is important to discuss these requirements thoroughly and present the client with a well presented written outline. This outline should include a portfolio of ideas and an outline of site structure, making reference to timescale and financial costs.
You must remember that the client will consider you to be the expert so it is essential you provide technical information such as domain and hosting issues in an easy to understand format. Storyboarding is evidence of good practice. This site should include advanced content such as dynamic scripting or media and be suitable for the audience concerned. This task will give you experience of planning a website implementation for a client as well as looking at methods that allow the site to be managed directly by the client.


A2 UNIT 9 WEBSITE DESIGN AND MANAGEMENT 
Project Plan This is a plan that you should set out at the beginning of your work. It will be a programme of activities and resources you will use within a timeframe over the life time of the project design. You should use a recognised project management tool to document this. An example of a project management tool would be a GANTT chart (examples of GANTT charts can be found on the exemplar paper 7 Investigating Systems (a synoptic unit)). See CCEA website at http://www.rewardinglearning.com/development/qualifications/gce/docs/suppo rtdocs/appliedict_unit7_exemplar_paper.pdf Other Gantt chart examples can be found at: http://www.ganttchart.com/. It is also possible to use EXCEL as a project management tool – see http://office.microsoft.com/en-ca/assistance/HA010346051033.aspx

A2 UNIT 9 WEBSITE DESIGN AND MANAGEMENT 
Site specification The site specification should include the following sections: ƒ Audience considerations. ƒ Domain Name and Hosting Issues ƒ Site Management Issues ƒ Site Structure Ideas ƒ Dynamic content requirements (e.g. scripted content) Dynamic content is content generated by some server process e.g. a list of web sites matching the search criteria on a search engine site, the content of a shopping cart on an e-commerce site, a personalized news page, a message on a bulletin board or the result of a database query. Before it is sent to the browser, the dynamic content needs to be combined with regular HTML elements into a page with the right layout, navigation bars, the company logo etc. ƒ
Use of and embedding of media content such as animation / movies. ƒ Content Requirements from client ƒ Accessibility Issues ƒ Legal Issues (Data Protection Act if applicable) ƒ Site scalability proposals ƒ Financial Issues ƒ Timescales Each page on the site should be described to show evidence of: ƒ Webpage screen shot ƒ Fonts / styles and colours used. ƒ Meta tags used and why they were employed. ƒ Navigation Issues. ƒ Use of text layout tools such as layers, tables or frames ƒ Use of images and if applicable how they were created. ƒ Use of multimedia and if applicable how created and embedded to page. ƒ Downloadable content. ƒ Advanced content ƒ Accessibility issues considered. Some other issues that need to be addressed in your portfolio include: Auditing issues http://www.e-zest.net/website_auditing.html Web hosting Your website must be hosted.

A2 UNIT 10 MULTIMEDIA TECHNOLOGY 
This unit is meant to demonstrate your understanding of the importance of multimedia technology and the use hardware and software in your given context. You must evidence of the design, description and presentation of a multimedia solution using a range of techniques including animation and video. You must show evidence of project management skills in your portfolio. The documentation you present in your portfolio should have a professional feel to it and should demonstrate an appropriate style for work at this level.

 YOUR COURSEWORK PORTFOLIO SHOULD BE BOUND APPROPRIATELY. 
In this Unit you must produce an interactive multimedia presentation including one piece of video or animation which includes a piece of edited audio supported by design sketches, storyboards and flow charts to meet your user’s specified requirements. It is strongly recommended that your portfolio should be presented using the following format and headings: Candidate Record Sheet This document should be signed by both you and your teacher. Contents Page If you choose to include a contents page with accurate page numbers it will significantly enhance your work. It will demonstrate a style commonly found in reports of this nature. Project Plan This is a plan that you should set out at the beginning of your work. It will be a programme of activities and resources you will use within a timeframe over the life time of the project design. You should use a recognised project management tool to document this. An example of a project management tool would be a GANTT chart (examples of GANTT charts can be found on the exemplar paper 7 Investigating Systems (a synoptic unit)). See CCEA website at http://www.rewardinglearning.com/development/qualifications/gce/docs/suppo rtdocs/appliedict_unit7_exemplar_paper.pdf Other Gantt chart examples can be found at: http://www.ganttchart.com/. It is also possible to use EXCEL as a project management tool – see http://office.microsoft.com/en-ca/assistance/HA010346051033.aspx


A2 UNIT 10 MULTIMEDIA TECHNOLOGY Multimedia Portfolio Presentation The multimedia presentation should ensure all information is presented in a structured, coherent, concise manner showing continuity. It should demonstrate the proper use of technical language showing an understanding of the design and production process. It should present a detailed analysis of the production task. Your portfolio should demonstrate that you know: • How digital technology works • What hardware and software to use in multimedia projects • How to design a multimedia project • The standard techniques used to create multimedia content • How to present multimedia content • What are the standard ways of working This unit will allow you to demonstrate team work. Each member of the team should be actively involved in the design and production process. You, as a team member, should be fully aware of what all other members of the team are producing for the multimedia project. Each team member must be responsible, at some time, of leading and directing the team. Each team member must produce their own distinct portfolio.

A2 UNIT 11 APPLICATION SOFTWARE DEVELOPMENT 
This unit is meant to demonstrate your understanding of the importance of an e-portfolio, which you will design to support business functions in a given context. You must show evidence of how you used research, selection, evaluation and use of advanced features of software. You must show evidence of your understanding of the issues involved in the choice of software. In this Unit you must produce an e-portfolio containing evidence of ƒ A digital training resource which will help a new member of an organisation understand the vision, aims and structure of an organisation. ƒ An automated database containing data that can be used by a spreadsheet and word processor. ƒ A digital briefing resource that explains e-communication tools. ƒ A two page document (or 2 minute video) evaluating your own performance.

A2 UNIT 12 VISUAL PROGRAMMING
 In this unit you were introduced to the fundamental concepts of modern programming in a visual language. You must show evidence that you have undertaken tasks in which you ƒ designed and created programmes (event driven in nature) ƒ prototyped applications using storyboarding as a design tool ƒ interacted with your user ƒ used procedures and functions ƒ developed a user interface design and ƒ utilised the software to produce GUI applications. You will develop a single application or undertake a set of tasks to design a set of GUI applications which meet a set of user requirements. You will be required to examine and apply standard ways of working in this context. The documentation you present in your portfolio should have a professional feel to it and should demonstrate an appropriate style for work at this level.
 Your portfolio should demonstrate that you know: • How to design a visual interface; • How to develop a prototype through storyboarding; • How to use tools for building a GUI application; • How to package and distribute a system; • The importance of testing your user specified system; • Technical and user documentation requirements; • How to evaluate a user specified system; • What the standard ways of working are. 

A2 UNIT 12 VISUAL PROGRAMMING In this Unit you must produce a working system which has been designed to meet your user’s specified requirements. It should be produced using a visual programming tool. It is strongly recommended that your portfolio should be presented using the following format and headings: Candidate Record Sheet This document should be signed by both you and your teacher. Contents Page If you choose to include a contents page with accurate page numbers it will significantly enhance your work. It will demonstrate a style commonly found in reports of this nature. Introduction This section must describe the current system in detail and the requirements for the new system. Project Plan This is a plan that you should set out at the beginning of your work. It will be a programme of activities and resources you will use within a timeframe over the life time of the project design. You should use a recognised project management tool to document this. An example of a project management tool would be a GANTT chart (examples of GANTT charts can be found on the exemplar paper 7 Investigating Systems (a synoptic unit)). See CCEA website at http://www.rewardinglearning.com/development/qualifications/gce/docs/suppo rtdocs/appliedict_unit7_exemplar_paper.pdf Other Gantt chart examples can be found at: http://www.ganttchart.com/. It is also possible to use EXCEL as a project management tool – see http://office.microsoft.com/en-ca/assistance/HA010346051033.aspx Design Documentation You must use storyboarding and state the data requirements and output to be produced by your system. You should use detailed sketches/ storyboards to present a graphical representation of the proposed system. The storyboards should include relevant controls e.g. labels, text boxes, list/combo boxes, images, menus and toolbars. Navigation through the system should also be represented. Along with the actual storyboards, details of the modular design of the programs should be explained.

A2 UNIT 12 VISUAL PROGRAMMING Implementation You must show evidence of your implementation by including annotated screen dumps and code listings of the system you have built. This should be generated from user requirements. The initial prototype should only provide a snapshot of the proposed system, giving a flavour of the screens, navigation, controls used and output screens. The refinement of the prototyping should be carried as necessary taking into account user feedback each time. Forms should be fit for purpose, professional, original, intuitive, consistent and employ a variety of text, menus, controls and graphics.
There should be evidence of e.g. combo box, scroll bar, list box, graphics, check box etc. Processing and Code - students should use appropriate programming structures e.g. Sequence, Selection and Repetition, Case statements, For to Next, and Nested If statements. A number of user-defined modules should be evident. The entire code should be printed out in full. Use of control arrays can reduce the amount of code keyed in. Processing and Printouts – The programs produced should contain validation of controls, menus etc.. User Documentation This is a separate document which you will produce for a naïve user to allow them to use the system. The User Guide should be a separate document and have a title page and table of contents This naïve user will be assumed to have no knowledge of your system. This naïve user should NOT be able to amend or have access to raw data. For some advice on this see http://www.klariti.com/technical-writing/User-Guides-Tutorial.shtml You must also provide evidence that THREE users have tested your system using your user guide. You must also evaluate how your system meets its original objectives. This could be evidenced by a signed questionnaire.

A2 UNIT 12 VISUAL PROGRAMMING 
Technical Documentation This is a separate document which you will produce to allow a TECHNICAL user to maintain or upgrade the system. Technical Documentation is written for people will maintain the system once it is installed and being used. Remember - All systems evolve. This means that the user will need the system to do things better, faster or even in a different way. Some things may have even been overlooked or forgotten. The user will only realise that improvements need to be made once they start using the system. Maintaining the system means keeping it running well and doing what the user needs it to do. Technical guides may use technical language and system diagrams if they are needed. Examine http://en.wikipedia.org/wiki/Technical_communication A technical Guide may include the following: ƒ Technical details such as the type of system being used – technical details such as type of computer system, RAM, printer etc. ƒ Explanations may include o how to load the software, upgrade a sub-system, make a user interface, add fields, validate and verify data, amend the database structure, fault find etc. o How to produce a query or report. o
How to edit a macro or change some code. ƒ You may also put in a FAQ section or contact details (email support address, web site support address, telephone support line numbers.) You must also provide evidence that THREE users have tested your system using your technical guide. You must also evaluate how your system meets its original objectives. This could be evidenced by a signed questionnaire. Test Documentation You should provide a comprehensive test plan with evidence that testing has been carried out. Test plans should include evidence of: ƒ Navigation ƒ Data capture ƒ Data manipulation ƒ Data output ƒ Reports produced A2 UNIT 12 VISUAL PROGRAMMING Evaluation This section is where you describe your solution and reflect on how it meets the quantitative user requirements specified at the beginning. It should comment on the effectiveness of the use of prototyping and this section should also report your recommendations for future improvements. You must also mention how your time management skills were used as well as the interaction between yourself and the user during prototyping when extracting and refining your user’s requirements. You should also discuss how your performance could be improved. ƒ
You should concentrate on your initial project management plan – did everything go according to plan – do you deliver when you said you would?– if not? - why not? – did things take longer than expected? – why? – were there any unforeseen events that slowed the project ?– what were they and how did you cope or catch up? ƒ You should reflect on the usefulness of the prototyping approach to system development. ƒ You should reflect on the future of the project – are there any enhancements that you could add later – give reasons for them. ƒ Statements such as ‘I thought I did well. There were no real problems at all’ should be avoided – it is unrealistic to expect everything to run smoothly. ƒ Statements such as ‘Everything was fine, but if I had to do it again I’d do it differently’ should also be avoided. It’s a contradiction in terms.


A2 UNIT 14 IMPLEMENTING A BUSINESS SOLUTION 
This unit allows you to develop a software system from a User Requirements Specification. You will design, develop, test, document and evaluate a software solution to a specified problem. You will be required to demonstrate project management skills and to appreciate all aspects of the systems development life cycle. You will be required to develop a software solution to a business problem taking into consideration the needs of the end user. You will be required to explore and select appropriate design methods. You will be required to develop, test, document and demonstrate your solution. You will examine and apply standard ways of working in this context. WHAT YOU NEED TO DEMONSTRATE. Your portfolio should demonstrate that you know: • How to use appropriate design methods to develop a software system to meet user requirements • How to develop a functional software system from the design specification using a recognised development tool • How to test the developed system • How to produce the documentation • How to evaluate the final system in terms of the User requirements • What are the standard ways of working

In this Unit you must design, develop, test, document and evaluate a software solution to a given problem. It is strongly recommended that your portfolio should be presented using the following format and headings: Candidate Record Sheet This document should be signed by both you and your teacher. Contents Page If you choose to include a contents page with accurate page numbers it will significantly enhance your work. It will demonstrate a style commonly found in reports of this nature. Project Plan This is a plan that you should set out at the beginning of your work. It will be a programme of activities and resources you will use within a timeframe over the life time of the project design. You should use a recognised project management tool to document this. An example of a project management tool would be a GANTT chart (examples of GANTT charts can be found on the exemplar paper 7 Investigating Systems (a synoptic unit)). See CCEA website at http://www.rewardinglearning.com/development/qualifications/gce/docs/suppo rtdocs/appliedict_unit7_exemplar_paper.pdf Other Gantt chart examples can be found at: http://www.ganttchart.com/. It is also possible to use EXCEL as a project management tool – see http://office.microsoft.com/en-ca/assistance/HA010346051033.aspx Introduction This section must describe the current system in detail and the requirements for the new system. Design The choice of design method applied to the development of a software system will reflect the nature of the problem under consideration. You must always consider the needs of the User and choose a design method that will help you to interact in an appropriate manner with the user of your developed system. You must show evidence that you understand how a range of design methods available e.g. Algorithms, Storyboards, Data flow diagrams, Data dictionaries can be applied in the development of a software solution. You should produce a specification of user requirements.

Implementation Based on the specification of user requirements you must produce your solution, suitably annotated. Testing You must should detailed evidence that you understand the importance of software testing. You must document: - How you have tested the functionality of a system; - How you have tested the User interface; - How you have tested the original specification against the final product; - How you have produced a test plan for a developed system; User Documentation This is a separate document which you will produce for a naïve user to allow them to use the system. The User Guide should be a separate document and have a title page and table of contents This naïve user will be assumed to have no knowledge of your system. This naïve user should NOT be able to amend or have access to raw data. For some advice on this see http://www.klariti.com/technical-writing/User-Guides-Tutorial.shtml You must also provide evidence that THREE users have tested your system using your user guide. You must also evaluate how your system meets its original objectives. This could be evidenced by a signed questionnaire.


 A2 UNIT 14 IMPLEMENTING A BUSINESS SOLUTION  
Technical Documentation This is a separate document which you will produce to allow a TECHNICAL user to maintain or upgrade the system. Technical Documentation is written for people will maintain the system once it is installed and being used. Remember - All systems evolve. This means that the user will need the system to do things better, faster or even in a different way. Some things may have even been overlooked or forgotten. The user will only realise that improvements need to be made once they start using the system. Maintaining the system means keeping it running well and doing what the user needs it to do. Technical guides may use technical language and system diagrams if they are needed. Examine http://en.wikipedia.org/wiki/Technical_communication A technical Guide may include the following: ƒ Technical details such as the type of system being used – technical details such as type of computer system, RAM, printer etc. ƒ Explanations may include o how to load the software, upgrade a sub-system, make a user interface, add fields, validate and verify data, amend the database structure, fault find etc. 
o How to produce a query or report. o How to edit a macro or change some code. ƒ You may also put in a FAQ section or contact details (email support address, web site support address, telephone support line numbers.) Evaluation Your final system must discuss how you have met the User’s Requirements. You must also mention how your time management skills were used You should concentrate on your initial project management plan – did everything go according to plan – do you deliver when you said you would?– if not? - why not? – did things take longer than expected? – why? – were there any unforeseen events that slowed the project ?– what were they and how did you cope or catch up? You should discuss the relative success or failure of your final product. You must include detailed analysis of results, conclusions and recommendations. You must comment on how your own performance could be improved.

Wednesday, March 4, 2015

How to draw Use case Diagram Sequence Diagram Class Diagram Database Diagram for software projects with symbols and examples

·          Use case Diagram

·          Sequence Diagram

·          Class Diagram

·          Database Diagram


What is a UML Use Case Diagram?

Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users.
YouTube https://www.youtube.com/channel/UCJojbxGV0sfU1QPWhRxx4-A
LinkedIn https://www.linkedin.com/in/ict-bit-tuition-class-software-development-colombo/
WordPress https://computerclassinsrilanka.wordpress.com
quora https://www.quora.com/profile/BIT-UCSC-UoM-Final-Year-Student-Project-Guide
Newsletter https://sites.google.com/view/the-leaning-tree/newsletter
Wix https://itclasssl.wixsite.com/icttraining
Web https://itclass-bit-ucsc-uom-php-final-project.business.site/
mystrikingly https://bit-ucsc-uom-final-year-project-ideas-help-guide-php-class.mystrikingly.com/
https://elakiri.com/threads/bit-ucsc-uom-php-mysql-project-guidance-and-individual-classes-in-colombo.1627048/
ucsc bit registration 2023 bit (ucsc syllabus) bit colombo university fees bit results bit vle bit course fee bit exam time table 2023 bit moratuwa

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.
Use Case

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor system with the actor stereotype.
Actors

Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.
Learn how to draw relationships.
Relationships


https://www.andrew.cmu.edu/course/90-754/umlucdfaq.html

With the help of a use case diagram, you can discuss and communicate:
  • The scenarios in which your system or application interacts with people, organizations, or external systems.
  • The goals that it helps those actors achieve.
  • The scope of your system.
A use case diagram does not show the detail of the use cases: it only summarizes some of the relationships between use cases, actors, and systems. In particular, the diagram does not show the order in which steps are performed to achieve the goals of each use case. You can describe those details in other diagrams and documents, which you can link to each use case. For more information, see Describing Use Cases in Detail in this topic.
The descriptions you provide for use cases will use several terms related to the domain in which the system works, such as Sale, Menu, Customer, and so on. It is important to define these terms and their relationships clearly, and you can do that with the help of a UML Class Diagram. For more information, see UML Class Diagrams: Guidelines.
Use cases deal only in the functional requirements for a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately. Architecture and internal details must also be described separately. For more information about how to define user requirements, see Modeling User Requirements.
The examples used in this topic relate to a Web site on which customers can order meals from local restaurants.
  • An actor (1) is a class of person, organization, device, or external software component that interacts with your system. Example actors are Customer, Restaurant,Temperature Sensor, Credit Card Authorizer.
  • use case (2) represents the actions that are performed by one or more actors in the pursuit of a particular goal. Example use cases are Order Meal, Update Menu,Process Payment.Elements in a use case diagram
On a use case diagram, use cases are associated (3) with the actors that perform them.
  • Your system (4) is whatever you are developing. It might be a small software component, whose actors are just other software components; or it might be a complete application; or it might be a large distributed suite of applications deployed over many computers and devices. Example subsystems are Meal Ordering Website, Meal Delivery Business, Website Version 2.
A use case diagram can show which use cases are supported by your system or its subsystems.


Drawing Actors and Use Cases

The main purpose of a use case diagram is to show who interacts with your system, and the main goals they achieve with it.
·         Create Actors to represent classes of people, organizations, other systems, software or devices that interact with your system or subsystem.
o    To learn how to draw actors and other elements, see How to: Edit UML Models and Diagrams.
o    For each distinct set of goals, identify actors by their type or role, even though the physical persons or entities might be the same. For example, Restaurant and Customer are separate actors, even though a restaurant employee might sometimes be a customer.
·         Create Use Cases for each of the goals that each actor seeks to achieve with the system.
o    Name and describe the use cases in words that the actor would understand, instead of implementation terms.
·         Use Associations to link actors to use cases.
Use case diagram showing inheritance

Inheritance between Actors

You can draw a Generalization link between Actors. The specialized actor, such as Club Customer in the example, inherits the use cases of the generalized actor, such as Customer. The arrowhead should point at the more general actor, such as Customer. When you create the link, point first at the more specialized actor.
The specialized actor can have its own additional use cases that are not available to the other actors.

Structuring Use Cases

You should try to describe your system's behavior with just a few major use cases. Each large use case defines a major goal that an actor achieves, such as buying a product, or, from the vendor's point of view, providing products for sale.
When you have made these goals clear, you can go into more detail about how the each goal is achieved, and about variations in the basic goals.
Avoid decomposing the use cases into too much detail. Use cases are about the users' experience of your system, instead of its internal workings. Additionally, you will generally find it more productive to create early working versions of the code, instead of spending time structuring use cases into fine detail.
You can summarize on a use case diagram the relationships between major and more detailed use cases. The following sections describe this:

 

Showing the details of a use case with Include

Use an Include relation to show that one use case describes some of the detail of another. In the illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case.
You can share included use cases. In the example, the Order a Meal and Subscribe to Reviews use cases both include Pay.

Use cases decomposed with include

The goal and scenarios of an included use case should make sense independently so that it can be included in use cases that are designed later.
Separating use cases into including and included parts is useful to achieve the following goals:
·         Structure your use case descriptions into different layers of detail.
·         Avoid repeating shared scenarios in different use cases.

Sharing goals with Generalization

Use a Generalization relation to show that a specialized use case is a particular way to achieve the goals expressed by another general use case. The open arrowhead should point at the more general use case.

Use case steps shown in linked activity diagram

For example, Pay generalizes Pay by Credit Card and Pay by Cash.

Separating variant cases with Extend

Use an Extend link to show that one use case may add functionality to another use case under certain circumstances. The arrow should point at the main, extended use case.

Use cases showing the generalization relation


One use case extending another


System versions

You can use different subsystem boundaries to illustrate different versions of the system. For example, the Pay use case might be included in Website Version 2 but not in Version 1.This implies that the system helps customers make their orders. However, they have to pay the restaurant directly.
Use Dependency relations to link subsystems representing different versions or variants.

Subsystems show different versions of a system

Basic Use case Diagram For Hotel Management System

Use case diagram for hotel management system (UML)

Sample use case diagram for Patient Management System


Hospital Management Use Cases Example for Reception.

Use-case diagram for Library management system



What is a UML Sequence Diagram?

Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Basic Sequence Diagram Symbols and Notations

What is a UML Sequence Diagram?


Sequence diagrams describe interactions among classes in terms of an exchange of messages over time.

Basic Sequence Diagram Symbols and Notations

Class roles

Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes.
Learn how to edit text on a symbol.
Class roles

Activation

Activation boxes represent the time an object needs to complete a task.
Activation

Messages

Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.
Learn how to draw messages.
Messages Various message types for Sequence and Collaboration diagrams
Various message types for Sequence and Collaboration diagrams

Lifelines

Lifelines are vertical dashed lines that indicate the object's presence over time.
Learn how to attach activation boxes to lifelines.
Lifelines

Destroying Objects

Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.
Destroying Objects

Loops

A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting the loop at the bottom left corner in square brackets [ ].
Learn how to arrange objects on a page.
Loops


The diagram below shows how objects interact in the "rent item" collaboration when the item is not available during the requested period.


a typical UML sequence diagram.




Objects as well as classes can be targets on a sequence diagram, which means that messages can be sent to them. A target is displayed as a rectangle with some text in it. Below the target, its lifeline extends for as long as the target exists. The lifeline is displayed as a vertical dashed line.

Object

The basic notation for an object is
UML sequence diagram of named and anonymous objects.
Where 'name' is the name of the object in the context of the diagram and 'Type' indicates the type of which the object is an instance. Note that the object doesn't have to be a direct instance of Type, a type of which it is an indirect instance is possible too. So 'Type' can be an abstract type as well.
Both name and type are optional, but at least one of them should be present. Some example :
UML sequence diagram that shows various object stereotypes with icons.
As with any UML-element, you can add a stereotype to a target. Some often used stereotypes for objects are «actor», «boundary», «control», «entity» and «database». They can be displayed with icons as well :
An object should be named only if at least one of the following applies
·        You want to refer to it during the interaction as a message parameter or return value
·        You don't mention its type
·        There are other anonymous objects of the same type and giving them names is the only way to differentiate them
Try to avoid long but non-descriptive names when you're also specifying the type of the object (e.g. don't use 'aStudent' for an instance of type Student). A shorter name carries the same amount of information and doesn't clutter the diagram (e.g. use 's' instead).

MultiObject

When you want to show how a client interacts with the elements of a collection, you can use a multiobject. Its basic notation is
UML sequence diagram that shows creation, lifeline and destruction.
Again, a name and/or type can be specified. Note however that the 'Type' part designates the type of the elements and not the type of the collection itself.

Class

The basic notation for a class is
Only class messages (e.g. shared or static methods in some programming languages) can be sent to a class. Note that the text of a class is not underlined, which is how you can distinguish it from an object.
When a message is prefixed with an asterisk (the '*'-symbol), it means that the message is sent repeatedly. A guard indicates the condition that determines whether or not the message should be sent (again). As long as the condition holds, the message is repeated.
The above interaction of repeatedly sending the same message to the same object is not very useful, unless you need to document some kind of polling scenario.
A more common use of repetition is sending the same message to different elements in a collection. In such a scenario, the receiver of the repeated message is a multiobject and the guard indicates the condition that controls the repetition.
UML sequence diagram that shows an example of a loop combined fragment.
This corresponds to an iteration over the elements in the collection, where each element receives the message. For each element, the condition is evaluated before the message is sent. Usually though, the condition is used as a filter that selects elements from the collection (e.g. 'all', 'adults', 'new customers' as filters for a collection of Person objects). Only elements selected by the filter will receive the message.
If you want to show that multiple messages are sent in the same iteration, a 'loop' combined fragment can be used. The operator of the combined fragment is 'loop' and the guard represents the condition to control the repetition.
Again, if the receiver of a repeated message is a collection, the condition is generally used to specify a filter for the elements.
For example, to show that the bounds of a drawing are based on those of its visible figures we could draw the following sequence diagram :
UML sequence diagram showing the main success scenario
Several things are worth noting in this example
·        a local variable 'r' was introduced to clarify that it is the result of getBounds that is added.
·        naming the resulting Rectangle 'bounds' avoids the introduction of an extra local variable.
·        the loop condition is used as a filter on the elements of the figures collection.


What is a UML Class Diagram?

What is a UML Class Diagram?


Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes.
Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.
Learn how to create this symbol.
Classes

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.
Active Class

Visibility

Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class. Learn how to edit text.
Visibility

Associations

Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.
Note: It's uncommon to name both the association and the class roles.
Learn how to edit text.
Associations

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.
Multiplicity (Cardinality)

Constraint

Place constraints inside curly braces {}.
 Simple ConstraintConstraint

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the two classes are not dependent on each other. The diamond end in both a composition and aggregation relationship points toward the "whole" class or the aggregate.
Composition and Aggregation

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between two classes where one class is a specialized version of another. For example, Honda is a type of car. So the class Honda would have a generalization relationship with the class car.
Generalization
In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and PROTECTED functions of the superclass.
Learn how to draw a generalization relationship.


UML Class Diagram Relationships, Aggregation, Composition

There are five key relationships between classes in a UML class diagram : dependency, aggregation, composition, inheritance and realization. These five relationships are depicted in the following diagram:

UML Class Relationships
The above relationships are read as follows:
  • Dependency : class A uses class B
  • Aggregation : class A has a class B
  • Composition : class A owns a class B
  • Inheritance : class B is a Class A  (or class A is extended by class B)
  • Realization : class B realizes Class A (or class A is realized by class B)
What I hope to show here is how these relationships would manifest themselves in Java so we can better understand what these relationships mean and how/when to use each one.

Dependency is represented when a reference to one class is passed in as a method parameter to another class. For example, an instance of class B is passed in to a method of class A:  
?
1
2
3
public class A {
    public void doSomething(B b) {

Now, if class A stored the reference to class B for later use we would have a different relationship called Aggregation. A more common and more obvious example of Aggregation would be via setter injection:
?
1
2
3
4
5
public class A {
    private B _b;
    public void setB(B b) { _b = b; }

Aggregation is the weaker form of object containment (one object contains other objects). The stronger form is calledComposition. In Composition the containing object is responsible for the creation and life cycle of the contained object (either directly or indirectly). Following are a few examples of Composition. First, via member initialization:
?
1
2
3
public class A {
    private B _b = new B();

Second, via constructor initialization:

?
1
2
3
4
5
6
7
public class A {
    private B _b;
    public A() {
        _b = new B();
    } // default constructor

Third, via lazy init (example revised 02 Mar 2014 to completely hide reference to B):

?
1
2
3
4
5
6
7
8
9
10
public class A {
    private B _b;
    public void doSomethingUniqueToB() {
        if (null == _b) {
            _b = new B();
        }
        return _b.doSomething();
    } // doSomethingUniqueToB()

Inheritance is a fairly straightforward relationship to depict in Java:

?
1
2
3
4
5
6
7
8
9
10
11
public class A {
    ...
} // class A
public class B extends A {
    ....
} // class B


Realization is also straighforward in Java and deals with implementing an interface:

?
1
2
3
4
5
6
7
8
9
10
11
public interface A {
    ...
} // interface A
public class B implements A {
    ...
} // class B

Ref http://usna86-techbits.blogspot.com/2012/11/uml-class-diagram-relationships.html

Library Management system Sequence diagram
UML class diagram example of the Library Domain Model.

Online Shopping cart Sequence diagram

Online shopping domain UML class diagram example.


What is a Database Diagram?


Entity Relationship Diagram Symbols and Meaning
ERD Symbols
T

ConceptDraw PRO
Discover the World of Visual Communication©




Design elements Crow’s Foot notation
ConceptDraw gives the ability to describe visually a database using the Crow’s Foot notation icons for drawing ER diagrams - ERD.
Entity-Relationship model making possibility to describe a database in which in the tables data can be the point to data in other tables - for instance, your entry in the database could point to several entries.
                The symbols below are used at the most granular level of ERDs: physical data models, although some elements are also used for logical data models.
Tables are another way of representing entities.
Fields represent attributes of the entity.
Keys are one way to categorize attributes. A primary key is an attribute or combination of attributes that uniquely identifies one and only one instance of an entity. The primary key becomes a foreign key in any entity type to which it's related through a one-to-one or one-to-many relationship.
Types may refer to the type of data associated with the corresponding field in a table. Types can also refer to entity types, which describe the structure of an entity; e.g., a book's entity types are author, title, and published date.

Visual Database diagram Creation with MySQL Workbench