top of page

Unit 3 Outcome TWO

Source: Study Guide

Area of Study 2
Analysis and design

In this area of study students construct the framework for the creation of a software solution that meets a need or opportunity determined by individual students. This is the first part of a project, with the second part undertaken in Unit 4, Outcome 1. In this area of study students analyse a real-world need or opportunity identified by them. The analysis is stated in terms of solution requirements, constraints and scope (analysis stage of problem-solving methodology) and presented as a software requirements specification. There are two steps to designing. Initially, through the application of design and systems thinking skills, students generate two or three different design ideas for creating their solution. These are briefly stated and could include annotations to indicate key functions and layouts. The next step involves developing and applying evaluation criteria to select the preferred design idea. This is then fully detailed, addressing both the functionality and user interface of the solution. The evaluation criteria will be used in Unit 4 to evaluate the quality of this solution. Students prepare a project plan, taking into account all stages of the problem-solving methodology covered in this outcome and in Unit 4, Outcome 1. Students do not have to use dedicated project-management software. Students determine the milestones of their project.

​

Outcome 2

On completion of this unit the student should be able to analyse and document a need or opportunity, generate alternative design ideas, represent the preferred solution design and formulate a project plan for creating the solution. To achieve this outcome the student will draw on key knowledge and key skills outlined in Area of Study 2.

Key knowledge

​

Data and information

  • techniques for collecting data to determine needs and requirements, including interviews, surveys and observation

  • Approaches to problem solving

  • features of functional and non-functional requirements

  • constraints that influence solutions, including economic, legal, social, technical and useability factors

  • factors that determine the scope of solutions

  • features and purposes of software requirements specifications

  • techniques for generating design ideas

  • criteria for evaluating alternative design ideas and the efficiency and effectiveness of solutions

  • tools and techniques for depicting the interfaces between solutions, users and networks, including use case diagrams created using Unified Modelling Language

  • features of context diagrams and data flow diagrams

  • methods of expressing software designs using data dictionaries, object descriptions, mock-ups and pseudocode

  • factors influencing the design of solutions, including useability, affordability,  security, interoperability and marketability

  • characteristics of user experiences, including efficient and effective user interfaces

  • naming conventions for solution elements

  •  project management concepts and processes, including milestones and dependencies (concepts), and task identification, sequencing, time allocation, resources and documentation using Gantt charts (processes)

​

​

Digital systems

  • security considerations influencing the design of solutions, including data protection and authentication

  • styles of modern application architecture, including mobile, rich client, peer-to-peer and internet applications

  • Interactions and impact

  • types of goals and objectives of organisations and information systems

  • key legal requirements relating to the ownership and privacy of data and information.

​

​

Key skills

  • propose a range of methods to collect data for analysis

  • apply analysis tools and techniques to determine solution requirements, constraints, including vulnerability to security threats, and scope

  • identify appropriate styles of modern application architecture

  • document the analysis as a software requirements specification

  • generate alternative design ideas

  • select preferred designs based on student-generated criteria and express the solution designs using appropriate design methods and techniques

  • prepare project plans using software.

​

​

TEXT BOOK: Software Development: Core techniques and Principles 3rd Edition  Adrian Janson

​Unit 3 Outcome 2 Area of Study: Analysis and Design.

  • Chapter 1. Overview of the PSM

  • Chapter 3. From Planning to Analysis

  • Chapter 4. Analysis Tools

  • Chapter 5. The Art of Design 

  • Chapter 6. The structure of a programming language 

  • Chapter 10. The Law in software Development 

  • Chapter 11. Protecting the integrity of data

It is common among new software developers to want to get started coding as soon as possible, but there are a lot of decision to be made before we sit down to code. The Problem Solving Methodology outlines four key stages:

1. Analysis

2. Design

3. Development

4. Evaluation.

​

The Analysis stage is where the developer investigates the problem that needs to be solved with an information system. It is at this stage where the requirements of the solution are identified - these are the things the software must be able to do. It is important that other aspects of the software meet the needs of the end users and herein lies the non-functional requirements. These relate to the characteristics of the software such as ease of use. After the requirments are identified it is important to identify the constraints of the project - these are the limiting factors that affect the development of the software: cost, time, skills of users, materials and resources available. Finally the scope is an outline of what is included and what is not included in the final software to define a boundary of what needs to be in the final product.

​

The Design stage begins when the outcomes of the analysis stage have clearly outline the functiona and non-functional requiremetns, contraints and scope of the final solution. This stage incorporates the design of the soltuion - how it looks and how it will work. This can involve the interface design, the planning of functionality solutions by creating data dictionaries, use case diagrams, data flow diagrams and algroithms. Effectiveness and efficiency are taken into account to ensure the best possible solution. Once the solution foundation is designed it is importanat that a list of evaluation criteria are developed to test against once the solution has been completed and tested.

​

The Development stage is when the actual coding of the solution takes place. Important factors to be taken into consideration at this stage is data validation incorporated in the solution and clear documentation both as internal documentation as other user documentation. Testing the soltuion for errors also takes place in this stage.

​

The Evaluation stage is composed of two steps: 1. the development of a strategy to investigate the effectivness and efficieny of the solution and 2. Reporting on the outcome of the evaluation strategy. The evaluation stratgey usually involves an investigation after the solution has been provided to the end users logn enough for them to become familiar with its use. A combination of data collection methods can be used to collect relevant data to support the evaluation criteria list developed at the design stage. This will involve a wide range of tasks including interviews, running differnt scenarios, eadling with errors etc. Reporting on the outcome of the software solution is the final task whcih should outline the success of the new system over the one it replaces.

​

​

 

Features of functional and non-functional requirements

​

Solution requirements fall into two categories:

1.Functional  Requirments: what the software will do, what the input will be, what the output will be and how the data is processed, stored and transfered.

2. Non-fuctional Requirments: how the software will function in relation to:

​

​

Constraints that influence solutions, including economic, legal, social, technical and useability factors

​​

Constraints are the things that limit to the development of the solution that are out of the control of the developer or client. There are FIVE  factors that can can ast as a contraint on the development of a software solution.

​

Economic Constraints: As with all commercial projects, there will be a budget to adhere to. 

​

Technical Contraints: The final organisation that will use the software solution will already have equipment requirements such as operating systems, other software and hardware that the new system must be complient with. Depending on the nature of the organsation, security needs to be technically tailored to suit the environment. The processing speed and the memory capacity of the hardware the system will be using is a major technical contraint. The solution will have be compatible with other systems that will remain in place.

​

Social Contraints: Not everyone is keen or able to up-skill with new technology. The new system will need to take into account the expertise of end users and the amount of support they will require.

​

Legal Contraints: There are a range of legal obligations software developers need to adhere to. Thes cover data managment security, privacy of users and clients, and copyrigh ownsership of the final product through clear agreements between develoeprs and their clients.

​

​

 

Factors that determine the scope of solutions

​

It is important for a software developers to be clear about what is included in the scope of the project and what is not. This may sound obvious but consider this example:

​

A new app is being developed to assist the school in providing the canteen managers to be prepared for school lunch orders. The app will allow students to post their lunch order before 11am and the canteen managment can prepare enough lunches with minimal waste. From the manager's point of view this is a great managment tool and it has the potential to include all budgeting including developing costings for weekly orders from suppliers.

​

Due to time and cost contraints - it was decided by the project manager that the scope would include:

  • Student orders input from mobile networked devices

  • Total numbers of each lunch product required is calculated for 11.am

 

The scope will not include:

  •  Budgeting components for weekly orders.

​

​

Features and purposes of software requirements specifications

​​

​​

A Software Requirements Specificiation (SRS) document includes all the outcomes of the Analysis stage: Requirements, Scope and Constraints.

​

"Software requirements specification is a comprehensive description of the intended purpose and environment for purpose-designed software solutions. It documents the key activities associated with the analysing stage of the problem-solving methodology. Software requirements specifications (SRS) fulfil the purposes of breaking down a problem into component parts, providing input to the design stage and serving as a reference point for further stages of the problem-solving methodology."  from the Study Design

​

​

​

Techniques for collecting data to determine needs and requirements, including interviews, surveys and observation

​

A new information system is usually in response to a communication or efficiency issue arising in the operations of the organisation. To ensure the new system will meet the needs of the organisation it is important to research the requirements. To do this the developer needs to collect data from all stakeholders to ensure the solution they develop meets the needs of everyone affected and it is aligned with the organisation's goals and objectives. 

​

All investigations require the collection of both qualitative and quantitative data:

  • qualitative data: not measurable, often opinions or example case studies

  • quantitative data: measurable

​

Quanititative data is collected by counting results such as:

​

  • "How many times do you need to look up an ID number?"

  • "Would you need access online in the field?"

  • "Which data is required for a Product field?"

​

All these questions have responses that are countable:

  • number of times,

  • number of "Yes" results,

  • number of of instances of a field suggestion.

​

Qualitative data is collected by recording non-measurable results such as:

​

  • Stories provided by staff where instances of data loss or data integrity decreases.

  • Idea generation from staff and other stakeholders when provided with a stimulous.

​

Collection Methods

​

When a lot of people are required to provide feedback for a new system the best form of data collection are surveys and questionaires. These are easy to disseminate. with online surveys like Google Forms and Survey Monkey it is cost effective and efficient in the collection of a lot of data.  It is importanat the the questions posed in surveys carefuly designed to produce meaningful and useful responses. Once data is collected it can easily be analysed by counting responses. When surveys are not issued face-to-face legitimate and meaningful responses are not guarranteed.

​

Survey and questionaries only provide answers to questions that the developers have already anticipated. When there are issues the management and interveiwee to provide extra information that has not been anticipated by the interviewer. Interviews can include open questions that allow the inclusion of extra case study examples and new ideas. Focus groups allow for stakeholders to discuss a range of topics related to the needs of the organisation and produce more ideas and unanticipated issues that would need to be incorporated into the final design.

​

Observations of staff at work in the general operations of the current system can provide developers with insight as to what can be included int he new system and what can be streamlined. 

​

The data collected from the investigation into the requirments of the new system forms the foundation of the development stage.

​

​

Approaches to problem solving

​

There are many models of problems solving methodology, but for the VCE we use this one:

​

​

​

​

​

The SRS Structure should be as follows:

​

  • A Table of Contents (It will be a large document)

  • Gantt Chart: A project Plan. You can use GanttProject - a free online resources.

  • Overview of Data Collection methods and justification

  • The Purpose of software solution clearly outlined - defining  the functional requirements.

  • The characteristics of the end users and how these will inform the non-functional requirements and usability constraints of the solution

  • The scope of the project

  • A description of the Operating Environment

  • A full list of Functional requirements clearly identified with IDs

  • A full list of Non-Functional requirements with IDs.

  • The constraints of the project

​

Including an Appendix you should add:

  • Data Collection tools

  • Data Collection results

  • Context Diagram

  • Data Flow Diagram

  • Use Case Diagram

​

This is a powerpoint by teacher Mark Kelly that goes into Context Diagrams and Data Flow Diagrams in detail.

 

 

 

Techniques for generating design ideas

​​

Some people find it easier to come up with ideas than others. There are a number of tried and true methods for generating design ideas:

​

  • Brainstorming - this is a method of generating as many ideas as possible. There is no editing out of crazy, unfeasible suggestions because these can lead to other ideas that may well be more pertinent to the problem.

​

  • Mindmapping - this is a graphical technique where related concepts and key phrases are linked together. The object is to make sense of a wide range of ideas and to group them into a feasible strategy.

​​

  • Storyboarding - this is also a graphical technique where the journal through the use of the software is tabled as a series of interfaces. This provides the developers an opportunity to reflect on what is required and in what order each task needs to take.

​

  • Role playing - this is an opportunity for the developers to put themselves in the place of end users to investigate what solutions would best suit different scenarios.

​

​​

​

​

Criteria for evaluating alternative design ideas and the efficiency and effectiveness of solutions

​

"Efficiency is a measure of how much time, cost and effort is applied to achieve intended results. Measures of efficiency in a solution could include the speed of processing, its functionality and the cost of file manipulation. Measures of efficiency in a network include its productivity, processing time, operational costs and level of automation." Study Guide 

​

​​

"Effectiveness is a measure of how well a solution, an information management strategy or a network work and whether each achieves its intended results. Measures of effectiveness in a solution include completeness, readability, attractiveness, clarity, accuracy, accessibility, timeliness, communication of message, relevance and useability. Measures of effectiveness of an information management strategy include integrity of data, security, ease of retrieval and currency of files. Measures of effective networks include reliability and maintainability" Study Guide 

​

Evaluating Efficiency

​

There are three ways to evaluate efficiency of a software solution:

  • Speed of Processing - does it complete the task without an uneasible delay

  • Functionality - how well does the solution do what it was designed to do

  • Cost of File Manipulation - how many times are files manipulated? Minimum manipulation increases efficiency.

​

​

Evaluating Effectivness

​

There are many ways to evaluate effectivness of a software solution:

  • Completeness - Is all the output complete? Does the user need anything outside of the system to do the task?

  • Attractiveness - Has the design elements created a solution that is appealing and clearly realted to the system's function?

  • Clarity/Readability - Is it clear enough for users to read to complete a task using the system?

  • Accuracy - Is the output from the system always correct?

  • Accessibility - Is the interface easy to use for all the users? The design of the interface needs to pay attention to the characteristics and limitatin of end users. 

  • Timeliness - Is the entry, processing of data and the production of output information completed in a time frame that allows practical use of th eoutput?

  • Communication of Message - 

  • Relevance - Is the data that has been included in the output relevent to the needs of the user? 

  • Useability - Given the user characteristics, how easy is the solution to use?

​

​

It's important to be able to remember all the measures for evaluating effectiveness so here is a mnemonic to help you remember them:

​

​

​

​

Tools and techniques for depicting the interfaces between solutions, users and networks, including use case diagrams created using Unified Modelling Language

​​

Use Case diagrams use UML which is a general-purpose and standardised modeling language used in the development of software engineering. It is used to produce visual solutions in the design of a solution and includes a range of diagram types, including Use case. 

​

Use Case displays the way a solution will be used. Rather than writing a complex algorithm to solve the problem, the first stage is to identify the system in terms of it's users and what each "CASE" will be. Each CASE is a how a user interacts withthe solution. 

​

You create a USE CASE in 6 STEPS:

​

1. Create the System boundary

2. Identify the actors (the users roles)

3. Identify each CASE the user will interact with

4. Create associations between Actors and CASES

5. Add extra CASEs where there are more than one step required (includes)

6. Add extra CASEs where there may be an extra step involved on occasion(extends)

​

​

​

​

​

Features of context diagrams and data flow diagrams

 

It is important to know the structure of DFDs. First you must begin with a Context Diagram which is the highest level of DFD. It displays the system as a whole and how data flows in and out of the sytem to and from entities.

​

The Next Layer DFD takes the Context Diagram and adds up to 8 key processes that represent the solution. Please take care to use the all the rules as layed out on pages 42 - 43  of Adrian Jansen's text book:

​

A DFD contains: Processes, Enitities, Data Flows and Data Stores.

​

1. Reading the diagram should start at the top left and move to  the bottom right.

2. Data can't flow entity to entity

3. Data from a Data Store must go through a process before going to another Data Store

4. A process must have data in and data out. Don't leave them hanging

5. Data coming out of a process must be different to the data entering it.

6. rejected data can be sent out of the diagram

7. Keep the DFD to 8 processes at the 2nd level

8. Use good processing verbs in your processes: Calculate, edit, delete, sort, add.

​

VIDEO: Context Diagrams by Passy's World of ICT

​

VIDEO: Data Flow Diagrams by Passy's World of ICT

​

​

​

IMethods of expressing software designs using data dictionaries, object descriptions, mock-ups and pseudocode

 

The design stage of solving a problems requires the development of "Design Tools". These are the design tools related to programming:

​

  • Mock-Up / Design Layouts - A rough layout of how the software solution will look on the screen and the objects and elements clearly named and described.

  • Object Description Table - This is a table that lists all the objects, their types, and descriptions. It makes sense to create this after the Design Layout.

  • Data Dictionary - This is a second table that lists all the variable names and their data types and other important information.

  • Algorithm - An algorithm is written in pseudocode to show the flow of data into and out of the solution through the control structures that process the data.

​

MOCK - UP

​

It is important to display all the graphical user interface elements in your diagram. label ALL objects with object type and all objects that handle variables and data with their names. See image below for an incomplete Mock up of a mobile phone app. How many objects have not been labeled?

​

Also you can include justifications for your designs in relation to Useability, Maintainability, Readability and Validation/Feedback.

OBJECT DESCRIPTION TABLE

​

From your completed design layout, you can construct a more detailed table of objects. This identifies the object's name, type, method/event and description.

​

Using the Hungarian notation and Camel Case a text box that reads in the user's name should be called "txtName". This kind of object allows the user to enter text into it's "text" property. This means the object's purpose is "Method". When an object is used to have it's properties changed during execution, it is called a Method. However, when an object's purpose is to react to an event, such a button when the user clicks it, this is called an event object. Other event objects include 

​

​

​

DATA DICTIONARY

​

This design tool is crucial to your planning. Herein we define all the variables we will use in the solution, what names we give them, the data type each variable will handle, the size of the data in bytes, whether it is a global or local variable and a brief description.

​

Variable names need to be structured in Hungarian Notation and Camel Case in most cases to make the code as easy to read as possible. For example if the user to to enter their Name into a textbox, it would be held in a varibale called strName. Str indicates the data type string.

​

It is important to note the data types. If these have been incorrectly defined you will experince errors in your executable code. For example, if you have are calculating the average of some values, you will not be able to set the variable to integer. If in the calculation of the average the returning value is not an integer the program will not run.

​

Likewise if you have an array with many types of data they willneed to all be declared as strings. Once a value is access from the array, the data type can be changed within the code.

​

​

ALGORITHMS

​

Algorithims are solutions to logic problems. In software development we use pseudocode to write algorithms. Pseudocode is like computer coding but easier to read and is often completed with english words for clarity.

​

All pseudocode algorithms must begina dn end with "START" or "BEGIN" and "END"

​

Algerbraic elements can be used: +, −, ×, /, mod and logical elements such as "and", "or" and "not".

​

Comparison elements =, ≠, <, >, ≤, ≥, <>.

​

When allocating data to a variable the symbol ← is used.

​

Algorithms allow for the outline of control structures used to design the solution.

​

Decision Control Stuctures

​

START

​

   IF Condition is true THEN

​

       Action A

​

   ELSE

​

       Action B

​

   END

​

​

​

START

​

     CASE Selection

​

             CASE 1 : Do Action A

​

             CASE 2 Do Action B

​

     END CASE

​

   END

​

​

​

​

​

Iteration Control Structures

 

​

Counted Loops

 

     START

​

          FOR counter ← 0 to 9

​

               Actions

​

         NEXT

​

     END

​

Conditional Loops

(Pre-conditional Loop)

​

     START

​

          Do While Condition is true

​

               Actions

​

          End While

​

      END

​

(Post- Conditional Loop)

     START

​

          Repeat

​

               Actions

​

          Until a Condition is True

​

      END

​

For more information on Pseudocode check out Mark Kelly's powerpoint.

​

VIDEO: Algorithms and Pseudocode by Passy's World of ICT

​

​

​Factors influencing the design of solutions, including useability, affordability,  security, interoperability and marketability

​​

​Useablity influences the design:

​

Useablity is a measure of how use-able the solution will be to the people it is designed for. The users define whether the solution is useable or not, so it's important to look at the user's needs and expections of the of solution. If a key function for the solution is to display a calculated variable, it needs to be clear how that variable can be accessed by the user. This can be done with clear labels, the use of affordance (using objects and icons that are generally recognisable) and the display of data in a format that the end user can actually use.

​

Affordability influences the design:

​

Affordance is a property of a user interface that allows the user to easily and naturally take the correct steps to use the software. Graphical User Interfaces use a collection of recognisable images that imply to the user how they should be used. For example a pulldown menu has a small triangle that shows the user to click to reveal the options available. An input textbox has a beveled edge to imply something can be added to the space. Buttons are beveled out to imply they can be "pressed" to activate or execute code.

​

​

Security influences the design:

​

When sensitive data is being stored, processed, input and exported the security of the data needs to be kept in mind when designing a solution. Perhaps a login and password is required to limit the access to the data to authorised users. When saving data to a file or database, efforts to keep the data secure need to be put in place, including how the software solution accesses the data when required.

​

Interoperability influences the design:

​

If the data from one system is to be used by another system this is an example of interoperability. For example, when you tweet a comment and a photo on Twitter, the interoperability of Twitter and Facebook allow that tweet to be accessed and displayed in both social media sites. In an SD SAT software solution a student may use and XML file type to allow access to the data in excel, your Visual Basic program and MS Access. Application Programming Interface (API) allows for developers to create and draw from a software library so all functions use the save platform and can interact. An example might be a fully web-based software solution such as a school moodle or portal. This solution provides an interface and processing ofor a wide range of purposes and end users:

- administration entering attendance

- head teaching staff managing reports

- teachers posting teaching and learning resources and content

- students reading results and timetable information.

​

All sections that could have been built independently, but instead are part of a large over arching framework on the same platform so data can move easily between each component.

​

Marketability influences the design:

​

If a software solution is marketable, it means the solution is seen as a desired commodity or simply as an attractive product to potential users or clients. This can affect the design of the solution when there are desired integrated elements with other commonly used software already in place. Any software solution that saves the user time makes it highly marketable.​

​

​

Characteristics of user experiences, including efficient and effective user interfaces

​

The user experience is very important to the successful design of your solution. If the user finds the software frustrating, confusing or difficult to use this will probably be due to poor user interface design. The interface needs to be efficient and effective to allow the user to get the output they need easily an intuitively.

​

The characteristics of an efficient and effect user interface include:

​

1. Clear and Familiar Design Elements

​

User interfaces use a range of different object elements such as buttons, combo-boxes (pull down menus), input boxes, radio buttons, check boxes etc which are familiar to all users who have the most basic computer experience. This familiarity with interface elements such as these allow the interface designer to rely on the affordance the elements bring with them. 

​

Each year new students come to high school with fewer and fewer skills with actual computers. This is due to having spent most of their time with touch screen mobile devices. This is becoming an important consideration in interface design to allow for those with limited experience with WIMP interfaces (Window, Icon, Mouse, Pull-down menu). Sometimes menu buttons or icons need to provide hover information. This is text that describes the purpose of an element when the cursor hovers over it. Using icons that are familiar to the user is important. Traditionally the icon of a floppy disk is used to denote saving, however most students entering high school in 2018 have ever seen a floppy disk. It is important to keep these things in mind when designing icons and buttons for familiarity and clarity. The save icon has transformed into a downfaced arrow. Google Docs have lead this change.

​

​

2. Responsive and Robust to User input

​

A good interface needs to respond to the user. A common experience is when using an online store. If you "add" an item to your "cart" the interface responds by displaying a "1" next to the cart icon. This is providing feedback to the user that they have, indeed added an item to the cart. Without that feedback, the user could unknowingly add an item many times. 

​

An interface needs to also be ready for incorrect, misplaced, missing or unexpected data entry. If a user tries to progress through an online form without filling in all the fields, a robust interface would provide feedback such as "You must enter data into the required field". If they enter their date of birth into the name field the interface should be able to detect that the data is not appropriate and provide feedback to the user. This is called validation. There are three types of validation that assist in making a solution robust:

​

​

3. Consistent in Design 

​

Consistency is important to allow the user to intuitively know how to navigate and use the software solution. Locate key tools or elements (such as an exit or back button) in the same location on the screen for each screen. Use the same terminology throughout (example - only use "Exit" or only use "Quit", don't use a combination of both - this can be confusing.)

​

​

4. Efficient

​

Efficiency is measured in the number of actions a user is required to do to obtain the outcome they need. The fewer number of clicks required to access a screen the more efficient it is to use. When the same data needs to be entered in over and over again, this negatively affects efficiency. An efficient interface is has functions that allow data entry, access and editing in the fewest number of actions by the user.

​

5. Scalable and Attractive.

​

Your software solution may be accessed on different types of devices with varied screen sizes. Although some software may be required to be potimsed for a particular screen size of device, there is often an expectation that the software can be responsive to the needs of different devices. For example providing scroll bars, scalable forms, zoomable text and other useful features that allow smaller or larger screens to display the interface effectively for hte user.

​

An attractive interface is defined by pleasing colour choices, font styles and sizes, use of white space and layout design. A pleasing interface makes a software solution a more pleasant experieince which enhances the usability of the software.

​

​

Naming conventions for solution elements

​

To ensure your software solution is easy for you and your team to edit, there are a few conventions that allow the pages of code you have written is easy to read.

​

Firstly you design your interface in a form with objects. Here we need to name our Forms and Objects using Hungarian Notation and Camel case.

​

Hungarian Notation is a convention in naming an object so it declares what type of object it is and what the object will do.

For example:

 

     txtName

​

txt - indicates the object is a text file

Name - indicates it will handle data pertaining to Name.

​

Camel Case is the use of upper and lower case to break up the names of objects. It makes the names easy to read. The Capital letter makes it look like a camel hump.

​

Common Object Names:

​

  • frmwelcome - a Welcome form

  • cbxClientList - a combo box of Client Names

  • lblCost - a label that displays Cost

​

This naming convension is also used in Variable names, incorporating the data type of the data handled with it's purpose.

​

Common Variable Names:

​

  • strName - A string that hold the user's name

  • intAmount - An integer that holds the number of items

  • dblPrice - A double (decimal) value that hold the price of a product.

​

​

​

Project management concepts and processes, including milestones and dependencies (concepts), and task identification, sequencing, time allocation, resources and documentation using Gantt charts (processes)

​

Gantt Charts are tools that manage a project. They are created during the Analysis stage once the functional requirements are identified. These determine what needs to happen to create the software solution.

​

A Gantt Chart is basically a timeline that lists all the tasks that need to be done and in what order.

​

Below is a very basic Gantt Chart Example (Please note it is NOT A COMPLETE Gantt Chart!). Here 

​

​

​

​

​

​

​

​

​

​

​

​

Elements of a Gantt Chart

​

This table below shows six columns: Task Name, Duration, Start, Finish, Predecessors and Resource names.

​

Task Names -  list all the tasks the developer needs to do.

Duration  - is the length of time it will take to do the task

Start - is the start date of each task

Finish - is the deadline date for each task

Predecessor - is the task that needs to be completed BEFORE this tasks be started.

Resources - the list of hardware, software, personel and other resources required for the task.

​

Here is another Mark Kelly PowerPoint: Gantt Charts

The Gant Chart Layout

​

The graphical display of the Gantt Chart shows the tasks as bars along a timeline. Some bars are linked by arrows. These show the relationships between tasks and their predecessors illustrating the critical path from the first task to the final deadline.

​

The project plan is highlighted with MILESTONES. A milestone is a key task that needs to be completed in the timeline. These are indicated by a diamond on the gantt chart. You can see the SRS Milestone located in the diagram below on the 17th May.

Security considerations influencing the design of solutions, including data protection and authentication
​

When designing a software solution you are obligated to consider how the data will be authenticated when entered into the system and protected once saved.  

​

Authentication is the process in which the personal credentials of a user are provided and then compared to those on file in a database of authorized users. This process is commonly called "signing in" or "logging on" using a unique user name and password. Authentication limits access to the system and it's data only to authorised users within an organisation. Designing a solution needs to consider who, within the organisation, can access which areas of the system, for example only financial administrators would have authorisation to financial aspects of the system while HR (human resources) staff would have access only to the areas of a system related to their responsibilities.

​

How the data will be stored and retrieved needs to be considered in the solution design. If data is to be stored on drives accessible via a nework, security of that data needs to be implemented and integrated into the solution design. 

​

​

​

​

Styles of modern application architecture, including mobile, rich client, peer-to-peer and internet applications

​

Application architecture is the process of identifying the components, and their interrelationships, of a structured (software) solution that meets all of the technical and operational requirements, while optimising common quality attributes such as performance, security and manageability. There are styles of application architecture such as client-server, peer-to-peer, rich client and service oriented.

 Source: http://www.vcaa.vic.edu.au/Documents/vce/computing/ComputingSD-2016.pdf

​

CLIENT SERVER

​

A client is a device that operated by a user directly while servers provide storage of data, or organsiation of email. The clients and servers are physically separate hardware that communicate over a network as part of the same system. A server shares resources with clients. In a client-server architecture, clients do not share any of its resources, but make requests of a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests. Examples of computer applications that use the client–server model are Email, network printing, and the access web sites on the internet.

​

PEER - TO - PEER (P2P)

​

Peer to peer computing or networking is a distributed application architecture. Each device have equal "rights" to access the network and stored data. 

Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts. Peers are both suppliers and consumers of resources, in contrast to the traditional client-server model in which the consumption and supply of resources is divided. An example of peer to peer networking is the use of filesharing software such as Skype.(* update, Skype in 2017 moved to the cloud and is winding down the P2P framework)

​

RICH CLIENT

​

The rich client platform (RCP) is an architecture that is designed to make independent software components integrate easily by ensuring most of the data processing occurs on the client device. A rich client depends both on locally-stored programs/resources and those available through a network server.

​

The most common architecture that provides mobile access is web-based software.  Server-Side HTML is the most widespread web application architecture. The server generates HTML content and sends it to the client as a full-fledged HTML-page. Sometimes this architecture is called Web 1.0, since it was the first to appear and currently dominates the sphere of web development. This style evolved using JavaScript where the code is executed on the client side once the server has generated the web pages.The data is used by JavaScript application, which in turn generates the HTML content of the page. This architecture is a self-sufficient and rather complex JavaScript application, where part of the functionality is shifted to the client side. This is often called Web 2.0.

​

​

​
Types of goals and objectives of organisations and information systems

​

There are many kinds of organisations, some are businesses where their primary purpose is to make a profit, while other oranisations are not-for-profit and provide services to the community. Regardless of the size of the organisation they all require information systems to support their operations.

​

An organisation will have goals and objectives that determine their operation. 

​

A goal is a statement that the organisation will strive for. Eg: "To provide excellent customer service" is one of the goals ironically touted by Telstra.

A goal may not have tangible or measurable results. It is intended to provide direction for the operations of the organisation to acheive some general improved state. Goal assist with future planning.

​

An objective is a measurable aspect of the oranisations goals. Eg: "We will expland the 2020 Network Archecture by 10% in the next 12 months". (Not a genuine object of Telstra - this was just wishful thinking on my part.)

​

​

When an information system is developed, it is important to define goals and objectives for its operation.

​

Goals for an information system could include:

  • "To enhance the custormer experience online"

  • "To improve the managment and tracking of stock"

  • "To report on student progress through an education program".

​

Information system objectives are much more specific. They identify excatly what the system will do in a measureable and tangible way.

​

Objectives for an information system could include:

  • "To provide immediate customer feedback on an e-commerce site"

  • "To display calculated discounts."

  • "To increase the number of users by 20%."

​

​

Key legal requirements relating to the ownership and privacy of data and information.
​

The steadily increasing production of data and information has lead to an evolution of traditional laws to ensure that the individuals are able to be live a free and private life and to protect the authors of data, software, information systems and information from having their work stolen.

​

PRIVACY

​

With the onset of electronic media, social media sites and increased digitisation of all aspects of regular life, such as paying bills, banking, education and training and e commerce; we are placing our personal details in the hands of digital informations systems. Keeping personal details private has been the task of the The Privacy Act since 1988 in Australia. Since then, as technology expands, there has been a Privacy Amendment - Enhancing Privacy Protection in 2012 and the Privacy and Data Protection Act in 2014. There are 13 Privacy principles that relate to a range of relevant factors such as:

​

  • the open and transparent management of personal information including having a privacy policy

  • an individual having the option of transacting anonymously or using a pseudonym where practicable

  • the collection of solicited personal information and receipt of unsolicited personal information including giving notice about collection

  • how personal information can be used and disclosed (including overseas)

  • maintaining the quality of personal information

  • keeping personal information secure

  • right for individuals to access and correct their personal information.

​

Some personal information can be sensitive and is required to be kept private such as:

​

  • health (including predictive genetic information)

  • racial or ethnic origin

  • political opinions

  • membership of a political association, professional or trade association or trade union

  • religious beliefs or affiliations

  • philosophical beliefs

  • sexual orientation or practices

  • criminal record

  • biometric information that is to be used for certain purposes

  • biometric templates.

Source: https://www.oaic.gov.au/privacy-law/privacy-act/australian-privacy-principles

 

The Australian Privacy Principles are outlined here in this fact sheet in more detail, but here is an overview:

​

Australian Privacy Principle 1 — open and transparent management of personal information

Australian Privacy Principle 2 — anonymity and pseudonymity

Australian Privacy Principle 3 — collection of solicited personal information

Australian Privacy Principle 4 — dealing with unsolicited personal information

Australian Privacy Principle 5 — notification of the collection of personal information

Australian Privacy Principle 6 — use or disclosure of personal information

Australian Privacy Principle 7 — direct marketing

Australian Privacy Principle 8 — cross-border disclosure of personal information

Australian Privacy Principle 9 — adoption, use or disclosure of government related identifiers

Australian Privacy Principle 10 — quality of personal information

Australian Privacy Principle 11 — security of personal information

Australian Privacy Principle 12 — access to personal information

Australian Privacy Principle 13 — correction of personal information

​

The SPAM Act 2003 addresses the immerging issue of unsolicited emails and text messages from organisations attempting to coax potential customers to purchase goods and services. Before the Act, email inboxes filled with unsolicited emails. After this bill was enacted, organisations that wish to send out emails are required to include an opt-out or discontinue option for those receiving them. Organisations are now required to get permission from email owners before sending promotional material.

​

Why is it called "spam"? This Monty Python sketch is the origin of the use of spam to describe repeated unwanted messages. 

​

The Health Records Act 2001 covers the management of data by health service organisations to protect the medical data and information of patients. There are eleven Health Privacy Principles found here in this government information sheet. These cover: the collection of data, use and disclosure of data, quality of data, security of data, openess of managment policies, access to data to edit correctness, the use of unique identifiers, maintaining anonymity, the transportation of data across borders, the collection of sensitive information, and finally  the transfer of data regarding health professional services from one practice to another.

​

The Charter of Human Rights and Responsibilities Act 2006 (Victoria) and 2012 (Australia) was enacted to protect the privacy  and freedom rights of Australian individuals and to govern the responsibilities of Australians and their organisations to ensrue they do not encroach on those rights. Australians have a right to:

  • maintain their privacy and reputation, 

  • express freedom of expression, religion, thought and belief

​

OWNERSHIP

​

The Copyright Act 1968 protects the ownership of creative writing, software, photography, artwork, design elements, sound recrodings, compositions and other information based products. This information sheet is an overview of the Act. 

​

As information-based works became digitised, they became increasingly easier to copy and distribute. To protect the ownership of TV programs, movies, music and other digital information products, the Copyright Ammendment Act in 2006 was enacted to stop the illegal resale of domestic and international  copywrited material. Exceptions were made for "fair dealing" in educational contexts and for making copies for personal use on devices such as MP3 players.

​

Open Source Software is software with source code that anyone can inspect, modify, and enhance where only the original authors of proprietary software can legally copy, inspect, and alter that software. To protect the authors in this situation, a licence agreement is written up. A licence is a legal agreement between two entities such as an organisation and its customers. Different licences allow for different access and distribution. An organisation called Creative Commons developed a few licences that protect developers and content makers:

​

  • Attribution: "This applies to every Creative Commons work. Whenever a work is copied or redistributed under a Creative Commons licence, the original creator (and any other nominated parties) must be credited and the source linked to."

  • Non-Commercial: "Lets others copy, distribute, display and perform the work for noncommercial purposes only."

  • No Derivative Works: "Lets others distribute, display and perform only verbatim copies of the work. They may not adapt or change the work in any way."

  • Share Alike: "Allows others to remix, adapt and build on the work, but only if they distribute the derivative works under the same the licence terms that govern the original work."

​

Source: https://creativecommons.org.au/learn/licences/

 

​

​

​

​

​

​

​

​

​

​

​

​

​
​
​
​
bottom of page