Chapter 3

Methodology
3.1 Introduction
Methodology refers to a discussion of the underlying reasoning why particular ways of
doing things (methods) were used. It includes describing the theoretical concepts that
inform the choice of methods to be applied, placing the choice of methods within the
more general nature of academic work, and reviewing its relevance to examining the
research problem( Bryman Alan, 2008). Several methodologies exist and it is prudent to
critically analyze each particular one before implementing use in any
project.Methodologies also continue to experience a morph in structure due to varying
reasons e.g. A change in the user or business requirements, a change in technology used
or due to the possible limitations that may exist in existing methodologies.
Designing a product to fulfill the requirements of the user based on the different standard
development life-cycle models is a crucial aspect of the development process. A predefined development process is of essence. The development life-cycle might be
impacted if the development occurs incrementally. If the customer is engaged in the
development process,customer requirements are better implemented by the end of the
development process leading to better customer satisfaction (Jamwall, 2010). Waterfall
model, Spiral model, Iterative model and Prototyping model are some of the software
development life-cycle models widely used in the industry. There is need to have a
distinct mobile application development life-cycle model.The successful development of
mobile applications is challenged by several development and deployment
landmines,rapidly emerging standards, volatile platforms,intermittent connections, varied
devices, and inconsistent user-interface and input technology.Unfortunately, not only does
the infrastructure pose a threat to successful deployment, the sheer
volume of potential users and growing demand for accelerated delivery exacerbates
potential risks. To keep development costs down and ensure high quality software,we
must approach software development with a commitment to internal efficiency. As a

result, many of todays most successful mobile application vendors have transitioned to
iterative and incremental delivery methods just to keep up with the rapid pace and
constant change inherent in the industry (Holler, 2006). Software development for mobile
platforms comes with unique features and constraints that apply to most of the life-cycle
stages. The development environment and the technologies that support the software are
different compared to traditional settings. The most important distinguishing
characteristics are identified in (Abrahamsson, et al, 2004). Environment particularities
include a high level of competitiveness, necessarily short time to delivery, and added
difficulty in identifying stakeholders and their requirements. Development teams must
face the challenge of a dynamic environment, with frequent modifications in customer
needs and expectations. Technological constraints apply to mobile platforms in the
form of limited physical resources and rapidly changing specifications. There is also a
great variety of devices, each with particular hardware,firmware and operating system
characteristics.Another view of the constraints associated with mobile applications is
presented in (Hayes, 2003). The author mentions two types of constraints, evolving and
inherent. Evolving constraints, such as bandwidth, coverage and security, currently apply
to the mobile technology, but are likely to be addressed and possibly resolved in the near
future. On the other hand,inherent constraints such as limited screen real estate, reduced
data entry capability (due to a limited keypad for example), memory capacity, processing
power and limited power reserve, are permanent, at least relative to desktop
environments. Various approaches must be used in order to lower the impact of inherent
constraints.In this paper we looked at some of the pertinent methodologies in use today so
as to assist us to come up with the most appropriate project.

3.2 Research Methodology

Research in general refers to the search of knowledge whereas research methodology is a
scientific and systematic search for relevant information on a specific area or topic. This
information assist in defining problems, evaluating data, formulating hypothesis, making
deductions and suggesting new solutions. There are a number of research methodologies
that is why it is of importance to select the appropriate method that fits and clearly
outlines the problem domain of the researched area. In this project, experimental and
build methodologies were used as a tool to assist in gathering information that pertains to
the development of mobile applications and time and attendance systems.Other
methodologies where then further discussed.
3.2.1 Experimental
Experimental methodologies are broadly used in computer science to evaluate new
solutions for problems. Experimental evaluation is often divided into two phases, which
are exploratory and evaluation phase. In an exploratory phase the researcher is taking
measurements that will help identify the questions that should be asked about the system
under evaluation. Then an evaluation phase will attempt to answer these questions. A well
designed experiment will start with a list of the questions that the experiment is expected
to answer.
3.2.2 Build
This is the research methodology for this project and consists of building an artifact either
a physical artifact or a software system to demonstrate that it is possible. It is a powerful
research method which complements the weakness of experimental methodology and
enables the visualization of the structure of the system to be built.Build also puts
emphasis on the reuse of existing software components to reduce the development time.
Using this methodology increases the reliability of the system being built because it is a
test driven methodology.To be considered research, the construction of the artifact must
be new or it must include new features that have not been demonstrated before in other
artifacts.In this project the use of Bluetooth beacons poses as a particularly new feature in
time and attendance systems.

3.3 Software Development Methodologies

Software Development Methodologies approach consists of procedures, standards,
techniques, an analytic framework, a philosophy and models in order to make system
development more manageable (Sullivan, 2006). It provides the step by step procedures
of how the software would be developed.
3.3.1 Agile Development For Mobile Applications
Agile development is a conceptual framework for undertaking software engineering
projects.It is an umbrella term used to describe several popular, highly iterative
software methodologies such as Extreme Programming (XP), Feature-driven
Development (FDD), Lean Development, Adaptive Software Development, Scrum, and
Crystal. Most agile methods attempt to minimize risk by developing software in short
time-boxes, called iterations, which typically last one to four weeks. Each iteration is like
a miniature software project of its own, and includes all the tasks necessary to release the
mini-increment of new functionality: planning, requirements analysis, design, coding,
testing, and documentation. While iteration may not add enough functionality to warrant
releasing the product, an agile software project intends to be capable of releasing new
software at the end of every iteration.Agile methods emphasize real-time communication,
preferably face-to-face, over written documents.Due to the nature of this project and the
review time-lines stipulated by the University code, these methods proved to be the
perfect fit to development of this project . At the end of each iteration, there was
reevaluation of the project priorities and how they where going to be met.
3.3.2 Extreme Programming (XP) Methodology
XP is a methodology for creating software within a very unstable environment. It allows
flexibility within the modeling process.The main goal of XP is to lower the cost of
change in software requirements. With traditional system development methodologies,
like the Waterfall Methodology, the requirements for the system are determined and often
frozen at the beginning of the development project. This means that the cost of
changing the requirements at a later stage in the project (something that is very common
in the real-world) can be very high.

The core practices of Extreme Programming can be grouped into four areas or 12
practices(Kent Beck,1999) as follows:
1. Fine scale feedback

Test driven development

Planning game

Whole team

Pair programming
2. Continuous process as opposed to batch

Continuous Integration

Design Improvement

Small Releases
3.

Shared understanding
Simple design
System metaphor
Collective code ownership
Coding standards or coding conventions

4. Programmer welfare
Sustainable pace (i.e. forty hour week)

A set of corollary practices are listed in addition to the primary practices(Kent Beck et al ,
2004).The core practices are derived from generally accepted best practices, and are
taken to extremes:

Interaction between developers and customers is good. Therefore, an XP team

is supposed to have a customer on site, who specifies and prioritizes work for the
team, and who can answer questions as soon as they arise. (In practice, this role is
sometimes fulfilled by a customer proxy.)

If learning is good, take it to extremes: Reduce the length of development and

feedback cycles. Test early.

Simple code is more likely to work. Therefore, extreme programmers only write
code to meet actual needs at the present time in a project, and go to some lengths
to reduce complexity and duplication in their code.

If simple code is good, re-write code when it becomes complex.

Code reviews are good. Therefore XP programmers work in pairs, sharing one
screen and keyboard (which also improves communication) so that all code is
reviewed as it is written.

Testing code is good. Therefore, in XP, tests are written before the code is
written. The code is considered complete when it passes the tests (but then it
needs refactoring to remove complexity). The system is periodically, or
immediately tested using all pre-existing automated tests to assure that it works.
See test-driven development.

It used to be thought that Extreme Programming could only work in small teams of fewer
than 12 persons. However, XP has been used successfully on teams of over a hundred
developers.

3.3.3 Feature Driven Development Methodology (FDD)

Feature Driven Development asserts that:

A system for building systems is necessary in order to scale to larger projects.

A simple, but well-define process will work best.

Process steps should be logical and their worth immediately obvious to each team
member.

Process pride can keep the real work from happening.

Good processes move to the background so team members can focus on results.

Short, iterative, feature-driven life cycles are best.

Fig The FDD project life cycle

FDD addresses the items above (numbers in brackets indicate the project time spent):
1. Develop an overall model (10 percent initial, 4 percent ongoing)
2. Build a features list (4 percent initial, 1 percent ongoing)
3. Plan by feature (2 percent initial, 2 percent ongoing)
4. Design by feature

5. Build by feature (77 percent for design and build combined)

3.3.4 Rational Unified Process (RUP)
RUP is an iterative approach for object-oriented systems, and it strongly embraces use
cases for modeling requirements and building the foundation of the system. RUP is
inclined towards object-oriented development. It does not implicitly rule out other
methods, although the proposed modeling method, UML, is particularly suited for OO
development (Jacobsen et al,1994).The lifespan of RUP project is divided into four
phases named Inception, Elaboration,Construction and Transition. These phases are split
into iterations, each having the purpose of producing a demonstrable piece of software.
The duration of iteration may vary from two weeks or less up to six months.

RUP Phases (Kruchten ,2000)

In the inception phase, the life-cycle objectives of the project are stated so that the needs
of every stakeholder are considered. This entails establishing the scope and boundary
conditions, and acceptance criteria of the project. Critical use cases are identified; these
are the ones that will drive functionality of the system. Candidate architectures for the
system are devised, and the schedule and cost are estimated for the entire project. In
following elaboration phase.The elaboration phase is where the foundation of software
architecture is laid. The problem domain is analyzed, bearing in mind the entire system
that is being built. The project plan is defined in his phase if the decision is made to
proceed to next phases at all. In order to be able to make that decision, RUP assumes that
the elaboration phase will yield a sufficiently solid architecture along with sufficiently

stable requirements and plan. The process, infrastructure and development are described
in detail. As RUP emphasizes tool automation, the support for it is also established in the
elaboration phase. After the phase, most use cases and all actors have been identified and
described, the software architecture described, and an executable prototype of the
architecture created. At the end of the elaboration phase, an analysis is made to determine
the realization of risks, the stability of the vision of what the product is to become, the
stability of the architecture and the expenditure of resources versus what was initially
planned.In the construction phase, all remaining components and application features are
developed and integrated into product and tested. RUP considers the construction and a
manufacturing process, where emphasis is put on managing resources and controlling
costs, schedules and quality. The results of the construction phase, before proceeding to
the final, transition phase.The transition phase is entered when the software product is
mature enough to be released to the user community. Based on user response, subsequent
releases are made to correct any outstanding problems or to finish any postponed
features. The transition phase consists of beta testing, piloting, training the users and
maintainers of the system, and rolling the product out to marketing, distribution and sales
teams. Several iterations are often made with beta and general availability releases. User
documentation is also produced (manuals)
3.3.5 Mobile D
This is a relatively new approach to mobile development, dubbed Mobile-D. The
methods purpose is to establish a functional, agile archetype for software development.
Its also useful in other applications, such as financial or logistical applications.It
comprises of 9 components enmeshed within the various methods associated with the
cycle of development:
1) Phasing and Placing
2) Architecture Line
3) Mobile Test-Driven Development
4) Continuous Integration

5) Pair Programming
6) Metrics
7) Agile Software Process Improvement
8) Off-Site Customer
9) User-Centered Focus
Mobile-D aims towards product delivery within 10 weeks. It grounds itself in agile
development practices, which All About Agile reports focus on trusting the judgment of
the team, communication with customers, quick turnaround on products, and frequent
testing during the projects life-cycle.Theres a crucial importance placed on team
cohesiveness, harmony, and confidence in each other. Because a close knit, committed
team is required, small teams of no more than ten members are suitable for MobileD.Communication is crucial within the team and vertically throughout the
organization.Being one of the most challenging tasks, communication often determines
the success of the project in general.Continuous interaction and communication with
customers allows project managers to discern priceless information on the target market
and its needs. This area presents unique challenges as the customer base isnt always
willing to cooperate, communicate or provide relevant insights.
The Mobile-D process comprises of 5 phases:
1) Explore
In the first phase, a strategy and the projects components are determined by the
development team. Three stages are required to complete this phase:
Stakeholder establishment
Scope definition
Project establishment

The team will complete tasks specific to this phase such as determining which customers
will take an operative role in the process of development.

2)

Initialize

The team meets with active stakeholders to understand the product and assemble crucial
assets, such as communications, technological and physical resources, to commence with
production activities. The three stages involved in this phase are:
Project set-up
Initial planning
Trial day
3) Production
The majority of implementation takes place and should be completed during this phase.
Planning days, working days, and release days are the structural driving force behind this
phase.

Planning days: Planning days are aimed at enhancing the development process,
prioritizing and analyzing requirements, planning the iteration content, and creating
acceptable tests that will be run later in release days.

Working days: During working days, functionality is implemented using the TestDriven Development (TDD) practice.
Release Days: Release days are spent creating a working prototype which will be
certified through acceptance testing.
4) Stabilize

During the stabilization phase, product finalization occurs. This may encompass fine
tuning and modifications, or in a multi-team project ,integrating subsystems if needed.
5)

System Test & Fix

As its name implies, this phase involves testing the product and ties in closely with the
fourth phase, stabilization. Stabilization and system test & fix may continue to cycle until
the product meets expectations and client requirements are met.
3.4 Influence of software development methodologies on mobile systems

(Corral et al,2013)
(Corral et al, 2013) discuss the suitability of Agile methods to fit the mobile needs, the
contribution of Agile methods to implement mobile products, the real use of the proposed
methodologies and the rise of new conditions that challenge some of the premises upon
which the proposed methodologies were designed. Agile practices allow adapting
processes and practices to the unsteady needs of the mobile domain. They also provide
flexibility to understand the market, structure the product and release it short time frames.
Agile practices may suit the business needs of the mobile environment, but fall short on
providing an implementation framework for the mobile product this is because great
focus is on the what and less on the how.Agile methods represent a relatively new

approach to software development, becoming widespread in the last decade. The ideas
behind these methods originate from the principles of Lean Manufacturing (in the 1940s)
and Agile Manufacturing (1990s), which emphasized the adaptability of enterprises to a
dynamic environment (Salo, 2006). The unique features of agile methods derive from the
list of principles found in the Agile Manifesto. It states that individuals and interactions
are more important than processes and tools, working software is more valuable than
comprehensive documentation, customer collaboration is preferred over contract
negotiation, and adaptability is valued higher than creating and following a plan (Agile
Alliance, 2001).When trying to compare mobile application characteristics to those of an
agile method, difficulty
comes partly from the fact that boundaries of agile methodologies are not clearly
established. A comprehensive overview of research in the field is presented in (Dyba and
Dingsoyr, 2009). The authors partition studies into four categories. These categories are
introduction and adaptation,human and social factors, perception of agile methods, and
comparative studies. Findings indicate that the introduction of agile methods to software
projects yields benefits, especially if agile practices do not completely replace traditional
ones, but work together with them.However, according to the authors, studies in the field
are mostly focused on Extreme Programming (XP), are limited in number and are of
doubtful quality. In (Abrahamsson, 2005),the author compares between agile method
characteristics and mobile application features,focusing on environment volatility,
amount of documentation produced, amount of planning involved, size of the
development team, scale of the application in-development, customer identification, and
object orientation. Except customer identification, all other agile characteristics render
the methods suitable for mobile application development. The customer may be identified
as the software distributor. However, especially in the case of mobile applications, the
customer identification problem is much more complex.
3.5 Chosen Methodology
In this project the chosen software development methodology is Rational Unified
Process(RUP) and the chosen research methodology is Build methodology. The

development method chosen depends largely on one key factor, the clarity of the user
requirements.RUP represents an iterative approach that is superior for a number of
reasons:

It lets you take into account changing requirements which despite the best efforts
of all project managers are still a reality on just about every project.

Integration is not one big bang at the end; instead, elements are integrated
progressively.

Risks are usually discovered or addressed during integration. With the iterative
approach, you can mitigate risks earlier.

Iterative development provides management with a means of making tactical

changes to the product. It allows you to release a product early with reduced
functionality to counter a move by a competitor, or to adopt another vendor for a
given technology.

Iteration facilitates reuse; it is easier to identify common parts as they are partially
designed or implemented than to recognize them during planning.

When you can correct errors over several iterations, the result is a more robust
architecture. Performance bottlenecks are discovered at a time when they can still
be addressed, instead of creating panic on the eve of delivery.

Developers can learn along the way, and their various abilities and specialties are
more fully employed during the entire life-cycle. Testers start testing early,
technical writers begin writing early, and so on.

The development process itself can be improved and refined along the way. The
assessment at the end of iteration not only looks at the status of the project from a
product or schedule perspective, but also analyzes what should be changed in the
organization and in the process to make it perform better in the next iteration.

3.6 Development Tools

The main development tools that were used were Android Studio,Apache web
server,PHP,EddyStone beacons,Googles proximity APIs and Parse Cloud database.

Android Studio is the official IDE for Android application development, based on IntelliJ
IDEA.On top of the capabilities you expect from IntelliJ, Android Studio offers: flexible
gradle-based build system, build variants and multiple apk file generation, code templates
to help you build common app features, rich layout editor with support for drag and drop
theme editing and much more.
The main benefits of using an Apache web server include its long history of reliability
and performance,mass adoption means there is a LOT of documentation out there and it
is very easy to get help with any trouble you might run in to,It is free and commercial
friendly(no licensing fees or costs),it will run on pretty much any OS (Linux, Windows
and MacOS),it is actively maintained and it is one of the most feature rich web servers
available.
3.7 Conclusion
In order to obtain a set of improvements to a given development methodology, one must
first analyze the key method characteristics that have yielded successful results in
previous projects.For mobile application development methods, key success
characteristics are identified in (Rahimian and Ramsin, 2008). These are agility of the
approach, market consciousness, software product line support, architecture-based
development, support for re-usability, inclusion of review and learning sessions, and early
specification of physical architecture.

1.Of Methods and Methodology." Qualitative Research in Organizations and

Management: An International Journal 3 (2008):159-168; Schneider, Florian
2.Extreme Programming Explained. Kent Beck. Publisher: First Edition September 29,
1999.

3.Extreme Programming Explained: Embrace Change, Kent Beck,Cynthia Andres.

Addison-Wesley.2nd Edition. 2004.
4. Software Development Processes for Mobile SystemsLuis Corral, Alberto Sillitti,
Giancarlo Succi,Center for Applied Software Engineering,Faculty of Computer
Science,Free University of Bozen.Bolzano,Italy May 25, 2013
5.