A Well Detailed Spiral Model Information Technology Essay

The life cycle model most likely preferred or suitable for Sales Order Despatch Application system would be the Spiral Life Cycle Model.

The Spiral Life Cycle Model is a software development approach combining elements of both design and prototyping in a much more comprehensive and understandable stages.

The spiral life cycle combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product.

A WELL DETAILED SPIRAL MODEL

The spiral life cycle model typically contains 6 task regions:

i. Customer Communication

ii. Planning

iii. Risk Analysis

iv. Engineering

v. Construction and Release

vi. Customer Evaluation

All the above mentioned tasks has to be addressed during the development of the Sales Order Despatch Application.

1.1 Customer Communication

This task region basically has to do with knowing the customer and establishing an effective communication and gathering the requirements of the system to be developed. Customers therefore would be referred to as the management of the Sales Order Despatch System. These requirements can be gathered using several fact finding techniques. The techniques used for this system would be:

Questionnaires

A survey will be simply carried out on selected Sales Order Despatch Application current workers. This survey would help us understand what the end users of the SODA would want from the new system. And by placing any current problems they are facing as at the time the survey is being carried out can help in enhancing the new system and tackling such problems in the new system.

Interviews

In this particular fact finding technique, different levels of workers and bodies of the organisation would be interviewed in order to get a suitable and preferable view of the system to be implemented. Such problems being faced in the current system also need to be addressed, and those problems must be surpassed by the new computerized system.

The most important people who would be interviewed would be the Managing Director of Fizzypop Plc and major end-users of FizzyPop plc in charge of the day to day activities.

The purposes of these fact findings are to understand the functional and non-functional requirements of the system.

1.2 Planning

Once all the necessary information is gathered through the interviews and questionnaires, they should be addressed as requirements.

Also the system must be developed within a limited time and budget. In this stage an initial budget will be built to get a rough idea on what the final cost will be to implement the system. This initial cost will vary from the final budget due to many changing factors.

Also a deadline must be given by the restaurant as to when they want the system implemented. A Gantt chart must be developed to monitor the progress of the system. This will ensure that the system is finished and delivered on time. This a view of the gantt chart which the developers and analysers will use to monitor the progress of the system to be developed:

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32

Here are the functional requirements identified for the system:

Functional Requirements

Functional requirements are the requirements needed for the new computerized system to function properly. The following are the functional requirements for the Sales Order Despatch Application system:

* Allow the end-user to specify the customers soft drinks and delivery requirements via an intranet web page.

* Able to edit, add to the job sheet online.

* Allowing staff and management to view and produce reports of packaged items, via their internal networking infrastructure (i.e., their intranet).

* Customers order is been verified against current capacity, stock availability and delivery dates.

* Receive confirmation of the delivery date and related billing information

* The information system needs to be integrated with their current customer and distribution database.

* The system will, from time to time, provide the company with detailed reports of customer profiles (number of customers, types of drink purchased, and current revenue).

* 1.3 Risk Analysis

In this particular task region, all possible risks to be encountered are been identified. A risk probability impact matrix should be also put up in order to understand the effects of the risks better. Whereby Risk categories have been divided in to 2 sections, namely Technological and Management, and here are examples of such risks:

* Management Risks

o Computer illiteracy within end-users

o Takes time for end users to be comfortable with the change of initial system to current system

o Misuse of developed system might lead to unnecessary expenditure on maintenance

o Lack of team Support

o Inadequate time to complete project

o Inadequate funds/ Final expenses higher than initial budget

o Disclosure of company information

* Technological Risks

o Power Failures are vulnerable to loss of data

o Due to improper management Data Corruption / Loss of Data can occur

o There might be Intruder Attacks from hackers.

o Hardware Failures.

o The Rapid evolving and change in software.

Initially after getting all the risks for the system, it has been noted down that the following risks that have an actual threat to the SODA system are mentioned below:

* Inadequate time to complete project

* Inadequate funds/ Final expenses higher than initial budget

* Data Corruption / Loss of Data

* Intruder Attacks

* Hardware Failures

* Misuse of Equipment

1.4 Engineering:

This task region is to design the system with the gathered requirements information using selected tools and coding techniques selected. A sample prototype can be designed as well in this stage.

The programming language that can be used to develop the Sales Order Despatch Application SODA could be Java and ASP.NET Since java is a very popular programming language with its own GUI. While ASP.NET is a web based programming language which is also platform independent with JAVA therefore it would be easy making future amendments to the system, in case the system hardware is changed or ready to be reviewed again.

SQL server 2008 can be used to create the database for the Bottling companies. It is easier to create and link tables and create queries using SQL server 2008 and will be able to handle all customer and bottling information, including record keeping of customers visiting the website.

1.5 Construction and Release

This is the stage where the prototype of the system that was initially designed in the previous stage would be brought into life by coding the system.

Once the coding is carried out, the system has to test to see if it meets all the requirements. Testing can be done using sample of test cases and then the actual output is matched against the expected output of the above mentioned system.

Once we are through with testing and it meets the given expectations, the final documentation is prepared along with a training manual showing the customer on how to use the system. Technical support will also be provided along with the training manual.

1.6 Customer Evaluation

This is the task region whereby feedback is been gotten from the management of FizzyPop Plc. Whether or not the developed system is up to their expectations is learned in this stage. This could be determined as the final stage of the project if the system is acceptable by the FizzyPop plc. But. If it is not accepted therefore you have to case it is back to task region one, Customer communication, by getting the information needed to do amendments and understanding what the customer wants in the system.

QUESTION 2

The goal of every software engineer in software engineering is gaining durability for quality products depending on the attributes of such products. There are laid down set of qualities specifically linked with system dependability attributes such as security, safety, fault tolerance; quality that makes for convenience of use, such as usability, adaptability, and clarity; and quality that facilitates and makes future upgrades and maintenance easy. There is some agreement about the attributes that define software quality and dependability over a range of products. These definitions provide the base knowledge from which individual quality products are planned, engineered, analysed, measured, and enhanced.

There are many dependability measurement attributes that could be applied to the SODA system, but only few of such attributes of dependability measurements would be described below. These attributes have been selectively chosen due to its high contribution to Sales Order Despatch Application SODA namely:

1. Efficiency/ Performance of the system

2. Accuracy

3. Dependability

4. Usability

2.2Efficiency/ Performance of the system

Performance/ Efficiency of a system, is a set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used and under stated conditions. Resources may include other software, hardware, services of operating and users for maintenance and operation. This attribute have 2 major features namely: Time and resource behaviours.

And if a processing results requires a very high performing processor and lots or RAM to display the processed result under 3 seconds, that is an indication of poor resource performance.

In other words even if the processed results are accurate to its single term, it still requires excess time and resources, it will simply affect the overall quality of the system.

.

2.1 Accuracy

Accuracy is an attribute of software that deals with the provision of right or agreed results and its effects. The question to be figured out next is how accurate the system performs.

For example, the user enters drink specification Mountain dew using the Add function in the database, and the system displays results for Drink specification of only Mirinda or Malta , that indicates an inaccurate system. This happens due to poor programming and system designing.

Overall an inaccurate system means the quality of software is poor and therefore the end-users (FizzyPop plc) will not be pleased with the entire software.

2.4 Dependability

After the system has been designed for FizzyPop plc And it has proven to be efficient, effective, user friendly and safe, we still have to worry about how dependable the system could be.

That is to say that Dependability basically is how dependable the system implemented would be, which has many features and some of those features are:

* Maintainability

Normally after the system is implemented and sold to FizzyPop plc, it must be maintained, and this maintenance will be done by the users of SODA. Maintenance will usually include updating the system software, taking backups. All this will be taught to the user during the training phase, but this also must be easy to do.

* Reliability

FizzyPop plc would be open throughout the day, and the system will also be on and running as long as FizzyPop exists.it could only be altered when further development process is been carried out and ready to implement.

NOTE: The system must be able to operate during these times without and crashes or system failure.

* Availability

The system must be able to be started up within a short time, and ready to use. Queries must be responded to as and when the user demands them, that is the basic idea of availability. The system must be ready to use on the users demand.

2.3 Usability

Usability is a set of attributes that put up with on the effort needed for use of a system, and on the individual assessment of such use, usually evaluated by the user of the system.

The system developed for FizzyPop plc should be easy to use and learn. The user involved with the day to day function of the system, does not really need to be very good technically. Therefore the system must be designed in a way it easy to understand for users who will be using the system. All error messages must be in simple understandable English with less technical jargon. Therefore in the event of any errors the system user should be able to overcome the problem by themselves. Any new user of the SODA system should be able to have an experience and understand how the system works on their own. That will be a good indication of a user friendly system, in other words a good quality system.

Also a training session must be provided to the users of SODA in order to show them on how the system works. A manual will also be given, in any case, if there are any problems in the system that needs any attention, SODA users (FizzyPop plc. Staffs) can look up the manual for details.

CONCLUSION

The spiral life cycle model has been chosen to develop the system so that the final product developed for FizzyPop plcwill very few or no problems will be found at all. This model makes sure that all the risks involved will be identified and taken care of before being handed over to the Bottling Company known as FizzyPop plc. Since the spiral model uses a rotating pattern, it ensures that all requirements are identified, and the system designed meets the specifications in order to make sure SODA users are satisfied with the system before the system is delivered to them. This spiral way of designing the system is also a bit costly to FizzyPop plc compared to developing the system using other methodologies, but its outcome is much worthy.

In summary of the dependability measurement attributes, it could be said that, the software which is most efficient, effective and user friendly would be bad in terms on quality if it has low dependability qualities, such as, taking too long to start-up , regularly freezing up/ crashing and requiring high end technical training for users to maintain the system. If it is also a very dependable system, but with poor efficiency, performance and a bad user interface. it will not be a good quality system either.

Finally we have concluded by saying that the system developed for FizzyPop plc must be perfect in all of these attributes; any defect or failure in any of these attributes will compromise the overall software quality for the system.