Monday, 1 July 2013

Editorial

Hello all,
Here is an appeal to all to contribute for the rehabilitation of victims of Uttarakhand and Himalchal Pradesh Flash Flood. Most affected are locals of these valleys like Kedarnath, Badrinath, etc.

Here are some handy links to contribute online

  1. Prime Minister's Relief Fund
  2. Goonj NGO


This time we are also re-publishing one of the article that describes history and tradition of Vari or as some of you know as Palkhi.

Happy reading!


From Management Team’s desks

Dear Decosians,

Innovation Day was successfully organized and executed in Decos NL office on Jun 21, 2013. Day was full of presentations and workshops like one on Artificial Intelligence from futurologist Yuri van Geest (from Singularity University) and workshop on “Team Work and Team Building” by boxer Arnold Vanderlyde. The purpose is to build the team spirit needed to innovate in IT solutions and services. Looking back on a very successful day, CEO and founder Paul Veger is convinced that this goal will be absolutely achieved.

Last month, we launched a drive “Innovate Ideas” with purpose to stimulate brains at DSD to share their brilliant ideas that can take shape of a product. We received tremendous response. Overwhelming count of 28 ideas has been submitted. Now as part of next step committee will go through each of these ideas and evaluate its merit & feasibility of implementation. All ideas will be shared with board directors of DTG. Thank you to all for making this initiative a success. Special thanks to Vaishnavi for successfully leading it and to Sharjeel and Nishant Patel for laying infrastructural foundation. They made it possible so that we could share and collaborate on shared ideas.

Recently we saw lot of travel from India to the Netherlands. Sanket, Balbir, Abhijit and Arindam travelled. This month we will see few more people travel. Kavita and Praneti will be travelling for Minute and join Balbir over there to give final touches to the application. Sunny and Ashish will also be travelling for gathering information and requirements of new project based on RGBZ Standards. These standards are related to case oriented working in government sectors.

In June, we started with UAT for Munro.Net application. End user response is very positive. We also started a short term new project “HQ Trands” for Munro.

First basic version of PresoPlay is available on Azure cloud. Team’s effort and output has been appreciated much by product owner Rutger. With positive energy, team is moving into next phase of developing more advance feature sets.

ITyX team delivered first phase of product fileee (iOS application) to the customer.
Minute project is in its last phase of launch. Paul, Martin, Roel, and Rutger are working aggressively on marketing it in Europe and US. We are hopeful that this app will be a huge success.

In continuation to effort towards “Go Paperless”, all those who opted for Lumias have received the same. Second batch of iPad Minis have also been distributed and we have seen lot of excitement in people with both devices. Those who are still waiting for iPads will be getting it soon. As communicated in earlier edition, we will be buying these devices in batches.

Vari… a spiritual journey to Pandharpur

- Subodh Patil

Being in Pune we all are at least aware of the words like Vari, Palakhi, Pandharpur, Vithoba etc.

Every year in the month of Ashadh (month in Marathi-Hindu Calendar which falls somewhere in June-July) and Kartik (month in Marathi-Hindu Calendar which falls somewhere in November) many people walk to Pandharpur (make the pilgrimage to Pandharpur) with Palakhis (palanquins) of saints from respective saints’ Samadhis (spiritual birthplaces). And this is called as Vari though it has many different spiritual and social aspects. The Vari or the periodic pilgrimage to Pandharpur is a living tradition of Maharashtra.

The people who participate in Vari are called as Varkari. The Varkaris are pilgrims vowed to visiting the sacred city of Pandharpur. Pandurang, for them, is the cosmic spirit that is present simultaneously within all space and time, and also beyond!

The Varkari tradition has affected the life of the common people of Maharashtra for six hundred years (from 13th century to 18th century). Varkaris look upon God as the Ultimate Truth and ascertained grades of values in social life but accepted ultimate equality among men. The Vari was started in the current form by Saint Tukaram's son Narayan maharaj in 1685. But it is believed that the first pilgrimage was done by the parents of Saint Dnyaneshwar in the 13th century and their son Saint Dnyaneshwar during his time popularized it.

The current famous Vari’s of Sant Tukaram Maharaj and Sant Dnyaneshwar Maharaj starts from villages Dehu and Alandi respectively, which are in Pune district and adjacent to the city.

This year the Sant Tukaram and Sant Dnyaneshwar Palakhis started their journey to Pandharpur from 22ndand 23rd June respectively; with more than 2 lakhs of people participating. On the last day i.e. on Ashadhi Ekadashi (11th day in Marathi month Ashadh, this year 19 July 2013) around 12-15 lakhs people are expected to come to Pandharpur from various parts of Maharashtra. The Varkari’s walk 100’s of miles to Pandharpur for more than 3 weeks to meet lord Vithhala.

Vithoba also known as Vitthala and Panduranga is a Hindu god, worshipped predominantly in the Indian states of Maharashtra, Karnataka, Goa and Andhra Pradesh. He is generally considered a manifestation of the Hindu god Vishnu or his Avatar (incarnation) Krishna. Below is the photo of Vithhal from very famous Pandharpur Mandir (Temple).



Sant Tukaram (1608–1650) was a prominent Varkari Sant and spiritual poet during 17th century. He has written around 4 and half thousands Abhangs (form of devotional poetry sung in praise of the Hindu god Vitthala). Abhang is Marathi word where bhang means - to break; a- bhang is opposite of bhang i.e. which does not break. It’s one of the ways to praise the Lord. Tukaram’s Abhangas are so beautiful that their translation from the booksays Tuka by Dilip Chitre have been included in The Longman Anthology of World Literature Volume C -The Early Modern Period published by Pearson Longman, New York.

The beauty of Vari is that all kind of people walk together. It presents a perfect amalgamation of all castes, creed, rich, poor, young, old and children. And this explained in more beautiful way in one of a popular abhang “Khel Mandiyela….” by Sant Tukaram; which says about the spiritual meaning of Vari and highlights many of its aspects.
खेळ मांडीयेला वाळवंटी घाईनाचती वैष्णव भाई रे |
क्रोध अभिमान गेला पावटणीएक एका लागतील पायी रे ||
गोपीचंदन उटी तुळशीच्या माळाहार मिरविती गळा |
टाळ मृदुंग घाई पुष्पवर्षावअनुपम्य सुखसोहळा रे ||
वर्ण अभिमान विसरली यातीएक एका लोटांगणी जाती |
निर्मळ चित्ते झाली नवनीतेपाषाणा पाझर सुटती रे ||
होतो जयजयकार गर्जत अंबरमातले हे वैष्णव वीर रे |
तुका म्हणे सोपी केली पायवाटउतरावया भवसागर ||.

Vari is not something to explain by what the above abhanga means; but needs to experience it to understand it more. However the short summary of this poem is all kind of peoples make pilgrimage without thinking of their cast, age, religion etc. They all are dancing with joy while chanting the holy name of lord. This all is pleasant to watch. And this is the way Sant Tukaram has shown us to reach to the lord.

You can find more updates and photographs on this year’s Vari at http://esakal.yolasite.com/.
References: Wikipedia, http://www.tukaram.com, Dilip Chitres’ articles

Indicative Function Point Count – An overview

- Hariharan Menon

As an organization we often do software estimates. These estimates help us determine the answers to the following questions-
  • How much money (in US $/EUR) it would cost us to develop this software?
  • How many people need to work to create this software?
  • How much time (in days/months/years) would be required to develop this software?

Function Point Analysis (FPA) is a method used to measure the functional size of software. In FPA the size estimation is done on the basis of functional requirements. This method relies less on estimator's potential bias & prior experience and is a more accurate though costly standard based process.

Using FPA, the functional size of software i.e. the size of the software to be developed is measured in number of function points. Please note that the functional size represents the size of the functional requirements. Also the term “functional requirements” represents WHAT functionality would be included in the software. In simple terms, functional size is the size of what the software must do from an external, user perspective, independent of how the software is constructed or how well it must perform.

For a new development project, the functional size is the size of all of the newly developed functionality. For an enhancement project, functional size is the total size of all functional requirements that are new, changed or removed from the software.

To count function points we basically check the following logical components of the software based on the functional user requirements-
  • Internal logical files (ILF) - Data maintained by processes within the software
  • External interface files (EIF) - Data referenced by processes within the software
  • External inputs (EI) - Processes that enter data to be stored within the software
  • External outputs (EO) - Processes that extract derived data to be provided to the user
  • External Inquiries (EQ) - Processes that retrieve stored data to be provided to the user

Context diagram for Function Point

Creating a full-fledged FPA estimate requires time & detailed requirements which might not be always available. At the initial stages of a project where there is need to understand at a high level the estimates required to complete the project or to make a “Go/No-Go” decision we can use a method called Indicative FP. Indicative FP is a method proposed by NESMA (Netherlands Software Metrics Association) and is referred to as "the Dutch method".

The Indicative function point count can be calculated in following steps:
  1. Identify the number of data functions(ILFs & EIFs)
    1. Identify the count of ILFs (#ILF)
    2. Identify the count of EIFs (#EIF)
  2. Calculate the total unadjusted function point count of the application as follows: Indicative Size (UFP) = 35 × #ILF + 15 × #EIF 
  3. Here #ILF represents the count of ILFs and #EIF represents the count of EIFs

Thus this estimate is based solely on the logical files (ILFs and EIFs) which are present.
The indicative function point count is based on the assumption that there will be about three EIs (to add, change, and delete information in the ILF), two EOs, and one EQ on average for every ILF, and about one EO and one EQ for every EIF.

Case Study 1:

In above Customer Input screen, the “Add Customer” button causes the Customer data maintained inside the application boundary to be updated with the fields entered by the user.
The “Clear Screen” button causes all of the fields to be erased.
The “Error Message Window” displays any errors associated with validations performed against an externally maintained Zip Code Data file after the “Add Customer” button is pressed.

Solution:
Step1: Identify the number of data functions (ILFs & EIFs)
Step 1.1: Identify the count of ILFs
ILFs:
1.       Customer data
Total ILF Count (#ILF) = 1

Step 1.2: Identify the count of EIFs
EIFs:
2.       Zip code data
Total EIF Count (#EIF) = 1

Step2:
Indicative Size (UFP) = 35 × #ILF + 15 × #EIF = 35*1 + 15*1 = 50

Case Study 2:
The user requires the Human Resources application to provide the following capabilities:
  • The software application must store and maintain employee information
  • The software application must store and maintain department information
  • All foreign employees must be paid in Euros
  • When the user adds or changes employee information, the Human Resources application must access the Currency application to retrieve a conversion rate. 
  • After retrieving the conversion rate, the HR application converts the employee’s local rate to a Euro rate using the following calculation: standard local rate ÷ conversion rate = Euro rate. 

Solution:
Step1: Identify the number of data functions (ILFs & EIFs)
Step 1.1: Identify the count of ILFs
ILFs:
1.       Employee data
2.       Department data
Total ILF Count (#ILF) = 2

Step 1.2: Identify the count of EIFs
EIFs:
1.       Currency Conversion Rate data
Total EIF Count (#EIF) = 1

Step2:
Indicative Size (UFP) = 35 × #ILF + 15 × #EIF = 35*2 + 15*1 = 85

Case Study 3:
The following list represents a sample set of user requirements for a new development software project:

  1.  The software application must store and maintain employee information consisting of the following data fields: name, employee number, rank, street address, city, state, ZIP code, date of birth, phone number, office assigned, and the date the employee data was last maintained.
  2. The software application must provide a means to add new employees, update employee information, terminate employees, and merge duplicate employee records (in cases where all fields other than employee number are identical).
  3. The software application must provide a scheduled weekly report. Its header includes the Report Period and provides a retrieved list of all employees (Name and Employee Number) where information has changed within the previous 7 calendar days (report period).
  4. The application must provide a means for the end user to view an employee’s data.
  5. User security data (user ID, password) is referenced from the security application for user logon security validation.
  6. Complex algorithms are used to encrypt the employee date of birth so that it cannot be directly read from the information stored for an employee.
  7. The software application must provide sub second response time for data maintenance processes during the peak business hours between 8 a.m. and 5 p.m. Eastern USA Standard Time (GMT – 5).
  8. The software application must use programming language(s) that are compatible


Solution:
Of the preceding list of user requirements, 1 through 5 represents the functional user requirements, while 6 through 8 are non-functional (quality and technical) requirements. Only requirements 1 through 5 will be used to determine the functional size of the software.

Step1: Identify the number of data functions (ILFs & EIFs)
Step 1.1: Identify the count of ILFs
ILFs:
1.       Employee data
Total ILF Count (#ILF) = 1

Step 1.2: Identify the count of EIFs
EIFs:
2.       Security data
Total EIF Count (#EIF) = 1

Step2:
Indicative Size (UFP) = 35 × #ILF + 15 × #EIF = 35*1 + 15*1 = 50

Summary:
To summarize Indicative FPA is an extrapolative approach to size approximation. The strength of this type of count is that one easily gets a rough estimate of the size of an application in only a very short time.

Acronyms:
  • FPA: Function Point Analysis
  • ILF: Internal Logical File
  • EIF: External Interface File
  • EI: External Input
  • EO: External Output
  • EQ: External Inquiry


References:
  • NESMA (Netherlands Software Metrics Users Association), www.nesma.nl
  • Practical Software Project Estimation: A Toolkit for Estimating Software Development Effort & Duration. Compiled and edited by Peter R. Hill
  • Certified Function Point Specialist Examination Guide by David Garmus, Janet Russac & Royce Edwards

Test Estimations

- Sudhir Bhagat 

There are different standard and non standard methods for test estimation. In many product based companies, people utilize non standardized but conventional estimation methods to make things work. These methods might have developed over a continuous period accommodating hidden factors like nature of application under test, environment, and risk factors for that specific product/market. But these methods can’t be adopted as a generalized organization standard for a mature operation model.

We will discuss following methods for test estimation:
1. FIA (finger in the air) or best guess
2. Ad-hoc method
3. Experience Based - Analogies and experts
4. WBS
5. Delphi technique
6. Three-point estimation (successive calculation)
7. Function points / Test point Analysis
8. Percentage of development effort method
9. Percentage distribution
10. Use case point estimation method
 
Lets discuss one by one:
1. Best Guess – This technique is purely guesswork and based on the some sort of experience.
The method is very common, but since it is based on your gut feeling, its uncertainty contingency is probably around 200% or even higher.

2. Ad-hoc method - The test efforts are based on tentative timeframe. The timeline set by managerial or marketing personnel or by client without any guess/experience. Alternatively, it is done until the budgeted finances run out.
This is very common practice in extremely immature organizations and has error margins of over 100% at times.

3. Experience Based - Analogies and experts: 
Metrics collected from previous tests.
You already tested similar application in previous project.
Inputs are taken from Subject Matter experts who know the application (as well as testing) very well.

4. Work Breakdown Structure - It is created by breaking down the test project into small pieces. Modules are divided into sub-modules. Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities.
Review all the requirements from Requirement Document to make sure they are added in WBS. Now you figure out the number of tasks your team needs to complete. Estimate the duration of each task.

5. Delphi technique – Same as above WBS. Here functionalities and each task are allocated to each team member. Then team member gives estimate that they will take this many hours to complete the task.
Averagely, this technique gives good confidence in the estimation. This technique can be combined with other techniques.

6. Three-point estimation – This technique is based on statistical methods in this technique, task is broken down into subtasks (similar to WBS) and then three types on estimation are done on each chunk.

Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = a
Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.) = m
Pessimistic Estimate (worst case scenario which everything goes wrong.) = b
Formula to find Value for Estimate (E) = a + (4*m) + b / 6
Standard Deviation (SD) = = (b - a)/6

7. Function Point/Testing Point Analysis: The FP technique is a direct indicator of the functionality of software application from the user's perspective. This is the most accepted technique used to estimate the size of a software project.
Base of this technique is function point technique. Here we convert function points into test points. In Test Point analysis, we usually carry out the following: 
Dynamic Test Points
Static Test Points
Environmental Factor
Productivity Factor
Primary Test Hours
Control Factor
Total Test Hours

In Testing, This estimation is based on requirement specification document, or a previously created prototype of the application. To calculate FP for a project, some major components are required.
The major components are:
Unadjusted Data Function Points: i. Internal Files, ii. External Interfaces
Unadjusted Transaction Function Points: i. User Inputs, ii.  User Outputs & iii. User Inquiries
Capers Jones basic formula:
Number of Test cases = [Number of Function Points] x 1.2
Total Actual Effort, TAE = (Number of Test cases) * (Percentage of development effort /100)
This method is done in a case when a detailed low level design document or requirement document is available (i.e. measure of function point is available) & Previous data for development and testing is available. But now days, when we are using agile and iterative methodologies to deliver projects, so most of the times all this documentation is not available.

8. Percentage of development effort method
Here the assumption is that a more complex business application may require more testing effort. The test effort required is a direct proportionate or percentage of the development effort.

Note: The development effort can be estimated using line of code (LOC) or function point (FP) which is not in the our scope.
Example:
If a previous project with 500 FPs required 50 man hours for testing, the percentage of testing effort is calculated as:
P = (50 / 500) * 100 =10%
For the current project with a development effort, say 1500 FPs, the testing effort is:
Total Actual Effort, TAE = 1500 * (P/100) = 1500 * (10/100) = 150 man hours.

9. Percentage distribution – Here all the phases of SDLC are divided in parts and assigned effort in %. Like –
Project management 7%
Requirements 9%
Design 16%
Coding 26%
Test (all test phases) 27%
Documentation 9%
Installation and training 6%
Now testing % is further distributed into all testing phases:


OR 

All phases
%
Component testing
16
Independent testing
84
Total
100
Independent testing
%
Integration testing
24
System testing
52
Acceptance testing
24
Total
100
System testing
%
Functional system testing
65
Non-functional system testing
35
Total
100
Test Planning and Design Architecture
50%
Review phase
50%

10. Use case point estimation method: Use case point (UCP) method is gaining popularity because now-a-days application development is modeled around use case specification. The test case development is normally kicked off after baseline use case. So the various factors in use case give a direct proportion to the testing effort. 
Use case is a document which well specifies different users, systems or other stakeholders interacting with the concerned application. They are named as ‘Actors’. The interactions accomplish some defined goals protecting the interest of all stakeholders through different behavior or flow termed as scenarios.



UCP Estimation Method in brief:
1. Obtain unadjusted actor weight (UAW)
2. Determine unadjusted use case weight (UUCW)  
3. Calculate unadjusted use case points (UUCP) UUCP = UAW + UUCW
4. Determine the technical/environmental factor (TEF)
5. Compute the adjusted use case point (AUCP) AUCP = UUCP * [0.65 + (0.01 * TEF)]  
6. Arrive at final effort using a conversion factor Total Actual Effort = AUCP * CF

Conclusion
There can’t be a sole hard and fast rule for estimating the testing effort for a project. There may be different other methods also which can be effectively used for the purpose. 

Four quadrants of time management

- Abhijit Khot

Everything you do in life can be classified as:
  • Urgent / Not Urgent
  • Important / Not Important.

Most people spend their lives focused on the Urgent things regardless of their importance. In business as in life it is extremely important to always ask yourself: “Am I doing this because it is truly important or am I doing this just because it is urgent?”


Only focus on the important things — ignore everything else regardless of the urgency.

Quadrant 1: IMPORTANT AND URGENT
Firefighting mode: Crises, real hard deadlines for important project, health & family emergencies, etc…
These are things you cannot and should not ignore.  However spending too much time in this Quadrant will lead to stress and burn out — you will be caught in a never-ending cycle of crisis management and fire fighting.

The only way to reduce the time you spend in this quadrant is to be proactive and to spend more time on the important things BEFORE they become emergencies.

Quadrant Example :
Dealing with a heart attack is an Urgent and Important problem (Q1) that cannot be ignored — but maybe if you would have spent more time eating healthy and exercising (Q2) you could have avoided it altogether.

Quadrant 2: Important but not urgent
This is where you should spend most of your time.
Activities in this quadrant include planning, prevention, capability improvement, relationship building, recognizing new opportunities, etc…

Spending your time in this quadrant will lead to:
  • Clear vision
  • Balanced life
  • Discipline
  • Control
  • Very few crisis situations.

Quadrant Example:
  • Eating healthy and exercising to avoid future health issues.
  • Preventative maintenance on your home, car, bike.
  • Saving and budgeting money.
  • Reading, Learning, and Education.
  • Forming bonds and strengthening relationships with your friends and family.
  • Self updating and spending time on things that inspire and uplift you (like working on a Hobby).
  • Frequently buying chocolates and flowers for your daughter/wife/girlfriend “Without a reason”.

Quadrant 3: Not important but urgent
People spend a big portion of their time in this Quadrant confusing Urgent things for important things.

This Quadrant is full of pressing matters: Interruptions, Ringing phones, emails, etc…  Spending too much time in this quadrant leads to a very short-term focus with continual crisis management. You will begin to see plans and goals as useless since you are unlikely to have time to devote to them.  Your relationships and reputation will suffer and you will feel victimized with no control over your life. (Stay away from this quadrant: Puppies will almost certainly die).


Quadrant Example :
You have scheduled an important meeting with a co-worker 2 weeks ahead of time.  This person has very limited time and so you carve out a 30 minute window to deal with a very important matter.

As you sit down and start the meeting, your phone starts to ring.  The phone is screaming: “Pick me up! Pick me up! Pick me up!”

Most people will pick up the phone and sacrifice the Important but not urgent meeting for the Not Important but Urgent ringing phone.

Quadrant 4: Not urgent and not important
Quadrants 4 things are the time wasters in your life:
Spending too much time in this quadrant can lead to dependence on others for your basics, loss of jobs, irresponsibility, etc…

Quadrant Example :
  • Trivial busy work
  • Mindless web surfing
  • Watching too much TV
  • Lots of pleasant activities.

What’s now? How do i use this to make my life better?
Identify quadrant 2 activities

  • Write down all the Quadrant 1 and 3 activities you routinely do (all the Urgent stuff)
  • Write down how you can prevent these things from reoccurring or from becoming emergencies in the first place: These are your new Quadrant 2 activities.

Free up time for quadrant 2 activities

  • Look at all the things in Quadrant 4 and stop doing them!
  • Look at all the things in Quadrant 3 and stop doing them too.  This is more difficult as it involves saying NO to people.
  • You should now have time to spend on Quadrant 2

Schedule time for quadrant 2

  • Schedule time to do Quadrant 2 activities. (Put them in your calendar just like a meeting).
  • Do thing you scheduled





Reduce quadrant 1
  • The beauty with spending more time in Quadrant 2 is that it should slowly chip away at all your Quadrant 1 activities.
  • As you reduce your Quadrant 1 activities you have more time for Quadrant 2, creating a fly-wheel effect.

Simple, right?
Not quite.  The Question “What is important to me?” usually does not have a simple answer.

Example 1: going to a movie or sporting event (at multiplex or ipl, etc…)
Which quadrant does this fall into? The answer is it depends on yourpriorities and what is important to You. On the surface it looks clearly like a Q4 item – a time waster.  Not urgent and certainly not important.

But, it could be a Q2 event (important) if you consider the event to be an opportunity to spend quality time building relationships with your parents, children, or friends.

Example 2: Watching TV
Clearly another Q4 item: A time waster.  Or is it?  If watching TV is a stress reliever for you and serves as a way to wind down and chill out after a hectic day, it could very well be a Q2 activity.  Just as long as you frame it correctly and consume it in the right way.

To be successful with this method you must have a very clear understanding of what is important to you, what your long term goals are, etc…  But that will be the topic for another day.