1.2.3 Software Development | D:\domain\daffyduck.tech

Feasibility Study: (Analysis) – This takes all of a project’s relevant factors into account.

The purpose of analysis is to carry out initial enquiries. This is to see if there are any reasons to why a new system may not be acceptable before starting to produce it and to determine whether the problem can be solved.

Before a problem can be solved. It must be defined. The requirements of the system that solves the problem must be established:

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 rate.
Problems with any existing system.
Time available: Is the time scale acceptable for the proposed system to be possible.

Requirements Specification: (Design) – This creates an understanding of the problem and presents solution

Processing: The algorithms and appropriate modular structure for the solution, specifying modules with clear documented interfaces.
Data Structures: How will data be held and how will it be accessed.
Output: Content, format, sequence, frequency, medium (e.g screen or hardcopy) 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 appropriate configuration.

Testing: (Ensures that the program works correctly)

Black Box Testing (Functional/Behavioural Testing): This 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. It tests different possible suitable predefined set of inputs to see if they produce the expected output according to the design.
White Box Testing (Structural Testing): This is dependent on the code logic, and derives from the program structure rather than its function. It tests the workings of an application, as opposed to its functionality (black-box testing). It uses the source code to test the actual steps of the algorithms in order to make sure all parts work as intended. This means every possible condition must be checked as well as going through all different paths of the algorithm.
Alpha Testing: This is performed by the programmers, developers and employees within the software company. They play the role of the user during development in order to find bugs/errors in the program. Emulators may also be used to replicate the physical hardware that the final program may be built into it.
Beta Testing: This involves giving the software project to selected users, who agree to use the system and report any problems that occur to the developers.

User Documentation: This givens instructions to ensure that software users can successfully use the system in order to produce their desired results. This may contain information describing the Input/Output procedures, using processing tools and overall instructions how to operate the system.

Technical Documentation: This describes and explains how the system works. This is useful for a technician who may need to maintain and further develop or alter the system in the future

Implementation: Coding and testing will be carried out, errors traced and corrected. When the software is released and installed on a user’s system, more testing will occur. There is a chance that new weaknesses will surface and more work will have to be carried out.

Evaluation: This may include a post-implementation review, which is a critical examination of the system three to six months later 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 understanding the procedures required. It allows management a chance to evaluate the usefulness of the reports.

Algorithmic Thinking: This is a process of solving any problem by producing algorithms.

Algorithms: This is a reusable set of instructions (a series of steps) to solve a given problem. They are written as a set of numbered steps to follow. In computing, this is represented using pseudocode or flow diagrams.

Methodologies: (Process Methodology. This is used to understand the processes used to accomplish tasks in Computer Science.)

There are different methodologies that can be used for organising the development of a piece of software.

The Waterfall Life Cycle Model: Each step is completed one at a time from the beginning to the end. Each stage in the waterfall lifecycle produces a large amount of documentation.

Requirements are defined.
Analysis of the problem. What solutions are ready to implement? What can be used or adapted to help to produce a solution?
Design: A solution is produced to meet all of the user’s requirements.
Implementation: When the developers write the code and build the designed solution.
Testing: Checking that the system works and that it meets the user requirements.
Deployment: When the installation of the system is put into place within a client’s organisation.
Maintenance: When any bugs in the system are fixed and works as intended.

Agile Methodology: Each step may not be completed one at a time in a linear sequence. The developer can go back to either design, plan or program the software. Its iterative stages allow requirements to be changed and to develop a product over several iterations. These iterations are called ‘sprints’.

User requirements are split up into User Stories. These are different ways the system will be used.
Sprint: This is a short time-frame during which a specific User Story is completed.
Throughout the process, feedback will be obtained from the user. This is an iterative process. The software is produced in versions, each building on the previous. This means that if the user realises that they haven’t fully considered a requirement, they can have it added in a future iteration.

Extreme Planning: (XP) This is an example of the Agile Methodology, which is good for rapidly changing user requirements. It takes on the agile approach and is iterative in nature. It is intended to improve software quality and responsiveness to changing customer requirements.

A representative of the client basically becomes part of the team. They help to decide the ‘User Stories’, decide what tests will be used to ensure that they have been correctly implemented and to answer any questions about any problem areas the programmers might have.

Extreme Planning: This is the first stage. The client is in constant communication with the project team in order to establish the user requirements.
Extreme Designing: Simple designs will be built that implement the needed functionality.
Extreme Programming: This is where the agreed items for the project is developed. Programmers will work together and criticise each other’s code.
Extreme Testing: The code is tested in units. Integration testing is also completed to ensure that the program works together. The code is reviewed for efficiency and quality.
Acceptance Testing: This is where the client feeds back on the product in its current stage. This is then taken into the next iteration of extreme planning for the next release. This process repeats until the project is completed.

Spiral Programming: Each step is completed one at a time from the beginning to the end in iterative stages to allow requirements to be changed and to develop a product over several iterations.

Each successive loop around the spiral generates a more refined prototype until the product is finished.

Analyse: The client and the project team collaborate to establish requirements from the user. After the first spiral, this stage is also used to review what has been achieved before and what needs to be added.
Design: During the first spiral, they will develop a conceptual design for the project. Then architectural design, then logical design and finally a physical design in the subsequent spirals.
Implement: The program will be constructed to develop the agreed requirements. During the first spiral, a concept version will be built to get feedback from the client. After that, functionality will be added in each spiral.
Evaluation: A product evaluation, including a risk assessment, will take place by the client. This information is then fed into the next spiral.

Rapid Application Development (RAD): Another agile methodology which focuses on getting a product made and quickly. This is where a prototype system of the program is designed and produced with reduced functionality to a set deadline.

The use of prototyping allows to continually refine the system in response to user involvement and feedback.
Producing each part of the system within a time limit, which may not be perfect but good enough.
Reusing any software components, which have already been used elsewhere.

Analysis: The project team will look at the user requirements against what they can adapt or use from other systems.
Design: A simple design of the solution will be produced.
Build, demonstrate and refine: This stage is repeated multiple times where the project team will: Develop a product. Demonstrate it to the client. Refine the product based on the feedback they have received.
Testing and Implementing: Product is tested and if the client is happy, then implemented.

Methodology:	Merits: (Advantages)	Drawbacks:	Usage:
The Waterfall Cycle:	-Easy to understand. -Easy to follow. -Each stage can only be started when the previous one is completed. Easy to manage as a team is only focused on one stage at a time. -Fewer production issues during development due to the amount of time invested in user requirements, analysis and design. -Orderly sequence of development ensures quality documentation with reliability and maintainability of the developed software. -Project progresses forward, with only slight movement backwards.	-Inflexible and doesn’t cope well with change requirements throughout the project. This can cause delays and significant cost increase as additional work will be required. -Doesn’t work well for very complex or long term projects as it would take too long to get through each stage of the process. -It can be very difficult to capture all of the user requirements at once. This is because the client will often not know what exactly what they want.	-Works well for small projects. -Can be very effective when the client has a very clear and precise detail of what they want to be developed.
The Agile Methodology:	-A product can be marketed more quickly. -Clients can receive incremental updates for the product. -The final product has absolute certainty that it is what the client wanted as they are constantly involved with its development over each iteration	-There is less predictability when compared to the waterfall timings and costings as the process constantly repeats. -Requires higher time input from the client as they are constantly required for feedback at all stages of the development process. -The project can easily go off track and the project can last well beyond the initial idea. This can lead to higher costs and more time input	-Best suited to clients who has a good idea of what they want, but also a lot of time they can invest into controlling the project and feeding back on it.
Extreme Programming (XP)	-Can produce a product very quickly for the client to sell and use. -Product can be quickly incremented for improvements and additional features. -The project is constantly refactoring in response to continuous client feedback. This can save time and money for developing. -The project is at lower risk of failure, as the client has guided the project with their continuous feedback.	-The project can be too code focused and not design focused. It may not be the best possible product. -Produces little to no documentation. -If developers are split geographically, then it can cause issues when it is time for code review.	-Best suited to requirements where the client has a constantly changing set of requirements, but needs a product quickly to get to market and for the lowest possible price.
Spiral Methodology:	-A product can be developed at each cycle with more added to the system. -Makes use of prototypes. This means the user sees a system very early on. -The client is able to see the product being developed to ensure it is what they want.	-It is easy to fall off track. The costs and time scales can escalate quickly. -Client is needed to make significant time investment for feedback and evaluation to steer the project. -Produces poor quality documentation compared to waterfall	-Best suited to clients who has a good idea of what they want, but also a lot of time they can invest into controlling the project and feeding back on it.
Rapid Application Development:	-Allows a product to be made and put to the market very quickly. -Project is relevant to the client and the market by the time it is released. -Produces iterative deliverables. This means improved versions can be released. -End user can see a working prototype early in the project. -End user is more involved in the design and can change the requirements as the project becomes clearer to influence the direction.	-Requires a heavy time input from the client to feedback and guide the project. -Focuses on delivering a product that is simply ‘good enough’. Not perfect. -Not suitable for safety-critical systems. -Potential for inconsistent design and a lack of detail in respect of administration and documentation.	-Best suited to large projects that have short time scales, where it is important to have a timely release to keep market relevance.