Mobile Application Development

Primary tabs

 

 AALBORG UNIVERSITY MICT PROGRAM

TRIMESTER TWO PROJECT PROJECT TOPIC: MOBILE REVENUE PERFORMANCE REPORTING SYSTEM FOR THE ELECTRICITY COMPANY OF GHANA MANAGEMENT AND STAFF

 

 

 

 

REV. LAMBERT NTIBREY lambert@lamberntibrey.net

EDWARD OSEI-TAWIAH osetaw@yahoo.com

SETH ANSAH-NYARKO ohenebako@gmail.com

DATE: NOVEMBER, 2011

 

Copyright © 2012. This report and/or appended material may not be partly or completely published or copied without prior written approval from the authors.

 

3.0 CHAPTER 3 - METHODOLOGY

 This chapter presents the methodology of the software development.  

 

A STRUCTURED ITERATIVE METHODOLOGY FOR CROSS PLATFORM TARGETING MOBILE APPLICATION DEVELOPMENT

 

Figure 12 :- A structured iterative methodology for cross platform targeting mobile application development.

 

This methodology, labeled as "A Structured Iterative Methodology for Cross-Platform Targeting of Mobile Application Development", which was derived from the combination of aspects of the Basic Software Development Process Model (Somerville, 2010), the RESCUE (Requirements Engineering with Scenarios for User-Centered Engineering), the case study of Maiden et al. (2004), and the Knowledge Structuring and Representation in Requirements Specification process (Astesiano, 2002), has been used to solve the research question of "how can a mobile application be used in making revenue collection and performance information readily accessible and transparent to Electricity Company of Ghana Management?"

Figure 12 shows the outline of this methodology. In this methodology, the requirements and data structures (Sommerville, 2010) elicited through feasibility studies are analyzed and into Context Views, Use Case Views and internal Views (Astesiano, 2002).

In these views, the various platform requirements are determined. For the development of mobile application, the following information is required on platforms: Target OS; cross platform targeting tools, device database, Integrated Development Environment (IDE) and the software development tools for modeling the application.

For the target Operating System (OS), from Reza et. al, (2009), a Software Development Platform (SDP)(Reza et. al, 2009) is required. For the determined SDP, the Software development Tool (SDT) or the Software Development Kit (SDK) are required. This may take the form of a standard SDK which can be used to port application to different target OS. However, for manufacturer device specific features to be exploited, the manufacturer device specific SDK or SDT would be required.

The above target OS information is used to configure a cross platform porting tool and also an Integrated Development Environment (IDE) which is used to integrate all required development kits and tools and also provide the development platform.

The device database is a database of the features of the device needed to configure the porting of application onto that device. This is setup in both the IDE and cross platform targeting tool.

Developed application is tested on the emulator and/test device. Having passed through an iteration process (Schwaber, no date) to satisfaction, the component processed is placed in a Donebin awaiting component integration.

Goals are further modeled (Maiden et at., 2004) through persona character formulation processes (Cooper, 1999) of interviews and observations. Analysis is once again made into the three views of Astesiano, 2002. Any required update of the platform to achieve the newly engineered requirements is done.

Testing iterates using the model of stages of testing (Somerville, 2010). Use Case View components are integrated from the “Done” bin to produce the user interaction with the system. After testing the integrated components, usability testing is done with the user through walkthroughs.

The results of this usability test are analyzed for any further action and run through the development process until completion.

The integration of Internal Views components are used to interface the various components needed in the abstract state of the system to place data behind the screens.

The integration of Context Views components establishes the interface to context entities such as WAP sites through ISP gateways, and ECG Billing system.

Having completed various deployable stages a final product walkthrough (Maiden et al., 2004) and deployment takes place.

Reverse engineering into sequence diagrams has been used for code structure verification. Challenges for the movement of paper information to small device screens have been tackled using various information browsing techniques.

The database design placed the ECG MISDB as a context entity whose data must be accessed indirectly through a separate server. Implementing the connection to the ECG MISDB is beyond the scope of this work.

Copyright © 2012. This report and/or appended material may not be partly or completely published or copied without prior written approval from the authors.