-
WAP Push – This service allows content to be sent or "pushed" to devices by server-based applications via a Push Proxy. This functionality has been enhanced for the WAP 2.0 release. Push functionality is especially relevant to real-time applications that send notifications to their users, such as messaging, stock price and traffic update alerts. Without push functionality, these types of applications would require the devices to poll
application servers for new information or status. In wireless environments such polling activities would constitute inefficient and wasteful use of the resources of wireless networks. WAP's Push functionality provides control over the lifetime of pushed messages, store & forward capabilities at the Push Proxy and control over
bearer choice for delivery.
-
User Agent Profile (UAProf) – This service provides a mechanism for describing the capabilities of clients and the preferences of users to an application server. Enhanced for WAP 2.0 release, it is based on the Composite Capabilities / Preference Profiles (CC/PP) work of the W3C, UAProf supports the client-server transaction model by sending client and user information to servers with the request. This information permits the servers
to adapt their content accordingly in preparation for the response. This service model would also permit intervening proxies to provide value-added services by providing these adaptation services directly.
Recognizing the importance of user's privacy, personal information submitted in these requests may be controlled by the user.
-
Wireless Telephony Application (WTA) – This service provides tools that provide for a range of advanced telephony applications to be operated from within the application environment that traditionally supports data functionality. These call handling services, such as making calls, answering them, placing them on hold and redirecting them, can be seamlessly combined with other data services. This truly permits WAPWTA enabled
cell phones to be viewed as fully integrated Internet and voice service platforms.
-
External Functionality Interface (EFI) – This service specifies the interface between WAE and components or entities with embedded applications that execute outside of the defined WAE capabilities. This is analogous to providing a plug-in module, which extends or enhances the capabilities of browsers or other applications. The
EFI framework provides for future growth and extendibility of supported WAP devices. This framework can be used to define the specific interfaces needed for accessing external devices (e.g. smart cards, GPS devices, health care devices and digital cameras).
-
Persistent Storage Interface – This capability specifies a standard set of storage services that are coupled with a well-defined interface for organizing, accessing, storing and retrieving data on the wireless device or other connected memory device.
-
Data Synchronization – In an approach that helps to ensure a common solution framework, the WAP Forum sought out a solution for data synchronization. As a result, WAP 2.0 acknowledges the work of the SyncML initiative by adopting the SyncML language as its choice for the data synchronization solution. The SyncML messages are supported over both the WSP and HTTP/1.1 protocols. See www.syncml.org for more
information.
-
Multimedia Messaging Service (MMS) – This service provides the framework to implement a feature-rich messaging solution. MMS provides features and functionality that permits delivery of varied types of content. Depending on the service model, MMS permits a quick delivery paradigm (like SMS) or a store-and-forward approach (like email) or could permit both modes to operate. This flexibility permits users and operators to tailor the resulting user experience. By using other WAP services, like Push and UAProf, MMS provides an efficient messaging solution that is capable of providing message notifications which initiate adaptation services to structure the delivered content into a form that is efficiently used by the receiving device.
-
Provisioning – This service provides a standard approach to providing WAP clients with information needed to operate on the wireless networks. This permits the network operator to manage the devices on its network using a common set of tools.
-
Pictogram – This service permits the use of tiny images, such as this smiling sun , in a consistent fashion. Such images can be used to quickly convey concepts that permit efficient communication in a small amount of space. Such communication can transcend traditional language boundaries.
The following section will introduce us and illuminates on Banking related sections.
CHAPTER 2
BANKING
The key feature of designing and implementing this kind of system is its architecture.
Effective implementation of the architecture gives the system the scalability and flexibility to add further information sources and distribution channels efficiently, as and when they become available.
Figure 7 Architecture Diagram (Gulliver)
Retail Banking
The attributes that typically classify the deployment of retail, WAP-based, financial applications include:
-
Large numbers of end users – the potential user base for retail banks and stockbrokers is large
-
A large number of differing terminals - because the typical retail institution does not directly offer mobile handsets to its customers in order to access the service, it can expect that it will need to support a variety of different devices
-
Relatively non-technical users – this means that the service being offered needs to be easy to operate and access. The operation of WAP banking services is relatively straightforward – assuming good WAP design principles are maintained – and there should be minimum requirements upon the end users to reconfigure their handsets to access the service.
-
High volume transactions with low individual values. As is typical in retail environment, the amount of capital at risk when conducting an individual transaction is low, but there are large numbers of transactions being executed.
-
The ability of financial institution to reach its customers is enhanced by using the portals of the mobile operators, as it greatly reduces the amount of independent branding required to alert the audience to the service.
Financial Institution Concerns
When a financial institution takes the decision to implement a multi-channel service, there are a number of initial concerns that must be looked at seriously.
Security
Security of information is the primary concern of any financial institution when deploying its applications across the wireless devices. Deploying a solution across multiple distribution channels causes its own problems. More often than not, there are different sets of security technologies on the different distribution channels. These available technologies must be investigated and a security strategy drawn up.
The security Strategy used by the financial institution is of utmost importance—
Every service that is delivered over an electronic medium has to associate risk.
The key to a successful strategy must be to determine the acceptable level of risk for the service.
Investment in the Future
Financial institutions that recognize the importance of delivering their financial services across multiple distribution channels will need to be confident in the technologies that they are using. By choosing the right technologies ,it makes it easier to deploy the new services, and to take advantage of new distribution channels as they become available.
Functionally Rich Application
The financial institution will want to deliver as much functionality as possible to its customers. The functionality that will be delivered is dependent upon multiple issues.
All of these concerns must be weighed up , and a balance between them decided upon.
Technical Concerns
When setting out to implement a mobile-based banking application, there are a number of immediate technical problems that need to be overcome.
Multiple Sources of Information
In a typical deployment, there is more than one back-end application to interface with (for example, a banking mainframe database). These applications usually reside on different platforms, and provide their content in different formats. Because of this, when developing a distribution and transactional system, apiece of middleware is required that will facilitate the consolidation of information into a standard format thereby allowing for the extraction of tat information in a uniform way from multiple channels.
Multiple Distribution Channels
-
Cross Compatibility in WAP devices the problem with delivering information to multiple WAP devices is that each device has its own capabilities , such as display , security, configuration, and so on.
-
Security how we create a security policy tat can be extended to multiple different distribution channels with the technologies that are currently available
Middleware
When we were deciding on a middleware solution, there were a number of different areas that were covered:
- Data representation
- Data distribution
- Data manipulation
Data Representation
A generic architecture requires a generic data representation. The solution to this problem is the Extensible Markup Language (XML). The Purpose of XML (and its related technologies) is to provide a means of describing information generically, which facilitates easy machine manipulation and rendering. XML is portable data.
Testing / Deploying the Solution
We recommend that any financial institution currently looking to deploy a secure financial service over WAP environment have two environments: Deployment and Test/Back up. The deployment environment is self-evident, but the use of a test/backup environment is prudent in the current climate for a number of reasons. Not all mobile operators support WTLS, so they’re not able to support secure delivery of banking services using their own WAP systems. Providing an environment that supports banking irrespective of current mobile operator facilities is an important ability. Independence from operators . Because use of the operator’s WAP gateway is an essential part of the financial institution’s m-commerce offering, it is important that an element of independence is possible. An existing application may become non-operational due to a change in the mobile operator’s configuration. A separate configuration will allow backup service. New Services. With separate facility it is possible to try new services with closed user groups, without having to ensure that the service works successfully with all the operators in the financial institution’s area of operation.
Direct Debit
What is Direct Debit?
Direct Debit is the simplest way for organisations to collect regular or occasional payments from their customers- both business and consumer. It saves time reduces the costs of collections and puts cleared funds directly into their bank account.
A Direct Debit is an instruction from a customer to their bank or building society authorising an organisation to collect varying amounts from their account, as long as the customer has been given advance notice of the collection amounts and dates. 44% of the adult population actively prefer to pay their bills by Direct Debit. More than two thirds of the UK adult population have at least on Direct Debit. Around 16,000 organizations use Direct Debits for collecting a variety of regular and occasional bills including utility payments, insurance, council tax, mortgages, loans and subscriptions.
Direct Debit Customer Benefits
Direct Debit is the preferred payment method for over 44% of the bill paying population because it provides so many advantages:
Bills can be budgeted for more effectively by spreading the load across the year.
Peace of mind of knowing bills are being paid automatically and payment dates will not be missed.
Apart from eliminating the expense of mailing cheques, there are many Direct Debit discounts available.
No more trips to the high street and queuing up to pay bills. Many organisations offer a choice of payment dates giving you the convenience of choosing a date that suits you best.
The reassurance of knowing that every Direct Debit is protected by three main safeguards: an immediate money back guarantee from the bank or building society if an error is made, advance notice from the organisation if the date or the amount of the Direct Debit changes and ultimately, the right to cancel.
What’s left is available to spend
Paying regular by Direct Debit means it is easy to see what disposable income is left to spend after all other commitments have been met.
This is what you have to do if u don’t setup your direct debit by WAP.
- Step 1 – Contact the organisation you wish to pay
In order to set up a Direct Debit first contact the organisation you wish to pay. They will ask you to complete a Direct Debit Instruction. This may be posted to you, or alternatively, some organisations can set up the Direct Debit Instructions over the telephone or via the internet.
- Step 2 – Complete the Direct Debit Instruction
You will need the following information to complete your Direct Debit Instruction.
Name and address of your bank or building society
The name(s) of the account holder(s)
Your Bank or building society account number
The branch sort code (see your cheque book)
Ensure that all the details given are correct and (in the case of paper Instructions) return it to the organisation.
The organisations will update their payment records and forward the instruction onto your bank or building society. The instruction, to your bank or building society, gives the named organisation authority to collect varying agreed amounts from your bank account on certain dates.
- Step 3 – Check the advance notice details
The organisation will give you advance notice of collection dates and amounts, whether you set up a Direct Debit by the telephone, internet or completing a paper Direct Debit Instruction. Check these details are correct. Should you wish to query any of the details contact the organisation straight away.
Other than making sure you have sufficient funds in your account when the payment is due there is nothing further for you to do. Although, it is a good idea to check your bank statement regularly to ensure that all your Direct Debits are going out as agreed.
Managing Direct Debit on your bank account
As you will now have realised, Direct Debit is by far the easiest way to pay your bills. Managing Direct Debit on your bank account couldn’t be quicker or simpler, all it takes is a few simple checks.
Checklist
- Always check your bank Statement Direct Debits are usually shown with a DD alongside the payment. Make sure the amount and date paid are correct.
- If you are offered a choice of payment dates on a Direct Debit instruction, choose a date after your pay day, so that you can be sure there will be money in your account to cover your bills. That way you won’t become overdrawn
- If you choose to pay your bills at the beginning of the month, you will be able to see clearly what’s left in your account, enabling you to decide how you want to spend the balance.
- You should have been notified in advance of any changes to amounts to be paid or the payment dates (normally 10 working days in advance)
- The Direct Debit Guarantee ensures that, in the unlikely event of a mistake, you will receive a full refund from your bank or building society.
- And because Direct Debit allows you to budget all your bills at a stroke, it could save you a ticking off for forgetting to pay one.
Although this checklist is easy to do imagine u could do that easier, on the move and even from your house or everywhere you are and all this using WAP on your phone.
CHAPTER 3
Methodologies
Soft Systems Methodology
The soft systems methodology was developed in the 1960s by at Lancaster University. This methodology arose out of attempts to apply systems engineering principles ("hard" systems theory) to business problems. Systems engineering emphasizes measurable system objectives and the top down decomposition of systems into subsystems. Advanced views of systems engineering (such as ) show how systems exhibit emergent (unexpected, counterintuitive) behavior because of complex feedback loops among system components. When applying systems engineering to what he came to call "human activity systems" (people working together to achieve something) Checkland found a number of problems. Organization goals (I use "goals" and "objectives" more or less interchangeably) were matters of controversy; in particular most investigators assumed that all members of the organization accepted goals set by top management, but this is usually not the case. Formal methods usually begin with a problem statement; Checkland found that fixing the problem too early made investigators unlikely to see different, possibly more basic, problems. And the method itself restricted what could be found out; if we expect the organization to be describable by the interaction among a number of clearly bounded subsystems then that will happen - we will see in the organization a reflection of our methods. To overcome these problems Checkland eventually proposed the following methodology. As with most methodologies, SSM was derived by summarizing experiences from apparently successful projects done over a number of years. These projects usually involved external consultants advising on fairly high level problems (eg a publisher losing market share, a government agency wondering how it can benefit from new technology). A key feature of SSM is the advice to keep the project vague and wide ranging for as long as possible - don't jump to conclusions, and don't ignore the current situation by concentrating on some utopian future. At times Checkland would probably say that the process is more important than the outcome - just going through SSM will change the organisation, and this will probably include a changed opinion about what problem we were really trying to solve. (SSM is not for high achievers, because a goal is never reached!) It is important to realise that in principle an SSM project is done by the people in the organisation, with the consultant acting as a facilitator. Problem Expression
In Checkland's earlier work this was two phases, problem statement and analysis. The new name indicates that we don't know what problem we are interested in until the analysis is done. It is important in this phase to be as unsystematic as possible. There may be checklists of things to look for, and we will use many analogies from engineering, politics, biology and culture but it is important not to get stuck with one model. The usual creative techniques such as brainstorming will be used.
CATWOE Analysis of Stakeholders Part of the problem expression is working out who are the involved parties. Checkland uses mnemonic CATWOE to describe the human activity and its situation. A certain Transformation (process) is performed in a certain "atmosphere" (Weltanshauung - world view). It is performed for Clients (those who more or less directly benefit - customers - or suffer) by Actors. The activity is ultimately "controlled" or paid for by Owners, and occurs within an Environment. Notice that some of the people categories (actor, client, owner, environment) may overlap. Checkland actually recommends CATWOE analysis as the first step in working out a root definition, but I think it is useful during problem expression. Still, you should avoid doing it too early in case you jump to conclusions about who is "important". If, for example, we were examining a system which landed an aircraft, the transformation would involve getting the aircraft from (say) 100km and 10000m from the airport onto the runway in one piece. The actors would be the pilots (maybe both human and auto), the clients would be the passengers and crew, the owners the owners of the airline, and the environment air traffic controllers, air lanes, traffic conditions and geographic features. The weltanschauung would involve high concern for safety and (for a large aircraft) high technology operations. Notice that the system here is the operational one. If we were inventing or designing a new system the clients may very well be airlines and/or government regulators.
Rich Pictures
Checkland tends to describe his systems with diagrams known as "rich pictures". Some students have commented that this can be any sort of picture, a diagram "without rules". This is exactly the point, though rich pictures do have some distinguishing features. They show the people involved, their stated purposes, and their desires and fears (usually in think bubbles). They show more environmental detail than most diagrams (human activities, like processes, cross organisational boundaries). And they show how interests agree or conflict. Rich pictures are cartoons - they can be funny, sad, political, preferably all at once. You can compare a from with a from (an Australian systems cartoonist).
Figure 8 Rich Picture Example from ()
Figure 9 Rich Picture Example a from (an Australian systems cartoonist)
CATWOE analysis and rich pictures concentrate on the process view. Since SSM is quite concerned with existing systems, Checkland also recommends that we find out about the organization structure and how this interacts with the process. Part of this interaction is the "climate" of the organization (is it efficient, sloppy, democratic, sulky, joyous, ...?). After the problem expression stage SSM participants will see the organization in new ways. They will have a vast collection of "facts" at varying levels of detail, and many "problems", some major and some trivial . (But which are which?)
Root Definition. Now we have to bring it all together. Somehow or other the SSM team has to agree on what it is all about. What is the human activity on which we spend so much of our time together? This is the root definition. It is like a very brief mission statement, though it applies to an activity and not necessarily an organization or division of an organization, and it is definitely for internal use rather than public consumption. In one sense it is the minimum we can agree on, but it must describe our real activity. And there will have already been much argument, because people will see what they are agreeing to and what has been left out.
Typical examples might be "we land the aircraft safely at any well-equipped, probably busy, airport", "we make gearboxes in the shadow of Mt Fuji", "we try to understand what is meant by BPR, and its advantages and disadvantages", "we are maintaining Australian capability in IC manufacture", "we provide full time employment for locals in this town" or "we inform students of their results, taking into account privacy considerations". Notice that the root definition defines what is agreed and what is still up for discussion, and that many important (but not yet agreed) things might not be mentioned. We need to be sure that so far everyone is still with us. Achieving a truly agreed root definition (at least for the time being) is probably the most beneficial part of SSM.
Conceptual Model
Once the SSM team has agreed on a root definition (and the CATWOE participants) they temporarily forget about the existing system and model their "ideal" system to do the job. Here we can come up with lots of crazy ideas, though eventually we need to choose the "best". This means that we need choice criteria (though in the end the "best" model will be the agreed one, so the criteria can be implicit). Checkland suggests as criteria five Es: efficacy (will it work at all), efficiency (will it work with minimum resources), effectiveness (does it contribute to the enterprise), ethicality (is it moral) and elegance (is it beautiful). The construction of the model was originally seen by Checkland as fairly formal, and he provided a definition of a "proper" logical model. Recently he has rejected the idea of a formal model. His current models are usually process models, with a small number of steps. Unlike BPR, however, SSM includes in its conceptual model management and support activities. The model must have enough detail (including resource use and performance measures) for it to be evaluated, but complete specification is not necessary since, as we shall see, the model is unlikely to ever be fully implemented.
In the aircraft landing example, the model may be: choose a runway, wait until runway available, lock onto approach path, fly to runway, lock onto final approach, touch down, stop; with supporting activities: ensure safe operation of aircraft, cooperate with airport operators and other aircraft, perform peer monitoring of crew performance. In this example these steps are probably fairly fixed in the short term, so the suggested ideal system would come in the detail of how these steps are implemented. Comparison
The conceptual model is used for comparison with the current system. Why aren't we doing it the "ideal" way? What is the reason for our current odd behavior? How do we measure up to the ideal, semi-formally by the four criteria of efficiency, effectiveness, ethicality and elegance, and intuitively by group opinion? (We know the current system is efficacious - it does something - because it exists.) The conceptual model is meant to provide inspiration, not criticism.
Agree on Changes
Assuming our current system is not perfect (which is why we undertook the study in the first place) the enterprise needs to agree on desirable changes. Presumably these changes will move towards the ideal system. At this stage we go back and draw on the knowledge gained during the problem expression stage, particularly in understanding how proposed changes might affect and be affected by stakeholders. Changes which are not agreed on will not happen.
Action
Finally, we need to implement the agreed changes. But even here the outcome is not predictable. Checkland sees implementation as a new human activity, so we can start the whole SSM process over again. It is unlikely that the final outcome will match the agreed change exactly. During implementation new compromises will need to be crafted.
You may wonder how an SSM project will ever finish. In one sense it is not meant to - SSM has a philosophy of continual improvement. But in another sense we hope for convergence. We hope that some of the issues agreed in the early stages will not resurface, that discussions arising during implementation will be more focused as the participants' skills in SSM and understanding of the enterprise increase.
Criticisms of the Soft Systems Methodology. Soft systems methodology has many critics, both from the "right" and the "left". Technically oriented critics complain that SSM doesn't actually tell you how to build a system, that there is no real method. A possible reply is that we have plenty of technology based methodologies which don't work - what we need is a way of securing commitment and taking into account a variety of interests. Management oriented critics worry that the open ended nature of SSM makes it impossible to manage - Checkland himself has said that there is no way of telling whether an SSM project is a success or a failure. The same criticism applies to any prototyping or evolutionary approach - perhaps traditional ideas of project management just don't work for organization change. Radical (and traditional left) critics say that SSM assumes that all members of the enterprise have choice, in fact equal choice. The idea that managers and workers can openly discuss their problems and needs is fanciful - SSM ignores issues of power. SSM supporters would reply that the very act of open discussion changes the organizational culture and empowers workers, though some would also argue for the rationalist "common good" view - "what's good for the company is good for the workers". Critics also argue that SSM involves manipulation by the consultants, that, like "human relations" management, can "trick" the participants into thinking they are happy with the consultant's hidden agenda. Further, critics claim, SSM imposes values of openness and "niceness" which are more suitable to middle class academics than to managers or workers. These criticisms do indicate that SSM has a fairly simple understanding of society. Nevertheless, the use of "socially aware" methodologies such as SSM has been growing gradually as people see that the outcome of "hard" systems approaches is seldom satisfactory to anyone.
RAD
Figure 10 Rapid Application Development Diagram (http://www.bgsu.edu)
Definition
A software development process that allows usable systems to be built in as little as 60-90 days, often with some compromises.
Principles Behind The Definition
In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution. In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied. In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.
Problems Addressed By RAD
With conventional methods, there is a long delay before the customer gets to see any results. With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use. With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.
Bad Reasons For Using RAD
To prevent cost overruns (RAD needs a team already disciplined in cost management) to prevent runaway schedules (RAD needs a team already disciplined in time management).
Good Reasons For Using RAD
To converge early toward a design acceptable to the customer and feasible for the developers to limit a project's exposure to the forces of change to save development time, possibly at the expense of economy or product quality.
Schedule Versus Economy Versus Product Quality
- Tradeoffs determine the pace of development.
Efficient Development balances economy, schedule, and quality, Schedule (faster than average), Economy (costs less than average), Product (better than average quality)
Sensible RAD tilts away from economy and quality toward fastest schedule, schedule (much faster than average),Economy (costs a little less than average), Product (a little better than average quality)
All-out RAD
"code like hell", Schedule (fastest possible), Economy (costs more than average), Product (worse than average quality)
- For RAD, something other than schedule must be negotiable.
RAD has a fair chance of success if the customer will negotiate either economy or quality
RAD has a better chance for success if the customer will negotiate both economy and quality NOTE: Negotiating quality does NOT mean accepting a higher defect rate. It means accepting a product that is less usable, less fully-featured, or less efficient.
- So, with RAD, one or more of the following goals may be unachievable.
The fewest possible defects (because developers may not have the legal right to modify the source for some plug-in components), the highest possible level of customer satisfaction (because secondary requirements may be sacrificed to stay on
schedule), the lowest development costs (because buying reusable components may cost more than building)
Abbreviated History of RAD
Barry Boehm (spiral model) ,Tom Gilb (evolutionary life cycle), Scott Shultz (RIPP, rapid iterative productive prototyping), James Martin (RAD, circa 1991)
Characteristics of RAD
Teams should consist of about 6 people, including both developers and full-time users of the system plus anyone else who has a stake in the requirements. Developers chosen for RAD teams should be multi-talented "renaissance" people who are analysts, designers and programmers all rolled into one.
- RAD USES SPECIALIZED TOOLS THAT SUPPORT ...
"visual" development creation of fake prototypes (pure simulations) creation of working prototypes, multiple languages, team scheduling, teamwork and collaboration, use of reusable components, use of standard APIs ,version control (because lots of versions will be generated)
-
RAD USES "TIMEBOXING"
Secondary features are dropped as necessary to stay on schedule.
RAD Uses Iterative, Evolutionary Prototyping
JAD (Joint Application Development) MEETING High-level end-users and designers meet in a brainstorming session to generate a rough list of initial requirements.
Developers talk and listen, Customers talk and listen
Developers build / evolve prototype based on current requirements. Designers review the prototype. Customers try out the prototype, evolve their requirements. FOCUS GROUP meeting Customers and developers meet to review product together, refine requirements, generate change requests. Developers listen. Customers talk. Requirements and change requests are "timeboxed". Changes that cannot be accommodated within existing
timeboxes are eliminated. If necessary to stay "in the box," secondary requirements
are dropped.
Iterations require between 1 day and 3 weeks. At some stage, exploratory prototypes may evolve into operational prototypes. Focus Group Sessions last about 2 hours are led by an experienced facilitator, who keeps the group "on focus" by having clear goals regarding the kind of information that needs to be elicited by preparing an issue-oriented agenda in advance of the meeting by ensuring that adequate discussion is directed toward each issue by ensuring everyone has an adequate opportunity to participate are followed by a report from the facilitator.
IMPORTANT RAD CONSTRAINTS
From Sun and other sources "Fitness for a business purpose" must be the criterion for acceptance of deliverables. All constituencies that can impact application requirements must have representation on the development team throughout the
process. Customers, developers and management must accept informal deliverables.
Paper prototypes rather than full-scale systems Notes from user workshops rather than formal requirements documents Notes from designers' meetings rather than formal design
documents PRINCIPLE: Create the minimum documentation necessary to facilitate future development and maintenance.
Development teams must be empowered to make some decisions traditionally left to management. End-to-end timescale must be 6 months or less. Iteration must be used in such a way that the development process converges toward an acceptable business solution. Prototyping must incorporate evolving requirements quickly, in
real time, and gain consensus early. There must be a "buy before build" bias.
When RAD Works And When It Doesn’t RAD Tends To Work
When the application will be run standalone Major use can be made of pre-existing class libraries (APIs). Performance is not critical. Product distribution will be narrow (in-house or vertical market). Project scope (macro-schedule) is constrained. Reliability is not critical. System can be split into several independent modules. The product is aimed at a highly specialized IS (information systems) market. The project has strong micro-schedule constraints (timeboxes). The required technology is more than a year old.
When RAD Tends To Fail
Application must interoperate with existing programs. Few plug-in components are available. Optimal performance is required. Product development can't take advantage of high-end IS tools (e.g., 4GLs). Product distribution will be wide (horizontal or mass market). RAD becomes QADAD (Quick And Dirty Application Development).
RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD). Technical risks are high due to use of "bleeding" edge technology. The product is mission-or life-critical. The system cannot be modularized (defeats parallelism).
Evaluation of RAD Advantages of RAD
Buying may save money compared to building Deliverables sometimes easier to port (because they make greater use of high-level abstractions, scripts, intermediate code)
Development conducted at a higher level of abstraction (because RAD tools operate at that level) Early visibility (because of prototyping) Greater flexibility (because developers can redesign almost at will)
Greatly reduced manual coding (because of wizards, code generators, code reuse) Increased user involvement (because they are represented on the team at all times) Possibly fewer defects (because CASE tools may generate much of the code) Possibly reduced cost (because time is money, also because of reuse) Shorter development cycles
(because development tilts toward schedule and away from economy and quality) Standardized look and feel (because APIs and other reusable components give a consistent appearance)
Disadvantages of RAD
Buying may not save money compared to building Cost of integrated toolset and hardware to run it Harder to gauge progress (because there are no classic milestones)
Less efficient (because code isn't hand crafted) Loss of scientific precision (because no formal methods are used) May accidentally empower a return to the uncontrolled practices of the early days of software development More defects (because of the "code-like-hell" syndrome) Prototype may not scale up, a B-I-G problem Reduced features (because of timeboxing, software reuse) Reliance on third-party components may ...
sacrifice needed functionality add unneeded functionality create legal problems Requirements may not converge (because the interests of customers and developers may diverge from one iteration to the next) Standardized look and feel (undistinguished, lackluster appearance) Successful efforts difficult to repeat (no two projects evolve the same way) Unwanted features (through reuse of existing components)
CHAPTER 4
SSADM
Introduction
In the early days of large scale information systems development many organisations used the Cobol programming language together with indexed sequential files to build systems for customer billing, payroll, stock control and a variety of other business areas. Developments at this time were characterized by limited user involvement, inadequate requirements elicitation, use of ad hoc analysis and design techniques, absence of CASE support for analysis and design, time consuming use of 3GL tools, inflexible file and 3rd generation database management systems.
Frequently the results of this approach were systems which, on delivery, did not satisfy business requirements. This caused extensive maintenance requirements and thus an increase in the applications backlog. A variety of problems may have caused the mismatch between system functionality and business requirements a lack of ownership of and commitment to the system from users as a result of the low level of involvement, business requirements may have changed between inception and delivery, requirements may have been mis-understood ,inadequate analysis and design tools and techniques may have been used, or more likely a combination of these problems.
The response from the information systems community to these problems was the development of structured methodologies for ISE. The purpose of these methodologies seems to have been to (a) formalize the requirements elicitation process to reduce the chances of mis-understanding the requirements and (b) to introduce best practice techniques to the analysis and design process SSADM (in common with other structured methodologies) adopts a prescriptive approach to information systems development in that it specifies in advance the modules, stages and tasks which have to be carried out, the deliverables to be produced and furthermore the techniques used to produce the deliverables. SSADM adopts the Waterfall model of systems development, where each phase has to be completed and signed off before subsequent phases can begin. SSADM is one example of a structured methodologies, a variety of others are widely used in ISE, including:
STRADIS: (Structured Analysis, Design and Implementation of Information Systems) a methodology developed by Gane and Sarson (1979). The methodology is based on the philosophy of top down functional decomposition and relies on the use of Data Flow Diagrams.
YSM: (Yourdon Systems Method, Yourdon, 1993). YSM is similar to STRADIS in its use of functional decomposition, however a middle-out approach is dopted and slightly more emphasis is placed on the importance of data structures.
MERISE: (Quang and Chartier-Kastler, 1991)The methodology is widely used in ISE in France, Spain and Switzerland. MERISE consists of three ‘cycles’, the decision cycle, the life cycle and the abstraction cycle. The abstraction cycle is the key, in this cycle both data and processes are viewed firstly at the conceptual level, then the logical or organizational level and finally at the physical or operational level.
EUROMETHOD: (CCTA, 1994) Euromethod could be described as a framework for the integration of existing European methodologies rather than as a methodology in its own right.
What is SSADM?
SSADM (Structured Systems Analysis and Design Methodology) is a methodology (Def. a system of ways of doing things especially regular and orderly procedures), used in the analysis and design stages of systems development. SSADM does not cover SITP issues or the construction, testing and implementation of software.
"SSADM has been used by the government in computing since its launch in 1981. It was commissioned by the CCTA (Central Computing and Telecommunications Agency) in a bid to standardize the many and varied IT projects being developed across government departments. The CCTA investigated a number of approaches before accepting a tender from Learmonth & Burchett Management Systems to develop a method." (Eva, SSADM Version 4 - A Users Guide)
Since 1981 SSADM has been further refined and version 4 was launched in 1990. SSADM is an open standard, i.e. it is freely available for use in industry and many companies offer support, training and Case tools for it.
Why is SSADM Used?
Within government departments SSADM has to be used. External contractors producing software for the government also have to use SSADM. SSADM is used by other companies because they expect the use of a disciplined ‘engineering approach will eventually improve the quality of the systems they produce. many companies have been willing to incur the considerable expense of implementing SSADM (e.g. staff training) with this expectation in mind.
How is SSADM Controlled in the UK?
SSADM is managed by the CCTA, however the Design Authority Board (DAB) is responsible for maintaining and developing SSADM and the NCC (National Computing Centre) produce and maintain the definitive SSADM documentation.
What are the Major Tools of SSADM?
SSADM revolves around the use of three key techniques, namely Logical Data Modeling, Data Flow Modeling and Entity/Event Modeling.
-
Logical Data Modeling This is the process of identifying, modeling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS - The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS s represent Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).
-
Data Flow Modeling This is the process of identifying, modeling and documenting how data flows around a business information system. A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. DFDs represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow).
-
Entity Event Modeling; This is the process of identifying, modeling and documenting the business events which affect each entity and the sequence in which these events occur. An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation.
Three Interdependent Views
The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides a different viewpoint of the same system, each of which are required to form a complete model of the system. Within SSADM each of the three techniques are cross reference against each other to ensure the completeness and accuracy of the complete model.
How is SSADM Structured?
SSADM consists of 5 main modules, which are in turn broken down into a complex hierarchy of stages, steps and tasks.
-
Feasibility Study: Module 1 the feasibility study consists of a single stage (Stage 0 Feasibility), which involves conducting a high level analysis of a business area to determine whether a system can cost effectively support the business requirements. In stage 0 an overview DFD is produced together with a high level LDS. At this stage the DFD will represent the existing system warts and all and the LDS may be incomplete and contain unresolved M:M relationships.
-
Requirements Analysis: Module 2 requirements analysis consists of 2 stages; Stage 1 Investigation of Current Environment and Stage 2 Business System Options (BSO). During stage 1 the systems requirements are identified and the current business environment is modeled in terms of the processes carried out and the data structures involved. During stage 1 DFDs and an LDS are used to produce detailed logical models of the current system During stage 2 up to 6 business system options are produced and presented. As a result one of these options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs and LDS are produced to support each business system option and the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM, this is where we move from a logical model of the current system to a logical model of the required system, i.e. this is where the DFDs and LDS have to be refined to cater new/changed requirements.
-
Requirements Specification: Module 3 Requirements Specification consists of a single stage (Stage 3 Definition of Requirements) which involves further developing the work carried out in module 2, detailed functional and non-functional requirements are identified and new techniques are introduced to define the required processing and data structures. In stage 3 the DFDs and LDS are refined and cross validated in the light of the chosen business system option. The LDS is enhanced using relational data analysis (normalisation). The DFDs and LDS are validated against the ELHs also produced during this stage. DFDs LDS and ELHs are used as input to the subsequent stages of SSADM.
-
Logical System Specification: Module 4 Logical System Specification consists of 2 stages; Stage 4 Technical System Options and Stage 5 Logical Design. In stage 4 up to 6 technical options (specifying the development and implementation environments) are produced, one being selected. In stage 5 the logical design of update and enquiry processing and system dialogues (menus etc.) is carried out.
-
Physical Design: Module 5 Physical Design consists of a single stage (Stage 6 Physical Design) in which the logical system specification and technical system specification are used to create a physical database design and a set of program specifications.
Introduction to SSADM
Objectives
The objective is to encourage you to view SSADM not as a magic pill which can be swallowed whole or not at all, but as an analysis & design framework or set of tools which can be adopted in whole or in part depending on requirements and which can be modified, tweaked or manipulated by people with sufficient experience and expertise.
Critique of SSADM and DSDM
Avison and Fitzgerald (1995) summarize the problems of the applications backlog along with a number of other issues which are potential weaknesses of ‘traditional’ approaches to information systems development. One of the responses to these problems from the information systems community was the development of structured methodologies for Information Systems Engineering. The purpose of these methodologies seems to have been to (a) formalize the requirements elicitation process to reduce the chances of mis-understanding the requirements and (b) to introduce best practice techniques to the analysis and design process. SSADM (Structured Systems Analysis and Design Method, NCC, 1995) is a typical example of a structured methodology.
RAD (Rapid Application Development, Martin, 1991) approaches began to be adopted in the late 80’s and are based on a number of fundamental premises, the most important being the acceptance that business processing requirements will inevitably change during the development cycle of a system. In order to work with this fact of systems development life the RAD approach mandates: the use of 4th Generation Tools (to enable quick delivery), an iterative model of systems development which allows backtracking in the light of changing requirements, the use of evolutionary prototypes (SSADM adopts the adage that a picture is worth a thousand words, RAD goes a step further and advocates that a working model is worth a thousand pictures), a very high level of user involvement in the development process to aid in communications and to encourage feelings of commitment and ownership, the empowerment of highly skilled, multi-disciplinary teams consisting of users, analysts and technical specialists. The RAD approach has been used successfully in many organizations and is currently gaining more formal support with the advent of DSDM (Dynamic Systems Development Method, DSDM Consortium, 1995), a framework for RAD.
Framework
A brief explanation of a framework for comparing methodologies developed by Avison and Fitzgerald (1995) is followed by its application to the SSADM and DSDM methodologies. The framework consists of 7 elements:
-
Philosophy: In their terms a philosophy is a principle or set of principles that underlie a methodology. In fact they define a methodology as a set of techniques underpinned by a philosophy.
-
Model: The model is the basis of the methodology’s view of the world, e.g. the Waterfall and Spiral models of Information Systems Engineering.
- Techniques and Tools: Typically a methodology adopts a set of integrated techniques, such as Entity-Relationship Modeling and Data Flow Modeling and may use CASE tools to support the techniques.
-
Scope: The scope of a methodology defines its start and end points within the ISE lifecycle.
-
Outputs: The outputs define the deliverables to be produced during the phases of the methodology.
-
Practice: This element looks at the use of the methodology in terms of the differences between the theory and the practice.
-
Product: This element looks at the nature of the product itself, in terms of documentation, CASE tool support, training courses etc.
The forthcoming evaluation addresses each of these elements, however it concentrates on the philosophy, models, techniques and tools and scope areas. The framework is also extended to enable comparison on the basis of the suitability of the methodologies for use within a Corporate Information Management Strategy.
Critique
Neither SSADM nor DSDM really address the fundamental importance of corporate data management. SSADM adopts a structured, rigorous, project led approach to the development of data structures and processes. DSDM adopts a dynamic, project led approach to both data structures and processes. Both approaches fail to recognise that data structures are largely stable and many processes dynamic. SSADM can reduce the chances of initial requirements being mis-understood and of the systems functionality straying from the requirements through the use of inadequate analysis and design techniques. However, SSADM assumes that the requirements (in the form of an agreed requirements specification) will not change during the development of a project. Following each step of SSADM rigorously can be time consuming and there may be a considerable delay between inception and delivery (which is typically the first time the users see a working system). The longer the development time the more chance of the system meeting the requirements specification but not satisfying the business requirements at the time of delivery. RAD has been used successfully in many organizations and is currently gaining more formal support under the auspices of the DSDM consortium. The RAD approach however is not without its pitfalls. DSDM advocates that RAD is only suitable for certain kinds of applications, i.e. those which are interactive, with clear functionality at the user interface, have a clearly defined user group, are not computationally complex and have requirements which are not too detailed and fixed. DSDM advocates that RAD is not suitable for real-time or safety-critical applications or for applications where functional requirements have to be fully specified before any programs are written. Thus RAD would only appear to address part of the applications backlog. Applications suitable for RAD and those not would appear to be at opposite ends of a scale. What about the large class of information systems in between, i.e. those which have:
- a mixture of interactive and non-interactive functionality,
- a core user group which is clear but an ill-defined group of ‘other’ users,
- some elements of computationally complex functionality,
- a range of requirements, from the detailed and fixed to the unclear and variable.
RAD depends on active user involvement in the development process. What happens if the right users are unavailable? It has been stated that the best users to be involved in RAD teams are those which business can’t afford to lose!
There is a common misconception that RAD is a ‘license to hack’, it isn’t, however the temptation is there. There may also be integration and data sharing problems when a number of RAD project teams are working concurrently on different systems. (It should be noted that integration problems are not peculiar to RAD projects, the possibility also exists within structured environments, however the use of consistent analysis and design techniques reduces the probability of this occurring.)The following section explains the flow of the framework.
CHAPTER 5
Specification Frame Work
The below figure demonstrates the operation of the Direct Debit service and how it can be applied by each end user. Each user sends a request to the web server where the application is based and once the server response it redirects the user to the Login/Register section. During this process the user has two options one is to login to the service or to register if it is necessary. If the username and pin code is correct where this can be checked from the datastore then the user will be redirect to the main service area. where he will have the option to choose between the three following services check, activate and deactivate of his direct debit. In case the user is not registered then he has to register first where his details will be stored into the datastore and then do the login process as explained above. Reaching this part of the application the user as mentioned above can check, activate and deactivate his Direct Debit. The check process returns the present status of his Direct Debit account, where the user can either log out from the service or activate, deactivate any of the Direct Debits. If he choose to activate or deactivate any of Direct Debits then this process will update the datastore. When the user has finished any kind of processes he can log out. By the next time the user uses this service his Direct Debit account will be up to date. Below the DFD diagram.
Figure 11 Data Flow Diagram (WAP Banking Application)
Software experimentation
The following software was used for the development of this application
WML, WML SCRIPT, IIS
The following will allow you to setup IIS to deliver WAP content.
The following are the mime types and the file extensions used for WAP.
WML Example Code
Wap Gateway
When you need to interface your WAP phone to your company network, you will need some sort of WAP gateway. Gateway is needed for couple of reasons.
Figure 12 WAP Gateway (www.realwow.com)
1) It handles session management, what regular HTTP is unable to do.
2) It converts WML plaintext files to compressed format (WMLC), which is needed by most phones currently.
Mobile Gateway works with any WAP enabled phone. Gateway work with both Connection oriented and Connection-less browsers. The only limit is the number of licenses purchased and the shared bandwidth of your network.
WAP Gateway is component which only redirects the material, so you will also need the part, which serves/generates content. Such a thing can be WWW-server equipped with CGI
Microsoft Access XP SP2
For the creation of the Database
Figure 13 Microsoft Access Database (Service Pack 2)
Generating dynamic WAP content
The script for generating WAP content with ASP, PHP, Perl, and JSP is given here. In all cases except with ASP, we’ve given that part of the code that tells your browser that WAP content is being sent to it and specify the MIME type of the content. You can put in your actual content after this.
Response.ContentType = "text/vnd.wap.wml"
Response.Write"Welcome Visitors"
Response.Write " WAP is good "
WAP with PHP
PHP is so flexible that one HTML document containing a PHP script can be used for both HTML and WML compatible browsers. The PHP source code is invisible to the client, just like ASP, and it’s up to you to either output HTML code or WML. However, be extra careful here, as some built-in features of PHP output HTML by default, typically error messages, which your WML micro-browser won’t understand.
For example,
<?
header("Content-type: text/vnd.wap.wml");
echo("
echo("\n\n");
?>
… Put your content here…
As with PHP, in Perl too, you first need to send the correct MIME type to the browser. Here’s how to do it.
print "Content-type: text/vnd.wap.wml\n\n";
print "<?xml version=\"1.0\"?>\n";
print "<!DOCTYPE wml PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\"\"http://www.wapforum.org/DTD/wml_1.1.xml\">\n\n";
….. Put your content here…..
Dynamic WML documents can be easily developed using Java servlets. Once you know the WML syntax, building WAP applications using Java servlets can be an easy task. Just set content type in your class and you can then send WAP tags. The line
Response.setContentType("text/vnd.wap.wml");
defines the WAP MIME type to the browser. This is followed by
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class MobileDate extends HttpServlet {
public void service (HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
To set the content type for your wireless data:
response.setContentType("text/vnd.wap.wml");
PrintWriter out = response.getWriter();
Now, you can write what you would like to display on the user’s screen:
out.println("<?xml version=\"1.0\"?>");
out.println("<!DOCTYPE wml PUBLIC \"-//WAPFORUM//DTD WML 1.1//EN\"");
out.println(" \"">");
out.println("<wml>");
out.println("<card title=\"Hello\">");
out.println(" <p align=\"center\">");
out.println("java with wap<br/>");
out.println("</p>");
out.println("</card>");
out.println("</wml>");
}
}
Nokia Toolkit 3.1 for coding purposes
Figure 14 Nokia Toolkit 3.1
Photoshop/ Image Ready for the logo creation
Figure 15 Photoshop 7.0
Editplus for coding purposes
Figure 16 Editplus
Dreamweaver MX for coding purposes
Figure 17 Dreamweaver MX
FireWorks MX for the creation of the logo
Figure 18 Fireworks
HTML2ANYCODE for coding purposes.
Figure 19 HTML 2 ANYCODE
PHPMYADMIN for the navigation and creation of the database.
phpMyAdmin can manage a whole MySQL server (needs a super-user) as well as a single database. To accomplish the latter you'll need a properly set up MySQL user who can read/write only the desired database. It's up to you to look up the appropriate part in the MySQL manual.
Currently phpMyAdmin can:
- create and drop databases
- create, copy, drop, rename and alter tables
- do table maintenance
- delete, edit and add fields
- execute any SQL-statement, even batch-queries
- manage keys on fields
- load text files into tables
- create (*) and read dumps of tables
- export (*) data to CSV, XML and Latex formats
- administer multiple servers
- manage MySQL users and privileges
- check referential integrity
- using Query-by-example (QBE), create complex queries automatically connecting required tables
- create PDF graphics of your Database layout
- search globally in a database or a subset of it
- transform stored data into any format using a set of predefined functions, like displaying BLOB-data as image or download-link or ...
-
communicate in
MySQL for the Creation of the Database
The MySQL is the world's most popular open source database. Its architecture makes it extremely fast and easy to customize. Extensive reuse of code within the software and a minimalistic approach to producing functionally-rich features has resulted in a database management system unmatched in speed, compactness, stability and ease of deployment. The unique separation of the core server from the storage engine makes it possible to run with strict transaction control or with ultra-fast transactionless disk access, whichever is most appropriate for the situation.
Java SDK 1.4.1
Java 2 Platform, Standard Edition (J2SE) software is the premier solution for rapidly developing and deploying mission-critical, enterprise applications. Version 1.4.1 builds upon Java technology's cross-platform support and robust security model with new features and functionality, enhanced performance and scalability, and improved reliability and serviceability. Version 1.4.1 advances rich client application development and provides the foundation for standards-based, interoperable Web services that can be built and deployed today!
Figure 20 Java SDK 1.4 ()
Java SUN ONE STUDIO for coding purposes
Figure 21 SUN ONE STUDIO
The following section will demonstrate how the Wap Direct Debit service works through a number of screenshots. Also the all the pieces of code of the application will be shown and a questionnaire which will help for future development and fixes of the parent version.
CHAPTER 6
Prototype evaluation
The below figures shows us all the possible cases the user might come across during the navigation and the usage of the application.
Figure 22 Login / Register Screen(Welcome Screen)
This is the welcome screen where the user has the option to login if he is already registered or register first and then get access to the service. In the following figures we will assume that the user is not registered and he has to register first.
Figure 23 Registration Section
In this figure we see the registration form where the user fill out his personal and bank details.
Figure 24 Registration Section
This above figure shows a part of the registration form where the user chooses which direct debit would like to activate or just leave it deactivated by choosing YES/NO next to the one of his choice.
Figure 25 Registration Section
This figure shows the last part of the registration section where the user fills out the last details and presses the register button. By doing that the user becomes register and the details of his/her stored in the database. Assuming that all the fields all completed we continue to the next figure.
Figure 26 Registration Section
If the users make no error during the registration then this screen will come up. The user by pressing the continue button will redirect to the welcome screen so as to login. But in case of any error the next figure shows what the user will probably come across with.
Figure 27 Registration Section
The user will come across with the above figure (error) in case he/she forgot to fill out one or more fields in the registration section. What has to do is go back and check where he/she forgot any field empty. Once this is done then he/she will probably see the figure 25 and the registration will go though the system.
Figure 28 Login Section
This is the login screen where the user writes down the name and the pin number where he previously entered in the registration form.
Figure 29 Login Section
This screen appears only if the user is not register which by pressing the button below it will take him/her to the registration area figure 23.
Figure 30 Login Section
This screen appears if the user has entered wrong password which he has to go back and write again his password.
Figure 31 Login Section
This screen is the one that appears when the user has been registered and then login’s correctly, the continue button will take the user to the main application area.
Figure 32 Main Section Direct Debit
This is the main area where the user has 3 choices 1) is to check direct debit 2) to see the contact information 3) log out
Assuming the user checks the his direct debit right away…..
Figure 33 Main Section Direct Debit
This screen appears when the user enters the direct debit section where it informs the users which direct debits is activated and which aren’t. The user can change the state anytime he wants by going to one of the appropriate links for each one. Assuming the user would like to deactivate the direct debit for electricity, what he has to do is go to the deactivate link press it and ……
Figure 34 Main Section Direct Debit
This screen will come up which will inform the user that the change was successful and by pressing the continue button will take him back to the main area. But just to make sure that the service is working and the change really made we check it again and what the below figure show as is this…..
Figure 35 Main Section Direct Debit
In case you haven’t spotted the change the electricity was activated and the link below it was saying deactivate and now is says activate so we are sure that the change has made.
Figure 36 Information Section(Contact Page)
This is the contact information section where the user can make a call and learn more about this service or just in case of any queries.
Figure 37 Login / Register Screen (Welcome Screen)
And this is again the welcome screen where it comes up when the user logs out. In the following section the pieces of the application code will be shown.
The below code is for the Index.html file which is the welcome screen.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title> Welcome</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body text="#000000" link="#0033CC" vlink="#0033CC" alink="#0033CC">
<div align="center"><img src="logo.gif" width="103" height="47" /><br />
Welcome to<br>
<strong>W</strong>ap<strong> D</strong>irect <strong>D</strong>ebit<br />
<a href="login.htm">Login</a><br />
<a href="register.htm">Register</a> <br />
</div>
</body>
</html>
The below code is for the register.htm which is for the registration form where the user fills out his details.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Registration</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body text="#000000">
<form name="form1" id="form1" method="post" action="newuser.php">
<p align="left">Username:<br />
<input name="Username" type="text" />
<br />
Pin:<br />
<input name="Pin" type="password" size="4" maxlength="4" />
<br />
Type:
<select name="Type" size="1" >
<option value="Mr">Mr</option>
<option value="Mrs">Mrs</option>
<option value="Miss">Miss</option>
<option value="Ms">Ms</option>
<option value="Dr">Dr</option>
</select>
<br />
Firstname:<br />
<input name="Firstname" type="text" />
<br />
Surname:<br />
<input name="Surname" type="text" />
<br />
Address:<br />
<input name="Address" type="text" />
<br />
Town:<br />
<input name="Town" type="text" />
<br />
County:<br />
<input name="County" type="text" />
<br />
Postcode:<br />
<input name="Postcode" type="text" />
</p>
<p>
<label> </label>
<select name="Electricity" size="1">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Electricity:<br />
<select name="Gas">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Gas:<br />
<select name="Water">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Water:<br />
<select name="Telephone">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Telephone: <br />
<select name="Council_tax">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Council Tax: <br />
<select name="Tv_licence">
<option value=""></option>
<option value=1>Yes</option>
<option value=0>No</option>
</select>
Tv Licence: </p>
<p> Bank Name:<br />
<input name="Bank_Name" type="text" id="Bank_Name" />
<br />
Account Holder Name:<br />
<input name="Account_Holder_Name" type="text" id="Account_Holder_Name" />
<br />
Bank Address:<br />
<input name="Bank_Address" type="text" id="Bank_Address" />
<br />
Branch Sort Code:<br />
<input name="Branch_Sort_Code" type="text" id="Branch_Sort_Code" />
<br />
<input name="Register" type="submit" value="Register" />
</p>
</form>
</body>
</html>
The below code is for the newuser.php where the checking is done about the registration and if everything is ok then the data are inserted to the database.
<?php echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Registration</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<?php
// QUERY
$strSQL="INSERT INTO userinfo (user, pin, typr, fname, sname, address, town, county, pcode, elec,gas, wat, tel, ctax, tvlice, baname, ahn, ba, bsc) VALUES ('".$_POST['Username']."', ".$_POST['Pin'].", '".$_POST['Type']." ', '".$_POST['Firstname']." ', '".$_POST['Surname']." ', '".$_POST['Address']." ', '".$_POST['Town']." ', '".$_POST['County']." ', '".$_POST['Postcode']." ',".$_POST['Electricity']." , ".$_POST['Gas'].", ".$_POST['Water'].",".$_POST['Telephone'].", ".$_POST['Council_tax'].",".$_POST['Tv_licence'].", '".$_POST['Bank_Name']." ', ' ".$_POST['Account_Holder_Name']."', '".$_POST['Bank_Address']." ', ' ".$_POST['Branch_Sort_Code']."')";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
die( "Could not connect to database" );
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid != false )
{
?>
<div align="center">Your registraton was successfull:</div>
<?
// print "Your registraton was successfull:";
?>
<form name="form3" method="get" action="index.htm">
<div align="center"><br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
?>
<div align="center">Your registraton was unsuccessfull please go back and make
sure you have all the fields filled:</div>
<?
// print "Your registraton was unsuccessfull please go back and fill out all the fields:";
?>
<form name="form3" method="get" action="index.htm">
<div align="center"><br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
?>
</body>
</html>
The below code is for the login.htm which is another form with about where the user writes down his name and pin.
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//OPENWAVE//DTD XHTML Mobile 1.0//EN" "http://www.openwave.com/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Login</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<form name="form1" id="form1" method="post" action="login2.php">
<p align="center">Username:<br />
<input name="Username" type="text" id="Username" size="10" maxlength="10" />
<br />
4-Digit Pin:<br />
<input name="Pin" type="password" id="Pin" size="4" maxlength="4" />
<br />
<input name="Enter" type="submit" value="Login" />
</p>
</form>
<div align="center"><br />
</div>
</body>
</html>
The below code is for the login2.php where the checking for the pin and the username is done.
<?php echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Login</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<?php
// QUERY
$strSQL = "SELECT user, pin FROM userinfo WHERE user = '".$_POST['Username']."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
die( "Could not connect to database" );
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid != false )
{
if (mysql_num_rows($resultid) == 0)
{
?>
<div align="center">Sorry you have to register first to use this service press the continue button to take you to the registration area:</div>
<?
// print "Sorry you have to register first to use this service press the continue button to take you to the registration area:";
?>
<form name="form3" method="get" action="register.htm">
<div align="center"><br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
exit;
}
$row = mysql_fetch_assoc($resultid);
if ($row['pin'] != $_POST['Pin'])
{
print "The password is incorrect please go back and try again";
}
else
{
?>
<div align="center">Access Granted:</div>
<?
// print "Access Granted";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $_POST['Username'] ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<div align="center">
<?
}
}
else
{
print " There was an error executing the query: ";
}
mysql_close($database);
?>
</div>
</body>
</html>
The below code is for the afterlogin.php which contains three (button-forms) check direct debit contact us and log out each one used for its reason.
<?php
?>
<div align="center">----- Welcome -----<br></div>
<?
//print "Welcome ";
?>
<div align="center"><? print $_POST['user'] ?></div>
<?
//print $_POST['user']."<br>";
?><title>Direct Debit</title>
<form name="form1" method="post" action="checkdd.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $_POST['user'] ?> ">
<br>
<input type="submit" name="Submit2" value="Check Derict Debit" >
</div>
</form>
<form name="form2" method="get" action="contact.htm">
<div align="center">
<input name="Submit3" type="submit" value=" Contact Us " >
</div>
</form>
<form name="form3" method="get" action="index.htm">
<div align="center">
<input name="Submit" type="submit" value=" Log Out " >
</div>
</form>
The below code is for the checkdd.php is where the links for the direct debit service is located where it passes the details to the dd.php when everything is done.
<?php echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Direct Debit</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<?php
// QUERY
$userinf = $_POST['user'];
$user = ltrim(rtrim($userinf));
$strSQL = "SELECT elec, gas, wat, tel, ctax, tvlice FROM userinfo WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
die( "Could not connect to database" );
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
$row = mysql_fetch_assoc($resultid);
if ($row['elec']==1)
{
print "Electricity is activated:<br><a href=\"dd.php?dd="."elec"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Electricity is deactivated:<br><a href=\"dd.php?dd="."elec"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
if ($row['gas']==1)
{
print "Gas is activated:<br><a href=\"dd.php?dd="."gas"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Gas is deactivated:<br><a href=\"dd.php?dd="."gas"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
if ($row['wat']==1)
{
print "Water is activated:<br><a href=\"dd.php?dd="."wat"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Water is deactivated:<br><a href=\"dd.php?dd="."wat"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
if ($row['tel']==1)
{
print "Telephone is activated:<br><a href=\"dd.php?dd="."tel"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Telephone is deactivated:<br><a href=\"dd.php?dd="."tel"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
if ($row['ctax']==1)
{
print "Council Tax is activated:<br><a href=\"dd.php?dd="."ctax"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Council Tax is deactivated:<br><a href=\"dd.php?dd="."ctax"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
if ($row['tvlice']==1)
{
print "Tv Licence is activated:<br><a href=\"dd.php?dd="."tvlice"."&v=1&user=".$user."\">(Deactivate?)</a><br>";
}
else
{
print "Tv Licence is deactivated:<br><a href=\"dd.php?dd="."tvlice"."&v=0&user=".$user."\">(Activate?)</a><br>";
}
?>
</body>
</html>
The below code is for the dd.php is where the processes about the direct service are done activate/deactivate.
<?php echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Direct Debit</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<?php
$userinf = $_GET['user'];
$user = ltrim(rtrim($userinf));
switch ($_GET['dd'])
{
case 'elec':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET elec=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Electricity deactivated:</div>
<?
// print "Electricity deactivated:";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET elec=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Electricity activated:</div>
<?
// print "Electricity activated:";
?>
<form name="form2" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print $strSQL."<br>";
print " Could not update record";
}
}
break;
case 'gas':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET gas=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Gas deactivated:</div>
<?
// print " Gas deactivated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET gas=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Gas activated:</div>
<?
// print " Gas activated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print $strSQL."<br>";
print " Could not update record";
}
}
break;
case 'wat':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET wat=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Water deactivated:</div>
<?
// print " Water deactivated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET wat=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Water activated:</div>
<?
// print " Water activated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print $strSQL."<br>";
print " Could not update record";
}
}
break;
case 'tel':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET tel=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Telephone deactivated:</div>
<?
// print " Telephone deactivated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET tel=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Telephone activated:</div>
<?
// print " Telephone activated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print $strSQL."<br>";
print " Could not update record";
}
}
break;
case 'ctax':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET ctax=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Council Tax deactivated:</div>
<?
// print " Council Tax deactivated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET ctax=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Council Tax activated:</div>
<?
// print " Council Tax activated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print $strSQL."<br>";
print " Could not update record";
}
}
break;
case 'tvlice':
if ($_GET['v']==1)
{
// QUERY
$strSQL = "UPDATE userinfo SET tvlice=0 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Tv Licence deactivated:</div>
<?
// print " Tv Licence deactivated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
// na valo tin form
}
else
{
print " Could not update record";
}
}
else
{
$strSQL = "UPDATE userinfo SET tvlice=1 WHERE user = '".$user."'";
// Connect to MySQL
$database = mysql_connect("localhost","TGSMA","sofiamaria");
if ( $database == false)
{
die( "Could not connect to database" );
}
mysql_select_db("project",$database);
//Executes Query
$resultid = mysql_query($strSQL,$database);
if ($resultid!=false)
{
?>
<div align="center">Tv Licence activated:</div>
<?
// print " Tv Licence activated";
?>
<form name="form1" method="post" action="afterlogin.php">
<div align="center">
<input name="user" type="hidden" value=" <? print $user ?> ">
<br>
<input type="submit" name="Submit" value="Continue" >
</div>
</form>
<?
}
else
{
print " Could not update record";
}
}
break;
}
?>
<body>
</body>
</html>
The below code is for the contact.htm just contains general information.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Contact Us</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body link="#0033CC" vlink="#0033CC" alink="#0033CC">
<div align="center">If you have questions about this Bank service, or need help
with Direct Debit, please call us at <a href="wtai://wp/mc;5551515" title="Call">(0044)
01582-418835</a>. </div>
</body>
</html>
The section that follows is about a questionnaire which was given to ten people to complete it for feedback purposes.
Questionnaire
The below questionnaire will gives us a feedback of what the end users think of this kind of service which this can be used for many kind of reasons such us future development.
Findings
Figure 38 Question 1 Findings
The above chart illustrates the reactions of the users who have tested in this kind of mobile service.
Figure 39 Question 2 Findings
The above chart illustrates the reactions of the users in case of errors using the service.
Figure 40 Question 3 Findings
The above chart illustrates the reactions of the people while navigating in the service.
Figure 41 Question 4 Findings
The above chart illustrates the reactions of the people for the screen layout in relation navigating the system.
Figure 42 Question 5 Findings
The above chart illustrates the reactions of the people for the terminology they come up with in relation navigating the system.
Figure 43 Question 6 Findings
The above chart illustrates the functionality of the system in relation to navigating the system.
Figure 44 Question 7 Findings
The above chart illustrates the speed of the system in relation to navigating the system.
Figure 45 Question 8 Findings
The above chart illustrates the error messages in relation to navigating the system.
CHAPTER 7
Conclusion
The main objective which was to develop a WAP banking application was met although there were huge difficulties during the development process because I didn’t know the exact software and languages to use but after a lot of background research and software experimentation I finally manage to finish it on time with having the results you can see at the screenshots at chapter 4. Although it is finished my belief it that this application is deficient in some parts such as checking if the fields at the registration area are empty or if the appropriate information written is correct, also other kind of services could be added apart from direct debit for the serve of the end user, such as money transfer credit card check etc, almost all the services a person could have from a bank but all these though his mobile anywhere anytime with low cost and now that the 3G are taking place with high speed. Also the experience i received from developing this application is priceless because I learned to deal with huge amount of work compare it to the usual assignments and this by having my time scheduled in that way so as to be enough for every kind of research and experimentation which this will help me afterwards out to the real life with real projects and work. Also the experimentations with the software had a result of getting me a great variety of knowledge and make me think different kinds of methods developing an application such as this one or something totally different. One other thing I earned from all this is finding a way to solve error messages and in case I come up with any of the same errors again in the near future i will probably will be much easier to deal with. Closing I would like to say that Mobile computing is new and unstable technology that potentially can change much about how organization work and it would be a mistake for managers not to have an eye towards keeping multiple future opportunities open such as this one.
REFERENCES
APPENDIX
Gantt Chart
Progress Reports
Poster
Figure 46 Poster (A Mobile Application for Banking Processes)
Questionnaires