Steve Bastable

SDD Notes

steve@jamark.com.au

Social and Ethical Issues

Anything that goes through a creative process could be classified as intellectual property. Copyright allows the creator of such items to be acknowledged and compensated for the time and effort involved. Therefore software is subject to the laws of copyright. The acquisition of any software, whether it is purchased, freeware or custom developed brings s with it the responsibility that the user adheres to the condition of any license. Most software licenses give the purchaser the rights to use the software, and then user does not have ownership of the software or the code. Therefore the software can only be used in the way specified by the license and in the majority of cases the code cannot be modified or backwards engineered. Because a software license is a legal document a user enters a contract upon opening the software and therefore accepts the condition of the license. The license will usually specify the number of computers that can be installed with the software as well a s the way in which any backups or duplication of the media can be managed. The license agreement is binding whether it is purchased commercially, as a downloaded shareware of public domain.

Rights and Responsibilities of Software Developers

These responsibilities include: Claiming authorship only of what they have written themselves. Creating reliable software. Creating quality software. Responding to problems. Following an ethical code of conduct. Preventing the spread of viruses.

Authorship
An author has two responsibilities: To protect their interests in the system being developed. To protect the rights of other authors whose modules are incorporated in the final solution. The authors of these modules need to be acknowledged. The developer also needs to clear any code used with the copyright holder. If clearance is not gained then the module cannot be used and therefore the developer will need to create their own module.

Reliability
A developer should ensure that the program performs its task reliab ly and effectively. Reliability is the softwares ability to perform without failure. Software is unreliable when it performs in an unpredictable way. Failures in software are usually the result of faults within the software. However they are not the o nly source of failure. Sometimes the introduction of a new OS or hardware driver may cause a conflict in the program. Failure in software does not necessarily mean the software is unreliable as it may only affect the program itself and if correct safeguards are built in full data recovery should be possible. However a program that is unreliably and upon failure starts overwriting other files on the system is undesirable and therefore deemed very unreliable. An alternative example of unreliable software is when one thing is requested and the program performs another function (eg performing an ascending sort when a descending sort was requested. The issue of reliability is a complex one. An author can include code to improve the reliability which thoroughly checks input data and operational aspects of the code. The disadvantages of this method are that the performance of the software is degraded and development costs are higher which will more than likely be passed on to the consumer.

Quality
Quality is measured by a number of criteria. Many companies, including software development companies, can seek endorsement via Quality Assurance (QA). These companies are often identified by the red vertical rectangle logo containing a number of ticks. The criteria are: Ease of use (eg Consistent and intuitive interface). Interface will often mimic a familiar non computer system. Quality of documentation including both process documentation which is created during the development cycle as well as the product docume ntation which is created for the end -user. Both should be of high quality. Current trends have much of the end -user documentation in an electronic format. This can either be printed off or used active, and it is generally a cost saving to the manufacturer. Software standards. These standards cover aspects such as the form of documentation, algorithm description, coding and the user interface. This keeps developers in the production of re-usable

Steve Bastable

SDD Notes

steve@jamark.com.au

modules. It also gives a new member to a development team a very easy learning cycle when they come into a company and begin working on an existing project.

Response to problems
One of the existing challenges that many programmers relish is solving different programming problems. This needs to be done in an or derly fashion and the first steps that must be carried out then are: Understand the development problem. Design and test a solution to the development problem. Implement the solution to the development problem.

Code of Conduct
Codes of conduct for develop ers should cover the following: Acknowledgement of contributions made by all participants involved with the development process. Clearance of copyrighted modules written by others. Privacy of personal details, security of data and maintenance of business s ecrets. The use of appropriate prompts within the program so that it is non -threatening, non-racial and intrinsic.

Viruses
Developers have a responsibility to ensure that they have procedures in place so that they do not receive or transmit viruses. The following precautions should be taken: Scan any removable media before use (including floppy disks, CDs, disk cartridges and storage devices such as external hard drives). Filtering of e-mail so that malicious e-mails are removed before causing problems. Not mixing home and work applications on the same computer (eg use games and internet on a separate workstation). Keep your virus checking software up -to-date.

Software Piracy and Copyright

The laws of copyright are there to protect authors from copying l egal software commonly known as piracy. Following terms are associated with copyright and piracy: Intellectual Property - Intellectual property is a work relating to some creative activity. Plagiarism - Plagiarism is the process of claiming authorship of an intellectual property owned by another person. Shareware Shareware usually has a time limit and is freely distributed and usually has a nominal charge after the time limit has expired. It is an honesty system which usually works if the software is good quality. Public Domain Public domain is shareware that is freely distributed (freeware). Ownership VS Licensing A common misconception is that when you pay for software that you own it. Wrong. In most cases the purchaser has the rights or license to use that software with certain restrictions. The author owns the software. The only time an end -user can outright own a piece of software is if the author was commissioned to write the software for a company and then agrees to relinquish all rights of ownership. Copyright Laws Copyright laws are there to protect the rights of authors. The copyright act of 1968 is commonwealth act number 63 of 1968, of Australia. The full act can be found at scaliplus.law.gov.au/home/mainpage Reverse\Backwards Engineering - Reverse\Backwards Engineering is the process of looking at an existing software solutions code and then using their methods to solve your solutions. Decompilation Decompilation is a process of translating executable files into assembler language, so that the structure of the program can be examined. It is possible, however illegal in most cases, to decompile an executable. License Conditions License conditions spell out how the software is to be used, including the making of backup copies and the number of computers the software can be installed on. Network Use Explains how the software can be used on a network and will usually reference the number of computers that can be connected. Site licenses for network computers can be for a total site, limited numbers that are self administered or software licensing - metering must be used to control the number of access points.

Steve Bastable

SDD Notes

steve@jamark.com.au

Application of Software Development Approaches

Solutions to Problems
There are four major types of software development ap proaches.

Structural Development Approach

The structural development approach is a tried and tested system divided into five stages: 1. Define the problem. 2. Plan the solution. 3. Build the solution. 4. Check the solution. 5. Modify the solution. Importantly each stage must be completed before the next stage begins.

Prototyping
A prototype is the creation of a working model. They are often used to get end -user reactions to screen designs, etc before and during development of an application. The model may only be use d to gather information that can be used as a guide in the development of the final solution using more appropriate tools. However prototypes can also be further developed into the final solution. The method is very good for interactive software (eg mult imedia) where additions can be made as the ideas come to mind. It is not suitable for complex systems including those requiring mathematical calculations\manipulations. The temptation is to develop prototypes without documentation however this should be avoided as the same development processes used in structural development should be used in prototyping.

Rapid Application Development (RAD)

RAD allows foe fast application development. Some RAD approaches allow for the re -use of code, or the use of Computer-Aided Software Engineering (CASE) tools and also using templates. CASE tools are Visual Basic, HyperCard, Hyper studio, Tool book, Microsoft Access, File maker Pro and real BASIC. The RAD approach usually lacks formal stages and is more suited for sma ll, low-cost projects with small development teams. Users and programmers are often directly involved in the development process.

End-User Development
End-user development involves the adaptation of software tools by the user. Development is usually informal. Projects are usually very small and are usually very cheap to produce. Most end -user development uses fourth generation programming environments such as spreadsheets or databases.

Software Development Approaches

Structured Approach
Structured approach is the most formal. With each phase being thoroughly documented. This allows for the reference of the processes for later development. Structured approach can be viewed using the waterfall model. Define the problem Plan the solution Build the solution Check the solution Modify the solution The structured approach will usually involve a number of specialists. System analysts are involved in the first two stages which is planning, implementation and maintenance of the computer based system. System analysts need good management and personnel skills so that they can interview users and make recommendations as to the hardware and software needed. From this information they develop plans and schedules. They need to be up -todate with current computer trends including hardware and software developments. After the analyst has done their job they pass their findings and designs on to a programmer, who in fact will probably do the majority of the work on the system. The programmer depends on the analyst for detailed specifications in order to meet the requirements of the new system. Two types of programmers exist: 1. The system programmer who also writes instructions for the computer s OS 2. The application programmer who writes the instructions for the computer to perform a particular task.

Steve Bastable

SDD Notes

steve@jamark.com.au

Both analysts and programmers will usually have a tertiary degree in computer sciences. Programmers will often have a number of languages they are proficient in however they will have a preference for one. Management are heavily involved in the system development cycle as they should have an intimate knowledge of the existing system. It is virtually impossible to successfully develop a new system without the involvement of management and users.

Steps Involved In the Structural Approach Define the problem

Problem definition looks not only at the problems being experienced by users of the current system but at all aspects of the system as something that is actually working well may in fact be causing problems elsewhere in the company. During this stage, management and users are interviewed; data is collected about the existing system using observation, collection of documents, questionnaires and surveys. After data has been collected and analysed, a set of requirements are drawn up. These requirements are used to design the software and are also used as a performance measure of the final product. The problem definition will also state and restrictions that may need to be placed on the software solution. The most important section of this phase is to produce a feasibility study. The feasibility study considers many factors in an attempt to determine whether to proceed or not with a new system. The feasibility study includes: 1. If the problem is worth solving. 2. Constraints on the development. a. Financial Feasibility b. Operational Feasibility c. Technical Feasibility d. Scheduling 3. Possible alternatives 4. Social and ethical issues.

Constraints on the Development

These are the limits placed on the system which may control the a mount of change possible or needed to implement the new system. Financial Feasibility Financial feasibility is the ability of the organisation to profit from the implementation of the new system. It is often presented as a cost -benefit analysis where the costs of the new system are compared with its benefits. Operational Feasibility Operational feasibility is centred on the capability of the organisation to handle the manual processing involved with the system. Technical Feasibility Technical feasibility is concerned with matching the organisation s technical resources with those needed by the new system. You need to assess the hardware and software requirements so that tasks can be handled by the proposed new system. Scheduling Scheduling examines the proposed system can be implemented within a deadline. Deadlines can be inflexible (eg Y2K). Any new system needs to take into account social and ethical issues (eg safeguards of personal information located on a large database need to be protected in ways that will avoid non-authorised viewing.

Methods of Implementation
When converting from an old system to a new one there are a number of methods of converting to the new system. Each has its positives and negatives and each system needs to be looked at on its own merits for the conversion method that best suits it. There are four conversion methods: Direct Direct conversion involves and immediate conversion to the new system. The old system is discarded. Data from the old system would need to be convert ed over to suit the new system prior to conversion. Any testing of the new system would need to happen remotely. The new system comes online with all users converting simultaneously. If both hardware and software are new the conversion is usually a minor disruption. If no computers were in use then this may be a major conversion for the company. Old data would need to be entered while the business still attended to normal daily operations therefore extra staff may be needed, for the data entering and t he training of old staff. If the system fails or a problem becomes evident the old system is not available and therefore direct conversion is rarely used.

Steve Bastable

SDD Notes

steve@jamark.com.au

Parallel Here both new and old systems are run simultaneously for a period of time so that any bugs in the new system can be ironed out, users can familiarise themselves with the differences of the new system and if there are any problems in the new system then the old system is there as a constant backup. The major problem with this method is the addi tional workload required of all staff. Phased Phased conversion involves the gradual implementation of the new system, where certain operations of the new system are carried out using the direct or parallel conversion method while the rest of the organisation operates using the old system. Operating modules of the new system can be used to test the system and train staff. If the modules are tested to be reliable and the staff become more confident in its use the new modules are fully implemented. This is repeated until the whole system is operational. This is a far safer method of converting however it is more time consuming. Pilot Here the new system is fully installed but only used for some operations as the old system is still being used. One part of the company maybe taken off the old system and instructed to use the new system. The old system is still available if any problems are experienced with the new system. In this way only a small amount of data will be lost. Variations to this allow for pa rts of the system to run, be tested and trained on by small groups while the old system is still operational. The pilot group of users evaluate the new system and if implemented are used as peer trainers for the rest of their section. This method eliminates many of the problems associated with direct conversion.

Current Trends in Software Development

Software development is continually evolutionary. Initial development approaches were very formal due to the need to program in such a way that easily conv erted into machine code. As the costs of computing power decreased, the environment became more sophisticated allowing programmers to employ more sophisticated ways to program. It also meant the general population had better access to computing power wit h non-computer professionals creating computer programs for their own use. The industry itself has moved away from the use of mainframes and terminals to networked PCs. Therefore the way software is obtained has changed. Early commercial computing had in -house specialists writing software for specific applications. Two businesses with exactly the same needs and computer systems would each write their own applications. As business computer numbers increased and a greater standardisation of operating syst ems and the use of horizontal software has become the popular option to custom -designed software. For those solutions that are more specific to a particular user, software is usually developed by contract software developers or end -user development.

Outsourcing
Most large organisations have disbanded or at least reduced permanent IT staff. Most permanent IT staff has a maintenance role. If new vertical software is needed then outside developer contractors are sought. Outsourcing allows a business to hav e expert software developers when needed without the expense of maintaining a full-time IT staff.

Popular Approaches to Software Development

These range from very formal structural approaches to ad-hoc approaches taken by many end-user developers. Web page development tools, for example, use an evolutionary prototyping approach especially for end users. Commerce and industry need software that is both accessible and usable by large numbers of users. A client/server approach to software engineering cater s for this need. Small end-users often simply customise off-theshelf applications to provide the solution.

Popular Languages
Languages which are formal, structured, software development tools include C++, VB, Delphi and Java. Languages than range down to informal languages such as spreadsheets, webpage editors and macro recording tools. End-users with little or no formal training in programming can develop quite sophisticated software solutions with informal languages. Note: as technology becomes more powerful and accessible, variations to these informal languages will become increasingly popular.

Employment Trends
Most businesses have moved to outsourcing development. Therefore most IT employment is based on a contract model by lasting until the end of the development or a fixed term.

Steve Bastable

SDD Notes

steve@jamark.com.au

Networked Software
Businesses have moved away from time-sharing a mainframe to a network of PCs linked to a server(s). This trend impacts on the development of software as the client/server model involves four parts: 1. Interface The interface governs the interaction between the user and the system. It communicates not only the state of the application but also network messages. 2. Application - The application should meet the software requirements of the end user. 3. Database Management - Database management system is responsible for manipulating and managing the data. 4. Network Software - The network software provides the means for communication to take place on the network Other considerations when developing network softwar e are the demands placed upon it if multiple users need simultaneous access to the same file.

Customised off-the-shelf packages.

There is an increasing demand and availability of off -the-shelf (horizontal) software. Some, for example word processors, perform their tasks with no need for modification. Others, such as book keeping programs (MYOB, Quicken), will need to be modified from the options available within the package to meet the individual needs of the end-user. Developers can benefit from this type of software as it gives them a larger audience for the sale of their product. Customisations can include interface, reports and conversion of old data to the new system. Developers often use a prototyping approach or and end -user development approach. Other advantages to the developer and end -user are that cost of development is reduced and end -users acquire cheap software that performs the desired task to at least 90% of their needs. Technical support is also cheaper due to the larger user ratio.

The use of CASE tools and their application in large system development.
CASE stands for Computer Assisted Software Engineering. CASE tools assist developers in their software development and maintenance of it. Some assist in a particular activity or fun ction while others form an Integrated Development Environment (IDE). Some tools perform particular tasks (e.g. text editors).

Software Versions
During the development of a software package, it will have a release version that supersedes older versions or development versions and there will more than likely be a number of future versions under development. A number of CASE tools help in this version situation. The problem with continually evolving software is managing the different versions. To help this, each version is given a name or number, the numbering system being the most common. First release versions of software are usually version 1 or have no number at all. Major version changes and \or upgrades are given whole number identities (Eg v2.0, v3 .0, etc). Updates within major releases are given a point value (Eg v1.1, v1.2, v1.3). Bug fix releases are given a point identity (eg v1.1.1). (SEE Software Version Symbols. jpg) The management of software product changes is known as software configurat ion management (SCM). To avoid conflict of different versions by the different parts of the development team, a central body is needed to evaluate and track the different version developments. One of the most important aspects is to properly document the changes for both developers and users. Some integrated CASE tools such as AIX SDE Workbench and SPARC works tools contain version management components.

Data Dictionaries
Large development projects will often use appropriate networked CASE tools to mana ge the data dictionary and it will enable all the developers to have access to the current, up -to-date data dictionary for their project. Many large projects have data dictionaries so complex that they would be manage manually. Some integrated CASE tools will allow the data dictionary to be created from a data flow diagram. Produced within the CASE environment. These data dictionaries will contain a number of entries for each data item including: 1. Identifier The main name of the control or data item (e g Cost, Name). 2. Alias An alternative name for the same data item (eg if a swap has to take place a temporary data item will be needed such as i.e. cost_temp). 3. Processes Processes that use the data item together with the way in which the data item is use d (eg Cost may be calculated by multiplying the quantity and unit price together). 4. Other Information A generalised category which includes data type information which includes limitations or restrictions on the data items and any pre -set values.

Test Data
Test data falls into two categories:

Steve Bastable 1. 2.

SDD Notes

steve@jamark.com.au

Data to test the correct the workings of modules. Test data to evaluate the performance of the system under simulated working conditions.

There exist test data generators used to create large sets of test data. Spe cifications and syntax for the particular test data are input into the generators which then run a comprehensive set of test data through the system automatically. A program known as a file comparator can be used to compare the outputs of two different ver sions of the same program. The same test data is entered into the two versions with the output being saved. File comparator then evaluates and displays what differences there are.

Production of Documentation
Documentation is a continuous process through out the software development cycle. Draw programs can be used to produce data flow diagrams and a CASE environment incorporates the production of documentation. This allows the developer to produce documentation at the same time as the development of the application. In its simplest form, a word processor can be used to keep track of software documentation with outline mode being the best utilisation. Graphical type applications (eg VISIO) allow for the production of DFDs, system flowcharts, structure ch arts and flowcharts, etc. Graphically based CASE tools include: 1. Adobe Illustrator 2. Create 3. Gsharp Graphical tool for Sun, DEC and IBM and other mainframe and mini computers. 4. Rose\C++ 5. Smart Chart 6. VISIO A number of document-oriented CASE tools exist. Their purposes vary from templates through to automatic document production. For example 1. ALDA 2. DocBuilder 3. LifeCDM

Defining and Understanding the problem

Define the Problem
Three stages exist: 1. Understand the problem 2. Work out the solution 3. Checking the solution To understand the problem we must first identify the problem, its needs, its objectives and its boundaries.

Identify the Problem

You need to examine a number of factors which include the needs of the users, the objectives that the solution is to meet and the boundaries in which the solution is to operate. Lastly, a feasibility of whether it is actually possible to implement the proposed solution must be considered. By covering needs, objectives and boundaries and that all contributing factors have been id entified will ensure that the solution meets the requirements of the end -user.

Needs
The users needs are one of the most important factors however there are other considerations. The needs of the system will also involve the need to represent various da ta items, the need to store certain facts, the need to perform certain processes and the need to output data in a particular manner (IPO of the system). Human needs are probably the easiest for systems analysts to identify since they can mentally put themselves into the position of the user. By using surveys, interviews and observations, the analyst can identify how people interact with the current system and highlight the problems they face. All classes of users need to be considered, wether they be direct or indirect users, so that the new system may perform properly. Other system needs are determined by the type and the amount of processing required (eg graphics systems and full screen motion video will need suitable hardware in order to work acceptably ). However if personal organisers are to be used within a system then their processing power will be much less demanding, however wireless connectivity may be an issue.

Steve Bastable

SDD Notes

steve@jamark.com.au

Objectives
Objectives are an analysis of the needs of the system. The objectives can be placed into categories. Some will relate to the interaction with the user, while others might specify how the output is to be presented. When determining the objectives, the needs of the system are examined and converted into a number of statements. These statements are written in such a way that they provide a means of evaluating the performance of the new system (eg manufacturing company may wish to automate its production line. The need of a company is to perform several of the manufacturing tasks using robots. This need is then translated into certain objectives such as the production line being able to produce a certain number of articles within a particular time.

Boundaries
A system performs a certain function within a wider environment. Each system interacts with one or more other systems that exist within the same environment. The outputs of one system become the inputs of the next one in the chain. When designing a system its important to identify where the boundaries of each system are. Individually different people may see different boundaries from someone else. Ergo when we develop a system we need to ensure that the boundaries are clearly identified, especially when there is a team developing a software solution.

Determining the Feasibility of the solution

You may want but that does not necessarily mean you can achieve that goal. Some things are impossible and ergo it is not feasible to attempt the impossible. The feasibility of the solution will depend upon a number of factors. T hese factors range from the obvious ones (eg is the problem worth solving) to the less obvious ones (eg can it be implemented within a reasonable time frame). When a system is developed, these factors are examined and reported on in a feasibility study.

Feasibility Factors
The following is a list of all the feasibility factors that need to be covered. 1. Is it worth solving? If the problem is a trivial one then its probably not worth solving. To a certain extent if the system aint broke, why fix it? However if there is a fundamental flaw in some part of the system that may be making it difficult for a whole system to operate efficiently then it is more likely that this is a problem worth solving. 2. Constraints. Constraints are the limitations. The nature of all the constraints must be fully investigated as the design of the new system must take place within these constraints. The constraints are usually set by the owner of the system\company and are often as simple as budgetary or can be as complex as staffing and operational with other unchangeable external systems. 3. Budgetary considerations. There are a number of areas to consider. The development costs of a system are but one cost that has to be met. Others include the initial cost of implementing the system, and the ongoing running costs. The business needs to be able to afford to implement the new system and then hopefully benefit from that implementation. However one consideration that is often forgotten is that the additional income and/or the pr ojected savings made by implementing the new system need to be more than the cost of implementing the system. The cost-benefit analysis is an important part of the budgetary component of the feasibility study. You need to weigh up all the costs involved in implementing and operating the new system. The costs of the system together with the running costs should be calculated as accurately as possible over the estimated lifetime of the system. These costs are then weighed up against the increased income a nd decrease in costs and then incorporate it into the final report that provides an opinion as to whether the project is financially worthwhile. 4. Operational considerations . The purpose of the new system is to meet the needs of the organisation. In meeting these needs there will be some form of impact on the members of the organisation from management through to direct users. The main impact is in the area of manual processing and in order for the new system to be successful it must be complimented by an e fficient manual system. If the manual processing component is too difficult to implement then the overall performance of the system will suffer. Implementation of a new manual process may involve the following: Tasks carried out by personnel are usually very clearly defined. If the new system changes these then the issue of redefining the worker s role become important. Simple negotiation or possible union intervention may be required to solve the individual s changing roles. Government regulations need to be considered. They may require specific documentation, etc, that no system can actually handle.

Steve Bastable 5.

SDD Notes

steve@jamark.com.au

6.

7.

8.

Technical considerations . The technical feasibility is establishing whether the hardware and software needs of the solution can be realistically met. Users often have an unrealistic concept of the tasks that can be performed by computers (eg a system can be developed that reads in and interprets and then displays an essay. However it would be extremely difficult to write a computer program that could accu rately mark that essay). Since the major success of a solution is dependant on the ability of the hardware and software to perform the required tasks, the systems analyst must be well up on the current availability and trends. Saying you can do something and being able to actually do it are often two entirely different things. Scheduling. You often need to implement a new system within a fixed time frame (eg Y2K bug). These time limits can place pressure on a development team. Therefore scheduling feasib ility will investigate the feasibility of completing a project within a certain time frame. A report will often state the best options and any that are unrealistic. It is always a good idea, if possible, to leave the time frame as open as possible (eg Microsoft), however this is not always possible and an increase in the number of developers may be needed to meet the demands of the system. Possible alternatives. After all factors have been investigated, a number (usually 3 maximum) of alternative solution s, including leaving the system unchanged, should be proposed. Rough estimates of costs and the advantages and disadvantages are needed for each proposal. These are placed into a report that should conclude by stating the final recommendation to be made by the analyst and then passed on to management for a decision. Social and ethical considerations. A new system will always have some impact on people, from management down through direct users (employees) and indirect users (customers). Impacts can include a change in work practice may lead to loss of jobs or the performing of new tasks. Sometimes if efficiency is greatly increased, an increase in jobs can happen. Some effects spread outside the organisation (eg suppliers may need to work with a new syst em because of your changes).

Example of Social and Ethical Considerations

A new system can affect employees and the general population. Automatic ticketing machines for a public transport system affect both employees and the public.

Design Specifications
Once the option has been chosen, the design process starts. Careful planning is necessary if the system is to work. The design specifications lay down the guidelines for development and should also allow for and be a reference for the success of the project. The specifications cover a number of different aspects of the design process. 1. The scope provides details about how the software fits in with the whole project. The scope also defines the boundaries within which the software will operate. All for ms of input, outputs and special processing needs are included. 2. Data design will identify the data objects needed for processing and the resulting data types required. File access and structure are also covered. Finally the data items should be cross referenced to their appropriate files. 3. The overall design of the program is represented by a series of structure charts representing the program modules and the interaction between them. 4. The interface design is concerned with the human/machine interface. It specifies how the user will interact with the program and establish a set of design rules for the interface. Just as important is the interface between modules and between program and external devices. Each module within the program must then be described in detail. 5. The processing of each module is then written. This includes: a. A description of the interface. b. The algorithm or the algorithms that describe the module. c. The local data structures used within the module. d. Any restrictions or limitations that may be placed upon the processing. 6. Cross-referencing - The requirements definition ensure that all the users requirements will be met by the software. It also indicates which of the modules are important in meeting each of the particular requirements. 7. Implementation and testing is not just a matter of testing each module then combining the modules and testing further, then putting the system in place and hoping for the best. In this section the general processes for testing are outlined. As each module is developed, it is tested within these

Steve Bastable

SDD Notes

steve@jamark.com.au

guidelines, however special testing methods may be required for specialised modules. If special methods are needed, then they also need to be designed under the general parameters that are set. Installation into the customers site needs careful planning to impact on normal working practices as little as possible.

Developers Perspective
A developer will often view a solution entirely differently from that of the customer. The customer wants the problem solved and does not particularly care how. The developer, however, needs to take the customer s wish list and create a computer program. To do this, the developer needs to look at the problem in terms of data types, variables and processes.

Data Types Example 1

A program is to be written to monitor the takings of a cash register. The program will only output the total days taking at the close of business. What is the appropriate data type to be used for this problem? The data that would be needed would be an alp hanumeric, real variable, and the process involved would be an accumulation.

Example 2
When the items barcode is scanned, the items barcode is checked to make sure the scan is successful. The check involves adding the sum of the digits in the odd posit ions to three times the sum of the even positions. If the result of the addition is divisible by 10 the object is deemed to have been successfully scanned. A data type has to be designed for a barcode verification module (eg a barcode 9780858596375, odd positions add to 50, even positions add to 30 and the result is 50+3*30=140. This is divisible by 10 so the barcode is valid). Choosing a suitable data type to use within a program is a developer s most important decision. Without appropriate data types, algorithms can be difficult, if not impossible, to design. A well chosen data type can make an algorithm simpler to design and implement. Three factors influence the choice of data types appropriate for a particular task. 1. Wether the data type is able to cater for the storage of all possible data items. 2. Wether the data type can be visualised by the programmer and expressed as a model on paper. 3. The data type has to reflect the data and be able to allow the sort of processing by the problem.

Variables
Variables are used to represent storage locations within the computer. A programmer will look at the entities (data items) that need processing and determine how they are to be accessed. The first part of this process is to determine the data type used to rep resent the data item and the second part is to choose an appropriate identifier for the data item. If an identifier is not given an appropriate name that represents the data item being processed, then it becomes difficult to follow the logic of the progra m without making notes (comments or remarks). Therefore the program should be easy to decipher for the majority of its code if meaningful identifiers are used and the needs for comments in these areas should be virtually eliminated. Therefore comments sh ould only be used in an area of very complex and not easy to understand programming. The choice of your variable names is known as internal documentation.

Example 1
Programming team was working on a GST solution. For expediency, one of the programmers c hose the variable identifier X to represent the amount of GST charged on a service. At a later date, another member of the development team had to read the algorithm and had no idea of what was being processed by the variable identifier X. It would have been much better, had the variable identifier X been something like GST_Value (note _ replaces a space which are not valid in identifiers) Using variables within a program is also important. Data values need to be made accessible to the modules (sub-programs) that need them. In this case, where a number of modules need to use the same variable values, global variables should be used. That is, all modules within the program have access to the values of global variables. If a variable, however, is only needed to store data and be used within only one module then it is wise to create a local variable for that module. The distinction between these types of variables is made so that unpredictable changes are not made to the values of variables.

Steve Bastable

SDD Notes

steve@jamark.com.au

Algorithms
The first stage of programming a solution should start with writing an algorithm. All of the stages prior to this should be used to translate the solution into an algorithm that will then form the program. To make the job simpler, the programmer should break the solution down into simple modules where each of the modules is easily solved. This is known as top-down decomposition. However, while decomposing the problem into these smaller units, the programmer must ensure that the requirements o f the problem are being addressed rather then just trying to make the program aesthetically pleasing. Once all the algorithms have been identified, the programmer looks for familiar modules. The programmer will then draw from their library of code, any that can be used and make the slight modifications needed to suit the new problem. For those modules that need to be written from the start, the programmer will often work through the processing manually in order to identify the individual processes involve d. These are then translated into an algorithm. The programmer needs a clear understanding of the data items that need to be manipulated, so that they can perform the required tasks.

The Users Perspective

Even though he programmer is producing one over all solution for a company, they often are in fact producing many individual solutions to suit the different users within the organisation. In order that different users can easily access their particular module(s) an efficient way to do this needs to be defined. A hierarchical approach is often the best one to use with choices being arranged in a number of levels that user s can navigate up and down through. Main Menu Menu 2 Item Item 2.1 2.2

Menu 1 Item 1.1 Item 1.2 Item 1.3 Item 1.4

Item 3.1 Menu 3 Item 3.2 Item 3.3

Modeling
Note: A programmer must fully understand a problem before attempting to create a solution. Tools that can be used to help this process are needed to gain an overall picture of the sys tem, with other tools being used to help understand the processing, while others are used to explain the interaction between parts of the system.

Representing a System Using Diagrams

A diagram can be used to represent a concept which could take pages of w ritten text. The various diagrams are:

1) IPO (Input Process Output) Diagrams

IPO diagrams are used to describe the elements that will enter the system or subsystem, the processes that will occur and the data elements that will leave the system. Besides showing the inputs, processes and outputs, they are also useful to understand how the data is being manipulated. They can also be drawn to show more detail such as a subsystem and therefore can show how each component manipulates the data.

Steve Bastable

SDD Notes Automated Greenhouse Processes Heat Moisture Light

steve@jamark.com.au

Inputs Water Sunlight Electricity Sensors Plants Soil Fertiliser Inputs Temperature sensors Electricity Inputs Moisture Reading Electricity Water

Output Growing Plants Food

Temperature Control Processes Reading sensors Watering System Processes Reading Sensors

Output Warmth

Output Water to plants

2) Storyboards
Storyboards are generally used to give an overview of a program. They are particularly useful in multimedia productions and interactive programs where there exist a large number of screens with complex patterns of navigation. However they are also useful to help define simpler navigation systems. They are often used as the first developer-user link as they show a potential user the ideas for the s creen layout and how groups or clusters of screens relate to each other. They also indicate the options or navigation. Storyboard arrangements are categorised as linear, hierarchical, unstructured (network) or hybrid (combination).

3) Data Flow Diagrams

An IPO only shows inputs, processes and outputs but fails to show the relationships between them. A storyboard only shows the relationship between the screens of an application. It is the job of the data flow diagram to clarify and then show the flow or path of data throughout the system. They indicate how and where data is entered, stored, processed and output. They are very useful for indicating where tasks overlap or where unnecessary storage or transmission of data occurs. The main data flow symbo ls are a. Square A source or destination of data. A box represents a source (input of data into the system) or a sink (output of data from the system). b. c. d. Circle A process. The circle represents the processing of data. An arrow with at least one arrowhead on one end The flow of data. Rectangle with the right hand side missing A file or data storage. Represents storage of data within the system.

Example: Cash Register and Barcode Reader Your sources of data are users. Your sinks of data are also users. Processes are cash register, reading the barcode, barcode validity check and obtaining product name and price. We have one storage, the product master file. Your problem is to, out of those entities; create a DFD that represents a supermarket barcode reader.

4) System Flowcharts
The IPO charts, storyboards and data flow diagrams provide an understanding of only the data flow and the processes involved. To be able to understand an existing system and identify possible improvements, it is a necessity to have an understanding of the hardware being used and how it all interrelates. The system flowchart is the graphical modelling tool that allows for this.

Steve Bastable

SDD Notes

steve@jamark.com.au

5) Screen Designs
The interface between the computer and user can not be treated as an afterthoug ht. In fact their design consideration need to start before programming commences, therefore allowing the programmer to integrate the screen design into the program from the start. As an extension to storyboards, that indicate how the user will navigate between the various screens, a screen design will indicate exactly what is to be shown on the screen. By using a screen design form, the designer will outline both graphically and descriptively what is required of the screen. A screen design form should contain 1. At the top of the screen the project name, the programmers name, the date and the name of the actual screen. In an area below this you will have: 2. The actual screen design. This is an exact graphical representation of what would be displayed on the screen, including: a. Title bar b. Menu Bar c. Toolbars (if any) d. Scrollbars e. Prompt areas f. Buttons, etc, etc 3. In an area under the above you will have the links. In this area, a description will indicate how each of the active elements on the screen (eg the File menu, Open submenu in the file menu) (Eg The save button links to the save -as dialog which allows the user to select the location to save a particular file. Under this section you will have 4. Any notes. These are simply for the programmer to refer to and may indicate some peculiarity about the screen or some special task that may be needed when programming. ASD Computing Screen Design Form Project: Programmer: Date: Screen: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <Actual Screen Design Goes Here> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Links File: Links for file submenu Edit: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Notes:

6) Prototypes
The use of a limited prototype is an effective development tool and in many cases is often further developed into the final working solution. A prototype allows the developer to create a dummy version of the solution which contains all screens and navigation entities (butt ons, etc) but in fact does not contain any workable data. Often dummy data is used so that the developer can show the user how the program is going to work. A good CASE/Protyping tool should even allow the developer to make modifications to the interface in front of the user as the user requests. The interface can then be tried to check if the change is an improvement. If the CASE/Prototyping tool allows, the prototype can then be fully coded in the same environment to the completed solution. However i n many cases, the prototype would then be coded in a different language from scratch using the prototype as a reference.

Other System Representations 1) Decision Tables and Decision Trees

One of the major tasks of an information system is the decisions that it makes. The programmer needs to define all of these decisions before they begin to program. Decisions are made based on the data entered into the system according to a set of rules or conditions. 1. A decision table is one method of showing these decisions.

2) Structure Diagrams
Structure diagrams are used to show precise relationships between the various modules within a system. They employ rectangles to represent modules, lines are used to connect entities and appear as labelled arrows with

Steve Bastable

SDD Notes

steve@jamark.com.au

the label representing the data items being passed between modules. Structure diagrams allow program modules to be developed independently because the exact form of the input and output from these modules is known. Structure Diagram Conventions are: Modules are represented by a rectangle and are arranged from top to bottom with a controlling module at the top. The order of execution of modules is from left to right. (GET DIAGRAMS FROM 3UNIT NOTES) A rectangle The rectangle represents a module. Arrow with open circle The arrow shows the passing of a parameter. Arrow with filled in circle A filled arrow indicates a control parameter. The box with the diamond and two lines - The diamond indicates that a decision has to be made as to which module is executed. The module with the line and the circle - The circular arrow indicates repetition. The module that is linked to another module with a diamond - Optional module is indicated with a diamond at the calling module. In the first example, data item A is passed from module 1 to module 3; data item g is passed back to module 1 and data item B passes from module 3 to module 7. Module 8 passes data item H to module 5, which in turn passes the item on to module 2. Module 2 illustrates the use of a decision, it wi ll either call module 5 and pass data item D to it, or it will call module 6 in which case it passes data item E as a parameter. Module 1 relatively calls upon module 4, passing data item C to it. The second example represents a supermarket scanning syst em at a checkout. The scanned barcode is compared with the barcodes database in the supervising system and the item s price is then sent to the till. At the same time, the item is deducted from the stock-in-hand database in the stock system. This proces s is repeated until all items have been scanned. After scanning, a total is calculated and printed on the customer s docket. When the total has been paid at the checkout, the amount is added to the day s takings transaction file for that checkout and the store.

Communication Issues
Communication needs to happen between developers and users. If conflicts during the development process are to be avoided. Developers are very familiar with the technical aspects of a system while users have their familiarity with the operation of that system. By joining these two areas, the overall system should be a better one if communication levels are high.

The Need to Empower the User

When work practices are changed, discomfort levels are usually high. Those people w ho are affected by the new system will more readily accept it if they have had a major input into its development process. The ability of a developer to allow users to claim ownership of the software they have jointly developed has achieved the ultimate i n systems development. This user ownership is even more important during and after installation, as the users are more likely to describe problems or suggest enhancements. Empowering users also means giving them the ability to make decisions that affect their work. People need mental stimulation that decision making provides. A worker who simply steps up to a machine and corrects a fault when it is not working has little job satisfaction. However, a worker whose tasks are varied and includes decision m aking, will generally enjoy their work more.

The Need to Acknowledge the Users Perspective

Even though a software developer may have expert technical knowledge, a successful solution is impossible without taking into account the users expertise of their system. The developer needs to realise that the user is the best source of knowledge about the function of the current system. By working together and working with each others strengths, the final solution will be a much better solution.

Enabling and Accepting Feedback

Developers need to establish both formal and informal channels of communications. Formal channels may include memos and regular meetings to keep users up to date. Informal communication allows for interim decisions to be made between those formal meeting times. Trust is the main thing that needs to be developed between all parties if the final solution is to be a successful one.

Steve Bastable

SDD Notes

steve@jamark.com.au

Planning and Designing of Software Solutions

Developing a Problem Solving Strategy
The only way to learn programming and algorithm design is with a great deal of practice. It must also be realised that the correct algorithm design will rarely be created in the first attempt. You firstly need to create an algorithm solution, secondly test it with some sample da ta and compare the results against some known expected outcomes. If there are variations to these expected outcomes then the algorithm should be modified and tested again. This cycle is repeated until all errors are removed and the algorithm performs the desired task with the expected outcomes.

Design Patterns
Expert programmers achieve their success by using design patterns. A design pattern is a way of combining programming structures into an easily identified and highly reusable group. These pattern s, once learnt, can be used again and again in the solution to problems. An experienced programmer will find that any problem is made up of many familiar design patterns. Therefore the programmer can apply these known design patterns to solve most of the problems. Any new concepts or unfamiliar aspects will need to be analysed and new structures created to solve them (eg consider the task of processing information as it arrives from an input stream. Often such input streams contain a special value that signifies the end of the data. These situations are common and a design pattern called a sentinel controlled, pre-test loop can be applied to them). As a specific example, consider the paying of groceries at a supermarket checkout. In practice, a piece of wood is used across the conveyer belt to separate customer s shopping. The block of wood here is the sentinel and the checkout operator sees it as a signal that the processing of your shopping can stop. BEGIN process shopping items Get the first grocery item WHILE (the item is not the separator) Process the item Get the next item END WHILE END process shopping items //Primary Read //Follow-up Read

This algorithm fetches a new item immediately before testing the item on the loop, first with the primary read before the pre-test loop starts and subsequently as the last instruction in the body of the loop just before control returns to the loop test.

Searches and Sorts

Binary Search
A binary search can only be performed on a sorted list. Bina ry search will pick the middle value of a list and decide if its higher or lower and keeps repeating this. Its the most efficient way of searching.

Sorting Arrays Bubble Sort

A bubble sort is relatively efficient. Its main logical structure is based o n transversing an array and switching adjacent pairs of values that are not in the correct order.

Selection Sort
The essential idea is that we place a marker at the first cell in the array and then search through the array from that position onwards looking for the smallest/largest value. When the smallest value is found, it is swapped with the marked cells value. The next step is to move the marker to the next cell and repeat the process.

String Processing
The word string means a string of characters

String Concepts
In traditional systems, strings were not defined directly in a programming language. Therefore the programmer had to work with individual characters using an array structure.

Steve Bastable

SDD Notes

steve@jamark.com.au

A Low Level String Function: Concatenation of 2 Strings

Concatenate means to join together BEGIN concatenate with string1 and string2 Set len1 to length of string1 (Determining the number of characters in string1) Set len2 to length of string2 (Determining the number of characters in string2) Bigstring is an array of characters from 1 to len1+len2 FOR counter goes from 1 to len1 Bigstring(counter) = string1(counter) (Populate the string array) END FOR FOR counter goes from 1 to len2 Bigstring(len1+counter) = string2(counter) (Populate the string array from after the first entered data ) END FOR Return bigstring END

Standard String Processing Functions Trimstring

A function trimstring is used to remove all the spaces from the front and the rear of the string.

Comparestring
A function called comparestings is useful for testing the alphabetical order of two strings. This function accepts two strings and compares them to see which one would come first in an alphabetical listing. It returns a number that is 1, -1 or 0 indicating which string would come fir st.

Tolowercase or Touppercase
These two functions convert all the characters of any string into lowercase or uppercase.

Stringcontains
This takes two strings as arguments and checks if the first string contains the second. If the first string does contain the second, the function returns true else returns false.

Records and Collection

A record can hold more than one data type at the same time.

Object Orientated Programming (OOP) Terminology

The various separate pieces of data are collected into an obj ect and are called members or attributes. In OOP functions as well as data can be encapsulated inside objects so each object is a collection of some data representing information and some functions representing certain behaviour. In OOP a class is used a s a template or definition of what data and behaviour a particular type of object can hold. The term used to describe a collection of objects is a container.

Steve Bastable

SDD Notes

steve@jamark.com.au

Implementation of Software Solutions

Interface Design of Software Solutions
A software solution can only be as good as the interface that presents it to the user.

The Design of Individual Screens

A number of factors will determine the overall design. These factors include the type of data to be presented, the type of audience the product is aimed a t, assistance required by the user and consistency between screens.

Identification of Data Required

Screens are designed to present data, either input or output. The type of data that is input will also affect the programming model chosen.

Design of Help Screens

Helpful Intuitive/User-Friendly Informing Concise Referenced/Cross-Linked Indexed

Audience Identification
Each screen in a program will have a target audience Children o Bright and colourful o Big things to click on Handicapped o Big fonts, contrasted o Large buttons

Consistency in Approach
There must be consistency between screens within an application. Consistency is important as it allows the user to anticipate actions and placement.

Language Syntax for Software Solutions

In order for a programmer to correctly code an algorithm in a particular language, the rules of that language must be followed. The most concise way of providing this information is by means of metalanguages. The most common metalanguages are syntax structure (railroad) diagrams, BNF (Backus-Naur Form) and EBNF (Extended Backus-Naur Form).

Use of BNF, EBNF and Railway Diagrams to Describe the Syntax of New Statements in the Chosen Language
Syntax structure diagrams are a graphical method of showing the structure of a language. T he two text based metalanguages (BNF, EBNF) use particular groupings of characters to show the structure of the language. Language elements in BNF are referred to by either their names (if they have been pre -defined) or as individual characters.

Translation Methods in Software Solutions

Translation is the process of converting high -level code or source code into machine code. Source code is said to be machine independent. This means it can be used on a number of different processors. Executable code, on the other hand, is very processor specific. Each family of processors will have different machine language instructions. The introduction of the World Wide Web has resulted in languages that can be implemented on a wide range of unknown processors. Lan guages such as Java undergo a two stage translation process. This byte code is translated in the web browser into executable code specific for that user s machine. There are three common methods of translation:

Steve Bastable

SDD Notes

steve@jamark.com.au

Interpretation
Each line of source code is translated into machine code and then immediately executed. If errors exist in the source code, they will cause a halt to execution once encountered by the interpreter. High level language interpreters advantage is that errors are detected as they occu r and can be corrected. Translation and execution can then continue. Interpretation does slow down the process of execution significantly. Users of interpreted programs must have a copy of the interpreter installed on their machines for execution to take place. This requirement requires further costs and memory over heads for the user. As the actual source code is distributed to users the developer has limited control over their intellectual rights.

Compilation
The source code is translated into execut able code. The executable code can later be executed without any need for the translator. Compilation is a batch process. Errors encountered during the process are relayed as a series of messages to the programmer. All coding errors are reported at the end of an unsuccessful compilation operation. A compiler does not produce any actual machine code until the entire source code is known to be correct in terms of the syntax of the source code. Compilers are used to produce executable code for the majorit y of commercial applications. Compiled programs generally run faster and more efficiently than similar interpreted products. Executable created by compilers will always be machine specific.

Incremental Compilation
The aim of incremental compilation is to reduce the time spent in compiling source code. Incremental compilers reduce the translation time by only recompiling those parts of the code that have been chanced since the last compile took place. Incremental compilation requires an integrated development environment. The development environment must carefully keep track of any changes to the source code.

The Translation Process in Detail

The process of compilation involved two distinct steps the creation of object code from the original source code followed by linking this code to existing runtime libraries and dynamic link libraries (DLLs). Large projects will often involve translating a number of source files into object code files. The linker is used to join all the components of a project into one final executable program. Translating source code into object code is the major task of the compiler. This process always requires the following steps:

Lexical Analysis
Lexical analysis is the process of examining each word to ensure that it is a valid part of the language. In terms of source code translation, lexical analysis is a process that ensures that all reserved words, identifiers, constants and operators are legitimate members of the high level languages lexicon. Lexical analysis is not interested in whether these language elements are in a sensible order. A table of symbols or tokens is used to check the language elements. This table will initially contain all the reserved words and operators that are included elements of the languag e. As the lexical analysis continues, identifiers and constants will be added to the token table. Each character in the source code is read sequentially. Once a string of characters, called a lexeme, matches an element in the symbol table, it is replace d by the appropriate token. Error messages generated as a result of lexical analysis will be in regard to the use of undeclared identifiers, incorrect naming of identifiers or incorrect constant syntax.

Syntactical Analysis
The word syntax refers to the p atterns or arrangements of words used to form phrases or sentences in a particular language. Syntactical Analysis is the process of checking syntax of sentences and phrases is correct in terms of the grammatical rules of the language. The second part of syntactical analysis involved checking that the type of identifiers and constants used in statements are compatible. Parsing is the process of checking the syntax of a sentence. A parse tree is used to diagrammatically describe the component parts of a syntactically correct sentence. Parse trees are like metalanguages for the programming language. If a particular component of the source code cannot be parsed, then an error message is generated. The error messages generated as a consequence of parsing wi ll always be in regard to the incorrect arrangement of tokens. Once a parse tree has been created, the data type of identifiers and constants within each statement can be checked for compatibility. This process is known as type checking.

Code Generation
If the process of lexical analysis and syntactical analysis have completed without error then the machine code can be generated. This stage involves converting each token or series of tokens into their respective machine code instructions. If a compiler is being used then the resulting machine code instructions are stored in an object file.

Steve Bastable

SDD Notes

steve@jamark.com.au

This file contains all the executable code from the source code, but does not generally contain links to runtime libraries and dynamic link libraries. Many compilers include methods for optimising the executable code. If an interpreter is being used then each instruction is executed immediately and access to runtime libraries is taken care of by the interpreter.

Documentation of a Software Solution

Documentation can be split into two broad categories, user documentation and technical documentation.

User Documentation
Users are the final operators of the product. Documentation targeted at users needs to be directed at their level of knowledge. There are many types of user documentation possible for example:

Installation Guide
Installation guides should provide the user with sufficient information to successfully install the software. Hardware and software requirements will be included together with step -by-step instructions to guide the user through the setup process. Often notes are included to help resolve common installation problems. Hardware requirements should be clearly stated. Often a minimum set of requirements will be given together with a recommended set of requirements. The main section of the installation guide describes the set of instructions that need to be undertaken to install the product.

User Manual
Quality user manuals aim to provide concise and accurate information in regards to the opera tion and purpose of software. Topics in user manuals describe: What the software can do Why it does those things How it does those things The most important information goes at the beginning whereas the more obscure information goes at the end. The manual should provide two explanations of the softwares functions: Conceptual What the function is and why. Procedural How the process is performed.

Reference Manual
Reference manuals are designed to be an efficient source of information ( i.e. they are not meant to be read through). Also often included is a quick reference card. Information should usually be in alphabetical order.

Tutorials
Tutorials provide instructions using example scenarios. Often sample data files are provided. Good tutorials should allow the user to work at their own pace and keep track of where they re up to.

Technical Documentation
Technical documentation is designed for an audience who is proficient and knowledgeable in regard to the subject matter. It describes the structur e and engineering behind the product. While software is being developed, thorough documentation should be maintained.

Process Diary
A process diary records the systematic series of actions that have occurred during the project s development.

Steve Bastable

SDD Notes

steve@jamark.com.au

Source Code Documentation

The source code itself is probably the most important form of technical documentation. Documentation within the source code is called internal documentation. Internal documentation can take two forms: Comments o Provide information for future programmers o Should explain what a section of code does rather than how o Comments that explain the logic of code should be used sparingly Intrinsic o Intrinsic documentation is part of the code ( i.e. the code should be self -documentary) o There are three main types of intrinsic documentation Meaningful identifiers Indentation of code Other formatting features (eg leaving blank lines)

Other Forms of Technical Documentation

Problem Definition { Needs Objectives Boundaries

&
Feasibility Study { Budgetary Operational Constraints { Technical Schedule Alternative Solutions

&
Design Specifications { Process Diary { Developers Perspective Users Perspective

&
System Models { System Flowcharts Data Flow Diagrams Structure Charts Data Dictionaries Screen Designs Storyboards

&
Algorithms { Standard Algorithms Custom Algorithms Standard Modules

&
Source Code { Comments Intrinsic Documentation

Hardware Environment to Enable Implementation of the Software Solution

All software solutions are designed with particular hardware requirements in mind. The installation guide will include minimum system requirements and possible additional hardware and appropriate drivers.

Minimum Hardware Configuration

o o o o o o Processor type and speed. RAM size and type. Secondary storage type, size and access speed. Input devices. Output devices. Network hardware.

Steve Bastable

SDD Notes

steve@jamark.com.au

Emerging Technologies
o o o o o Quantum Computers o The theory of quantum computers relies on spinning particles. The direction of the spin can be used to represent bits. In quantum computer terms, bits are known as qubits. Human computer interaction Secondary storage size and speed Technologies as a result of advances in processor tech nology Internet Access Initiates o Dedicated internet access devices o WAP (Wireless Application Protocol) o Cable Modems.