RSS

Category Archives: Software Development

Careers for a Business Analyst


Given the nature of the business analyst’s role in the present-day context, it is evident that he/she has a great opportunity to influence how a solution is visualized and is shaped on the customers’ side as well as how it is designed and build at the development end.

This exposure to thee customer/users’ domain as well as an understanding of the issues in developing and delivering the software solution gives the business analyst a unique advantage.

A business analyst can therefore move either into more direct customer facing roles such as:

1- Pre-Sales person

2- Sales and Marketing person

3- Account Manager

4- Relationship Manager

5- Project Leader

6- Consultant

The BA can grow in his own field of BA to lead the BA group of a large organization. So, happing growing 🙂

Advertisements
 
 

Building Prototype of software web application: What it means?


A model or a prototype is a representation of the reality. Models of an existing system or a proposed one can be constructed. Modelling and prototyping is used in the software field since it reduces risk,costs, time and effort in building the real product. Also, these prototypes help software business – users as well as BA’s to visualize the proposed solution.

The software applications can be really hard at times. Since the user’s view about a system is largely restricted to what he enters as input  or what he sees as output, prototyping in a software sense implies creating a model of such visible elements of the system. Thus screens could be designed and linked to each other, to see how the interaction happen. Fortunately, software tools can help in building prototypes of software solutions very quickly. For instance, you could create web(HTML) screens and link them up from the highest menu level to the most detailed page. Such a demo can help a user to visualize the solution and imagine the various possibilities. Prototyping can be used as a good method for analyzing software requirements.

One point to note about prototyping is that a BA must not in any way lead the user to think that the final product is just a step away from the prototype just demonstrated. In fact this is far from the truth. The screen- based prototype is really the surface of the application. There is a tremendous amount of coding to be done for the middle tier and backend of the application. Even thee front-end, in many cases, requires substantial improvements before it can be said to be final. Thus prototypes may at times mislead a user into thinking that the software is nearly reeeady thereby creating false expectations which the BA must quick enough to correct.

The second limitation of the prototype is that most prototypes are static in nature,i.e. they lack the dynamic behavior in terms of interactive actions which a real life solution would have. Hence, users at times find it difficult to visualize the proposed interactivity of the final product based on the static prototype. Hyperlinking and adding a basic level of navigation, etc. could partially help reduce this problem. It is thus important to use a prototype which is capable of stimulating the entire interaction as it would happen once the solution is ready- though it may use static screens for the same.

Before I end the post, I will share a link for a retail banking website’s prototype for better understanding: http://www.carettasoftware.com/gallery/banking-design.html

Happy building prototypes 🙂

 
 

Which Coding approach defines your software requirement better: Iterative or Incremental ?


Iterative Approach

In the iterative model, each successive iteration adds more details to the previously implemented functionality. For example, if we were to design a retail banking e-statement web application with all its pages giving only the title of the page in the first iteration. This iteration helps understand the relationship and navigation between pages. In subsequent iterations details of each page are added thereby completing the e-statement application.

Advantage? Entire system is visualized like a broad wire frame and over a period the details are filled in. When done in the presence of a BA / end user, it makes it easier for the end-user to visualize the complete system as well as help add the detail as the development progresses.

However, in Incremental approach developer develops the software in small increments. It helps the user and the BA priorities the features which are more urgent from business standpoint. For example, if we were to break up a retail banking  e-statement web application into following sub-applications: enroll for e-statement, view e-statement, and see, change, cancel e-statement- each of the increments could be planned, analyzed , designed and implemented in a waterfall style. Once one increment is complete the software is moved on to the next increment.

The essential difference between incremental and iterative is that iteration successively improves upon the existing functionality whereas incremental adds newer modules to the previous piece of code.

Many new methodologies tend to be a mix between incremental and iterative.

 
2 Comments

Posted by on February 16, 2011 in Software Development

 

Emergence of Business Analysis


I must say that my thoughts and experiences in the software industry has been shaped by my interactions with various end-users, business executives and software professionals and few inspiring books which I have read.

The post-2000 period has witnessed a major shift in the way information technology (IT) industry works. From the previous on-site model there was a shift to the offshore development model. This has had several benefits from the client’s standpoint. Cost was certainly one of them. But more importantly the IT department in client organizations could now focus on its core business, namely understanding and meeting the needs of various business departments which they served.

As a result of this shift and the rapid rate of progress of the IT industry and its profound effects on business practices, a need was felt to separate the user facing role from the technical role in the software development process. The role of Business Analyst was thus carved out of the System Analyst-cum-Developer.

This of course, is just one of the many explanations for this new role. Another and to my mind an equally valid one is that many business users felt bored dealing with techies and instead showed keenness to meet a person who could interact with them in their language and be knowledgeable about their business domain.

Various research reports have proved beyond doubt that the topmost reason for failure of software projects has been a failure in getting the correct and complete requirements of a user/client.

Thus, requirements gathering is a brilliant opportunity for a BA to shape expectations of each person associated in the process with the proposed solution.

 
2 Comments

Posted by on February 14, 2011 in Software Development