Developing Software

Software License Requirements

When software is purchased the right to use software is what is being purchased, not the software itself. There are a number of common types of / aspects of licensing models for software.

On 'Licence' and 'License'

Licence is a noun. For example, one might say that one has purchased a 50-user concurrent network licence.

License is a verb. For example, one might say that they have been licensed to use software.

Commonly in American English one would use License as a noun. (For instance, the Wikipedia page for EULA expands the acronym as 'End User License Agreement' rather than 'End User Licence Agreement'.) However, the current Western Australian syllabus uses the British English spellings, those given above.

Network Licence

There are two common types of network licences.

  • Per seat: The licence is based on the number of individual users with access to the software. In other words, if a per seat licence is purchased for 50 users, the software can only be installed on 50 computers.
  • Concurrent: The licence is based on the number of individual users that are allowed to use the software at one time. For instance, if a concurrent licence is purchased for 50 users, the software may be installed on as many computers as desired but it may only be used by 50 people at once.

Enterprise Licence

An enterprise licence is a licence issued to a large company generally allowing installation of software on all users and workstations in the organisation, i.e. unlimited installations.

Generally, an enterprise licence is applied to enterprise software.

Enterprise Software

Enterprise software is software used in large organisations, designed to meet the needs of the organisation as a whole rather than the needs of an individual user. Often enterprise software is available as a suite of customisable programs designed to cater for each of the departments in most organisations.

Some common categories of enterprise software are:

  • Accounting software
  • Business Intelligence
  • Business Project Management
  • Content Management System
  • Customer Relationship Management
  • Human Resources Software
  • Marketing Software

Commercial / Proprietary Software

Commercial and/or proprietary software is software owned by an individual or a company. Usually restrictions are placed on their use. The customers pay a licensing fee to use the software. Publishers grant rights to use the software, through the End User Licence Agreement. Users must accept the EULA to use software.

End User Licence Agreement.

When a licence is purchased, there are normally strict conditions attached to the licence, indicated in the EULA.

Some examples of conditions in an EULA are:

  • Restrictions on the number of devices the software may be installed on
  • Number/type of backup copies of the software you may have
  • Restrictions on sharing the software with other people

Software Development Factors

A number of factors influence the speed/success of software development.

User Needs

This involves determining exactly what a user of the system needs. Often when developing software the users will not be certain of what they need, or what they want and what they need will be different. Users should be included in the design process, to allow them to provide feedback on how the process is being designed; for the same reason they should also be an integral part of testing.

User Interface

There are three main factors to consider in terms of the user interface.

  • User input: What kind of input data is needed, and how data will be validated. This also includes the methods of entering data; for example, what type of field should be used to input a credit card number.
  • System Output: What kind of data is needed from the system, and the method and format of the output. Care should be taken not to add unnecessary distracting elements from the software, so-called "bells and whistles".
  • User friendliness: It is important that software is easy to use. Users should be able to use software without reading a manual or a guide, at least when using the software at the most basic level.

Processing Efficiency

The user needs and software requirements influence the processing efficiency. Considering processing efficiency is critical for high-end processing.

A number of factors influence processing efficiency.

  • Hardware factors: Processor type, amount/type of memory, graphics card, network card
  • Software factors: Algorithm efficiency, suitability of software, use of memory, choice of language (interpreted/compiled), data processing efficiency
  • Network communication: Whether or not software needs to be accessed across a network, how many users may be using software simultaneously
  • GIGO: Garbage In, Garbage Out: Efficiency/accuracy of data entry, whether or not data being entered is accurate

Development Time

Often development involves a trade-off between software's reliability and the speed of development of the software. The development methodology being used can have a significant impact on the time taken in development.

Development time can be estimated by breaking down the program into a list of modules, estimating the time taken per module/input-output screen/report and adding the estimated time for testing and bug fixing.

Technical Specifications

The technical specifications are a detailed description of the requirements and how they can be met. These specifications must be specific enough for the final product to be similar regardless of the developer. They give clear guidelines to programmers and describe relationships with other components of the system.

There are four main purposes of technical specifications:

  • Demonstrate that requirements can be met
  • Clearly state any issues or difficulties
  • Interpret requirements into instructions for programmers
  • Describe shared resources that developers may need to use to collaborate, such as schemas

Developers and users both have legal and ethical responsibilities and issues associated with them.

The differences between legal and ethical issues is outlined below.

  • Legal responsibilities are those required by law.
  • Ethical responsibilities are those guided by moral principles / obligations.

So, a legal responsibility may be unethical (i.e. being forced by law to give up customers' data for use as evidence in a court case).

Professional ethics

These ethics grant a level of professionalism. Professional ethics define / promote suitable standards, and protect professions as groups. These clarify the rights of members, employers and clients, and a guideline in legally and/or morally dubious areas.

Professional ethics exist mainly for the following reasons.

  • Software has a significant control over aspects of our lives
  • Software often plays an important role in safety, such as in anti-lock braking systems in cars and air bags, or in traffic controls.
  • Software has control over finances as well; for example it plays a significant role in banks for e.g. interest calculations, and in the Tax Filing System.

Ethical Responsibilities

The Australian Computer Society has a general code of ethics, applying to all members of the society.

  • Primacy of public interest
  • Enhanced quality of life
  • Honesty
  • Competence
  • Professional development
  • Professionalism

Some legal responsibilities include:

  • Intellectual Property
  • Copyright
  • Privacy
  • Licensing issues
  • 'Safety' of programs: the obligation to ensure that programs work as they were intended.

The following government acts are significant:

  • Copyright Act 1968 and Copyright Amendment (Digital Agenda) Act 2000: who owns the code you write
  • Privacy Act 1688 and Privacy Act 2000: what measures must be taken to protect people's data
  • Spam Act 2003: Disallowance of spam

According to the Copyright Act, a computer program is "a set of statements or instructions to be used directly or indirectly in a computer to bring about a certain result." This can include pseudocode, flowcharts, source code, parts of websites etc. This does not include the function of a program, only the written expression, so copyright does not protect against someone else rewriting the same code in a subtly different way.

A copyright owner is able to:

  • Reproduce the software
  • Edit the algorithm / source code
  • Publish the program for selling
  • Adapt the program
  • Communicate the program to the public, i.e. make it available for download / installation

Others are able to:

  • Copy 10%, or one chapter, of a reference book
  • Record TV / radio shows for personal use
  • Change the format of music, i.e. burn it onto a CD
  • Make a backup of a program if the licence has not expired
  • Make a backup of a computer program if there are no technological locks / measures in place to prevent it

If you write software while working for a company the company owns the copyright; as such you are disallowed from editing it. At university, submission of an assignment grants copyright to the university.

Privacy Act and Australian Privacy Principles

The Australian Privacy Principles regulate the handling of personal information. As of March 2014, there are 13 principles.

Part 1: Consideration of personal information privacy

APP1: Open and transparent management of personal information. This includes having a clear privacy policy available.
APP2: Anonymity and pseudonymity. This gives people the right not to identify themselves, or use a pseudonym.

Part 2: Collection of personal information

APP3: Collection of solicited personal information. When personal information can be solicited 'sensitive' information has higher standards.
APP4: Dealing with unsolicited personal information.
APP5: Notification of the collection of personal information.

Part 3: Dealing with personal information

APP6: Use or disclosure of personal information.
APP7: Direct marketing.
APP8: Cross-border disclosure of personal information.
APP9: Adoptions, use or disclosure of government-related identifiers.

Part 4: Integrity of personal information

APP10: Quality of personal information
APP11: Security of personal information,

Part 5: Access to, and correction of, personal information

APP12: Access to personal information.
APP13: Correction of personal information.

Spam Act

Spam is the sending of unsolicited commercial electronic messages (not voice messages).

Organisations must give users the option of removing themselves from a mailing list. It is illegal to sell email address lists, and you cannot use software to search the internet and compile email address lists from that.

User Responsibilities

Users also have legal and ethical responsibilities. Most of these revolve around copyright and spam laws. Users should adhere to copyright, both for legal and ethical reasons. It is illegal to make or distribute unauthorised copies of software.

Users have a responsibility to understand (and read) the EULA. Users should use software appropriately and responsibly, and adhere to any codes of conduct that may apply.

Software Development Cycle

The Software Development Cycle is the series of steps used to create a software program. It is used during the Development stage of the SDLC.

The SDC consists of eight stages.

Analysis

Using the program specifications from the design stage of the Systems Development Life Cycle, the exact requirements of the program should be determined. Constraints and limitations from any operational, technical, social and economic factors that have been identified should be considered. These factors should be used to analyse design considerations for the program. Generally, 80% of analysis time should be for I/O, and 20% for the program requirements.

Some factors to consider when analysing input requirements are:

  • Type of data to be input
  • The most appropriate input device
  • Screen layout
  • Instructions for the user
  • Minimisation of input needed
  • Minimising input errors

Some factors to consider when analysing output requirements are:

  • Reason for the information
  • The output medium i.e. onscreen vs physical printout
  • Output data types
  • Information that should be included/excluded
  • The layout of information
  • How often to update information
  • Issues regarding confidentiality

Design

Using the analysis of system requirements, the data structures and algorithms needed to implement the actual program should be designed in this stage. The program should initially be broken down into modules that can then be further broken down into sub-modules. This is called top-down decomposition.

There are three main steps to follow:

  • Design the program. The structure of the overall program should be defined, such as: the sequence and relationship between modules, the layout of input/output screens/reports, the internal and external file structures, the data transfer between modules, and the processing within each module.
  • Design the algorithm. The method of processing for each module should be defined using an algorithm. Some techniques include flow charts, pseudocode and Nassi-Schneidermann charts (which are not part of the syllabus). Some common algorithms include array and file processing, and sorting/searching.
  • Testing the design. The logic of the algorithms that have been designed should be checked in this step. Suitable test data should be created and the algorithm should be stepped through using a deskchecking method, such as trace tables.

Code

In this stage the data structures and algorithms are coded.

Development

There are two parts to development.

  • Code the algorithm in the chosen language.
  • Debug the program, checking for any syntax and logic errors.

Debugging techniques include tracking variables and stepping through code using breakpoints.

Initial debugging is also known as alpha testing.

Testing

This involves a complete review and test of the system to ensure it is ready for implementation. Sample data from real life users should be tested. The program should be reviewed against specifications and the constraints and limitations identified during analysis. Beta testing involves running the program outside the development environment with live data nad real users

Documentation

In this stage documentation is developed to assist in maintenance and use of the system. Technical documentation involves collecting all the documentation created during analysis, design and testing. This is necessary for the future maintenance and modification of the program. User documentation exists to assist users in actually using the final program, including user manuals.

Implementation

The program is installed and run on the client site. Often this is integrated with the implementation of the full system in the SDLC.

There are two main items that need to be addressed: training the users ,and testing the system and how it integrates with existing hardware and software.

Evaluation

This stage involves a reflection on how well the program meets the requirements and any problems that arise. Two procedures need to be addressed: bug and problem reporting, and improvement reporting.

results matching ""

    No results matching ""