An brief investigation into CSS Frameworks in website development

I have recently been investigating the use of CSS frameworks for rapid prototyping and production of webpages. In particular I have spent time implementing the 960 grid system (click here for further info) in the development of a number of websites.

On a personal level I found the framework to work very well especially when used in conjunction with a reset style sheet. This approach enabled the reduction of browser inconsistencies in things like default line heights, margins and font sizes of headings. So far I have tested with IE 6,7,8,9 Firefox, Safari and Opera. The only noticeable variation observed was the positioning of a single image on an entire test website when using IE6. 

There is an on going debate surrounding the best approach to develop a webpage structure tables or div elements, of which I have practical experience of both approaches. I would say the technique used to layout a website is down to personal preference and that both approaches can work well if implemented correctly. Ultimately website ranking algorithms have a greater focus on website content as opposed to the sites script structure, so therefore if a websites structure is well defined then the majority of resources should be aimed at the quality of website content.

An investigation of methodologies and frameworks as an approach to developing a solution to a problem domain

Here’s part of a recent investigation undertaken into utilising methodologies to produce a solution to an information system problem domain. 

Possible frameworks or methodologies

In order to select a development methodology best suiting a given problem domain, a number of considerations must first be taken into account. (Dennis, Wixom, & Roth, 2006) suggest that an appropriate development methodology could be selected based on six criteria, clarity of requirements, familiarity with technology, system complexity, system reliability, time schedules and schedule visibility. These could be considered as viable criteria for development methodology selection; however the following ten considerations suggested by (Trigoni, 2009) could also be taken into account to add further understanding and refine requirements for selecting a methodology:  

• How will the project be broken down into smaller components
• What tasks will be carried out during different stages of the project
• What outputs are required from the project
• When and under what circumstances should these outputs to be carried out
• What constraints are to be applied
• How should the project be managed and controlled
• What are the training needs for the methodology users
• Which people should be involved
• What support tools are to be utilised
• What methodology philosophy and underlying theories/ assumptions has shaped the development methodologies available

A way in which these considerations could be first identified and then used to assist in selecting an appropriate methodology could be through the use of a frame work. Frame works in the context of information system development methodology selection, are described by (Trigoni, 2009) as:  

“…guidance to the developer in choosing methods, techniques, and tools…”

(Trigoni, 2009) Also suggest that a frame work could be utilised in replacement of a “prescriptive” methodology. Some known frameworks are:

The multi view Frame work

A framework used to observe five different views, human activity, information, socio-technical aspects, human computer interface (HCI) and technical aspects using techniques from other methodologies.

Strategic Operations Development and Analysis (SODA)

A framework used to model complex problems, through interviewing and mapping (Institute for Manufacturing – University of Cambridge, 2009).

Capability Maturity Model (CMM)

A framework developed to assist in evaluating business processes used by ordering those processes into five levels (Select Business Solutions, Inc, 2011).

Euromethod

A framework used to provide a common understanding of requirements and solutions between countries within Europe (Helmerich).

Based on personal understanding of development methodologies, a methodology does not necessarily need to be strictly adhered to step by step, as problem domains do not always fit into an ideal model. Sometimes an element of flexibility or possibly a mixed methodology approach may be considered more appropriate in order to develop a suitable solution, however the possible pitfalls of doing so must be acknowledged. Which ever route is taken towards the development of an information system, best practices of information system development should be applied. These best practices include the involvement of system users, management of requirements, the application of iterative and incremental development, the visual modelling of systems, quality verification and the ability to control system changes (Rational Software Corporation, 2000). In adhering to this good practice a number of desirable system deliverables could be achieved, such as:

• Maintainability
• Reliability
• Simplicity
• Acceptability
• Efficiency
• Compatibility
• Cohesiveness

 

Proposed Methodology (or methodologies)

The assignment scenario suggests two elements that required addressing. A socio-technical aspect highlighted by the management through the following statement “They are aware that there will be some social and cultural issues that need to be addressed and solved before starting to think of the technical aspects”. The second element that required addressing was the managements concern over the limited time scale in which funding would be available. On reflection this scenario would not suit a structured methodology such as the waterfall methodology. The process and data models produced to aid the system design phase would not address the social implications discussed within the scenario. In addition the time lag between project planning and final system could be considerable reducing the likely hood of producing a system within the life time of the grant (Dennis, Wixom, & Roth, 2006, p. 11).

One possible solution could be to take a two phased approach utilising strengths found within two different methodologies, implementing a soft methodology such as Soft System Methodology (SSM) or Effective Technical and Human Implementation of Computer Systems (ETHICS) methodology, in order to determine both social and technical system requirements increasing the likely hood of system acceptability by its users. The second phase could take the form of an agile approach to implement the system with in a short time period comparable to a structured methodology approach. Another alternative solution could be the implementation of a Rapid Application Development (RAD) methodology in the form of prototyping. This methodology would consist of prototype iteration based on feedback from key stakeholders until a suitable solution has been developed.

8NH6RHPGB3HD

An investigation of information system development methodology evolution and Extreme Programming

Abstract

Information system development methodologies have evolved over recent decades due to a variety of factors such as changing business requirements, technology and limitations in existing methodologies. This report acknowledges that there are a wide variety of development methodologies available to system analysis and design practitioners and explores structured, rapid application and agile development methodologies in further detail. The report identifies relationships as well as highlighting strengths and potential weaknesses between the methodologies. A detailed investigation is made into a form of agile methodology named extreme programming and its development phases. Through analysis and reflection of these phases and other discussed methodologies, an understanding of how extreme programming has been developed to address the potential failings of the other methodologies was formed. The report concludes that although extreme programming has a number of strengths over other methodologies it also has its own limitations and there fore cannot be described as a “final solution” to information system analysis, design and development.       

 

Introduction

In order to effectively analyse, identify functionality, design and implement an information system the concepts of decomposition, modularity, coupling and cohesion must be understood and utilised. These concepts can be defined as follows:

Decomposition – Dividing a system into smaller components or even sub components in order to gain a greater understanding of the system in question.

Modularity – A result of decomposition, the break down of a system into modules of similar granularity.

Coupling – The degree in which modules depend on each other. Low coupling is a sign of a well structured system.

Cohesion – The measure of how a module performs a function. A module which is high in cohesion has benefits over low cohesion in the form of increased reliability, reusability and understand-ability.

The analysis, design and implementation of information systems face many challenges such as low productivity, failures and miss alignment between the information systems and business requirements to name a few (Tolvanen, 1998). A well publicised and documented example in recent times of system development falling fowl of these challenges, was the upgrade on the United Kingdoms NHS IT infrastructure (British Broadcasting Corporation, 2006). However there are success stories of these challenges being overcome, such as Atos Origin’s design and implementation of the Information Systems used in the Beijing Olympics (Ashford, 2008). There may have been distinct differences between the problem domains and how the projects were managed, leading to the eventual success and arguably failure experienced within the two examples. However one area that inextricably linked both projects was that they followed a system development methodology.

A methodology in the context of systems analysis and design is defined by (Dennis, Wixom, & Roth, 2006) as:

“… a formalised approach to implementing the System Development Life Cycle ”

This “approach” consists of procedures, standards, techniques, an analytical framework, a philosophy and models in order to make system development more manageable (Houghton Mifflin Company, 2011). Models are used to visually represent a system to aid system analysis or design. Models and can be either and can be either process centred, identifying how information flows in and out of processes in order to define the system. Data centred focusing on defining data and its organisation in order to model the system or Object-orientated which take both processes and data into consideration and combine them into modules referred to as objects and through the use of Unified Modelling Language (UML) attempt to describe a system.

There are many types of methodologies available to aid in information system development, some of which are:

• Structured System Analysis and Design (SSADM) methodologies
• Rapid Application Design methodologies
• People – oriented methodologies
• Soft System Methodologies (SSM) taking into account Customers, Actors, Transformation process, World view, Owner and Environmental constraints (CATWOE) to develop a perspective of the system (Institute for Manufacturing – University of Cambridge, 2009)  
• Jackson System Development (JSD) methodology
• Effective Technical and Human Implementation of Computer based Systems (ETHICS) methodology

Based on personal observations made during research into information system development evolution, three distinct categories of methodology were identified. These were structured methodologies, rapid application design (RAD) methodologies and agile methodologies. Each of these methodologies followed the system development life cycle phases (Feasibility, analysis, design, implementation and maintenance) however each category of methodology placed emphasis on the different SDLC phases as well as the sequence in which they were navigated to produce a completed system.

Structured methodologies

Structured methodologies were in wide use during the 1980’s and were a response to the previously unstructured ad hoc approach to system design. Structures Systems Analysis and Design (SSADM) methodologies introduced, as discussed earlier within this report procedures, standards, techniques, an analytical framework, models and a philosophy to the development of information systems. The Waterfall development methodology followed the SDLC phases sequentially (fig 1.1), producing a set of deliverables at each phase which required approval before incrementing to the next phase. An advantage of using this structured methodology was that it identifying system requirements well in advance of implementation (Dennis, Wixom, & Roth, 2006, pp. 10-11).   

Figure 1.1 Waterfall development based methodology. Taken from (Dennis, Wixom, & Roth, 2006, p. 11)

Rapid Application Development (RAD) methodologies

This category of system development methodology emerged in the 1990’s in a response to potential extensive time lapses between project initiation and completion experienced with structured methodologies. Side effects experienced were misalignment of system and evolving business requirements and time lapses between communications with the client and system developers (Dennis, Wixom, & Roth, 2006, p. 16). This could result in potential costly alterations to the end system due to missing requirements. The way in which RAD methodologies were used to overcome these issues were by altering the emphasis of the SDLC phases. One such RAD methodology is prototyping. By reducing time spent in the planning phase and concurrently running the analysis, design and implementation phases. An initial system could be developed and presented to the system stakeholders within a short time period. The stakeholders could then interact with the system and provide feedback. The process would then be repeated to add further functionality. This process would continue to iterate until the key stakeholders were satisfied that the system was ready for implementation (figure 1.2). Like structured development methodologies RAD methodologies also experience potential downsides that practitioners must be aware of. The reduced emphasis on planning and analysis in the initial project stages could potentially lead to fundamental problems being overlooked causing major and potentially costly alterations taking place within the system prototypes later in the project (Purcell, 2007).

Figure 1.2 A prototype development based methodology. Taken from (Dennis, Wixom, & Roth, 2006, p. 14)

Agile methodologies

These methodologies were described as “Programming-centric methodologies” by (Dennis, Wixom, & Roth, 2006, p. 16). This in essence means that the main focus and measure of project progress is working software. This software is developed in small teams that follow the manifesto for agile software development, defined by the agile alliance in 2001  (Beck, 2001) (figure 1.3).

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

  (figure 1.3) The manifesto for agile software development, taken from (Beck, 2001)

Twelve principles form the foundation of the agile manifesto (Beck, Principles behind the Agile Manifesto, 2001) the highest ranking of which being:

“Our highest priority is to satisfy the customer through early and continuous delivery of software”.

This definition further supports Dennis, Wixom and Roth’s statement that agile methodologies are “Programming-centric-methodologies”. Forms of agile development methodologies include Scrum, Dynamic Systems Development Method (DSDM) and Extreme programming and follow iterative and incremental system development processes similar to RAD methodologies. Agile methodologies are regarded as a “light weight” less structured methodology (Cockburn, 2008) contributor to the agile manifesto 2001.

The rest of this report will explore Extreme programming (XP) as an agile development methodology, exploring its principles and techniques, identify different phases of the methodology attempting to differentiate XP from other development methodologies and discussing appropriate situations for and against its implementation.

 

Extreme Programming principles and techniques

Similarly to the fore mentioned development methodologies, XP also follows a development model. A similarity between figure 1.3 and 1.4 can clearly be seen, however figure 1.4 does not illustrate the emphasis placed on extreme programming as a collaborative methodology involving equal team partnership between managers, customers and developers who follow the principles of simplicity, communication, feedback, courage and respect throughout a project. 

Figure 1.4 an extreme programming based methodology. Taken from (Dennis, Wixom, & Roth, 2006, p. 17)

Phases of the extreme programming methodology

 

Exploration Phase

An XP project starts with an exploration phase. This phase involves meetings of the team including the customer. The team will jointly (sometimes with the aid of a coach to steer the meeting) establish the requirements, project priorities and acceptance test criteria (Wells, 2009). During these meetings user stories are developed. User stories are used as a tool to develop a high level requirement definition containing enough information for developers to gauge the level of effort required to complete the work item. User stories replace requirement documentation found in structured and to a lesser extent RAD methodologies. User stories are also used to develop a system metaphor. A system metaphor is a tool to enable the team to visualise diagrammatically, at high level how a system will work (Ambler, 2010). Ambler also stated that Unified Modelling Language (UML) in the form of use case diagrams can be used as a tool to visualise relationships between actors. However he warned that UML is to be used sparingly as the emphasis of XP is to producing working code over documentation and user stories are the primary artefact produced and used in XP.

Planning Phase

When the exploration phase has established the system requirements, priorities and a system metaphor, the planning phase can begin. The development team produce a task card for each user story defining the tasks required to complete that objective. This can take the form of simple models, designs or text. These tools and techniques enable the development team to estimate the time required to implement each user story. Discussions are then held with the customer to determine the priority and time scales in which the user stories will be implemented. Typically these consist of small groups of user stories over short time scales and are referred to as iteration deadlines. This meeting is also used as an opportunity to establish acceptance test criteria with the customer in order to determine if user stories have been completed correctly (Ambler S. W., 2009).

Iteration phase

This phase consists short cycles consisting of iteration planning, code development, testing and integration. Iteration planning focuses on the user stories and task cards and for the current iteration only, however amendments and new cards may be required as the project progresses. Once a plan of progression and acceptance testing (an iteration plan) has been agreed between the team, development can begin. This development consists of developers working in pairs, one coding and one guiding. This is termed as collective ownership and aims to increase tested quality code (Wells, 2009).  Any unfinished or failed development code is then reintroduced to the iteration planning phase. This process can be interpreted as a form of test driven development (figure 1.5)

Figure 1.5 – the extreme programming iteration life cycle. Taken from (Ambler S. W., 2009)

Production and release phase

This phase consists of further testing, acceptance testing and software releases. The whole development team takes responsibility for testing throughout the XP project (Crispin, 2003). Testing can consist of system testing; load testing, acceptance testing and integration testing (Ambler S. W., 2009). This example of communal responsibility conforms to the principles of simplicity, communication, feedback, courage discussed earlier. Acceptance tests, based on user stories are used to prove to both the customers and the rest of the team, through black box testing for expected results that the code module works to a specific set of criteria. (Wells, 2009) states that acceptance tests should be automated and not manual in order to reduce iteration phase time. Each acceptance test is scored and failing elements are addressed and retested. Code that passes the acceptance testing is then incorporated into the latest version of the system.

Maintenance phase

(Ambler S. W., 2009) argues that the maintenance phase encompasses the planning, iteration and production phase of the XP methodology. He acknowledges that production related issues should be taken into account during system development. From personal understanding of the XP development process and research undertaken into the methodology, Amblers comments are interpreted as valid. This conclusion is based on the understanding that with continuous exploration, commitment and steering throughout the project between the customer, managers and developers future general maintenance issues should be addressed and kept to a minimum. However in addition to this system maintenance is carried out in conjunction with the planning, iteration, release and production phases of the project needs (figure 1.6), through successful group communication, testing and feedback as the project develops. This suggests that XP methodology can be interpreted as an evolutionary development methodology to identify, achieve system requirements and meet the customers business.

Figure 1.6 XP methodology development model. Taken from (Ambler S. W., 2009)

What differentiates this methodology from other development methodologies

Throughout the report clear distinctions have been made between a variety of development methodologies. The investigation into the XP development methodology highlighted the methodology is considered as “light weight” due to less emphasis being placed on the production of documentation during development. This enables more project time to be spent on development. This however can be considered as making future maintenance or development harder, as there are fewer artefacts available for reference, comparable with structured methodologies (Cunningham & Cunningham Inc, 2001).

Although both RAD and Agile methodologies can be considered as both having a greater emphasis on reducing system development time compared with structured methodologies based on the report investigation. There are still distinctions between the two methodologies. The potential reduced emphasis on planning and analysis during implementing RAD methodologies and the reliance on prototyping as an iterative development process could potentially lead to fundamental problems being overlooked until latter phases of development (Purcell, 2007). This may cause potential costly alterations taking place within the system prototypes later in the project. The XP methodology can be used to overcome this problem due to its test driven team oriented approach to analysis, design and development.

When and when not to apply the extreme programming methodology

The selection of XP as an appropriate development methodology does depend on a number of factors. This is also considered true for other development methodologies. (Dennis, Wixom, & Roth, 2006, p. 18) Highlight a selection of criteria that should be taken into consideration when selecting an appropriate methodology. figure 1.8.

• Clarity of user requirements
• Familiarity with technology
• System complexity
• System reliability
• Time schedules    

Figure 1.8 Taken and adapted from (Dennis, Wixom, & Roth, 2006, pp. 18-19)

Through the observation of figure 1.9 it can be seen that XP suits domains with unclear user requirements, short time scales and schedule visibility. XP methodologies do not suit domains with unfamiliar technology and high complexity, however RAD methodologies such as throwaway prototyping do.

Figure 1.9 criteria for selecting a methodology, taken from (Dennis, Wixom, & Roth, 2006, p. 19)

Conclusion

Structured and RAD methodologies have been discussed throughout this report, highlighting the advantages they bring to information system development, and their potential failings leading to the eventual evolution of agile methodologies. This is not to say however that structured or RAD methodologies do not still have a place in information system development. They can still be considered as effective methodologies in information system development based on (Dennis, Wixom, & Roth, 2006) arguments highlighted in the previous section of this report. During reflection into XP as a development methodology and its relationships to other development mythologies, a clear link has been identified taking the potential failings of previous methodologies to produce a new alternative methodology for information system development. This however does not mean that the XP development methodology can be described as the “final solution” to information system development, as it has its own potential limitations such as developing solutions for complex systems with unfamiliar technology.

YPK97UBV9FDN

Research Publication

Publishing your research.ppt

This is a short presentation I developed discussing the process of publishing research material to a journal. This may seem somewhat out of place for this blog; however it is important to recognise that the development of information systems should be documented. If the development or implementation of an information system you are involved with takes an interesting slant and can be measured against existing methodologies or case studies, why not share it with other individuals who will recognise its significance and contribution to information system knowledge? Who knows you may even be recognised as an expert in your particular information system field! The presentation in summery discusses reasons for publishing and possibly reasons that may prevent publishing, the presentation then finally illustrates the process of publishing a journal article. I have also provided a selection of material for further reading around the subject.

Evolutionary Systems Development & Rapid Development Methodologies

Evolutionary Development Methodologies Powerpoint

The above Powerpoint presentation contains the first 15 slides of a recent lecture I attended discussing evolutionary systems development and rapid development methodologies. I found it interesting and thought it highlights some relevent points to consider when developing an information system. It discusses good information system development practice, gives a brief overview of Rapid development methodologies as well as identifying some advantages and disadvantages of implementing such a methodology in the development of information systems.

Usability and Interactive Applications: The development of an interactive training aid

Prototype context

Previously working as an assistant manager at Dominos pizza one of my duties entailed training in-store staff to ensure good product quality. It was required that at the end of the training period all new members of staff were cross trained in all aspects of in-store positions to ensure a productive cross skilled workforce. During the initial phases of training time spent demonstrating and teaching processes to a new member of staff could be high. On reflection it was concluded that the same training content was required each time a new member of staff was trained.

A training aid was considered as a practical, concise and consistent solution to reducing personal time spent repeatedly introducing processes to new members of staff. The intention was that the time saved in reducing the process introduction phase would allow more time to be spent coaching the new staff in practical front of house processes. The training aid developed consisted of a series of videos and photographs introducing and illustrating in-store processes run on a laptop at the store. The material did have a positive impact in reducing training time; however the user experience was deemed as not very interactive and could have been developed to have a higher transfer of information to the target audience.

On analysis of the above scenario the system user, task and environment were identified:

The user

• Newly recruited staff, typically 16-18 year old A-level students attending the local college. Level of basic computer and internet skills are considered as good.

The task

• For the user to interact with the prototype system through selecting links in order to gain access to relevant Domino’s training material in order to support their understanding in front of house pizza making processes.

The Environment

• The prototype system must be able to run on the store laptop. The laptop is considered to have basic hardware specifications, which are able to support typical usage.

Based on the above identified criteria and the four point definition of usability identified by (Dumas & Redish, 1999, p. 4) a high level requirement statement was then produced:

 “To produce a prototype information system; which through human interaction could deliver a variety of electronic training media in order to facilitate different learning styles on new Domino’s staff.” 

This statement however only identified a set of high level requirements and did not identify the system specification. In order to address this, a more detailed analysis was required in order to successfully develop a prototype fulfilling the above statement.

 

Requirements and specification for usability

A usability requirements analysis is defined by the (SFIA Foundation) as:

“The establishment, clarification and communication of non-functional requirements for usability (for example, screen design/layout/consistency, response times, capacity)…”

It must be noted that as well as non-functional requirements, there are also functional requirements, these requirements consist of process orientated and information oriented system requirements (Dennis, Wixom, & Roth, 2006, pp. 103-105). Based on this complete understanding of requirement types, a list of non-functional and functional prototype requirements was developed (figure 1.1).

Non functional requirements

• Accessibility must be catered for according to recognised industry standards

 

• The user requires a central point of focus on the interface to receive information. Other page features should be “paler, softer focused or smaller” according to (Wagner & Mansfield, 2007, p. 19)

 

• (Wagner & Mansfield, 2007, p. 20) Also argues that computer monitor text can be harder to read than paper. The inclusion of “white space” and simple interface design may prevent users from being overwhelmed by interface information

 

• Clear user navigation based on the two of the three key features of good navigation design identified by (Benyon, 2010, pp. 401-405) will be implemented within the information system:

 

1)   Labelling – either text or icons

2)   Navigation – logical and consistent link structure throughout the system

3)   Search – locating information, this will be currently omitted from the prototype as navigation was not considered complex enough to warrant incorporating a search feature. Due to the nature of prototyping, this functionality could be added to a later version

• The system must be able to cope with the demand of users accessing it, without noticeable degradation of system performance.

 

• The training material must be at a suitable level to be accessible for new employees

 

• Information must be presented to the user in audio, visual and text formats in order to meet visual, aural and read/write learning styles identified (Flemming, 2001-2011) in preparation for kinaesthetic learning through practicing processes discussed within the training material.

 

• The system must be accessible via an easily accessible source for example compact disc, memory stick or web page

 

• The system must conform to the organisational image for which it was intended to be used in. For example adopting the same colouring and logos.
• All prototype pages must be accessible with a minimum number of mouse clicks in order to simplify navigation for user orientation (Jacob, 2011). 

Function requirements 

• Based on (Jacob, 2011) comments the number of mouse clicks used to access training material should be kept to a minimum number of mouse clicks from any location within the system. In this instance the maximum number will be three.

 

• Page rendering times should be within 8 seconds plus or minus 2 in order to retain user attention (Website Optimization, LLC, 2011)

 

• The graphical user interface (GUI) must be rendered the same way visually irrespective of hardware / software configuration

Figure 1.1 Non-functional and functional system requirements

After careful reflection of personal skills and the requirements identified within figure 1.1, it was concluded that the most appropriate implementation for the prototype would be in the form of a simple website. The prototype would be developed using a combination of Hypertext Mark up Language (HTML), Cascading Style Sheets (CSS) and PHP Hypertext Processor language (PHP). HTML would be used to display content, CSS would be used to position and style content and PHP would be used to add an element of functionality to the site. This was an option that would stretch and build on existing practical knowledge and skills based on the theory identified within this report.

There were two alternative software tools taken into consideration for prototype development, a system using Microsoft Power Point and using the Netbeans IDE to develop a Java application. A Power Point implementation, although considered a perfectly adequate option for the development of a prototype with the media available; was deemed as not expanding personal development enough so was abandoned. Alternatively the development of a Java application based on existing knowledge and time span with which to develop the prototype was considered too large a project.

Having identified the requirements and tools used to develop the prototype, a set of specifications were then developed.

Prototype specifications

• Buttons are to be images with clear text. Images allow the use of the HTML alt tag. This will allow descriptive messages to be displayed to the user when hovering over a button in order to aid in website orientation and navigation. This also complies with W3C accessibility guidelines (W3C, 2005).Buttons on the home page will adopt a central position and be the main focus of the user. An additional smaller exit button will be located on the bottom left hand side of the page. On all other pages a button for returning to the main page will be located on the bottom left hand side.

 

• All text throughout the site will use a clear, large font (Arial). The font colour will be black and high contrast with the white background, maximising visibility and highlighting important text. This specification is supported by the United States government research-based web design and usability guidelines paper (U.S. Department of Health & Human Services, p. 101).

 

• A Windows media audio file will be embedded into each training page. This will start automatically and take a central position on the screen. The embedded file will have controls that the user can interact with in order to control the media being played.   

 

• Text documents will be displayed in a new window when the text link is selected. This functionality will be implemented through Javascript.    

During the evaluation phase of this project the specifications were measured using a rating scale produce quantative data (Appendix D).

Prototype design and implementation

The prototype was designed by developing a website map and a series of story boards seen in (Appendix A) according to the identified non-functional, functional requirements and specifications identified within the body of this report. An alternative design was also developed (Appendix B) however on reflection was discounted as it was felt the position of the button links detracted from the central focus of the learning material. The prototype was then implemented based on the documentation produced and is located at the following location:

http://webpagelocation.ac.uk

Evaluation of the prototype came in two forms. The first evaluation was based on the ten usability heuristics identified by (Nielsen, 2005) (Appendix C). Overall the prototype met the usability heuristics criteria, in some cases such as matching the prototype and the real world environment it was intended to be used was considered to strongly meet the criteria, based on the level of learning material and environment it was presented in.

Evaluation

 

There was a problem regarding the positioning of links, however a solution to this was found. This is discussed in further detail within the evaluation (Appendix C). Another feature that strongly met the criteria of the evaluation was error prevention. The system was developed to limit the possibility of error occurring by presenting the user with limited functionality. The user could not change system settings or inadvertently interact with the prototype in an unexpected manner. There were some areas for improvement identified whilst carrying out the evaluation. Flexibility and efficiency of use were deemed to fail the criteria during the evaluation as there was no differentiation for the competency level of the users. This issue would be addressed in future versions of the prototype by incorporating a set of advanced features for experienced users such as follow up tests to further consolidate more advanced aspects of the training material.   

The second part of the prototype evaluation was based on rating how well the prototype met the identified specifications earlier in the report through the use of a rating scale (Appendix D). On analysis of the quantative data it was concluded that the prototype fully met all but one of the identified specifications. Sometimes there was a delay in training media being played when users viewed a page. It was presumed that this delay was a result of the media file size. The file size was compressed and this successfully reduced the delay, however it did not completely resolve the issue falling outside the recommended maximum eight second page rendering delay (Keynote NetMechanic, 2010) by up to 22 seconds. Two possible solutions for further reducing media playing delay may be further compressing the media, or splitting the media into smaller parts.     

 

Overall the prototype met the ten usability heuristics identified by (Nielsen, 2005), the intended requirements and specifications; however room for improvement was identified. The project followed a structured approach to developing a usable and interactive system, whilst closely following Jesse James Garrett’s model of website development and its five elements (Benyon, 2010, pp. 386-387) (Appendix E). Without having followed a structured approach the likely hood of the prototype meeting the evaluation criteria would have been considerably reduced.

A Brief Overview of Expert Systems

Having discussed information system development in the context of an internship to help develop a system to support collaberative buying in my last post. I thought that a brief overview of expert systems to support knowledge managment would be a suitable subject to address next. 

So what are Expert Systems?

“An expert system is a computer program that uses knowledge, facts, and reasoning techniques to solve problems or aid in making decisions.”

For this short discussion knowledge will be defined as: “knowledge derived from information by integrating information with existing knowledge”.

Expert systems are a branch of artificial intelligence (AI) that emerged in the 1970’s. They attempt to mimic human expertise by applying inference methods to a specific body of knowledge to aid in decision support or problem solving within a specific problem domain. Just as importantly expert systems can show how they came to their conclusion.

Key features of an expert system

Image 1.1 (model of an expert system)

A typical expert system consists of a series of smaller systems.

The knowledge acquisition system

This system used to gather the knowledge and rules used to solve the problems that the expert system is being used for. This can be done through a variety of methods such as:

• Direct input by expert or knowledge engineer.

• By analysing a database of past case studies and their results using machine learning techniques or case-based reasoning.

The knowledge base “not” a data base

The store of knowledge and rules about the specific problem domain the expert system is being used for.

The Inference engine

This is the control system that implements the knowledge and rules held within the knowledge base. Think of it as using IF, AND, THEN statements but with knowledge. There are a variety of different techniques can be employed in order for the inference engine to come to a conclusion / suggestion, however the technique used is dependent on the specific problem domain:

· Probability weighting

· Forward chaining (starting at the beginning and working towards a conclusion)

· Backward chaining (starting at the result and working backwards to a cause)

The model illustrated in figure 1.1 identifies two methods of interacting with the expert systems. Through a user interface or by direct data input (e.g. sensors in a factory).

Expert systems in context

So now the scene has been set, what is the “real world” applications, advantages/ disadvantages and ethical issues of expert systems?

Expert system applications: Medicine

MYCIN

A prime area for expert systems to be used is in Medicine for diagnosis of ailments. If you search for Expert systems on the internet you will almost certainly come across MYCIN. This was one of the first expert systems and some may say one of the most well known. Developed in the 1970’s at Stanford University it was used to diagnose blood disorders and recommend the correct antibiotics for treatment through the use of forward chaining techniques. http://www.macs.hw.ac.uk/~alison/ai3notes/section2_5_5.html Another medical expert system currently used within the United Kingdom is NHS Direct online http://www.nhs24.com/content/default.asp.

Expert system applications: Industry

PROSPECTOR

As you can imagine industry such as mining make massive investments on land and mining rights in order to find ore, so any kind of advantage determining the correct place to mine would make massive cost savings. Imagine buying all the land shown in figure 1.2 and finding out that you should have bought the plot 500 yards to the right. In 1980, an expert system called Prospector was used successfully used to assist geologists in analysing geological data from a site near Mount Tolman in eastern Washington (USA) for molybdenum (an ore). Subsequent drilling by a mining company confirmed the prediction http://library.thinkquest.org/11534/expert.htm.

Figure 1.2 (image of mining activity)

Why would management be interested in an expert system?

Well let’s have a look:

• How can a business retain knowledge? By storing it in some sort of system!

• An expert system is not just limited to a single expert adding to the knowledge base

• An expert system can work 24/7 356 days a year and stay consistent throughout

• As discussed before, expert systems can be interrogated to show how they came to their conclusion

• We are all aware of the speed advantages computers have over humans in problem solving (Met office computers)

• Leverage specialised skills – It doesn’t take an expert to use one and get a answer / decision from an expert system

• Over time an expert system can save a lot of money in wages and problem solving

Expert systems are brilliant!

Question… Why aren’t they being used for everything?

• Expert systems are limited to a very specific problem domain

• They have no common sense in decision making

• They cannot make creative decisions in unusual circumstances

• The experts cannot always explain their logic or reasoning (miss communication with knowledge engineer) GIGO (garbage in garbage out)

• Errors / conflicts can occur within the knowledge base

• Expert systems cannot adapt to changes in practice unless the knowledge base is updated

Legal implications of using an expert system

What happens if something goes wrong? Who is to blame?

· The Expert System user?

· The Expert?

· The Knowledge engineer?

· The developers / programmers of the ES?

· The company who sold the system?

It depends how the software is classified

Is the expert system a product?

Product liability laws will be imposed.

Is the expert system a service?

Professional misconduct laws could be imposed.

Ethical Issues

In addition to the legal aspects surrounding liability of something goes wrong; there are a multitude of ethical issues that rise from using expert systems.

Medical Ethics

In addition to the above expert systems are unable to replicate empathy, this is essential in a medical environment, for example where a 50:50 outcome is predicted.

Industrial Ethics

Using the PROSPECTOR expert system as an example, would it be ethical to mine in a place of special scientific interest or natural beauty?

Why not try an expert system yourself!

To further support this text, if you wish to explore the theories discussed in further detail I have provided you with these links where you can have a go!

Dog expert system

Choose a dog, decides on your ideal type of dog based on weighting of the answers you give and supplies you with the logic behind its reasoning.

http://www.exsys.com/Demos/Dogs/DogTitle.html

NHS Direct

B e a hypochondriac for a few minuets and have a go of the self diagnosis system on NHS Direct

http://www.nhsdirect.nhs.uk/en/CheckSymptoms

The development of an information system to facilitate collaborative buying

Introduction

Brief overview of scenario

In order to gain further software development experience during postgraduate studies, contact was made contact with the Chester University careers department and a placement organised. A placement was allocated with a free lance web developer. The project allocated by the web developer consisted of developing a social shopping website to a minimum viable product (MVP) level. Some of the pre requisites of the website were to integrate Facebook, Twitter and real time messaging. It was intended that the website offered bulk buy discounts which customers can group together and buy. The social media integrated within the website intended to give users the ability to discuss and encourage others to add the product to their shopping cart. When the required amount of customers added the product to their cart, meeting the discount criteria, the product value was then debited and an order is placed through the website to the retailers. If a product was not available on the website a wish list could be utilised customer notified when the item became available on the website. This concept was similar to other group buying websites such as Groupon and TipToken. However instead of daily deals been offered, customers could choose the products they want.

The assignment

This report aims not discuss technical development of the placement project, but the considerations that should be taken into account in developing such a system. An information system is described by (Beynon-Davies, 2002, p. 4) as

“… a system of communication between people. Information systems are systems involved in the gathering, processing, distribution and use of information. Information systems support human activity systems.”

A comparison of the placement project description and Beynon-Davies description of an information system strongly indicates that the placement project was an information system development project. To successfully meet the objectives of the work placement by developing an effective information system, the informatics model described by (Beynon-Davies, 2002, p. 3) would be used as a reference template. Figure 1.1

Figure 1.1 The Informatics Model. Taken from (Beynon-Davies, 2002, p. 3)

Three key factors influencing the development of such an Information System will be focused on during the report (Retailers, customers and Social media). In addition to this the direction that ecommerce could potentially take over the next three to five years was discussed. This discussion was based on the views and opinions of professionals within the field of ecommerce and payment gateways, made during a technology seminar at the Daresbury Science and Innovation Campus during December 2010.

Key influences in the new information system development, an overview

Retailers and Consumers

It would be fair to say that a number of retailers have realised the advantages available in ecommerce over the last decade, twenty four hour consumer access and being able to extend business activities globally, rather than being restricted by geographical location being but some of the advantages (Kendall, 1992). Retailers can also benefit from adopting ecommerce through increased trade, and improvement/ transformation of their business processes (Office for National Statistics, 2008). The advantages of product purchasing, research and comparison that ecommerce can bring from any location with an internet connection has also been embraced by consumers (Chan, Lee, Dillon, & Chang, 2001). During 2010 an estimated £100 billion pounds worth of sales accounting for 7.2% of the United Kingdoms (UK) gross domestic product (British Broadcasting Corporation, 2010) was through ecommerce. Data gathered by (Interactive Retail Media Group, 2010) also identified an estimated online sales growth rate of 13% during 2010. These figures may be in part influenced by the current economic climate; however it does highlight the current prevalence of ecommerce in the United Kingdom and identifies the market that the new information system would be operating in.

Social Media

Social media information systems support group human interaction. In the context of this report social media information systems are best defined in text by (Clicky Media, 2010)

“…user-generated content that allows users to share, discuss and participate the conversation. It also allows people or businesses to become both readers and publishers of content. ”

In essence this statement identifies the key role of social media being communication between users. This communication can take a number of forms such as text, images, videos and audio (Clicky Media, 2010). Of a top twenty list of most frequently visited websites for the week ending 08^th January 2011 produced by (Hitwise Pty. Ltd., 2011) Facebook, YouTube and Windows live mail were identified within the top 5 with Google in first place. This popularity is not just limited to the United Kingdom but spans the globe, highlight by sources such as (Qualman, 2009). In fact a brief Google search for “Social Media” returns 722,000,000 results comparable with 425,000,000 results for the search term “God”.

Collaborative consumption

During a series of presentations held by Technology, entertainment, design (TED) in Sydney, (Botsman, 2010) discussed the subject of collaborative and sharing through the use of network technologies, how it may change business and consumerism. During the discussion a move from 20^th century hyper consumption to 21^st century collaborative consumption was identified. Based on personal observations and reflection of social media such as Facebook and Twitter this argument could be considered true. The reasons in part for this recent change in consumption have been identified as pressures from four different sources:

• The renewed belief in community
• A torrent of peer to peer networks and real time technologies
• Pressuring unresolved environmental concerns
• A global recession that has shocked consumer behaviour

List taken and adapted from (Botsman, 2010)

During the speech by (Botsman) three types of collaborative consumption systems were also identified based on a series of case studies:

• Redistribution markets (Reusing items)
• Collaborative life styles (Sharing resources, money and time)
• Product service systems (Paying for benefits of a product without owning it outright)

In a recent research report (Fetherstonhaugh, 2010) argues that businesses/ retailers have not yet fully adapted the new “infosphere” of social media. Traditional face to face high street sales processes are similar to the process identified in figure 1.2.

Figure 1.2 the sales process model. Taken from: (Better Sales and Selling, 2009)

(Fetherstonhaugh) suggested a six point guide for businesses/ retailers as a guide to changing their business/ sales models:

• Adapt to the new buyer journey
• Use online content as digital bait
• Develop new listening skills (digital footprints)
• Future proof marketing skills with behavioural economics
• Learn a new way to sell: Social selling
• Sales and marketing as partners not opponents

List taken and adapted from (Fetherstonhaugh, 2010)

Featherstonhaugh identified a new framework within the report for businesses/ retailers to incorporate, based on the six point guide. See figure 1.3.

Figure 1.3 taken from (Fetherstonhaugh, Speed Summary | OgilvyOne Report on The Future of [Social] Selling, 2010)

These two arguments suggest that there was a shift in consumer consumption taking place during the writing of this report. Businesses and retailers were in a process of adapting to the changes in consumer orientation; however they still needed to adapt their information systems and business/ sales models on order to take advantage of the opportunities presented.

Information system planning and development

The development of an information system to meet the criteria of the assigned placement project should take the above discussions into consideration. This would ensure current and relevant issues from professionals within the field of social media and ecommerce are taken into account during the information system development. Since the orientation of consumer consumption is arguably still taking place, an information system addressing the issues highlighted by Fetherstonhaugh’s guide would produce a level of future proofing, assuming that the consumer orientation continues to follow the same direction.

There are various system analysis and design methods and techniques which could be incorporated into the development of the new placement information system. During a recent literature review of two articles sourced from “Information system journal”, Work by (Chiasson, Germonprez, & Mathiassen, 2008) entitled “Pluralist action research: a review of the information systems literature” discussed an exploration and findings into how Information Systems researchers practice action research (AR), through the review of a sample of journal articles published between 1982 and 2005. The second article by (Cordoba, 2008) entitled “Critical reflection in planning information systems: a contribution from critical systems thinking”. Presented, tested and drew conclusions on a framework for information system planning based on inspiration from Critical System Thinking (CST). CST takes critical awareness, emancipation and methodical pluralism into consideration during the development of social systems.

Both articles made use of literature resources in order to support their arguments. The articles argued that a mixed approach to information system development was a valid method. This is further supported in work by (Moon & Moon, 2004). However the articles did have different approaches in coming to this conclusion. Since both articles were credible, supported by a wide variety of references and case studies it would be reasonable to conclude that either approach could be used. On reflection the correct method should be based on the scenario and context of the information system. During further reading (Dennis, Wixom, & Roth, 2006) discussed Rapid Application Development (RAD). RAD was a system development methodology established in the 1990’s to overcome limitations experienced in structured design methodology (Dennis, Wixom, & Roth, 2006, p. 12). This methodology was identified as being suitable for the development of the work placement information system, due to the sometimes unclear expectations of requirements (must have and would like features) whilst taking into account the development time frame. See figure 1.4 for a comparison of development methodologies.

Figure 1.4 taken from (Dennis, Wixom, & Roth, 2006, p. 18)

The form of RAD suggested to the placement sponsor was prototyping, this iterative development technique focuses on key must have features first, with the development of would like features during later iterations and feedback. Figure 1.5

Figure 1.5 taken from (Dennis, Wixom, & Roth, 2006, p. 14)

The work placement sponsor was open to the suggestion of development methodology. Due to the social nature of the information system being developed, a mixed approach was suggested taking into account CST discussed by (Cordoba, 2008). In particular the opinions and awareness of the information system users were taken into account. A blog developed by (Court & Georgeson, 2011) along with notifications produced using social networks were used in order to encourage feedback and discussion in order to determine customer understanding of the proposed information system under development.

Information system issues

Further discussions were held in development meetings with the workplace sponsor. A major concern identified and discussed was data security and how to safely handle/ store electronic customer data, in particular sale transaction data. This concern had to be addressed and the solution incorporated into the proposed information system infrastructure from the outset.

Electronic data laws, their implications and effect on information system infrastructure

Hugh Jenkins (Enterprise marketing director for Dell UK) discussed the subject of electronic data laws and their impact on information system infrastructure in an online article for (BCS, 2011). Hugh Jenkins acknowledged that UK businesses can find electronic data laws and their legal requirements a “… challenging and expensive task” and that businesses and organisations based in the UK must ensure all trade, transaction and accounting data is accountable for auditing purposes. Some of the data handling laws currently governing UK based business are listed below:

• FE Strategic Review
• Data Protection Act 1998
• Freedom of Information Act 2000
• Intellectual Property Rights (Copyright)
• Electronic Communications Act
• Regulation of Investigatory Powers Act
• The Electronic Commerce Directive
• Sarbanes Oxley Act
• International Financial Reporting Standards
• Basel II

List taken from (In-Form Consult, 2004)

The ramification of this was described as business IT infrastructure must now be able to store data over long periods, keep it secure in its original format and be easily recoverable. Failure in doing so can result in litigation and criminal penalties. Data can have a high value to criminals through fraud. This was highlighted in a BBC news report (British Broadcasting Corporation, 2007) where two computer discs containing unencrypted details of 25 million people from the child benefit database were lost in transit between HM Revenue and Customs and the National Audit Office. The estimated value of the data to criminals was £1.5 billion. Based on the results of Dell UK’s research Hugh Jenkins stated that one tenth of annual technology budgets in UK businesses were spent on legislation compliance during 2006.

What are the implications for the proposed information system

It can clearly be seen based on Hugh Jenkins comments to BCS that the implications of electronic data laws can be major concern for all UK businesses. After a period of reflection of possible solutions within the development of the work placement information system, it was concluded that the integration of existing industry recognised and compliant information systems would be a practical secure solution addressing the problem of data security. Implementing Amazon web services for storing databases would ensure a stable, scalable and secure (ISO 2700 certified) data storage service (Amazon Web Services, 2010). Another suggestion made was to implement the PayPal third party payment gateway service for handling and storing customer transaction data through use of an Application Programming Interface (API). The way in which the API is incorporated into an information system does depend on the information system requirements; however the overall generic process is identified in figure 1.6.

Figure 1.6 Image taken from: (Web Merchant Services Ltd, 1997)

The proposed suggestions for handling and storing sensitive electronic data was agreed on as being suitable, lower risk solution for the proposed information system by the work placement sponsor, compared with the alternative of developing an “in house solution” taking liability for any instances of data security breaches.

Information system management

In addition to managing the work placement information system development considerations already identified within this report three, other management considerations also needed to be addressed.

• Information management – General planning, regulation and coordination of information policies within the organisation
• Information systems management – Planning, execution and operation of information handling applications
• Information Technology management – Maintenance of the organisation infrastructure

List Taken and adapted from (Beynon-Davies, 2002, p. 433)

In essence information management can be described as the ability to capture, manage, preserve, store and deliver the right information to the right individuals at the right time (Association for Information and Image Management, 2010).

The work placement undertaken would be considered as a small start up business. The three forms of management relevant to informatics identified by (Beynon-Davies, 2002, p. 432) had not been considered to any great extent. The placement sponsor was approached and the following recommendations were made:

Information Management

To develop and implement a strategy for identifying and organising key data elements used within the business and the relationships between the data.

Information Systems Management

To develop and implement a business policy outlining how information collection, storage, dissemination and use will take place within the business.

Information Technology Management

To develop and implement a framework for maintenance of the existing information system and development of new software and additional infrastructure that supports the business information system.

Benefits of adhering to the proposed suggestions through all levels of the business from directors to employees would be acknowledging and retaining relevant information as a corporate asset. Identifying and organising information by business and department need, making the information available to the relevant individuals, development of an information organisation, retention and archiving. Recognising these benefits would aid in the development of a business continuity policy (Association for Information and Image Management, 2010). Potential problems that may arise from ignoring the suggestions could be, decentralisation of data within the business, leading to increased chances of data loss and misplacement. Poor data storage and archiving policies leading to lowered business efficiency and being unable to successfully comply with auditing and electronic data laws discussed earlier within the report.

Opinions of professionals within the field

During the work placement an opportunity arose to attend a conference from professionals within the ecommerce industry. The presentations were held at the Daresbury technology and innovation centre on the 13th December 2010 organised on the behalf of Techelerate (Ranaweera, 2010). The presentations were considered as an excellent opportunity to gain further understanding about the direction that ecommerce information systems were viewed as potentially taking over the next 3-5 years.

Three representatives from the mobile phone and payment gateway fraternities were sourced to take part in the presentations:

• Keith Curran – Yes Telecom (sold to Vodafone)
• John Lunn – PayPal, Head of Platform and Integration
• Paul Johnson – Founder & CEO – MPP Global Solutions

Each presenter “cloud” and identified the current influence and power of smart phones such as the Apple I phone, Blackberry and Google Android phones in modern society. These points coupled with John Lunn’s interesting examples of PayPal concept systems, did indeed make a very compelling argument for the eventual decline of the wallets in our pocket. John Lunn also gave the example of a trial PayPal system in the United States of America that allowed customers to purchase Costa Coffee via mobile phones. John Lunn discussed a recent PayPal survey to highlight the impact of mobile technology information systems on society, the question was posed “If you had to leave your house for 24 hours and could only take one of these three items (wallet, keys or mobile phone) which item would you take?” 60% of individuals said they would take the mobile phone.

All presenters supported the argument of the eventual decline and obsolescence of the wallet as we currently know it. However based on example of United Kingdom banking system phasing out the out of the cheque book as an example, this prediction may not happen immediately. This may be because successful management of change requires five key phases to be addressed:

• Awareness of the need to change
• Desire to participate and support the change
• Knowledge of how to change (and what the change looks like)
• Ability to implement the change on a day-to-day basis
• Reinforcement to keep the change in place

List taken from (Change Management Learning Center, 2007)

The five phases identified are based on the ADKAR model published by Prosci in 1999. Figure 1.7

Figure 1.7 Taken from (Change Management Learning Center, 2007)

It is suggested that based on the principle of the ADKAR model that change can take place in two dimensions. The business dimension and the people dimension. Successful change requires simultaneous change to take place in both dimensions (Change Management Learning Center, 2007). Figure 1.8

Figure 1.8 Taken from (Change Management Learning Center, 2007)

The guest speakers however predicted that around 60% of all mobile phone users would be using smart phones within the next two years, equating to 3-5 years in their opinion before the wallet becomes obsolete.

The guest speakers envisaged that large retailers such as Tesco’s, Marks & Spencer’s and Sainsbury’s may start their own banks (they have all currently branched out into finance and insurance (Tesco Personal Finance plc, 2010) ). It was suggested that customers wages could be paid directly to the afore mentioned banks, a widget on a smart phone could then be used to purchase food, clothes, entertainment and of course shopping which could be delivered to the home. An interesting concept and one that doesn’t seem to be outside the realms of possibility the technology exists and many of the information systems required are already in place. An example of this would be that some smart phones have the ability to read barcodes and search the internet for item descriptions. One of the large retailers mentioned (Tesco) has already used its databases alongside a publically available mobile phone application to add items to an online shopping cart. This service is currently being marketed on UK television.

On reflection it seems as though the people dimension and the five key phases identified as an influencing factor within the ADKAR model may be in part a reason that consumers have not yet fully embraced mobile ecommerce. (Botsman, 2010) And (Fetherstonhaugh, 2010) both suggest there may be a shift taking place during the writing of this report from high street retailers to collaborative ecommerce. Mobile ecommerce could be viewed as the next phase of evolution from this point however it may take a period of time before consumers adapt to the new changes within the information systems. All presenters at the Techelerate conference admitted that consumers trust in mobile security was a contributing factor to the delay in the changes, and that finding a balance between ease of use and security was currently an point of discussion in the mobile payment industry.

Summery

The report was based on a work placement organise through the University of Chester careers department. The placement consisted of planning and developing an information system that facilitated human interaction in order to the goal of group purchasing products at a discounted price. In order to meet the placement objectives research was undertaken into understanding the current environment the information system would be placed in. Three external factors that would directly influence the information system (Retailers, customers and Social media) were identified and researched. An informatics model identified by (Beynon-Davies, 2002, p. 12) was used a template to base the information system development around. A selection of views and opinions were taken into consideration for determining the appropriate methods to apply in the information system development. RAD in the form of prototyping and CST were chosen as the most appropriate methods of development. Electronic data laws were considered as a potential issue surrounding the systems development and a solution to this problem was found in the form of integrating API’s and secure data storage solutions into the system to handle sensitive data. Information management was also taken into consideration and a set of recommendations were made to the placement sponsor, highlighting potential benefits and possible repercussions of not taking appropriate courses of action. An opportunity arose to attend a conference in which industry professionals were discussing ecommerce and the potential future of mobile commerce and how it may take place. A hesitation in consumer acceptance was identified during the presentations. This consumer hesitance was compared with the ADKAR model to better understand possible causes.

Conclusion

Through out the work placement project, observation and research into current issues governing human activity aided in placing the analysis and development of the information system into a more informed context. This allowed for an appropriate development method to be identified and applied to the information system. (Chiasson, Germonprez, & Mathiassen, 2008) and (Cordoba, 2008) both presented arguments for mixed method approaches in information system development. The facts presented within their discussions facilitated the development of a mixed method approach using RAD and CST to be appropriately applied to the information system. The information system was under development using the mixed method approach during the writing of this report. Feedback from key stakeholders suggested the development methodology was meeting the requirements of the project and they were please with the progression of the project. Through researching a wide selection of sources, a shift in consumer orientation was identified from ecommerce to collaborative consumer ecommerce. This is supported by arguments presented by (Botsman, 2010) and (Fetherstonhaugh, 2010). Based on discussions form the “Wallet in the cloud conference” organised through (Ranaweera, 2010) the direction that mobile payment information systems may take in the future was discussed. However an element of reluctance by consumers to embrace the technology was identified, possibly due to the five key phases of ADKAR model not being fully realised by consumers.

Wallets in the cloud

Wallets in the cloud and the impending lack of them in the physical world was the main subject at the December 2010 Techelerate workshop held at the Daresbury technology and innovation centre on Monday.

Three representatives from the mobile phone and payment gateway fraternities:

• Keith Curran – Yes Telecom (sold to Vodafone)
• John Lunn – PayPal, Head of Platform and Integration
• Paul Johnson – Founder & CEO – MPP Global Solutions

Took their places in the lecture theatre and one by one discussed the cloud. Identified the current  influence and power of smartphones such as the Apple I phone, Blackberry and Google Android phones in modern society. These points coupled with John Lunn’s interesting examples of PayPal concept systems, did indeed make a very compelling argument for the death of the wallet in our pocket. Did you know that during a recent survey the question was asked “If you had to leave your house for 24 hours and could only take one of these three item (wallet, keys or mobile phone) which item would you take?” 60% of people said they would take the mobile phone.

So when is going all going to happen? In my opinion taking the phasing out of the cheque book in the UK into consideration quite a while. We are all creatures of habit and habits can sometimes be hard to break. The guest speakers however predicted that around 60% of all mobile phone users would be using smart phones within the next couple of years equating to 3-5 years in their opinion before the wallet starts to die out.

So how do they, the guest speakers and the companies they work for, predict it is all going to happen? Well it’s envisaged large institutions such as Tesco’s, Marks & Spencer’s and Sainsbury’s for example, owning their own bank (they have all currently branched out into finance and insurance). Your wages could be paid directly to them, a widget on your smart phone could then be used to purchase food, clothes, entertainment and of course your shopping which could be delivered to your house. An interesting concept and one that doesn’t seem to be outside the realms of  possibility. The technology definitely exists already.

So why has it not happened all ready? It can be argued that it is happening right now! Some smart phones have the ability to read barcodes and search the internet for item descriptions. One of the institutions mentioned (Tesco) has already used it’s databases along side a publically available mobile phone application to add items to a shopping cart. This service is currently being marketed on UK television. But what about the other institutions? It seems as though social factors may be the main influence at the moment. Consumer habits are changing, evidenced by the recent surge in ecommerce over the last decade. However there’s still a way to go before mobile phone commerce is trusted as a legitimate way of purchasing goods. So maybe the other retailers are watching Tesco to see what happens before jumping on the bandwagon?  

3-5 years until the wallet as we know it dies out? Probably not in my opinion. Will they die out? I think so. 

A Web aid to help understand key concepts of object-orientated programming

Abstract:

This dissertation aimed to develop a dynamic content managed website that could be used as an aid to help the understanding of Object-Orientated programming concepts, based on data gathered from a sample of students and lecturers at Chester University.  In order to achieve this aim a comparison and evaluation of current solutions to web aids for Object Orientated Programming was undertaken.  In addition quantative and qualitive data was collected and analysed to determine website content.

Based on the data analysed and reflection of the tasks undertaken, an appropriate solution was designed emulating principles encountered within research of adaptive hypermedia systems. Through design and implementation of a prototype system a greater awareness was gained into the challenges faced by developers of modern software systems.

To read this report in full please leave a comment including you contact details and reason for interest.