Section Three: Software development Flashcards
(37 cards)
Chapter 11 – Systems analysis methods
Aspects of software development
Stages of analysis, design, implementation (which includes coding, testing and documentation), installation and evaluation are common to all projects, though they may not easily fall into these categories in some methodologies. The tasks performed at these stages in the old, traditional lifecycle methodology are briefly described below.
Chapter 11 – Systems analysis methods
Analysis
The requirements of the system that solves the problem must be established. In the case of a data processing system, or for example the construction of a website, this could cover:
- the data – its origin, uses, volumes and characteristics
- the procedures – what is done, where, when and how, and how errors and exceptions are handled
- the future – development plans and expected growth rates
- problems with any existing system
Chapter 11 – Systems analysis methods
Design
Depending on the type of project, the systems designer may consider some or all of the following:
- processing: the algorithms and appropriate modular structure for the solution, specifying modules with clear documented interfaces
- data structures: how data will be held and how it will be accessed – for example in a dynamic data structure such as a queue or tree, or in a file or database
- output: content, format, sequence, frequency, medium (e.g. screen or hard copy) etc.
- input: volume, frequency, documents used, input methods
- user interface: screens and dialogues, menus, special purpose requirements
- security: how the data is to be kept secure from accidental corruption or deliberate tampering or hacking
- hardware: selection of an appropriate configuration
Chapter 11 – Systems analysis methods
Programming and testing
Programming normally involves breaking the problem down into individual modules and further breaking these down until each module performs a single well-defined task. The program code is then written in the chosen programming language.
Obviously a system must be thoroughly tested before being installed to make sure that all errors are discovered and corrected before going ‘live’. It is part of the designer’s job to come up with a test plan which will ensure that all parts of the system are properly tested.
Chapter 11 – Systems analysis methods
Black box testing (functional testing)
Black box testing is carried out independently of the code used in the program. It involves looking at the program specification and creating a set of test data that covers all the inputs and outputs and program functions.
Chapter 11 – Systems analysis methods
White box testing (structural testing)
White box testing is dependent on the code logic, and derives from the program structure rather than its function. The program code is studied and tests are devised which test each possible path at least once. The weakness of white box testing is that it will not detect missing functions – you cannot test what
isn’t there!
Chapter 11 – Systems analysis methods
Alpha testing
Alpha testing is carried out by the software developer’s in house testing team. It is essential because it often reveals both errors and omissions in the system requirements definition. The user may discover that the system does not in fact have the required functionality because the requirements were not specified carefully enough, or because the developer has overlooked or misunderstood something in the specification.
Chapter 11 – Systems analysis methods
Beta testing
When a new package is being developed for release as a software package, beta testing is often used. This involves giving the package to a number of potential users who agree to use the system and report any problems to the developers. Microsoft, for example, delivers beta versions of its products to hundreds of sites for testing. This exposes the product to real use and detects problems and errors that may not have been anticipated by the developers. The product can then be modified and sent out for further beta testing until the developer is confident enough in the product to put it on the market.
Chapter 11 – Systems analysis methods
Implementation
Coding and testing will be carried out, errors traced and corrected. When all is thought to be satisfactory the software will be installed on the user’s system and more testing will be done. At this stage new weaknesses and omissions are almost bound to surface and more work will be carried out.
Chapter 11 – Systems analysis methods
Evaluation
The evaluation may include a post-implementation review, which is a critical examination of the system three to six months after it has been put into operation. This waiting period allows users and technical staff to learn how to use the system, get used to new ways of working and understand the new procedures required. It allows management a chance to evaluate the usefulness of the reports and on-line queries that they can make, and go through several ‘month-end’ periods when various routine reports will be produced. Shortcomings of the system, if there are any, will be becoming apparent at all levels of the organisation, and users will want a chance to air their views and discuss improvements. The solution should be evaluated on the basis of effectiveness, usability and maintainability.
Chapter 11 – Systems analysis methods
What will the post-implementation review will focus on?
The post-implementation review will focus on the following:
- a comparison of the system’s actual performance with the anticipated performance objectives
- an assessment of each aspect of the system against preset criteria
- errors which were made during system development
- unexpected benefits and problems
Chapter 11 – Systems analysis methods
The waterfall lifecycle model
The Waterfall Model illustrates the methodology described above, in which each step is completed one at a time from beginning to end. Each step has specific outputs that lead into the next step. It is possible to return to a previous stage if necessary but the model shows that the developers then have to work back down through the following stages.
The user/customer is involved at the start of the process, in the Analysis stage, but then has little input until the Evaluation stage.
This model was adopted from the manufacturing industry, where changes to hardware made later in the project had high cost implications to work already completed so it was important to get each stage right before moving to the next. Although still popular, it has been now superseded by more effective models.
Chapter 11 – Systems analysis methods
Spiral model
The Spiral Model uses the same structured steps but introduces the idea of developing the software in iterative (repeating) stages. At the start of the process the requirements are defined and the developers work towards an initial prototype. Each successive loop around the spiral generates a refined prototype until the product is finished.
Chapter 11 – Systems analysis methods
What happens each time around the spiral?
Each time around the spiral the following activities are performed:
- Analyse the requirements for the next prototype
- Design the next version, the new prototype
- Implement (code and test) the new prototype
- Evaluate the new prototype, which generates a plan for the next iteration
The Spiral Model is mostly used for large scale projects, for example, projects that take years to deliver.
Smaller projects use a variation on this called the Agile Model
Chapter 11 – Systems analysis methods
Agile modelling
At all the stages of analysis, design and implementation, an
agile approach may be adopted, as the stages of software development may not be completed in a linear sequence. It might be that some analysis is done and then some parts of a system are designed and implemented while other parts are still being analysed and then, for example, implementation and testing may be intermixed. The developer may then go back to design another aspect of the system.
Chapter 11 – Systems analysis methods
Tips for the success of the development
At each stage, a prototype is built with user participation to ensure that the system is being developed in line with what the user wants.
The success of the software development depends on
- keeping the model simple, and not trying to incorporate features which may come in useful at a later date
- rapid feedback from the user
- understanding that user requirements may change during development as they are forced to consider their needs in detail
- being prepared to make incremental changes as the model develops
Chapter 11 – Systems analysis methods
Extreme programming
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. It is a type of agile software development in which frequent “releases” of the software are made in short development cycles. This is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Chapter 11 – Systems analysis methods
Rapid application development (RAD)
Some very large projects may be developed over a long period of time during which both technology and user requirements change. Major changes at late stages of development can sometimes lead to projects being cancelled or restarted, at considerable cost. In response to this problem the RAD methodology was introduced, offering the promise of much faster completion of major projects.
Chapter 11 – Systems analysis methods
Relative merits and drawbacks of each development methodology
The waterfall system lifecycle approach is suitable for very small projects which need careful supervision, such as those undertaken by students or trainees. The absence of user involvement is a serious drawback.
The spiral model and the agile approach are an improvement in that they acknowledge that users often cannot specify their requirements accurately because they don’t understand what is possible. It is much easier to examine a working prototype and figure out what needs to be done to it to turn it into a useful system.
Extreme programming and rapid application development are good methodologies for large projects where there is a danger of getting bogged down or sidetracked by suggested improvements, so that developers are continually chasing a moving target.
Chapter 12 – Writing and following algorithms
Computational algorithms
A good algorithm has the following properties:
- It has clear and precisely stated steps that produce the correct output for any set of valid inputs
- It should allow for invalid inputs
- It must always terminate at some point
- it should execute efficiently, in as few steps as possible
- It should be designed in such a way that other people will be able to understand it and modify it if necessary
Chapter 12 – Writing and following algorithms
What kinds of problem are solved by algorithms?
Internet-related algorithms
Algorithms are used to manage and manipulate the huge amount of data stored on the Internet. How does a search engine find all the pages on which particular information resides in a fraction of a second?
Route-finding algorithms
Given two locations, how does a route-finder determine the shortest or best route between the two points? There may be thousands of possible routes. This type of algorithm is used not only for driving a vehicle from A to B, but also for many other applications, for example, finding the best route to transmit packets of data from A to B over a network.
Compression algorithms
These are used to compress data files so that they can be transmitted faster or held in a smaller amount of storage space. For example, MP3 files are compressed so that you can hold thousands of tracks on a mobile phone.
Encryption algorithms
When someone purchases something over the Internet and sends their credit card number and other personal details to the store, the data needs to be encrypted so that even if it is intercepted, it cannot be read.
Chapter 12 – Writing and following algorithms
A “Divide and Conquer” algorithm
The binary search algorithm uses the “Divide and Conquer” strategy to halve the search area every time a
guess is made.
Chapter 12 – Writing and following algorithms
Strategy for interpreting algorithms
Here are some tips, which may seem fairly obvious.
- Read the comments in the program
- Look at the variable names to see if they give any clues
- Follow the steps in the program
- Try a “dry run” with some test data
Chapter 13 – Programming paradigms
Procedural programming
Procedural programming is supported by languages such as Python or Pascal, which have a series of instructions that tell the computer what to do with the input in order to solve the problem. They are widely used in educational environments, being relatively easy to learn and applicable to a wide variety of problems.
