Saturday, July 28, 2018

It Is About "Design Thinking"

Source: https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process

What is Design Thinking and Why?

Design Thinking is a methodology used by designers to solve complex problems, and find desirable, practical, creative resolution to the clients. A design mindset is not problem focused but  solution focused and acting towards creating a preferred future.

Thinking like a designer can change or enhance the way organizations develop products, services, processes or even strategy. It can bring together what is desirable from a human point of view with what is technologically feasible and economically viable.


Source: https://www.ideou.com/pages/design-thinking


5 Stages of Design Thinking Process ?

The design thinking process has various stages including:

  • Empathize
  • Define
  • Ideate
  • Prototyping
  • Testing 

The steps can occur simultaneously and be repeated.

Empathize

The first step of the design thinking process it to gain understanding or empathize about the problem you are going to solve. Empathy allows design thinkers to set aside his or her own assumptions about the world in order to gain insight into customers and their needs. 
This can be achieved by speaking to the subject matter experts to gain more knowledge about the domain or observing the problem area or even talking and empathizing with people who are experiencing the matter.

Adding my opinion in to this, in requirements gathering I always believe that you need to act dumb to get the information well. This helps you to go in to the shoes of the stakeholder and think about the problem and feel the problem.

Define


During this stage, put together the information gathered during the earlier stage and analyse your observations and synthesize them in order to define the core problems that you and your team have identified. Generate the problem statement.
This stage will help the team to gather great ideas to establish features, functions, and any other elements that will allow them to solve the problems.

Ideate


This means forming or generating ideas. With this solid background formed at the first two stages (Empathize and Define) your now ready to  'think outside the box' to identify new solutions to the problem statement you’ve created, and you can start to look for alternative ways of viewing the problem.

Idea generation can be done by using the below techniques:
  • Brainstorming
  • Brain-write
  • Worst Possible Idea
  • Scamper
Brainstorm and Worst Possible Idea sessions are used to stimulate free thinking and to expand the problem.

You should pick some other idea generating techniques such as focus groups work shops by the end of this phase to help you investigate and test your ideas to find the best way to either solve a problem, or provide the elements required to circumvent the problem.

Always talk of what you believe that should  be there in the system, standing in the customers shoes. Do not ignore any idea but consider every possibility in order to create the best value to the customer. Remember they pay you for this system and you should create value for it. Not to forget the rework you would have to do if you do a unsatisfied/ lame business, it is better to think and do the best as possible in one go. 

Prototype

The aim of this stage is to identify the best possible solution for each of the problems identified during the Empathize, Define and Ideate stages. The prototype do not have to be a half baked application all the time but a user interface narration or even sets of UIs would be enough for this stage. The solutions are implemented as prototypes and are investigated to accepted, improved and re-examined or rejected on the basis of the user experiences. 

By the end of this stage, you should have a better idea of the constraints inherent within the product, the problems that are present, and have a better understanding of how real users would interact with the end product.

Do not forget to consider the UX aspects of the User interfaces (UIs). The age groups of the users, thinking pattern, likes and dislikes to colors and every other small detail. Try to use the standards when designing the UIs.

Test

Test teams should test the complete product using the best solutions identified during the prototyping phase. This is the final stage of an iterative process.

The test he results generated during the testing phase are often used to define the problems. Alterations and refinements are made to the prototype even in this stage in order to rule out problem solutions and derive as deep an understanding of the product and its users as possible.

The results from the testing phase may reveal some insights about users, which in turn may lead to another idea generation or the development of new prototypes. and this is why design thinking is non linear and more flexible in practice.


Source: https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process


Ex: More than one stage may be conducted concurrently by different individuals/groups within the team, or the designers may collect information and prototype during the entire project so as to enable them to bring their ideas to life and visualize the problem solutions. Or as I mentioned testing phase may reveal some insights about users, which in turn may lead to another idea generation or the development of new prototypes.

Below is a great framework to be used for Design Thinking as per my understanding:

Source: https://www.creativityatwork.com/design-thinking-strategy-for-innovation/



Sunday, March 4, 2018

Code Coverage Tool Analysis

What is a code coverage tool?

Code coverage is a methodology which is used to measure and describe how much source code of the program is executed when a specific test suit runs. It gives a percentage value and the user can determine if the source code is well covered or needs improvements or covered more. If the percentage value is high, the test suit has covered and if its law the coverage should be improved.

There are 03 code coverage test methodologies.
  1. Source Code Instrumentation
  2. Byte Code Instrumentation
  3. Run time Information Collection

Instrumentation is being able to analyze the code coverage that a test suit achieves that it is necessary to compile a version of the application in which statements are inserted that monitor the execution of the source code. 
The generation of such modifies version of the program is called instrumentation.

The most famous of the above 3 are Source Code and Byte Code instrumentation.

Source Code Instrumentation :This approach adds instrumentation statements to the source code and compiles the code with the normal compile tool chain to produce an instrumented assembly.

Byte Code Instrumentation : Bytecode Instrumentation Is A Process Where New Function- Ality Is Added To A Program By Modifying The Bytecode Of A Set Of Classes Before They Are Loaded By The Virtual Machine.

Let me now walk you through the most commonly used code coverage tools in the market.


Open- Clover


Open Clover Report



Jacoco


Jacoco Report


Cobertura 


Cobertura  Report



Among the above 3, most famous is Jacoco and Open Clover. 

Open Clover was put in to the open source market very recently and was a very well known commercial product. The team has now made it a fully opensource product.

Jacoco can be described as an extension of the well famous eclEmma code coverage tool implemented by the Eclipse team. Most of the marker researches recommend Jacoco over the other code coverage tools in the market because of its ability to integrate and instrumentation method.

Most open source code coverage tools use Java as the language where as there are many commercial code coverage tools focusing on .Net or other programming languages. 

Please refer the below link for a better comparison between the code coverage tools.

https://confluence.atlassian.com/clover/comparison-of-code-coverage-tools-681706101.html

So that is a very much what we should know about a code coverage tool in selecting one. Please feel free to comment and share your thoughts.

Tuesday, December 19, 2017

Business Intelligence Requirements Gathering - Part 02 : Data Warehouse Bus Matrix

Apologizing the delay, but as promised, here I am writing to you about the bus matrix.

The enterprise data warehouse bus matrix is the essential tool for designing and communicating the enterprise data warehouse bus architecture. According to the Kimball's Group technology independent bus matrix architecture allows incremental data warehouse and business intelligence solutions  and "identifies and enforces the relationship between business process metrics (fact) and descriptive attributes (dimensions)".

The associated Enterprise Data Warehouse Bus Matrix, shown below, is a key design tool representing the organization’s core business processes and associated dimensionality. It’s the architectural blueprint providing the top-down strategic perspective to ensure data in the DW/BI environment can be integrated across the enterprise, while agile bottom-up delivery occurs by focusing on a single business process at a time. (source: https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/kimball-data-warehouse-bus-architecture/)

If you look at the below diagram, the rows of the matrix showcase the business processes while the columns displaying the dimensions.  

The design team scans each row to test whether a candidate dimension is well-defined for the business process and also scans each column to see where a dimension should be conformed across multiple business processes. Bus matrix is used as an input to prioritize DW/BI projects with business management as teams should implement one row of the matrix at a time. 

The implementation of this should be of more granular where each business process row has been expanded to show specific fact tables or OLAP cubes. At this level of detail, the precise grain statement and list of facts can be documented.

Below is a sample done for the sales department of a local food manufacturer. (Assume that the most granular level of date is day and the location is city)  


Once this is successfully completed, the BA should start with the working on the visualizing the  dashboard and report. 

I will do my next article on selecting the best visualization to represent the data. Till then please do comment and share your thoughts.

Reference:

https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/enterprise-data-warehouse-bus-matrix/

https://en.wikipedia.org/wiki/Enterprise_bus_matrix




Wednesday, July 5, 2017

Business Intelligence Requirement Gathering - Part 01

The organization I am working for is working towards improving it's business intelligence capabilities. This opened me the doors to learn a brand new subject which I was never exposed to in my career anywhere before.

This is an innocent attempt to collect all my learning to one location which may help any business analyst who is a total novice like to to the huge business intelligence arena.

Just as any other project the very first step of a business intelligence project is a Request For Proposal (RFP).  It is a document that solicits proposal, often made through a bidding process , by an organization interested in procurement of a commodity, service or valuable asset, to potential suppliers to submit business proposals.

As per the request the proposal was  made and submitted which went through many discussions and finally we got the project after many iterations of proposal reviews and negotiation sessions.

So then the Statement Of Work (SOW) which again prepared together with contribution of the legal team.

All done and it is closer to start the requirements gathering phase of the project. This is my very first project and I wanted to learn some DW/BI before going to the client as I need to satisfy the customer and make a good impressions while making sure that the necessary details are gathered and brought  back to the office for the team to implement the solution.

Since the beginning of a well designed Business Intelligence solution is a data warehouse, my first approach was to learn bits and pieces on data warehousing concepts. The learning outcomes until now on  basic data warehousing concepts  are listed below and definitely this added certain level of confidence to me before walking to a client.

Know Little DW/BI 

Know the needful technical and business aspects - jargon/basic concepts/methodologies  always plays handy.For most of the non technical business analysts in the IT industry find this challenging though worth giving a try as I guarantee the level of value it can add to you.

What is a Data Warehouse? A data warehouse is constructed and integrating data from multiple data sources. It can  support analytical reporting and decision making. Further a data warehouse contain more generalized and consolidated data in a multi dimensional way.

Difference between a dataware house and a data mart is that while a data warehouse serves an organizations data mart is focused on on particular business segment. So as a business analyst we might need to collect requirements for a BI solution which supply analytics for the whole organization of a department.




For me a data ware house is also another database with more processed data which has pre-populated data in it.It removes the effort of  querying and  joining multiple tables in the database but have the data readily available and anyone interested can view data faster than in an operational database.

The type of data ware house needed for this assignment is a analytical type as the requirement is to slice- dice and  drill down data  to evaluate sales and marketing performance of the organization.

So me being the business analyst for the BI solution implementation for the XYZ organization, my first assignment is to understand the facts and related dimensions . Now what is facts and what is dimensions?

Fact table contains the numerical and historical data. Ex: Number of Orders Placed, Total Revenue, Quantity goes in to fact list as they are all numerical and organizations use these figures to take decisions on  their business. Data warehouse consultants collect the facts to create fact tables.

Dimensions are categorized by which summarized data can be viewed.Ex: Number of Orders placed can be viewed against the location, time/date/month or even by sales agent. Further Quantity can be viewed against the time by customer by location or even by the sales personnel. The dimensions can create dimension tables.A dimension has its attributes.Ex: Customer dimension has name, address and country as its attributes.

Fact tables and dimension tables together create sachems.

STAR Schema

The fact table is connected to its dimensions in the shape of a star which is the reason why this is called a star schema. Dimension tables are not duplicated/repeated.





Each dimension table alone with its attributes is linked to its fact table and all the data in the schema are de-normalized.

SNOWFLAKE Schema




In the snowflake scheme there can exist tables which are normalized. Further the table structure is more complected and may not be able to provide the expected level of fast data retrials to the end  solution.

The star schema is advised to be used in the projects.


When deriving the dimensions for a DW it is advised to use the most granular level as possible as it ease the analysis process.

I will be write on a BUS MATRIX - the first deliverable of requirements gathering in a DW/BI project  as my next post.

Stay tuned. Next Post is Coming Soon.

P.S: Please feel free to comment on the items which I have not written correct as if will be a good learning to me and everyone else who is following me.

Thursday, November 5, 2015

Ready to walk with the GIANTS?

Great thoughts from Robin Sharma - if you want to walk with a giants towards SUCCESS 

--Release scarcity + adopt generosity as your main way of thinking. 
--Forgive the unforgiven, as you are carrying them on your back. 
--Understand that every person who has shown up in your life arrived to help you become the person you now are. Appreciate and love them. 
--Trust that suffering grows strength and your trials can serve your growth vastly. The best of us who have graced this earth leveraged their pain into greater humility, bravery and love. 
--Commit to doing the projects that terrify you + shifting from accepting good work from yourself to demanding legendary production from yourself. 
--Never miss an opportunity to serve or encourage another human. 
--Refuse to cling to stagnation. Complacency destroys potentially awesome lives. So as you rise to new levels of success and joy, keep optimizing. 
--Aggressively notice the miracles in every so-called average day--they are there for those awake enough to witness them. 
--Smile at strangers, do kind things for zero return + be polite (it's so uncool to be rude). 
--Make a stop doing list so you delete the misuses of your oh so precious time. 
--Less news more books. Period. 
--Be a person of depth, wisdom, understanding, ingenuity, audacity, decency and love. At the end, even the finest of us will have wished we'd loved more.
--Remember that we get what we settle for, so set audacious goals that evoke the fiery brilliance that resides within you. 
--Write hand written thank you notes to your mentors and those who have helped you. In a world of digital, it shows how much you care. 


Believe in your talents + gifts + dreams. 

Thursday, October 1, 2015

What it takes to be 'LIKED'

Likeability is completely under a person’s control and has outlined what it takes to be likeable:

Ask questions
Many people make the mistake of not actually listening to people when they are talking because they are so focused on what it is they want to say, this comes across as rude. To avoid this people should ask questions, show interest in the other person and show that they have been listening.

Turn off your phone
People should commit to a conversation and focus all their energy on that conversation. Not only will they notice that they enjoy the conversations more when they are fully immersed but people will like them more when they are not constantly glancing at their phone or tuning out mid-conversation to reply to a text.

Be genuine
No one likes a fake. People gravitate toward those who are genuine because they know they can trust them. Likeable people are confident enough to be comfortable in their own skin, not pretending to be someone they are not.

Use positive body language
Likeable people are aware of their gestures, expressions and tone of voice. Using an enthusiastic tone, uncrossing arms and maintaining eye contact with the person speaking are all forms of positive body language that draws people in.

Smile
It sounds obvious but people naturally mirror the body language of the person they are talking to. If you want to be liked then smile during a conversation and the person will unconsciously return the favour.

Balance passion and fun
People gravitate toward those who are passionate. Having said that, passionate people can often come across as too serious or uninterested because they tend to be absorbed in their work. Likeable people balance their passion with the ability to have fun. At work they are serious, yet friendly. But outside of work they are also very sociable.

Monday, September 7, 2015

Getting Started with Agile-Scrum Methodology - Planning, Monitoring : Part III

Welcome to another most important section of Agile-Scrum methodology.Planning is one of the pillar stones in project management practice.If you are now thinking of the other pillars  - there are all together 4 pillar stones which are Planning, Organizing, Monitoring and Controlling.All these are equally important though planning is significant and mostly important as it is the stepping stone of the project.

In Agile-Scrum Planning happens in 2 steps.

As explained in Part I prioritized product backlog items are considered for the sprint and during the sprint planning meeting which all the team members participate, they turn the backlog items in to several user stories.

Ex:
Backlog Item: User Authentication

User Stories :
1.As a system administrator users should be able to enter their details and register with the system so that the information can be used for other marketing activities.

2.As a user I should be able to enter my username and the password and login in to my account so that I have maintain my own wishlist.

3.As a system administrator the users should not be able to try the password more than three times so that I can guarantee the security level of the system to the existing customers.

These user story stories needs to be given story points based on their complexity, effort and doubt.

The user story then needs to be broken in to tasks which are more simpler units so that it is more easier and suitable for estimations.

Ex:
As a system administrator users should be able to enter their details and register with the system so that the information can be used for other marketing activities.

Tasks:
user registration form
registration form integration with the email and email generation
database entry
user interface

Then each task needs to be added an hourly estimation using the experience  and the skill level of the developer.

These hours can be used as the sprint estimation and at the end of the project the scrum master can create a graph using the estimated hours against the actual which will provide many information to the stake holders.

So this is simply the planning process of Agile-Scrum.

Please feel free to add your comments and correct me if you think anything needs to be corrected as it will help me as well as the readers of this blog to grow more and more.

Monitoring happens via the daily stand up meetings.This meeting needs to be held everyday for 15 minutes.Each team member needs to talk at the meeting on the tasks they attended, what they are planning to do and any issues faced.Daily stand up meeting keeps the team updated about the current  situation of the project and it creates the platform for the team to understand if they are on the plan or if they have deviated and get back to the original plan.

At the end of each scrum retrospective meeting needs to be hosted and the team with the scrum master, product owner and client if possible needs to attend to the meeting which will help the team to understand what went right and what went wrong.


Sunday, September 6, 2015

Getting Started with Agile-Scrum Methodology - Agile Scrum Team : Part II


SCRUM TEAM is the heat of Agile Scrum.Below are some of the qualities of a Scrum team.It is a self organized cross functional  and a focused team.They believe in each other as in every other team and they work together for a smooth sprint cycle.There is no 'I' but 'WE'.They help each other to solve the impediments which occur during the sprint and make sure to achieve the target or rather the selected user stories for the sprint.

The team communicate with each other during the sprint meeting and make sure that everyone is transparent to each other

Scrum master keeps the team together and drive them for a good and quality software delivery. He/she keeps the team together and drive them towards the end.Scrum master should be great at conflict resolution and bonding people together.

This is not just for Agile Scrum team though I logged it under this but for any team who works towards achieving an objective.

Getting Started with Agile-Scrum Methodology- Introduction : Part I

Scrum is Agile methodology which is most widely and commonly used in the software industry.The methodology is a part of Iterating and Incremental methodology and is best suitable for projects with highly changing nature and rapidly emerging requirements.

There are many other project management methodologies though among all Agile -Scrum is now mostly popular among the software industry as it puts together a self organized team with max 7 +-2 members with no project manager to manage but a scrum manager to guide on the methodology for the team to get maximum benefits and a product manager who is available for the team all the times  for clarifications and requirement prioritization.I will explain the roles of Agile - scrum in the latter phase of this article.

SPRINT is one of the key terms used in Agile- Scrum methodology and it is simply a series of iterations.Sprint is usually 2 weeks to one months.BACKLOG is another like that and it is like a bucket where all the possible future amendable functionalities  brought out by the team while brainstorming or brought by the product owner after a business objective discussion with possible stake holders are kept in the backlog as then they are never forgotten or missed by anyone.

USER STORY is a simple and a understandable manner of writing the requirements.It contain 3 main sections.
As a <Actor> I want to <Action/Result> So that <Outcome>

Ex: As a project manager I want to generate the resource burn down chart so that I can plan my estimate for the next week.

Software development life cycle (SDLC) contains several steps and Agile-Scrum encapsulates almost all in it.'Requirement Analysis' is  happening without heavy documentations or complex use cases but user stories.In other project management methodologies requirement analysis itself costs so much for a business analyst and also for time he/she spends for documentation though in Agile - Sprint the development team  together with quality assurance team and Scrum Master brainstorm on the product backlog item which is prioritized by the Product Owner.Then they break the epic story  or the product backlog item in to user stories in manageable sizes to be addressed in a particular sprint.
The team cannot make the design in advance though the team will be designing the system in pieces and as the functionalities grow the design and the architecture of the system grow.Implementation do happen really well as the team is cross functional and contains developers, database engineers and technology experts.Testing plays a vital part and the Scrum team contain QA engineers for testing and test automation. 

STORY POINT is also a common term used in Agile-Scrum.Every user story is given a  Fibonacci number (Ex:0, 1, 1, 2, 3, 5, 8, 13, 21) based on its complexity.Highly complex user story will get 13/21 whilst a medium complected story gets 5/8 and low priority rather simple story gets 1/2/3.Team decides on the story point to be given for a user story and this story sometimes differ from QA members to the developers.The team then come to a agreement and decide one number which is accepted by everyone.

The total of the story points achieved within a sprint is called VELOCITY.The project team is normally measured by this number.

Communication is a key in Agile - Sprint just as every project management methodology and they use SPRINT STAND UP MEETING which happens everyday for not more than 15 minutes.During this meeting they discuss 

  • what is addressed yesterday
  • plan for today 
  • impediments/obstacles

Discussing the impediments is good though if the discussion  drags it is always good to arrange the discussion after the sprint meeting as it will not eat the valuable time of all the team members.

End of each and every sprint the team needs to integrate the new functionality to the core system and describe it to the product owner and the stake holders. Feedback should be always welcome though addressing again needs to be prioritized and if the feedback needs to be addressed as soon as possible go for it else put it to the product backlog which the team can always pull when time permits.

BURN DOWN CHART is a artifact of Agile- Scrum which displays what is left to be done.Burn down chart can be drawn using story point vs sprint or actual vs estimated for the sprints.

Sprint planning is a vast area which I will address at my next post.

Please feel free to post your comments on this article for me to grow and learn more and more so that I can bring many things in a nut shell.


Monday, April 20, 2015

Effective Executive - Effectiveness Can Be Learned

This article contains view points and knowledge of Peter F. Ducker from his book "Effective Executive" and some important view points of many other consultants.

Regardless of your designation learn to get the right things done. It is simply being effective. There are many individuals who are intelligent and have a good imaginary power thus it is very rare to find some one who is effective intelligent and with a great imaginary power.Peter F. Ducker in Effective Executive mentions that brilliant men are often strikingly ineffectual; they fail to realize that the brilliant insight is not by itself achievement.

Intelligence, imagination, and knowledge are essential resources, but only effectiveness converts them into results. By themselves, they only set limits to what can be attained.Even though effectiveness is so much important most do not pay much attention to it.The reason for this negligence is less knowledge possesses on the subject within the organization.

Efficiency is another word which is bound with effectiveness. Efficiency  is  the ability to do things right rather than the ability to get the right things done. Working on the right things is what makes knowledge work effective.

Knowledge workers are workers whose main capital is knowledge. Typical examples may include software engineers, doctors, architects, engineers, scientists, public accountants, lawyers, and academics.Most of you reading this article may be knowledge workers and those of us belong to this category gets motivated be being effective at work. Effectiveness keeps the momentum whilst taking away the frustration. Ducker mentions in his book that he knowledge worker is the one “factor of production” through which the highly developed societies and economies of today—the United States, Western Europe, Japan, and also increasingly, the Soviet Union—become and remain competitive.

Usually the people who are most important to the effectiveness of an executive are not people over whom having direct control. They are people in other areas, people who in terms of organization.So it is always important to gather those people whose very much effective and teach it across.Pass the knowledge among all the associates which will help them also to practice the experience of the experts whose already practicing effectiveness.Practice needs to be continued and repeatedly done which will help the other associates to add them to their habits and even that will help them to introduce more effective methodologies which they discover themselves.

1. Focus is everything: 
Arranging practice sessions limited to a duration that allows you to stay focused.

2. Timing is everything, too: Keep track of times during the day when you tend to have the most energy. This may be first thing in the morning, or right before lunch. Try to do your practicing during these naturally productive periods, when you are able to focus and think most clearly.

3. Don't trust your memory: Use a practice notebook. Plan out your practice, and keep track of your practice goals and what you discover during your practice sessions. The key to getting into "flow" when practicing is to constantly strive for clarity of intention. 

4. Smarter, not harder: When things aren't working, sometimes we simply have to practice more. And then there are times when it means we have to go in a different direction.

Just force yourself to be effective.This will help you big  time in the personnel life as well as work life.  

Thursday, April 16, 2015

Effective Executive- Introduction

Effective Executive is a great and a very much of an inspiring book by Peter F. Ducker. It speaks of self management towards an effective individual.This book further mentions that To be reasonably effective it is not enough for the individual to be intelligent, to work hard or to be knowledgeable. Effectiveness is something separate, something different.

It teaches you many ways to be effective and finally to become an effective manager who can manage him/her self as well as others. Effectiveness is not  "In-born" but "Practiced" .Effectiveness as an executive ways of doing certain—and fairly simple—things. It consists of a small number of practices which we will talk through out these articles as explained by Ducker and taken to a nut shell by Poornima. Without effectiveness there is no “performance,”no matter how much intelligence and knowledge goes into the work, no matter how many hours it takes. Yet it is perhaps not too surprising that people have so far paid little attention to the effective executive.Thus effective individual can turn an organization to a highly effective organization which sets examples to all the other organizations around. So lets put a collective effort to be a highly effective individual.

I will be posting a series of articles on this and those who are interested can read and help your selves and please do not forget that I value your experience.So feel free to comment and share your opinions/ideas/comments with me.

Lets start.....