Software Design and Development

Notes about these Notes

These notes are horribly incomplete


9.1 Development and Impact of Software Solutions
9.2 Software Development Cycle

9.1 Development and Impact of Software Solutions

9.1 Development and Impact of Software Solutions
V Social and ethical issues
V Rights and responsibilities of software developers
Rights are entitlements of the developer. Responsibilities are what the developer owes to the consumer
* authorship
The owner or person who created the work. Once created, they get to choose how the work is distributed or who the new owner will be. If there are multiple authors of a work then each member has different rights and responsibilities.
* reliability
Developers have the responsibility to their end user that they will create a product that the consumer is expecting when they buy it. The program should run without errors and efficiently. It should be compatible with as much hardware, operating systems and other programs as possible and also should be free of run time errors.
* quality
The product should be of a high quality, or at least up to the quality expected by the consumer. If the product does not meet expectations, it will be deemed low quality by the consumer and vice versa.
* response to problems
If a problem is found, the developer has the responsibility to their users to fix the problem quickly and efficiently. If the problem is minor, it might be given a lower priority to major vulnerabilities and bugs.
* code of conduct
Developers within a company may have a code of conduct by which they abide. This will boost their reputation by ensuring they stick to good methods and techniques for software developers.
* viruses
Distributed products must be free of viruses. This can be checked by virus scanners. Distributing viruses is a major problem and will significantly damage the reputation of the development company.
V Software piracy and copyright
V concepts associated with piracy and copyright including:
* intellectual property
Intellectual property is the result of mental labour. The owner of the intellectual property (usually the creator) is covered by copyright laws.
* plagiarism
This is the stealing of intellectual property and claiming or pretending that it is your own.
* shareware
A license for software programs that allows the free distribution of the product. However you must still pay for a license to use the program. You may test out the software and then buy it. It cannot be modified or decompiled
* public domain
Software that has been declared public domain means that it no longer has an owner. The owner has relinquished all control of the software and it may be used in any way.
* ownership versus licensing
When purchasing a software product, you do not buy the program as such, you buy the right to use it. Usually this is stated in the license agreement.
* copyright laws
These are laws set out by the government of a country that protects the copyright owners of intellectual property. It gives the owner the right to reproduce their own work.
* reverse/backwards engineering
This is the process of analysing the way a program works in order to create a similar program. This can be seen as plagiarism.
* decompilation
It is the opposite of compilation, where the compiled product is turned back into source code. This is usually against the licensing agreement and is usually for the purpose of steeling code.
* license conditions
The conditions set out in the license agreement are the conditions that the program must be used in. Breaking these conditions could result in the cancellation of the usage license and even legal action.
* network use
Licenses usually allow the use of the program on only one machine with additional licenses needed to use it on multiple machines. If a license allows network use t may be placed on a company server for all employees to use on their respective machines.
* various national perspectives to software piracy and copyright laws
According to a bunch of associations, heaps of software is pirated (about 30%). This causes huge losses to the software industry and as a result, big measures are being taken to combat this. Laws are being put in place.
* the relationship between copyright laws and the software license agreements
A license agreement is like a contract between the user and developer that designates how it should be used. The agreement must abide by copyright laws if it is to hold up in court.
V The software market
* maintaining market position
In order to keep market position a company must uphold its reputation as a good development company. The products sold must be useful to people, it must be sold in an appropriate place, it must have a reasonable price for what it does and its quality and it must be promoted in appropriate ways.
* the effect on the marketplace
If a company owns a monopoly in a certain field of software, the company may charge outrageous prices for something that is broken and could be of better quality. Smaller players may enter the field and shake up this market.
V Significant social and ethical issues
* national and international legal action resulting from software development
Sometimes people sue other people over software problems such as copyright infringement.
For example, Microsoft vs Apple when Microsoft released windows just after the Macintosh, Apple sued them because it was a lot like their own OS. A settlement was reached.
An American software company said that the Australia Government should pay for the upgrades to finance software being used by people in Australia after they changed the tax laws.They lost.
V public issues, including:
* the year 2000 problem
In the year 2000 people were worried that the variables used to hold year values were only two digits so some computers would think it was 1900. Software was thought to fail because of this. It didnt'.
* computer viruses
Viruses are annoying and break computers. They can damage data
* reliance on software
Software is in use in things that aren't computers such as toasters, microwaves and other appliances. Cars and airplanes have software to help them run and many large organisations, hospitals and banks rely on software to run smoothly.
V Application of software development approaches
V Software development approaches
V Approaches used in commercial systems, including:
* the structured approach
Rigid, expensive, comes up with a high quality product. Each stage of this cycle must be completed before moving on.
* prototyping
Involves interaction between end user and developer. It is a cyclical process where it is defined, planned, built, evaluated, then the cycle starts again based on the evaluation received. This is because not all goals are known at the defining stage sometimes. Concept prototyping makes several different prototypes and picks the right one to continue. Evolutionary prototyping continually iterates on the same prototype.
* rapid applications development
(RAD) A quick and cheaper development cycle. Quality reduced and less useable. Aimed to reduce development time so that the goals do not change during development. Involves continual feedback.
* end user development
Software created by the user. Plenty of errors, hard to do with no experience. Can be a customisation of existing software.
* combinations of any of the above
Sometimes combinations of the above are useful in development.
V methods of implementation
* direct cut over
When the old system is removed and the new one is implemented at the same time. New system must be able to handle the new stress and must be reliable otherwise there will be no system when it fails.
* parallel
The new system is implemented while the old one is still in place. Helps to iron out bugs in the new system. Involves double the workload for users.
* phased
When the old system is slowly phased out while the new one is phased in. For example, new features are introduced one by one. This helps to not overwhelm users.
* pilot
Some features or some people use the new system while the majority of users use the old system. This irons out some bugs in the test group.
V current trends in software development, for example:
* outsourcing
A development outsources their code generation to specialist software developers. It can be more cost effective to do this. It frees internal resources, give a higher quality result, allows access to new technology and allows you to do things not based on the company's expertise.
* popular approaches
* popular languages
Including: C, C++, Java, Visual Basic, PERL. Popular languages are used because lots of people can use them and lots of machines can execute them.
* employment trends
Jobs in the IT industry are steadily increasing due to the huge demand for software. Unfortunately the number of people graduating in these areas is not increasing at the same rate.
* networked software
Software is now distributed in lots of ways. Software can be executed remotely on mainframe servers, PC's are networked linked to printers and other external hardware, databases can be stored on servers for users to access. Stuff can be downloaded and executed in the browser.
* customised off-the-shelf packages
Things like Microsoft Office can be COTS packages. People customise them to do what they want. COTS packages can be combined together.
V use of CASE tools and their application in large systems development
* software versions
CASE tools can take snapshots of programs to make sure important milestones are not lost if they are altered beyond repair. They can also help for the release of software in number the version as a minor or major update.
* data dictionary
Can create a data dictionary documenting the variables in a solution automatically. This helps in creating non-clashing variable types.
* test data
CASE tools can examine the code of a solution and produce test data that will test boundary conditions of loops, gates, data passing etc.
* production of documentation
CASE tools can be used to produce developer and user documentation automatically. This will help later when developers need to go back and examine what they have done to maintain the solution.

9.2 Software Development Cycle

9.2 Software Development Cycle
V Defining and understanding the problem
V Defining the Problem
V identifying the Problem
* needs
If you are developing a software solution, you are probably trying to fulfill a need. It is important to know what the needs are when you start out. What is the need you are fulfilling by creating a solution? Sometimes they don't refer to a software solution at all. An example: A small business needs an easier way to track their finance than pen and paper. It is often described in emotive non-specific terms.
* objectives
Objectives are what the software solution needs to do in order to fulfill needs. For example, the software solution must be able to boot quickly when opened.
* boundaries
The limits of the system: what it will and will not do. The boundary can describe how far the system will extend, meaning knowing the boundaries can be important in determining the interface between the system and the environment.
V determining the feasibility of the solution
* is it worth solving?
Carrying out a feasibility study will determine if you should solve a certain problem in a certain way. It will ask the following questions:
* constraints
What are the constraints of the potential solution?
* budgetary
How much will the solution cost to build and implement?
* operational
How hard will it be to operate the solution once implemented. Will it benefit the users?
* technical
Is it difficult to create/implement the solution.
* scheduling
How long will this take to complete.
* possible alternatives
Is there another better way to solve the same problem.
* social and ethical considerations
How will this impact on the workers/users. How will this break the law or copyright?
V Design Specifications
V the developer's perspective in consideration of:
The developer's perspective considers everything they will need to deal with in the development including:
* data types
How will the data types interact and contribute to the final solution
* algorithms
How will the algorithms run in order to do its job? Inputs and outputs must be considered.
* variables
How will the variables interact in the final solution
* the user's perspective
Screen elements and user interface is the user's concern. Also, ergonomics and system requirements.
V Modelling
V representing a system using diagrams, including:
* Input Output Process (IPO) diagrams
A three column table: input, process and output. An input is placed in the left column and the processes that act on it are stated in the next column. At the foot of these processes, the output is placed in the right column.
* story boards
Show the flow between different screens in a solution. This can involve screen designs.
* data flow diagrams
Describe the path of data and nothing else through a system. Boxes are external entities, circles are processes, arrows are labeled with the data item(s) being passed. An open box is a data store.
* systems flowcharts
A flowchart that represents the flow of logic and data through a system including paper and physical processes. Boxes represent processes, a parallelogram represents input or output, a diamond is a decision.
* screen designs
Show what the GUI will look like potentially in the final solution.
* consideration of use of a limited prototype
V Communication issues, including:
* the need to empower the user
If the user is empowered in the development, they become fond of the final solution and will more likely enjoy using it. It gives them a sense of ownership.
* the need to acknowledge the user's perspective
The user must be involved otherwise the developer can lose sight of what the software was for in the first place. There must be meetings, questionnaires, interviews and informal chats.
* enabling and accepting feedback
The feedback received by the developers must be implemented or at least considered if they want the solution to be successful. After all the feedback comes from the target audience.
V Planning and design of software solutions
V Standard algorithms for searching and sorting
V standard logic used in software solutions, namely:
* finding maximum and minimum values in arrays
Use a linear or binary search below.
* processing strings (extracting, inserting, deleting)
Extracting: taking x to y from a string and turning it into its own string
Deleting: removing x to y from a string
Inserting: putting x to y at position z in a string
* file processing, including sentinel value
Sentinel value: A character/string that's sole purpose is to declare the end of a file or part of a file. Used in sequential files.
* linear search
Going through the entire array, looking for the biggest or smallest value one by one.
* binary search
In a sorted array, the middle value is tested. Based on this, half of the array can be eliminated. In the half that wasn't eliminated the middle variable is tested and so on until the correct value is found.
* bubble sort
The first two cells are compared, if they are out of order, they are swapped. Then the second and third are compared and so on. Once the end is reached, the entire thing is started again and again until no swaps have to be made. This makes the correct variables kind of float like a bubble to the correct position.
* insertion sort
In an already sorted array, we find the correct position for a new variable. The rest of the array is shuffled up one space to allow the new variable in. It is then placed in the array.
* selection sort
Like a linear search where the biggest/smallest value is found. This variable is then moved to the front/back and the process starts again in the rest of the array until completed.
V Custom-designed logic used in software solutions
V requirements to generate these include:
* identification of inputs, processes and outputs
IPO Chart!
* representation as an algorithm
Use a flowchart or pseudocode to represent some logic.
* definition of required data structures
You should figure out which data types you will need.
* use of data structures, including multi-dimensional arrays, arrays of records, files (sequential and relative/random)
Multi-dimensional arrays: arrays containing arrays. Can be represented as a table.
Array of records: An array that contains records: arrays with different data types in them.
Sequential files: have data stored in a way that you have to pass through the stuff in the file before your data.
Relative/Random: Usually contain a type of table of contents to direct you to where to go in a file. They have structure.
* use of random numbers
Usually make a number between 0 and 1. This can be multiplied by the maximum number needed to get a number between that value and 0. A rounding function can be used to make it an integer.
* thorough testing
This is important. Make good test data to test boundaries.
V Standard modules (library routines) used in software solutions
V requirements for generating or subsequent use include:
* identification of appropriate modules
Use a top down method: there is a main module which utilises sub-modules to do work for it. Like a jigsaw puzzle
* consideration of local and global variables
In each module there will be variables. Be careful not to allow variables from global and local contexts clash.
* appropriate use of parameters (arguments)
Passing of variables should be used. If it is a global variable, don't bother. Passing can help modules to do their work without confusing variables.
* appropriate testing using drivers
Drivers are like stubs but in reverse. They help to test sub-modules by giving them dummy values and seeing what they do.
* thorough documentation
Always important if you want to maintain effectively. External and internal.
V Customisation of existing software solutions
* identification of relevant products
Things such as Microsoft Office can be used as COTS packages.
* customisation
Sometimes COTS packages offer inbuilt languages that you can use to customise it.
* cost effectiveness
Customisation of something that already exists significantly reduces the time needed to create a solution. Be wary if you want to sell the product though, you may need to pay license fees.
V Documentation of the overall software solution
V tools for representing a complex software solution include:
* algorithm descriptions
As seen above (Defining and understanding the problem>Modelling)
* system flowcharts
As above (Defining and understanding the problem>Modelling)
* structure diagrams
Show the structure of modules in a solution. Like an upside down tree, boxes represent modules, lines between them represent calls and the arrows along them represent the data passed. They are useful for representing top down/modularised solutions.
* data flow diagrams
As above (Defining and understanding the problem>Modelling)
* data dictionary
A table to show all the variables used in the solution. Columns include name of variable, length, data type and description.
V Selection of language to be used
V event-driven software
* driven by the user
Is the user going to need to find their own path through the solution? Event driven languages would be best here. The language runs code based on events such as mouse clicks.
* program logic
V sequential approach
* defined by the programmer
If the program logic is linear then you might want to use a sequential language. These have lines of code that are executed one by one until the end is reached and the program terminates.
* relevant language features
Does that language you want to use support all the functions you need for the solution?
* hardware ramifications
Will the software you create be able to run on the required hardware? What are the minimum system requirements?
* Graphical User Interface (GUI)
Will the software require a GUI? If it does you will probably need an event driven language.
V Implementation of software solution
V Interface design in software solutions
V the design of individual screens, including:
* identification of data required
The screen design should be based on what data needs to be presented. So a list can be presented by a drop down list box and a string can by shown through a text box.
* current popular approaches
It is best to go with the interface design everyone else is, this is because users will not have to add an additional layer of learning to the implementation of the solution.
* design of help screens
Context help: Tooltips can be used when hovering over screen elements.
Procedural help: Step by step instructions on how to do stuff
Conceptual help: Help on what the program can do and what it is for
Tours/Tutorials: Walk you through a procedure.
* audience identification
If you are going to write a program for a blind person you aren't going to need screen elements are you? Little kids probably can't handle complex screen design.
* consistency in approach
Should be consistent with the operating system and within your own product.
V Language syntax required for software solutions
* use of BNF, EBNF and railroad diagrams to describe the syntax of new statements in the chosen language
In BNF: Terminal symbols have no brackets, non-terminal symbols have <these> around them, or is represented by this|thing, the equality statement is ::= that.
In EBNF: same as above but assignment is = that, Optional part is [this], possible repetition is {here}, repetition at least once is here{here}.
V commands incorporating the definition and use of:
* multi-dimensional arrays
* arrays of records
* files (sequential and relative/random)
* random number generators
V The role of the CPU in the operation of software
V machine code and CPU operation
* instruction format
An instruction is in binary. The order in which things occur in the instruction bytes are:
Telling the CPU what type of instruction this will be, which registers to use and how to obtain data.
Opcode: specifies the instruction to carry out a task in machine code, Operands: A value to be operated on.
* use of registers and accumulators
Registers are types of memory close to the CPU so they can be accessed fast. It holds the size of one word of the processor. The accumulator is a register that accepts the output of the arithmetic logic unit (ALU).
* use of program counter and fetch execute cycle
The program counter is used to store the location of the next line of code. Once code has been retrieved, the program counter is incremented. If a loop is occurring then the code fetched may be used to alter the program counter value.
In the fetch execute cycle, code is fetched from memory and placed in the instruction register. The program counter is incremented. Instruction is decoded by the control unit. The required operands are loaded from memory. The instruction is executed usually by the ALU and the result is stored, usually in the accumulator. Fetch-execute timer reset.
* addressing of called routines
A stack is used to point to the correct line of code when a subroutine is called. It is a way of keeping track of which line you are up to.
* linking, including the use of DLL's
DLL's: Dynamic Link Libraries, Files that contain code that add to the functions of a programming language. They are distributed with programs.
V Translation methods in software solutions
V different methods include:
* compilation
After writing code, the developer compiles the code: the entire program is converted to machine code. This is then distributed to users.
* incremental compilation
Like compilation but only the code that has changed since the last compile is compiled.
* interpretation
Source code is read line by line. Each line is converted into machine code, executed and then the next line is read etc.
* the translation process
There are three steps to the translation of program code into machine code:
Lexical analysis: Each word written in the code is checked against a list of reserved words or words that already exist. If the word is a reserved word in the language then it is swapped with that word's "token" (basically a symbol). If the word is not a reserved word, then it is checked to be a valid word in the syntax of the language. If it is, it is placed on a new list containing words used in this code and assigned a new token. If the word is not a valid part of the language then an error occurs.
Syntactical analysis: after the entire code has been converted to tokens, then each line of code (now tokens) is checked to be a valid line. You can do the same by checking a line against an EBNF or railroad diagram. If a line is found to be a problem, an error occurs.
Code generation: after the code has been syntactically analysed, it is converted into machine code. Each token is converted into binary. No errors occur here because the would have been found in the last two steps.
* advantages and disadvantages of each method
Compilation may take a while to export but it means the actual execution of the code is quick. Unfortunately the code must be executed on the same processor architecture that it was compiled on.
Incremental compilation's only advantage over compilation is that it makes compilation quicker in larger projects.
Interpretation means source code is distributed with the solution allowing anyone to see your code. The code must be converted at runtime so this significantly slows performance.
V Program development techniques in software solutions
V structured approach to a complex solution, including:
* one logical task per subroutine
A subroutine should be specialised in a way that it can be reused for many different purpose so it helps to make it only specific to one task.
* stubs
A stub is put in place to simulate a subroutine. It is used to test that main modules are working correctly.
* flags
A boolean value that tells the developer if a particular line of code has been executed or not.
* isolation of errors
Use any and all of these other techniques to isolate the location of an error.
* debugging output statements
These can be placed periodically to note the source of errors.
* elegance of solution
As simple as possible to reduce process time. Makes it easier to read too.
* writing for subsequent maintenance
If the software is going to be looked at again in the future (and you are kidding yourself if you say it isn't) then you might want to write the code so that it is easier to read later. Comments, logical structure, sensible variable names.
V the process of detecting and correcting errors, including:
* syntax errors
These occur when a word is used that is not in the language. Or when a line is not allowed in the language. Found during lexical/syntactical analysis.
* logic errors
These are hard to find because they are errors in the outputs while the program executes normally. Sometimes they can manifest as runtime errors such as infinite loops.
* peer checking
Get a friend to check your code if you can't see the error in it! They will bring a fresh perspective on the situation.
* desk checking
Try running code using the power of your mind! Write out the results on paper, line by line. This can reveal exactly which line an error occur on.
* use of expected output
If you know what you are expecting to get out of the program then you can compare what you actually get to find where a problem may be occurring. Or you could use it as a starting point to figuring out if there is an error at all.
V run time errors, including
* arithmetic overflow
Occur when big/tiny number occur. Numbers outside the programming language's number range will cause this error.
* division by zero
There is no value for something divided by zero, it simply cannot exist.
* accessing inappropriate memory locations
This can happen when assigning a string to an integer variable. Or if the variable you are trying to assign doesn't exist.
V the use of software debugging tools including:
* use of breakpoints
Breakpoints allow the developer to pause the execution of code at a specific line. Then you can examine the contents of variables.
* resetting variable contents
During a break in the code you can change a variables contents to see what effect it has on execution.
* program traces
These allow the developer to track the changes made to a variable. You can do this while executing code slowly, or during a breakpoint. Sometimes a log file can be created at the end of execution with the results.
* single line stepping
At a breakpoint it is often useful to step line by line through code examining how variables change with each step.
V Documentation of a software solution
V forms of documentation, including:
* process diary
Used for developers to document the progress made in a software solution. It can hold the processes used to come to a solution.
* user documentation
Including installation guides, user manuals, reference manuals and tutorials. I think these a pretty self explanatory.
* self-documentation of the code
Including comments and intrinsic documentation. Comments are placed next to lines of code to explain what it does. Intrinsic documentation like sensible variable names and indentation help developers see the code as it is organised well.
* technical documentation, including source code, algorithms, data dictionary and systems documentation
Help to explain the complete structure of a solution using ideas discussed earlier.
* documentation for subsequent maintenance of the code
A lot of developer documentation is specifically done to help the future developer who might want to alter the code.
* use of application software to assist in the documentation process
This is done by COTS packages but haven't we talked about this before? DUPE!
V Hardware environment to enable implementation of the software solution
V hardware requirements
* minimum configuration
If you have a computer worse than this then you can't use the solution. It should be low if you want to reach a large audience.
* possible additional hardware
Does the software need more hardware? This might cost extra.
* appropriate drives or extensions
Hardware requires drivers to operate properly with your software. Be wary!
V Emerging technologies
* hardware
New hardware is always being created to run faster and more efficiently.
* software
New software is also always being made
V their effect on:
* human environment
* development process