Structured Approach To Software Development

A system Analyst studies an existing system against the backdrop of the system's overall objective and then do changes or implement new system(s) to enhance its operation. In order for a system to function properly as intended, the system analysts usually employ at least one structured methodology. A structured technique can result in structured diagrams such as control logic flowcharts, hierarchy diagrams, business process flowcharts, organizational flowcharts, data-flow and entity-relationship diagrams, and other processes flowcharts, to mention a few.

System Analysis and Development goes through phases with the following general characterization: Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals. Design to answer important questions that relates to risk in pursuing the project's objective. Systems analysis, requirements definition: Refines the project's goals into defined functions and operation of the intended system. Does analysis of end-user needs and the overall system objective. Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, flowcharts, pseudo code and other process documentation. Implementation: The system is put together for actual operation from design and documentation. Integration and testing: All parts of the system are brought together in a special testing environment where checks are done to locate errors, bugs and determine interoperability. Acceptance, installation, deployment: This is the final stage of the system development. At this point the complete system is put into production and runs the actual process. Maintenance: This deals with issues of continued functionality during the rest of the system`s life. Therefore, it deals with actions of changes, correction, additions, and more. This, step seems to go on seemingly forever.

In the rest of this presentation we take a system to mean a organization or business Information System that is implemented, controlled and operated by digital computer systems. CASE TOOLS FOR INFORMATION SYSTEMS

Computer Aided Software Engineering (CASE) tools are used by the System Analyst to automate or support information system projects. There are many commercial tools available on the market. There are tools that provide facilities for the whole project life cycle and there are also specialise tools that provide facility for specific phase of the life cycle. Diagramming tools are used to create process flowcharts, business and control logic flowcharts; data flow diagrams, and the control structure of the system. These tools are used to make visual checks to determine if the actual processes and system they represent makes sense. A common visualization technique used for data base systems is data flow diagramming. Example commercial CASE tools include SSADM, Oracle`s Designer/2000 and Cool-Gen.

IMPLEMENTATION METHODOLOGIES

A methodology is the result of someone having studied a method of system development. It is a formalised approach in the procedure towards the solution of a systems problem. A system development methodology outlines the steps that should be followed in order to implement a complete system.

The chosen methodology must be appropriate towards the nature of the problem at hand. An inappropriate methodology can lead to frustrations. Choosing the correct methodology requires proper understanding of the basis of the method and the nature of the problem at hand. For example, you can not use a RAD method for a problem solution where the problem definition is outside of well known or similar systems definition. In this case, you may have components within the problem that are not addressed by the RAD system to be used for implementation of the solution. Therefore, a more fundamental approach may be required as is the case with the NHS e-booking system. For our project, we have chosen the traditional waterfall model System Development method for implementation. The phases in this approach are illustrated in figure xxx.

There is also Software System Development methodology which is a sub-component within the overall system development methodology. In addition, there are also other methodologies related to other aspect of the system development and implementation methodology. In order for a given system development methodology to be feasible, its individual methodologies must be consistent and compatible.

System analysts usually employ at least one methodology, especially the structured analysis techniques which results in visualisation of system components that are of particular interest to the analyst.

The more recent formal methodologies can be categorized as follows: Process driven Data driven or Object Oriented

THE WATERFALL DEVELOPMENT METHOD

This is the traditional approach as stated in section xxxx above. As can be seen from figure xxxx all steps in this traditional approach are executed in sequence as listed in section xxxx. The following diagram illustrates the stages in this model and gives a hint on why it is called the water fall model.

Figure xxx The traditional approach to the development of the system life cycle. Each stage in this approach follows in sequence of the previous stage as listed in section xxx.

Other alternative methodologies include: Parallel Development Rapid Application Development (RAD) - uses CASE tools, JAD sessions, 4th generation and visualization programming languages. Phased Development Prototyping Spiral Development Packaged Development

The project uses the traditional waterfall methodology as there were problem areas of web base software implementation that has never been solved. The Internet poses a challenge for the development and deployment of software system with functionalities that meets the requirements of a wide and varied user audience. The developer has to rely on the implementation of standards and compatibility of systems/tools to achieve these objectives.

TESTING AND EVALUATION

The overall aims of our test and evaluation plan is as follows: To determine that the online booking system implemented delivers the performance as stated in the original system objectives and that it meets the expectations of stakeholders.

The objective questions that we seek to answer from these test and evaluation are as follows:

OBJECTIVES Database System - does it work properly to cover the following issues? Redundancy kept to a minimum, recoverability, how fast is it, Input Data Validation to ensure correctness of user input HCI and Usability Issues - are stakeholders satisfied with performance of the system System Control Structure and Robustness - Scalability of system - can it handle small and large data values? What are the ranges. To identify risk in the system associated with accessibility and security - are there any risks associated with the current system design, is there an alternative design/implementation that would reduce or eliminate these risks.

The following methods will be used. Black Box Testing: will assign a user with no knowledge of the system, specific task and observe and evaluate results. White Box Testing: develop test plans with input data, expected output results and actual outcome when tested. (CS2078 Software Analysis & Verification)

EVALUATION

An evaluation is of a more subjective nature. Observed anomalities has less serious consequence on the functionality of the system than in the case of a system test. The main aim of the evaluation is to determine the degree of success of the project, summarises its functionalities and document any important lessons learned. This is further categorised in the following list.

To determine usability issues from user perceptions. To identify components in the system that performs well or does not perform at all. Identify modules from which generic systems can be constructed for future upgrade or similar applications in the future.

To achieve these goals and objectives, we designed and implemented the following software and system test plan.

SOFTWARE TEST PLAN http://en.wikipedia.org/wiki/Software_testing

A test plan is a planned set of activities for testing the validity of a system such as an engineered product or a software system.

A test plan usually consist of a detailed list of the activities that constitute the test plan. In addition to this, the test plan include the following information: Scope of testing Schedules Test Deliverables Release Criteria Risks and Contingencies

Testing is a part of the process of Quality Assurance (QA) and can therefore be decribed as the process of determining the following quality attributes: capability, reliability, efficiency, portability, maintainability, compatibility and usability. Software Testing is a process used for identification of correctness, completeness, security, and quality of developed software systems. It is a process of technical investigation, performed on behalf of stakeholders and is intended to reveal quality- information about the product with respect to the context in which it is intended to operate.

A test plan should therefore include references to documents related to the system under test. Example list of these documents can be:

The Project Plan The System Specifications and related requirements. Design documentations at all levels. Implementation tools and their documentation. Development and Test process standards. Methodology guidelines and examples. Guidelines and standards of the organisation where the project is implemented within a cooperate environment

A comprehensive test plan should include activity to identify risk associated with Complexity, Safety requirements, multiple interfaces, Impact on stakeholders, and requirements of Government regulations and rules. A key area of risk is a misunderstanding of the original requirements