The History Of Developing Ebusiness Systems

Published Date: 02 Nov 2017

The three ports which will be covered in this report are the Port of Antwerp, Port of Gothenburg and the Port of Newcastle. The reason the aforementioned ports have been picked is because they are all diverse in how they operate. They are based in different countries which mean different work ethic and cultures could be explored.

Port of Antwerp

Antwerp is Europe's second most vast port and the fourth largest in the world. In 2005 the Port of Antwerp handled of over 160 million tons of oceanic merchandise. Each year, 15,000 maritime vessels and over 64,000 inland crafts call at the port. More than 140,000 people make a living directly or indirectly from the Port of Antwerp. L:\University\Year 2\Developing eBusiness Systems UG2\CW 1\NOTH_SEA_ANTWERP_GOTHENBURG_BERGEN.png

The Port of Antwerp is an essential connection in the European Union import/export chain and a core hub for a vital number of trading actions worldwide. Container traffic is experiencing rapid development of ten to fifteen per cent a year. Containers account more than forty per cent of maritime traffic at the Port of Antwerp. (Port of Antwerp., 2012)

Port of Gothenburg

The Port of Gothenburg is the most extensive port in Scandinavia, with over 11,000 vessel calls every year. Generally 30 30 per cent of Swedish trade passes through the port. The Port of Gothenburg can offer a very wide range of routes, with traffic to over 130 destinations throughout the world. (Port of Gothenburg, 2012)

Port of Newcastle

The Port of Tyne is an essential northern portal and vital player in the North East area; a dynamic bartering centre with five business territories; conventional and bulk cargoes, logistics, car terminals, cruise and ferries and estates.

It is a deep river port with round-the-check access based in Tyne Dock South Shields, with a Global passenger Terminal based in North Shields. Managing a rail terminal joining straight to the UK's high speed east coast main line, the Port's area in addition offers effortless access to the UK national motorway grid. (Port of Tyne , 2012)

Port Service Charges

Port of Antwerp

There are many factors that influence the way the ports charge for their services. Starting with the Port of Antwerp, Each ship entering the port is charged a fixed fee in addition to the tonnage dues. To find out the tonnage dues, the shipowner, broker, the authorised representative of any one of them, must present the ship’s international tonnage certificate (1969) whenever a sea-going vessel calls the port.

The calculation of the berthing dues is based on the number of loaded or unloaded tons. The weight used to define the mooring right is rounded up to the higher ton for each individual section on the required declaration. In the event of transshipments the fee will be charged to both the unloading and loading sea-going vessel. (Tariff regulations sea-going vessels, 2012)

The precise cost will rely on a variety of factors that include:

"navigation service charges,

pilotage,

site occupation charges,

wharfage charges

Mooring fees.

Payment of Port Dues

sea-going vessel

Tonnage Dues under Guarantee

Duration of Stay" (Tariff regulations sea-going vessels, 2012)

Port of Gothenburg

The application of these tariff regulations is based on the following concepts:

The dues are based on GT (Gross Tonnage)

payment of dues for arrival and departure is made separately

for receiving waste from vessels

Harbour Dues For Vessels –

Tankers

Container vessels in regular services

Car carriers in regular services

Passenger ships/passenger ferries/rail ferries

Cruise liners

Private yachts

Official vessels etc. (Port of Göteborg, 2012)

Dues are billed for a complete call when the vessel lands at the Port of Gothenburg. The dues are dependent upon GT (Gross Tonnage) as per the 1969 estimation measurement rules, unless otherwise stated in the tariff. At the point that a vessel calls at the Port of Gothenburg outside of the norm or has been revamped, a bona fide tonnage endorsement as per the 1969 estimation tenets might be introduced by the transportation group or its representative.

In cases where landing and flight are taken care of by diverse dealers or alternately distinctive terminal associations, installment of duty for landing and takeoff is made independently. The costs stated underneath are in SEK and connect with complete calls, i.e. for landing in and takeoff from the port zone.

The Port of Gothenburg makes a charge for accepting waste from vessels, as per Swedish enactment and EU directive 2000/59/EC. Products duty of 27 SEK/ton are charged for unloading or stacking of products at dry freight quays possessed by or at the transfer of Port of Gothenburg AB (quay 751). The same charge is made for lightering between vessels. (Port of Gothenburg, 2012)

Port of Tyne

Types of Charges

The Navigation Service Charge is placed on vessels when it enters the port and for the common use of the Port and its infrastructure, including the following facilities and services:

Breakwaters

Vessel Traffic Control

Channels and Channel Dredging

Emergency Response Units

Hydrographic Surveys

Harbour Master/Port Management

Navigation Aids

Environmental Protection

Port Communications

A flat charge of £497.20 will be applied to each trading vessel entering the port. This levy is required to cover costs arising from implementing the Australian Maritime Transport and Offshore Facilities Security Act & Regulation 2003. (Port of Tyne, 2012)

Systems Development

Waterfall model

The waterfall model is a sequential software development model in which advancement is perceived as flowing steadily downwards similar to a waterfall through some stages. Waterfall Development’ is an additional name for the more conventional way to software development. The reason the name ‘waterfall’ is given, is due to the fact that this sort of development is frequently planned using a Gantt chart – you finish one stage, e.g. planning the groundwork before proceeding onward to the next stage, e.g. development.

In Waterfall approaches you will not intend to re-visit a ‘phase’ once it is finished. Thus, you must get whatever you’re doing right the first time. This way is exceedingly risky, often more expensive and usually less effective than more Agile approaches. (Tara Hamilton-Whitaker, 2009)

The primary issues with this methodology include:

The value is not realised until the end of the project, when it is deployed.

The testing is left until the end, which means issue discovery is left until late in the project lifecycle.

The approval is not recognised by the stakeholders until late in the lifecycle, in the meantime their requirements might have changed.

The heavy emphasis on a project manager is overwhelming – the power of one. (Tara Hamilton-Whitaker, 2009)

Spiral Model

The spiral model is a software development process joining components of both design and prototyping-in-stages, in a deliberation to combine together advantages of top-down and bottom-up concepts. (Boehm, 1986)

The spiral model was described by Barry Boehm in his article "A Spiral Model of Software Development and Enhancement from 1985". This model was not the first model to talk over iterative improvement, yet it was the first model to clarify why the emphasis matters. As initially envisioned, the iterations were typically 6 months to 2 years long.

Every stage begins with an outline object and ends with the customer (who may be internal) assessing the progress so far. Analysis and designing efforts are applied at every stage of the activity, with an eye in the direction of the end goal.

The Spiral model is used frequently within large projects and requires consistent reassessments to continue on board. For smaller projects, the concept of agile software development is becoming a feasible substitute. (Boehm, 1986)

Advantages

The financial estimates get more accurate as work progresses, for the reason that significant issues are discovered earlier.

It is more able to cope with the changes that software development generally entails.

Software engineers can get their hands in and start working on a project earlier. (Boehm, 1986)

The third systems development approach which is commonly used is Product Line Development. This is will be explained in detail below.

Product Line Development

A product line is a set of connected systems that address a market segment. Software engineers have designed software systems one system at a time since the start, and every software product includes investments in requirements analysis, architecture and design, documentation etc. (Nyholm, 2000)

Further and further businesses understand that they cannot afford to develop several software products at a time. They are similarly anxious to introduce fresh products and enhance functionality to current products at a fast pace to be able to compete at the market. These aims are difficult to hit when designing one system at a time. A lot of businesses nowadays typically develop new systems from previous cases to speed up the process. However, to reuse parallels between systems in the most effective way, a product line approach may be the correct answer to an organisation. The approach uses a mutual set of main assets to modify, assemble, instantiate, or generate multiple products and is referred to as a product line. Such a product line approach involves building a product line as a product family. https://www.research.ibm.com/haifa/projects/services/product_lines/images/pohl_460.jpg

(Pohl, 2005)

Not all businesses developing software ought to accept a product line approach. One reason is that it might not be worth the effort in all cases, since it is expensive and time consuming to adopt it. The viability and attractiveness of the business will be undesirably affected during the adaptation. Consequently, it is vital that the organisation knows that and tries to fulfil the process, since it will possibly be worth the time and effort. It is difficult to decide if a product line approach is good for a particular organisation and it involves study of numerous factors.

When initiating a product line, there are two dimensions to be considered. First the organisation can take an evolutionary or revolutionary approach to the introduction process.

Furthermore, the product line approach can be functional to a present line of products or to a novel system or product family that the organisation expects to use to increase its market. In a broad-spectrum, the revolutionary approach involves extra risks but you get higher returns compared to the evolutionary approach.

Evolve an existing set of products into a software product line: The organisation already has a set of current software products but have not used the commonalities between them. To use this method you have to develop a product-line architecture based on the product architectures. Then, when selecting the products to be members of the product line, the components need to be recognised and the products adopted to use the shared component.

Replace an existing set of products with a software product line: Since the evolutionary approach requires more time than the revolutionary approach it may be better for some organisations. It involves replacing the existing set of products by a product-line architecture and set of components. All efforts are focused on designing the architecture and develop the components in the product line. The goal with this approach is to develop a new platform that does not suffer from the problems that exist in the current set of products. (Nyholm, 2000)

Product Line Analysis

North Sea Ports - Product Family Analysis

Port Services

Antwerp

Gothenburg

Port of Tyne

Registration of Vessels







Container Vessels







Stena Line



Shipping Lines







Tugboats (Towing fees)





Cruise







Cranes







Cleaning



Liner Vessels







Inspection Fees





Bulk Lines





Warehousing







Maritime Services



Bulk Cargo



(Port of Tyne , 2012) (Port of Gothenburg, 2012) (Port of Antwerp., 2012)

Types of Products which pass through the Port of Antwerp

Port of Antwerp

Almost all products you use in your day-to-day life have been handled through the Port of Antwerp. And each product requires its individual technique of transport, or packaging. Five types of cargo can be distinguished:

Container cargo

Liquid bulk

Dry bulk

Breakbulk

Ro-ro

(Port of Antwerp., 2012)

Product Line Design

Below is a product design for the Port of Antwerp:

Log Arrival of boat

Service it requires

Create Order

Pay Order

Invoice

Alt 1.1

Pay Order via Telephone E E-Mailhttp://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.1

Alt 1.2

Opt 1

Pay Order via Credit Card

Send Invoice

Opt 2

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.2

Pay Order via Bank Transfer/Other

Alt 1.3 Printed

Document

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Decision Model

Alt 1.1: If payment method = Telephone

Alt 1.2: If payment method = Credit card

Alt 1.3: If payment method = Bank transfer

Alt 2.1: If continent = America

Alt 2.2: If continent = Europe

Opt 1: If email = Yes

Opt 2: If printed document = Yes

(Bayer, 2006)

Below is a product design for the Port of Gothenburg:

Log Arrival of boat

Service it requires

Create Order

Pay Order

Invoice

Alt 1.1

Pay Order via Telephone E E-Mailhttp://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.1

Alt 1.2

Opt 1

Pay Order via Credit Card

Send Invoice

Opt 2

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.2

Pay Order via Bank Transfer/Other

Alt 1.3 Printed

Document

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Decision Model

Alt 1.1: If payment method = Telephone

Alt 1.2: If payment method = Credit card

Alt 1.3: If payment method = Bank transfer

Alt 2.1: If continent = America

Alt 2.2: If continent = Europe

Opt 1: If email = Yes

Opt 2: If printed document = Yes

(Bayer, 2006)

Below is a product design for the Port of Tyne:

Log Arrival of boat

Service it requires

Create Order

Pay Order

Invoice

Alt 1.1

Pay Order via Telephone E E-Mailhttp://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.1

Alt 1.2

Opt 1

Pay Order via Credit Card

Send Invoice

Opt 2

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Alt 2.2

Pay Order via Bank Transfer/Other

Alt 1.3 Printed

Document

http://chris.gg/wp-content/uploads/2009/11/printer-paper-symbol1.png

Decision Model

Alt 1.1: If payment method = Telephone

Alt 1.2: If payment method = Credit card

Alt 1.3: If payment method = Bank transfer

Alt 2.1: If continent = America

Alt 2.2: If continent = Europe

Opt 1: If email = Yes

Opt 2: If printed document = Yes

(Bayer, 2006)

This Project’s Approach to e-Business Development

The systems development approach which will be used within this particular project will be the Product line development with iteration and evolutionary implementation. Iterative and Incremental development is any mixture of both iterative design or iterative method and incremental build model for development. During the software development, more than one iteration of the software development cycle may be in progress at the same time, and this process may be described as an "evolutionary acquisition" or "incremental build" approach. The relationship amongst iterations and increments is determined by the whole software development methodology and software development process. The precise number and nature of the particular incremental builds and what is iterated will be particular to every individual development effort. (Larman-Basili, 2003)

Phases

When it comes to incremental development, the systems functions are separated into increments (segments). In every increment, a piece of functionality is delivered through cross-discipline work, from the requirements to the deployment. "The unified process groups increments/iterations into phases: inception, elaboration, construction, and transition." (Boehm, 1986)

Contrast with Waterfall development

Waterfall development ends the project of every phase in one stage before moving on to the next phase in the next stage. Business value is provided all at once, and only at the very end of the project. Backtracking is possible in an iterative approach.

The reason the iterative development approach will be used is that the advantages outweigh the disadvantages. This is further explained below:

Advantages

Overall, the iterative development model permits for early adjustments to the product throughout development, instead of finding the problem once it is too late and having to spend a lot resources to implement the changes into the project. This approach would be beneficial with regards to the port service charging system, the reason because, if issues are detected during the lifecycle of the project, then the option of implementing a change with low cost is present. In addition, the ability to see the possible outcomes of each step and implement changes to areas of concern if necessary. This is one of the reasons that make the iterative model useful.

The corrective actions in the iterative development model are usually done at every interval; they are extremely precise and exact, this is because if there is a fault in the requirements or design stage than it can hopefully be established sooner rather than later. These corrective measures are also effective as they reflect the outcome of the specific stage of the project. Iterative development is more adjustable to changes as it considers each stage like a vital portion of the development cycle.

The period consumed on each sequential interval may be diminished depending on how the last stage went and what information was gained from past stages. The system consequently grows through adding new functionalities in the development part of all iterations. Moreover, since all iterations tackle a small requirement set, time is decreased as the testing evolves.

 

Disadvantages

When using the iterative model individuals working on the project can get caught in a loop. Constantly discovering problems, then having to go back and design a fix, implement it, than test the system again and discovering another problem can mean that the project can run over time and budget. Thus, the exigency of creating a ‘fault-free’ port service charging project is imperative.

The users need to be taking an active role during the project. If they are not taking a part within the project then it is more likely that they will be unwilling to use the system once it is finished. While this participation is constructive for the project, it is challenging on the time and the staff and can cause delays in the project. In this case, the users of the port service could be potential clients, customers or even the internal company staff. Informal demands for enhancement after every phase may lead to misunderstanding and may also create scope creep, since user feedback following each phase may lead to increased customer demands. As users see the system develop, they may realise the potential of other system capabilities which would enhance their work, this can be an advantage as much as it can be a disadvantage.

(Larman-Basili, 2003) (Nyholm, 2000)

Implementing the Port of Antwerp product

The Port Service Charging System will be implemented using many different elements such as testing and design. Below are the five critical steps in a successful implementation of the new port service charging system:

The first stage in the implementation procedure must instigate with a detailed review of the business requirements and processes, to classify what is working well and which aspects of the port service system may need development and modification.  These business requirements will then be represented into the project plan, which will drive the rest of the implementation.

Design, Develop and Build – Using the project plan created, the following stage will continue to build the pilot port service charging system.  This is used to authenticate those business processes and system functionality detailed in the project plan.

Train, Test and Accept – Learning on the lessons acquired in the pilot system and using test data transferred from the preceding system, this stage comprises educating the staff the best practices and measures to deliver the required functionality.  Effects from this testing and training period need to be studied and a sign-off should be secured, declaring that the development made to date is suitable and in line with the general goals of the implementation.

Implement and Go-Live – Working from the information attained in Steps 1 and 2, the new port service charging system should now be complete.  The legacy data is transferred a final time to the new system and all of the experience and resources of the project team are on-site and ready to make the final transition to the new system.

As these implementation steps are carried out, starting with a broad based and all-inclusive viewpoint of both your internal and external operating environments, the emphasis of the implementation project is then continuously narrowed to produce precisely the system that is needed to meet and surpass the business objectives that have been defined.

(Hoyt, 2009)

The Product Line Development Approach Evaluated

To conclude, the project will be critically evaluated with reference to Product Lime Development to understand which aspects were successful and which aspects were less successful.

Starting with the successful aspects, below is an in depth explanation of the successful aspects:

Successful Aspects

Availability of Case Study - The first successful aspect of the project was the fact that the Antwerp and Gothenburg case studies were readily available displaying the relevant and in depth information, which actually facilitated the PLD approach in the project.

Language Diversity - The information which was required was available in a variety of different languages, however, the relevant content was accessible to individuals whose first language is English. The language for the ports was available in English making it successful to conduct a product line development for the port charging system.

Ease of Access – The ability to access the required information for the research task was simple. It reduced the time which alternatively would have taken to navigate the website as well as the styles used made it simple to navigate or access the website.

Least Successful Aspects

Product Design – The less successful aspect was the product line design. That could have been designed more efficiently with further sufficient research. The design process could have been spent better with in depth research and development.

Utilisation of Product Line Development

Below is a short explanation on how the advantages of Product Line Development were capitalised upon and how the disadvantages were avoided:

Product Line Development has contributed significantly towards the design of the port service charging systems’ plan, as it has firstly allowed for the planning and requirements phase become to a large extent easier, as before it was rather structured and complex. If required, the information can completed and reused again if another system was to be built, this would save time if the client needed more systems to be built.

Another benefit which was fully utilised was the approach on what requirements needed to be implemented. This allowed for a concrete understanding of the project with a clear vision rather than causing confusion. The Product Line Development also enabled for a plan of action to be put in place with key features that will actually facilitate the design and coding phase.

The in depth analysis was also beneficial as it allowed for all angles to be covered. It would allow for a plan that is comprehensive in detail with accurate information. The information from the analysis can then be utilised towards the modelling and analysis phase, as it can produce ideas which can be explored, like time saving ideas for the project.

It was difficult to point out the disadvantages of PLD in this project. The incorrect following of the approach was avoided by creating a concise plan which was to be implemented when it comes to the creation and coding of the port charging system.

Recommendations

The First recommendation would be: include more ports and have a wide range of ports making the program more efficient. The Product Line Development planning phase and documents can be reused; therefore it would not be much of a problem – that is why I suggest this as a recommendation.

The second recommendation would be: conduct a lot more research by checking the history and future plans of every port included, to be built for the system. By researching the history and future in depth, it would allow for the trends to be recognised for the ports, therefore, the port which would have been designed would be more suited to the ports’ own future aims and objectives.