Thursday 16 May 2013

Social Gaming : Changing face of Computer Games


Social gaming has brought in a huge change in the pattern of computer gaming in the last 5 years or so. There used to be a time during our college days when people were crazy about Car racing games (like NFS) or War games (like Call of Duty). Unfortunately these games were popular only among a age group and section of the society.
Social gaming has brought in a huge inclusion of people including senior people, college goers, kids, housewives etc.
The console based video games market has lost the market considerably to the mobile game market.

One of the key reasons for its popularity is that this is a much relaxed form of a game and does not need you to do lot of things in rush. It does not require much concentration and so can be a quick way of relaxation.
Facebook games make the user experience much better and easy to understand for everyone. There is no disadvantage of starting late in such games and one can catch up very fast with one's peers.
People can form a group of friends who can help each other and get benefited  Instead of being possessive to not provide any help to others, people tend to share things to advance in the game.
The interactive dashboard makes everyone competitive with their peers. The games are very very easily accessible and does not need any high configuration/resolution hardware.

Researches say that more than 80 million people play social games atleast once a day and around 50 million play multiple times a day.

Farmville & Mafia Wars are still the most popular games in US & UK.
Casino related games like Casino, Soloto mania are the most popular so far followed by Hidden object games like Gardens of Time, Criminal Cases etc.
Role playing games like Zombie Lane also are very popular among people.

The primary developers are Zynga, EA, Woonga etc with various products for various choices & options.




Friday 28 December 2012

Smarter Release Management with Continuous Integration & Continuous Delivery

About this Article

This white paper aims to help readers understand Continuous Integration and Delivery as a concept and practice in software development projects that follow the Agile methodology.

The content organization is as follows:

  1. The first section explains the benefits of the model.
  2. The next section describes the processes to be established for Continuous Integration and Continuous Delivery.
  3. The conclusion summarizes how Agile methodologies involving Continuous Integration and Continuous Delivery can help improve considerably the customer/market readiness of product releases.

 Continuous Integration and Continuous Delivery

Releasing software is a complex and at times arduous process, well known for  compelling already  overworked professionals to extend  their workdays/nights and weekends  to ensure that the release is made. It always tends to become a stretched effort  despite  project scheduling and task estimates.
Over time we realize that the stretch and slippage is because of multiple factors which can be categorized as known knowns and known unknowns that inevitably surface in the course of a release.
Continuous Integration and Continuous Delivery is a practice recommended by the Agile software development methodology which has been able to deal with some of the traditional challenges of development to help product teams optimize and create a streamlined iterative  release management process that is predictable to a large extent.

What facilitates the process

Mindset of Minimum Viability: In Continuous Integration and Continuous Delivery we develop a small but fully functional feature-set rather than sweat over an ambitious list of features that inevitably results in  partially functional and often a buggy release. The key is to change the mindset of the team. Every team member needs to understand that the customer needs a set of completely working features rather than a big  list of partially functioning ones.
Right size Rule: Y.A.G.N.I. or the You ain’t gonna need it principle helps make the change. During product development the team should question and challenge the premise of the release so that we arrive at the “right size” of the release that  meets the customer’s expectations of the product.

 

 

Benefits

Product watchers have found that typical  user communities use only a part of a product’s feature set. For instance, survey statistics indicate that 90% of MS Word’s user community uses just about 10% of its functionality. Hence it is very important to develop the right set of functionality and release to the customer when they need it.  The benefits of this approach are multifold.
·         Faster go-to-market
Agile teams are better equipped to make interim, small and more impactful releases to meet the needs of customers/market as compared to non-agile teams.

 

 
·         Smart Product Backlog Management

 
Features and releases can be made available as per the request and need of customers, and yet at the same time product teams can continue work on their planned monthly or quarterly releases.
 
 

 
·         Real time response to Customer issues

 
 

Value and viability of a product’s features cannot be realized until the product is delivered to the customers for their use. If delivery and usage is established in cyclic and short time frames the feedback-response cycle can be addressed in almost real time.

The continuous delivery model helps to get iterative and quick feedback from the customers as to what is right, what is wrong and what they really want features to do. By this Agile method, instead of building the whole product we build the smallest possible useful part and give it to users, for validation.
 
 

 
·         Customer Delight

 
 

In the Agile development model, incremental cycles of two to four weeks of development and delivery enable the development team to release what one can term as the

Minimum Viable Product (MVP) or Minimum Marketable Features (MMF) within projected timeframes. Meeting customer friendly deadlines in this manner indicates that product releases when driven by customer needs leads to a higher level of customer satisfaction.
 
 

 
·         Investing in the right areas
One of the real challenges in developing software products is to ensure investments both monetary and effort are channeled in the right direction.

The Continuous Integration and Delivery model helps mitigate the risk that comes with the question “Are we building the right product?” to a large extent.  Since this methodology is inherently nimble it enables immediate course correction in terms of ensuring the right features are released to customers. Figure1, gives picture of the itirative processes which form the complete cycle.
 
 

                       Figure 1 (Source: http://www.collab.net/solutions/devops)
·         Minimal risk of failure

 
It is important to have the features  ‘Production ready’ always, even after changes are made to the code, database or configuration. Incremental development, testing and release
 
reduces  the quantum of ‘untested’ or ‘unreleased’ features as illustrated in Figure 2. This not only makes it easier to control the quality of the deliverable but also enables easier roll back to the pre-change state, in case of failures.

 
                 
                    Figure 2 (Source: http://www.collab.net/solutions/devops)

Core principles of the Practice

1.    Continuous Integration – across sites and timezones

The essential requirement here, for the multi-function teams –  development, testing and documentation, is that the features are continuously built, tested and integrated. This process also supports teams working in multiple geographical locations and across time zones to effectively collaborate and deliver fully functional releases.
·         Test as you develop the product  

The cost of quality of any software product  is closely tied to the time of finding errors in its functioning. In other words, for every bug detected early in the development process, the cost of quality reduces dramatically.
 
 

 
In a typical waterfall project  we get to the  testing phase in a sequential manner after the development phase is  completed. This  not only delays the point of catching defects but also increases the impact of the bugs in the form of re-work which in turn impacts delivery schedules. One way to mitigate the risks of increase in cost of quality and impact due to missed deadlines, is that testing should go hand-in-hand with  development.  
The question is can this be done? Figure 3 explains the process flow which can help to resolve this issue.
                         Figure 3 (Source: http://www.dynacrongroup.com/about/continuous-delivery/)
 
The key is to continuously integrate development and testing activities in a manner that enables software to get  tested  incrementally along with development  so that the issues get detected and fixed  at the earliest.
·         Automate the Build process

 
For product testing to be in synch with development so that it is effective,  the QA  team has to have their test environments (also known as the QA Build) ready at any point in time to be able execute their test cases.  The key requirement here is to have a process   that “builds and delivers” the QA Build on a regular basis.   Automating the build creation process becomes key in order to ensure that the QA Build  is ready for deployment  well before the QA team is ready to start testing. Further, this automation also releases considerable amount of time for developers to focus on core development activities as opposed to tasks associated with the process of packaging and building the release for testing.
Ready to use build-automation applications can be used to establish such an automated build  mechanism.
 
 

 
For the purpose of this paper, we refer to the following  tools:
·         Microsoft Unit Testing framework – used to execute automated service testing for  every

check-in
 
 

 
·         FinalBuilder – used to automate the generation of a daily build. Figure 4 shows a snapshot of FinalBuilder setup.
 
 
Figure 4
·         Build the product on every code commit

 
 

For build-automation to be successful, integrity of the code-base has to be such  that the software product can easily be compiled without any error. The bigger the code base  the higher  the risk of integrity-loss and error free build.

For example, in a team of 40+ developers if every developer encounters even an hour of code-integrity related issue it leads to a 40 hour loss in productivity. It is therefore very important that every  piece of code written,  is checked-in or committed to the main baseline at least once in a day so that the next  build can reflect the updates.

 

 
Use of the testing frameworks such as Microsoft Unit Testing framework to execute automated service testing, helps ensure that the impacted services work as expected with every check-in. A snapshot of such unit test configuration is given in Figure 5.
 

 
Figure 5
The build-automation process must trigger a build after every commit to the main baseline code base and it must also ensure that there are no build related issues after every

check-in/commit.
 

 
Tools such as FinalBuilder reports check-in issues to the concerned developer. An integrated messaging and reporting system built into it reports build-failures to a  team of build owner(s). As a result the build owner(s) can immediately log in (even from home) to resolve   the reported issue, thereby minimizing the risk of non-availability of the QA Build for the testers on any given day. This particular ability allows distributed agile teams to work effectively withou any loss of time due to possible time zone issues. The QA team starts every day by installing a fresh build to carry forward product testing. Automating a timed-install of the QA Build can make it even better by freeing the time spent in manual installation for testing.
·         Automating regression testing  

 
The Scrum model usually discourages manual regression testing. This is because in a development cycle  defects are expected to be fixed and closed during the scrum cycles – known as sprints. There is no room for defects to creep to a ‘regression test cycle’ in this methodology. In real practice however, despite incremental development and testing   there can be integration or system level issues that necessitate additional testing. Assigning resources to such testing can lead to unavailability of testing bandwidth for  the planned sprints. The recommended practice to minimise  time and resource investment for regression testing will involve the following steps
 
 

 
o    learning from the previous regression cycles
o    identify such defects or patterns of defects
o    set up automated procedures for testing them
o    run the automated procedures regularly to test the stability of critical functionality
·         Simulate a production-like environment for daily testing

Considerable time and effort is spent by developers and testers trying to replicate reported defects  It is therefore very important to simulate the real-time environment to enable effective testing of software.  For all practical purposes, there should be a production like environment that mimics the actual set up at the customer site.  This allows the QA team members to not just catch the functional issues but also test  the environment or installation related parameters as well.
 
 

 

2.    Continuous Delivery – to the “remote” customer

The essential requirement here is to deliver to the customer who is “remote” in relation to the development teams.
·         Delivery Pipeline

 
 

The Continuous Integration processes both manual and automated,  create a pipeline of steps where one process or step  waits for the previous one to be complete.

If not well planned, this approach poses the risk that it will not be possible for the product team to optimize the time for complete deployment. This situation as illustrated in Figure 6, is termed as ’Insufficient Parallelization’.
 

 
 
       Figure 6 (Source: Continuous Integration, Martin Fowler & Jez Humble)
 
The most preferred way to overcome this is to make the pipeline as wide and short as possible.  Conscious effort has to be made to eliminate the risk of queuing up the processes. Figure 7 illustrates how to bring in parallel processes to decrease the waiting time for deployment.
 
 
                        Figure 7 (Source: Continuous Integration, Martin Fowler & Jez Humble)
 
·         Automated Continuous Deployment

Continuous Deployment is a part of the Continuous Integration and Continuous Delivery process where every build gets deployed into a production like environment. This environment can be used by the QA team or even the customers. Any such deployment can happen easily with an automated process in considerably less time as compared to manually deploying the application components.
 
 

 
With  the latest software   always made available to  customers for exploration and use at their own time it has given them  great flexibility to use and validate regular releases.
·         Automated Acceptance Test

 
 
Acceptance Testing (AT) is very much a relevant process that contributes tremendous  value in the development and release phases. It is the most effective way to know if the software is meeting the objectives of the customer . It answers the question- are we building the right product?
 

 
Teams create one or more AT for each user story to ensure that the feature works per expectations. The acceptance test process is automated with the test results made visible to the stakeholders. As active stakeholders, customers  are responsible to check the results and set the priority for  resolution of the reported cases. Ultimately it is the responsibility of the development team to allocate time to correct  the features that have failed the acceptance tests.

Conclusion

In today’s world customers are not prepared to wait for long time-frames to receive features and then find out that the product is only partially meeting their needs. This has intensified the challenge for  software development organizations to find ways to deliver periodic releases as and when the customers want.
We believe Continuous Integration and Continuous Delivery is gaining more acceptance in the industry because of its capacity to enable teams to deliver solutions of value, in considerably shorter timeframes.
Industry studies report that most organizations take to Agile methodologies very well in the engineering phase but almost always follow a more tradtional release plan of doing a few fixed releases a year.  Here again, Continuous Integration and Delivery can help release well tested list of features in small bit sized chunks that lead to greater adoption by customers . There are industry figures that indicate upward of 80% improvement in  testing and release effectiveness, when this methodology was deployed.
The approach being very much customer centric ensures that  the customer is co-opted into the development process, and results in an inherent commitment on the part of the customer to adopt the product and use it.  This leads to a win-win relationship both for the customer as well as the vendor developing the software. 
 
References:
1.     Rapid Development: Taming Wild Software Schedules, Steve McConnell, Microsoft Press, 1996.
2.     Continuous Integration, Martin Fowler & Jez Humble
7.     http://www.collab.net/solutions/devops