Business Analyst Explained

Business Analyst explained:

Business Analyst plays an important role in any organization or to say in any business. So, in a nut shell a business analyst devotes his time on analyzing the current business / organization. But a business analyst roles is not only limited to just analyzing, but he also need to work on different business models and works on how they talk to each other with current technology.

SO, talking about day-to-day duties of a business analyst we can divide them into different parts.We will discuss one by one.

1) Planning: In this phase a Business Analyst needs to analyze the business needs of the organization. i.e what exactly needed for the current business to gget into right track that eventually leads to the financial success of the organization. SO, this is an on going process even though the business is established.

2) Analyzing the different Business Models:Here in this phase a business analyst needs to analyze the business policies and different business processes which are already in the market.

3) Designing the business process:Here the actual business process is modeled in a detailed way.

4) IT Business Analysis: Here it is the business policies, formulas and business requirements are interpreted and analyzed in detailed way. And the important thing here is these are analyzed in technology perspective (Information Technology).

Business Analyst Deliverables:A typical Business Analyst has to deliver many documents as part of his/her role. So, here we are gonna discuss few important of them. 1) Business Requirements: This is the project initiation document in which a Business Analyst must mention the quality measures and what would be his achievements etc.. These are mainly the business requirements which are explained ina broad way. The actual functionalities are not explained here.

Functional Requirements:Here the functional requirements are explained in detailed. i.e what the business will do? what are the different functionalities of the business? what we should do to fulfill the requirements?

User Requirements:These are very very important requirements because the stake holders involvement is there in this. Here the actual needs of the users will be discussed in detail.

Traceability Matrix:Traceability matrix is nothing but recording of the requirements in each and every phase. Here individual functionalities will have to match the actual requirements. This document is very important for both Business Analyst and developer because it acts as a proof of the original requirements.

What is a Business Analyst?

This is a position in a company that has the purpose of searching for the right businesses, then finding the right strategy for them to work at maximum level and resolving the problems by taking care of the business needs using Information Technology (IT). Shortly, they are making the connection between the business requirements and IT, maximizing the profits and reducing costs.

The Evolution of this Job

An analyst is one of the most important people in a corporation, they can make it grow by constantly seeking new technologies to support the required operations. Over time, with the rising of the Internet, society improvements, technology getting more and more powerful, analysts received new attributions. So in the IT business companies most of the jobs became freelancer based but the only career type that could not be outsourced was that of a business analyst, because the person who follows this career must remain indoor, inside the enterprise, this is the best way to take its pulse every day, to have the experience and take the best decisions.

What Are the Responsibilities?

Actually the term “business analyst” means something a little different to each organization. The analysts have many different assignments on a daily basis.. For example the person must meet with the client company, both manager and employees, do interviews, then analyze the collected data and consult business guides to see what has to be done to get best result for each case, also make charts, graphs and to develop strategies for company changes that have to be made to resolve the problems, design business models and organize group sessions to show their ideas, etc.

What Are the Requirements to Fit the Job?

First important thing when applying for a career in this area is to have analytical skills. You have to be able to analyze numerous company aspects, you must have an eye for detail to see what goes wrong and must be fixed. Another skill that is must – good communication to handle various meetings, interviews, presentations.

The position of a business analyst has various tasks to accomplish and is not boring at all, so the best candidate is a dynamic person who likes working in a vast area of expertise and different social environment. Conversation, attention to detail and good self management are the best qualities you can have.

Roles and Responsibilities of a business analyst

Roles and Responsibilities of a Business Analyst

One of the most favored industries to be working in is the Information Technology and ITES companies. A very common profile that you must have heard is Business Analyst. The name sounds enticing, but before you decide on embarking on a career as a Business Analyst, you must be aware of the roles and responsibilities of a Business Analyst.

So how is a Business Analyst and what does he do in any organization? These are the basic questions this article aims at answering.

To begin with, a Business Analyst is one who analyses a business and aims to better it with the use of Information Technology. He is employed by a company and he has a team of software developers to assist him.

Once a client assigns a project to the company, the Business Analyst understands the various nuances of the business and then attempts to solve the problems faced in the current working or he may try to better the current working – whatever the client wants to be done.

The business analyst has to know the workings of the industry in which the client’s business falls under so that he can fulfill his client’s needs and specifications from the project. To understand the specifications, from a business perspective as the client would think of them, a Business Analyst needs to be aware of the norms, laws, working, competitors, software, technical know-how, rules, procedures of the industry and the client’s business in particular.

This education about the client’s business is a must so as to draft the client’s specifications in a format that is feasible to work upon. The Business Analyst can then understand and envision how the client’s project can be embarked upon by the technical team of software developers and programmers.

The Business Analyst must also have the technical know-how that is necessary for him to understand how his technical team will go about working on the project and to supervise them. Also, if he understands the technological nuances of the project, then he can understand the technical team’s problems and help in solving them. Also, he can explain the client specifications in a format the technical team will understand.

Once the client specifications are properly drafted, and the technical team is briefed about the project, then they can start working on the technical part of the project. The Business Analyst must be around to help them and to supervise the project to check if the timelines assigned to the project are being adhered to.

The system which is designed by the technical team of computer engineers and software coders is then tested for errors and if any errors are found they are fixed. Testing of a software designed helps to check for bugs and if the system will work properly in a live environment.

Once the client is satisfied with the working, does the developers work end.

The Business Analyst thus works as a bridge between the developers and the end user ( client).

System AnalystSystem Analyst / System Analysis:

Any system has to be designed and developed according to the requirements. More specifically, a system has to serve the intended use in the right way. Having a plan and clear-cut idea upfront is thus vital to the entire process of design and development. The required analysis is done by the System analyst. He is the one responsible for handling the overall project from a higher level of view, managing within it the specifics of and integrity with the lower programming level of perspective. With sufficient knowledge about the dynamics of every aspect of the system, interactions with programmers, customers and other relevant people System analyst’s job is to get the right solution in the most efficient way. Let us see more about the role he plays.

Get the requirements!

Well, a solution to a problem can be really good only if the problem statement is taken in completely. Customers words are the key to figuring out the exact requirement set. As a System analyst, one has to be the customer’s voice when he drafts out the requirements clearly. Apart from the customer interactions, it is his job to translate the practical needs of customer into a more technical requirement. Acting as a bridge between the customer and the developers the System analyst has to give the right translation of customer’s terms into a programmer’s idea.

So, where does the analysis come in?

Stating the requirement gathering as just a “translation” can make it seem simple! The truth is that the technical documents that the System analysts prepare from the “Use cases” derived from the customer interactions or marketing documents should take in all considerations of technical feasibility and programming aspects/technologies. To do this a reasonable knowledge from the programming/development side is required. With interactions with the programmers he has to make sure of the feasibility of solution. Cooperation with the development team right through the

development phase makes periodic validation/verification possible. Checking for conformance to use case requirements, standards of development and guiding the entire team together forward towards the goal makes the analyst’s job a very critical one for overall success of the software system under development.

The Analyst is basically the Information access point for the customer and the marketers. From the design of the system to deployment, he keeps track of all the information in perspective of both the customer and the programming team. This makes him a vital part of the testing phase and deployment phase. As a person who has the best knowledge about practical needs of deployment and usage, he also plays a major role in drafting out the user manuals and other data sheets for the customers.

It is pretty clear as to how important the role of system analyst is. A strong base to phase out the actions and plans gives any project a good head start. Thus, it is the System analyst who can be the starting point for having a successful development cycle and really useful system from the customer’s perspective. He can really give the entire team the comfort levels by making a good sturdy base for operations.

What is SDLC? different phases of SDLC?

What is SDLC (Software Development Life Cycle)?

SDLC or Software Development Life Cycle is the life cycle literally of the development of a system or software. This life cycle details all the processes that a system undergoes while it is being designed. That is the basic layman understanding of what SDLC stands for.

The steps of the System Development Life Cycle are detailed as below. They show the detailed working of how a system is developed for a particular project.

The Software Development Life Cycle (SDLC) starts when a client expresses the need to start a new project. Once the project is in hand, the steps of the SDLC work as:

Project Planning: Planning is the core of every process and only effective planning can make a Business Analyst realize if the intended system can really be developed or not. A feasibility study is conducted in this stage to determine if the actual system intended is indeed possible to work upon or not.

System Analysis and Requirements Definition: Here, the requirements of the client in the system to be developed are properly analyzed and then a final requirement definition is written by the Business Analyst in consultation with the client, who will be the end- user of the project.

This requirements definition is used by the software team of programmers and developers to start the project.

System Design: This is the process of SDLC where the system is actually designed as per the requirements. The process of database design, structure design, nuances of the client/server technology, defining tiers of package architecture are all defined properly in this phase.

System Development: This is the phase where the actual project is made. The system‘s software is coded in this phase. Code generation makes the system machine-readable. The code is generated by the technical team of software developers and programmers. The code is generated with the help of languages like C, C++, Java, VB, SQL and tools like debuggers and compilers.

System Implementation – Here, the system developed is incorporated in the design of the project. The developers assemble their creations in the previous phases of the SDLC.

System Integration and Testing – The system generated is now checked for errors and bugs so to as to ascertain how workable the system developed really is. The System Testing phase shows whether the timelines of the project can be adhered to or how much work is still pending, depending on the number of errors and bugs found.

System Acceptance and Installation – Testing in live conditions is an acid test for the system’s success. Testing the project in a replica of live environment will enable the software developing team to ascertain whether the software developed will actually work in live conditions and as per how it was envisioned to work.

System Maintenance - Once system is implemented in live conditions, it has to be maintained properly. The software developed may face some changes due to some unexpected inputs or changes due to new personnel in the organization. Hence any problems arising need to be fixed to maintain the system well.

What is Usecase diagram and its importance

What is a USE CASE ? Importance of USE CASE diagrams

People in the Information Technology industry and other allied industries might have heard the term “Use Case “. They might be aware of its importance and how helpful they may be in executing projects, but if you are a newbie in this industry or just have to refresh your knowledge then it might be a good idea to just read up again on Use Cases and their importance.

So what is a USE CASE?

The technical definition of a USE CASE is that it is a description of a system’s behavior or a particular scenario in which a system responds to an external request that originates. An example of an external request is a user input.

Basically, a use case is helpful to understand the system from the end-user who is ultimately to actually use the system’s point of view. Use cases help to specify and explain the interaction between the actors and the system. Now the question that may arise in your head is who is an actor?

An actor is the one who initiates an action with the system and the Use Case is what is used as a tool to describe the sequences of the course of the action. These sequences of actions between actors and system are called scenarios or use case instances. Hence the Use case comprises actors and scenarios which describe the interactions of the system.

This is the simplest way to understand what Use cases are in software engineering and what they do. Actors could be anybody from persons who are the users of the system to organizations and computer systems too. They are basically initiators of the system.

Use cases are thus an organized way of categorizing the various system requirements. All system interactions or activities that are important and should be categorized since they are of value to the users of the designed system can be identified by using Use cases.

Thus the Use case is nothing but a systematic sequence of requirements, actions and interactions between system and users and vice versa and has some value. Use cases are easy to read and understand and hence they are widely used. However, it is worthy to remember that use cases do not specify details of the actions, only their intent and Use cases do not give implementation details. They are multi level.

Importance of Use cases:

Use cases are important because they are in a tracking format. Hence they make it easy to comprehend about the functional requirements in the system and also make it easy to identify the various interactions between the users and the systems within an environment. They are descriptive and hence clearly represent the value of an interaction between actors and the system. They clarify system requirements very categorically and systemically making it easier to understand the system and its interactions with the users. During the analysis phase of the project’s System Development Life Cycle, use cases help to understand the system’s functionality.

What is flow chart and its uses

A flowchart is very simply a diagrammatic representation of the flow of information. Now this flow of information could be in a Information Processing System or just an explanation of how an algorithm works. A flowchart typically shows the flow of data in a system, detailing the operations in a pictorial format which is easier to understand than reading it in a textual format. Besides, a flowchart quite simplistically shows the sequence of the operations taking place in the system too.

Hence a flowchart helps in solving a problem by offering an easy to understand graphical solution that shows the different operations which are the steps of the solution and the sequence of those operations. Hence a flowchart is used extensively in IT and ITES companies. A flowchart can be compared to the blueprint of a building. It shows what the structure of the building is (or algorithm or problem or the information processing system) and shows the building blocks of the structure which comprise the information needed to arrive at the solution through sequential blocks of data. It wouldn’t be wrong to say a flowchart is a sort of a ‘must’ to document and explain complex and lengthy programs.

A flowchart has certain rules that need to be followed while drawing it. These rules are given by a governing body known as the ANSI (American National Standard Institute). There are certain standard ways of drawing a flowchart with the symbols prescribed by ANSI. Knowledge of these symbols is necessary if u want to draw a flowchart. These flowchart symbols are given below:

The rectangle in a flowchart denotes processing function or a just a computational step while processing.

- The oval is used to denote start or end of a program.

- The parallelogram is used to denote the input or output steps of a program.

- Connector in a flowchart.

- This is used to denote a magnetic tape.

- This is used to denote a magnetic disk.

- This is used to denote an off-page connector.

- This is used to denote “ Display “

-

These arrow lines are called flow lines.

These are the basic symbols used generally. Now, the basic rules for drawing a flowchart with the above symbols are that:

The flowchart is to be read left to right or top to bottom.

A process symbol can have only one flow line coming out of it.

For a decision symbol, only one flow line can enter it, but multiple lines can leave it to denote possible answers.

The terminal symbols can only have one flow line in conjunction with them.

A simple example of a flowchart of a purchase and quality inspection routine is below:

What is RUP? Rational unified modelling?

Rational Unified Process is what is commonly known as RUP. It was developed by the IBM Corporation. A part of the IBM Corporation is the Rational Software Corporation which developed the RUP.

RUP is an adaptable and iterative software process framework. It is not prescriptive or singular process.

Rational Unified Process Origin

The Rational Unified Process framework was originally developed and created by its namesake, Rational Software. IBM then took over Rational Software in 2003.

What is Rational Unified Process (RUP)?

Rational Unified Process is an iterative adaptive software process. RUP framework is built on blocks or content elements. The main blocks answer the questions of who, what and how. The “Who” part is encompassed in the block “Roles “which define certain related responsibilities and competencies. The “What “part is encompassed in the building block “Work Products “that defines the result of a task. The “How” part is encompassed in the building block “Tasks “which is nothing but a unit of work that is assigned to a Role and which is intended to produce a result.

Iteration consists of nine disciplines. Out of these nine disciplines, six are engineering disciplines like Business Modeling, Requirements, Design and Analysis, Implementation, Test, Deployment and remaining there are supporting disciplines which consist of Configuration and Change Management, Environment and Project Management. These iterations have to be followed with guidelines and templates at each stage. This way RUP provides a set of standards to be adhered to for all the stages of the System Development Life Cycle (SDLC). The RUP consists of a life cycle with four distinct phases as listed below.

The RUP Life Cycle phases:

1) INCEPTION

2) ELABORATION

3) CONSTRUCTION

4) TRANSITION

1) INCEPTION: Inception is the phase where the concept is actually commenced or initiated. The concept is explored with the definition of the scope of business, the stakeholders, cost benefit analysis, feasibility analysis etc. Inception phase provides a strong foundation to the phases to come next. Hence Inception phase must be properly planned and done.

2) ELABORATION: Elaboration is the second phase after Inception. Here the first draft is finalized and the requirements are finalized so that the work can take place.

3) CONSTRUCTION: Construction is the third phase of the RUP Life Cycle. As can be thought, in the CONSTRUCTION phase, the actual work begins. The software is actually ‘constructed’ in this phase and most important of all - the coding part of the project; is done in this phase. Testing is also done in this phase itself.

4) TRANSITION: Transition is the final phase of the RUP Life Cycle. Any project, no matter how good it may have been conceptualized and developed, needs to be successfully complete

the transition phase at the client’s end .Here, software is released to the client and support phase then effectively starts.

USE OF RUP:

By its adaptive nature, RUP is a framework that can be used by any corporation or software project team for its purpose, by choosing the elements they need from it. It is this specific adaptive tailoring as per needs feature of RUP which makes it highly popular with the developers team and the industry.

What is UML? explain in detail.

What is UML (Unified Modelling Language) and what is its use?

Most of the businesses around the world use IT in their daily working and communication. The systems on which these businesses run are based on languages, which make the design of these systems easier than it would have been otherwise. System design and engineering complexities are greatly reduced by use of diagrams that convey much more than reams of paper would consume by way of text. Also, these diagrams used in modeling help to design the system faster and quicker.

Unified Modeling Language (UML) is one such Modeling language, used to make designing of systems faster and quicker. The UML is thus a visual tool that helps software Engineers and Business Analysts to understand the system design specifications better, clarify their doubts, and create time-bound solutions as required by the clients, through better facilities of communication.

UML is basically a graphical modeling language. It can be a standardized tool for system design.

The great part of Unified Modeling Language is that it can be used across all stages of the SDLC ( System Development Life Cycle) and later while being implemented in the real world and for the maintenance purposes too. UML found such appreciation in its usability that it became a standard (made by OMG – Object Management Group) in the year 1997 and over the years, another version too with minor modifications has been developed. The new version is called UML 2.

USES OF UNIFIED MODELING LANGUAGE:

UML is used for system design. Since UML uses visual depictions of software in the system design, it makes communication simpler and tasks easier to execute. Unified Modeling Language uses diagrams to create these visual descriptions called Use Case Diagrams. The Use Cases are nothing but descriptions of a system’s behavior to an external response. Use case

diagrams are the diagrams used to depict this information in a graphical visual manner that is easy to understand, thus facilitating communication making the design of the system faster to develop.

UML is versatile in the sense that it can be used for all processes involved in the designing of a system as required by the client.

UML reduces complexities that are involved in system design to a great extent as the Unified Modeling Language uses easy to understand graphical documents, thus avoiding lengthy and complex textual matter. This makes communication simple and makes it easier as well as faster to develop the system that is required to be designed.

There are different types of diagrams that are used to facilitate system design, during the various iterations in the various processes in the system design. Use Case Diagrams, Sequence Diagrams, Interaction Diagrams; Class Diagrams are the major ones, which help to convey the system’s behavior. Some diagrams are used for static purposes and some for dynamic purposes.

The Unified Modeling Language is thus a great tool for project modeling in Object Oriented Programming and has been used extensively through the years by programmers in system design.

Role of a business analyst

Roles of a Business Analyst

Business Analyst – this is a term which has come into prominence in the past few years especially with the advent of the software industry. Who is a Business Analyst and whats his role in an organization? These are the questions which we will be trying to answer here.

Business Analyst can be termed as an analyst who can delve deep into the business, understand the processes and make use of the knowledge in the betterment and success of the organization. But the term Business Analyst is used very generically in today's professional environment. It can mean analyzing the system, business processes, requirement analysis, supporting the business or system functions, handling the sales or financial KPIs' (Key Performance Indicators). But we will discuss the main responsibilities of a Business Analyst in a generic environment and it may happen that in some cases, its an amalgamation of roles or may be a subset of another role.

A Business Analyst is responsible for a host of processes and activities which are elaborated as follows:

a) At the Project Initiation process, its the responsibility of the Business Analyst to cover the high level scope and objectives of the project and establish communication channels

b)Understanding the business processes of a section or whole of the organization in a very clear cut manner so as to implement that knowledge in any required manner.

c) Clear Understanding and communication of Requirements is a very important aspect of a Business Analyst as it ensures that there is minimum gap between the expectations of the end users and the final deliverable from the technical team.

d) Analysis and Documentation should be very precise and clearly understandable so that starting from the end users or stakeholders to the developers can understand the

underlying stated expectations in the requirement documents.

d) Solution assessment and validation is one of the main roles of a business analyst as it should be ensured that there are no gaps in the requirement process to the development stages.

e) Regular interactions by the business analyst with the developers and the module leads is essential as the knowledge transfer of the user expectations should be made clearly

f) The business analyst has a major role to play in the testing phase where he can actually take part in the systems testing phase and also provide support during the acceptance testing phase.

g) After the implementation of the software system, the business analyst also may need to handle the change management process if there are any new requirements or changes proposed.

The business analyst profile actually encompasses different roles like that of a process analyst, system analyst, project manager, application support, data analyst and tester. Gaining all round knowledge in all these different role types will definitely give the Business Analyst an edge and will enable him to overview the project from all angles.

Implementation of such responsibilities will help the Business Analyst become the interface between the users and the technical team. The organization should also be responsible for guiding the Business Analyst through his correct responsibilities for the better advancement of the individual as well as the company as a whole.

What is business analysis

What is Business Analysis?

Business analysis can be described as the sequence of activities which are implemented in order to assess the business requirement needs and to fit the required solution so as to bring around the success of the organization and business. So, this sequence of task is normally performed by a “Business Analyst” or BA. Business Analysis can cater to different industries and so there are specialists created among business analysts. For e.g the business analysts who

solely work on developing IT systems are the Technical Business Analysts, and the ones which cater to the functional parts of the business processes and their improvement or re- engineering are known as Process Analysts.

Business Analysis is as such a vast subject and hence we will categorize it into subsets for better understanding of the various stages in any business process or software management. Business or Enterprise Level Analysis is the study and analysis of the business needs and the identification of initiatives to steer the organization on the path towards its strategic goals. This can include the finalization of the project scope, purpose and objective. This is the stage where the actual feasibility analysis occurs wherein the actual cost benefit analysis(CBA) of the project occurs and its evaluated whether the project should go ahead or not. Requirements elicitation and communication

is vital to the basis of business analysis as it involves the actual collection of data from the stakeholders and ensuring that their requirements are clearly illustrated and conveyed to each and every member involved in the project. This is the level at which the actual requirement needs are captured using using various requirement methodologies like Zachman framework etc. Requirements analysis or engineering has been synonymous with Business Analysis always and represents the requirements planning, development and management processes. At this stage the actual analysis of the requirements is done wherein the raw requirements are processed into functional objectives. The documentation of the requirements is done at this stage and may include the functional as well as the non-functional documents together with supplements like prototypes or UML diagrams. Finally,we come to Solution assessment and validation which ensures that the proposed solution design is in line with the requirements and there are no gaps in understanding which will trickle down the software development life cycle. At this stage, the requirements have taken form and have been converted to a solution design which can be developed and implemented as an application or software system. So its essential that analysis of the solution is done properly to ensure that the requirements are in synchronization with the solution. Business Analysis is not limited to this stage and can extend to the other parts of the project life cycle with significant contributions at the design, development, testing as well as implementation stage.

Business Analysis, in summary, is the art of managing the requirements and the business needs and synchronizing them in line with the strategic objectives of the organization. In order to implement this management methodology, one needs to understand that Business Analysis forms the base of the successful implementation of any business process or software management event in an organization.

What is sequence diagram

What is a Sequence Diagram

Sequence diagrams are part of UML(Unified Modeling Language) diagrams and come under the interaction view as they depict the interactions between the entities and the transactions that are taking place with the trigger point and the end point clearly distinguished. The diagram shows the different processes as vertical columns or lines and the messages or interactions between them is represented by arrows with the arrowhead pointing towards the receiver away from the sender. The name of the message is written above the messenger arrow line. It also includes the sequential order of events which will occur from the start to the end of the process(es). An important part of the sequence diagrams is that time passes from the top to the bottom. A message sent between two entities can be synchronous or asynchronous type. A synchronous type of message indicates that the sender will wait till the receiver has finished processing the message and then only proceed while in asynchronous message type, the sender will not wait for a response that the receiver has received and finished processing the message. A synchronous message is represented by a filled up arrowhead while an asynchronous message type is represented by an open arrowhead.

The sequence diagrams are helpful in detailing the flow of transactions between the entities such as actor, database, controller etc. Hence, for a sequence diagram to be prepared, its essential that the “use case diagram” would have been finalized, else it could mean rework might be required if the use case digram is revised. Sequence diagrams can be used by business analysts in their functional documentation process or by solution architects or designers in their design models. But whether the sequence diagrams are created by the analyst or technical designer, whats important is that the diagram conveys the right message across to both the user groups and the development team.

An example of a sequence diagram is provided in Figure A

Figure A – Sequence Diagram Example

In this example, there are three entities – Customer, Waiter, Chef. The flow of message can be read as follows:

The customer gives the order to the waiter Waiter will serve the wine and give the order of the food to the chef Waiter will pickup the cooked food from the chef and serve it to the customer The customer will pay to the waiter

This is a very simple example of how the flow of messages can be represented by using sequence diagrams. It cab be noted that the responses of the synchronous messages are shown in hashed arrow lines. Wherever there is a gap in the time line, it shows that there was no real interaction in that time period from the concerned entity.

Sequence Diagrams are a clear and simple way of depicting to the users, stakeholders and the technical team how the processing of messages will happen and an assessment of this will go a long way in clearing up any gaps or misunderstandings at the requirement level.

What is class diagram

What is a Class Diagram

For understanding class diagrams, we would need to understand UML first. So what is UML? UML is short for Unified Modeling Language and is a second generation notation for diagram-based object-oriented modeling. It was first developed by the company Rational Corp.(Booch). After that UML was advanced as an industry standard by the

Object Management Group (OMG).

Class Diagrams are a part of the structural view of UML as they represent the static structure of a system. Class diagrams are basically used by Business Analysts or Solution Architects to design the static view of the classes involved. The diagrams depicts the grouping of classes which have the same attributes and behavior(operation or functions) and also it includes the interrelationships between two class. A class is an entity which is represented by a simple rectangle and is divided into three parts. At the top we have the Class Name, in the middle the

list of the attributes specific to the class is included and lastly comes the class operation or function. If a simplified version of the class diagram is depicted then the last two compartments are not included or are left blank. The interrelationships are shown in the form of interconnecting lines between the classes and the dependencies are represented by symbols such as 1, 0, *(many), This part is similar to the data modeling diagram – entity relationship diagram.

As class diagrams are essential to all object oriented analysis, its used in 90% of the software projects with UML diagrams. But you should keep in mind that even though there are a number of UML notations, the lass diagram should be as simple and clear as possible without complicating it with unnecessary notations. Clasification of classes should be done keeping in mind the object orient principles and after listing the relevant classes you can depict them with the help of the class diagram.

An example of a class diagram is given in Figure A to give you an idea of the structure of class diagrams:

Figure A : Example of Class Diagram

In Fig A, lets take the “Dishware” class, it has three compartments. At present the attributes and operations compartment have been left blank, Each operation is prefixed a “+” sign to depict that its a function and suffixed by “(). The variables which will be input or passed through the function can be included within the symbol”()”.

Also included in the example are six other classes “Plate”, “Bowl”, “WoodenPlate”, “GlassPlate”, “WoodenBowl”, “GlasBowl”. The two classes “Plate” and “Bowl” are generalization of the main class “Dishware”. This can be depicted by the hollow triangle symbol as shown in Fig A. The two classes “WoodenPlate” and “GlassPlate” are generalization of the class “Plate” and similarly for the class “Bowl”, the two classes “WoodenBowl” and “GlassBowl” are generalizations. Generalization means that the sub classes will inherit the behavior of the main class but will have attributes of their own as well. Lets take the example of “GlassPlate”, it will have the attributes of the class “Plate” like shape etc nut will also have its own attributes.

What is RUP (rational unified process)?

RUP stands for Rational Unified Process. Its a software development process framework which has been taken forward by Rational(part of IBM corporation)

Its a proper guidelines to be followed so to achieve standardization and improvement of the existing processes. RUP has phases and iterations which have to be followed with the help of templates and guidelines implemented at each stage. The intention of usage of RUP is to provide standards for all stages of the software development life cycle. RUP is supported by different tools and methodologies among which is Rational's UML(Unified Modeling Language).

In the figure, the Rational Unified Process Model can be diagrammatically viewed. As depicted, RUP has four distinct project life cycle phases:

a) Inception – is the part where the actual exploration of the concept happens with the stakeholders management, definition of the project scope, cost benefit and feasibility analyses. This is the starting phase of the project and actually provides the foundation for each of the ensuing processes.

b) Elaboration – This is the phase where the project starts to take shape. The requirements are more or less frozen and the design of the system gets into its first draft.

c) Construction – This phase is the actual building phase of the project where the software takes shape and it involves the major coding part out of the four phases. Testing is also part of this phase. The first cut release of the software is the objective of the phase

d) Transition – This phase is the wrapping up of the system with the release to the client and the final support phase of the software system starts.

RUP also has six engineering disciplines and three supporting disciplines. These nine RUP disciplines are part of each iterations required in the project life cycle. The six engineering disciplines are somewhat similar to the waterfall model phases whereas the three supporting disciplines are unique to the RUP framework.

I. RUP Engineering Disciplines

a) Business Modeling – Initial modeling of business with the analysis and scope formation

b) Requirements – gathering and communication of requirements

c) Analysis and design – analysis and formation of the solutions designs

d) Implementation – Implementing the solution

e) Test – testing the system as a whole and in units

f) Deployment – finally deploying the system at client site and going into production level

II RUP Supporting Disciplines

a) Configuration and Change Management – configuration of the versions of documents and code. Management of changes to requirements, solution and codes as required

b) Project Management – Planning, estimation, resourcing and overall managing the team and customers as part of the project

c) Environment - Ensuring that the project team is aware of all aspects and of the RUP implementation.

Fig A – The Rational Unified Process Model

As per the Fig A , the RUP framework is depicted as a “hump chart” with the matrix showing the RUP phases and the RUP disciplines. Lets say for example, the requirement discipline is peaked at the initiation and elaboration stage after which it flattens bout does not completely disappear. Similarly project management discipline is required to be at a constant peak throughout the project and cannot flatten or lag behind in any phase.

RUP is one of the most complex software development project life cycles and involves proper project planning for the successful implementation of the system

What is UML?

UML or Unified Modeling Language is a modeling standard in the field of object oriented software systems. It has been standardized by OMG(Object Management Group) after being developed by Rational Corp(Booch Group). UML is a modeling language which puts together several diagrammatic views which can be used for any stage of the software development life cycle. UML was designed basically to provide a common platform for all the stakeholders in a project starting from the end users, analysts, designer, developers etc who are vital to the success of the project. So, in a way it cut down the miscommunication of the requirements and the display of the design in one common language which is understandable by everyone concerned.

But UML provides you with the syntax of the diagrams and views but does not actually give you the context in which it has to be used. Its up to the designer or analyst to find the best fit for the particular UML Diagram. The best thing about UML is that its code independent. As long as its object oriented programming, UML diagrams can fit into it.

UML provides us with the different diagram types which can be used in the design of an object oriented software systems. They are broadly classified into Structural Modeling diagrams(which depict the static structure of the system) and Behavioral Modeling diagrams(which depict the behavior and transactional movements of the system). Some of the most commonly used UML diagrams are:

a) Use Case Diagrams – is a high level diagram depicting the system boundary and the interaction between the actors(users/external interfaces) and the system

b) Interaction Diagrams – Shows how the different objects of the system interact with each other

c) Activity Diagrams – shows the business process flow and makes use of the use cases similar to data flow diagrams

d) Class Diagrams – depicts the properties and behaviors of the classes to be used in the system. Objects are instances of Classes and an Object diagram depicts the objects in a similar manner to the class diagram.

e) Sequence Diagrams – are used to display the orderly sequence of message transfer between entities of the system

f) Component Diagrams – shows the component types and their dependencies in the architecture of the system as a whole

g) Deployment Diagrams – shows the physical architecture and the deployment components.

Fig A – UML Diagrams

Out of these UML diagrams which are as shown in Fig A , Business Analysts worldwide would mostly use the Use Case Diagram, Activity Diagram and sometimes, Sequence and Class Diagrams. Apart from these , the majority of the rest of the UML diagrams are designed by the solution architect or designers. It is not essential that for any project all of the UML diagrams will have to be made. The UML diagrams are vital for a business analyst as they help him in getting the requirements validated and assessed. UML diagrams also add clarity to the functional specification documentation and hence are widely used by the Business Analysts to corroborate their requirement elicitation.

SDLC - Systems development life cycle

SDLC Process and methodologies

SDLC or systems development life cycle is the complete processes involved in the development of the software application. Generally, the software development life cycle follows broadly the steps as described :

a) Project Initiation

This is the stage where the initial feasibility of the project is done with the stakeholder management and actually laying the foundation of the software project.

b) Requirements Analysis

This is the stage where the stakeholder needs are analyzed, structured and documented.

c) Software Design

The requirements captured in the previous phase are converted into a viable solution design by the analyst and the solutions team.

d) Development or Coding

The actual programming or coding of the project happens in this stage and its essential that the actual requirements have been frozen.

e) Testing

This stage involves the various testing phases such as unit, integration, system , regression testing. The final acceptance testing is done by the users so as to test that there are no gaps in the requirements they signed off and the final delivery.

f) Deployment and support

This is final “go live” stage of the project where the system is deployed on client site and maintenance and support of the system is provided for a previously agreed upon period of time.

There are various SDLC methodologies which have developed over the past and guide us through the software development life cycles. The major SDLC methodologies are :

a) Waterfall method – this is the original model of SDLC and was one of the most widely used systems development process till the more advances software methodologies came up. Its still used in many major software projects and as with any other methodologies has its pros and cons. It is beloved to be very rigid in its structure and is believed not to have a very client friendly approach. A diagrammatically waterfall model is depicted with its different phases given in Fig A.

Fig A – Waterfall Model(Original SDLC)

b) Rapid Application development (RAD) – To counter the traditional, non agile software development processes, RAD was brought forward which involves iterative development and more interaction with the client at all stages of the project life cycle.

c) Prototyping Model – This model even though not very popular is a very useful methodology especially to the client. This is because it involves the presentation of a simplified prototype of the system based on the requirements gathered and analysed. So, based on the client's feedback on the prototype the rest of the software development process takes place.

d) Spiral model - its an amalgamation of the waterfall and the prototyping method, in which after an initial version of the prototype is evaluated by the customer and the next version is developed. Each iteration in between follows the phases of the waterfall model.

Usually, a hybrid of these SDLC methodologies are also used as they are the best fit for the success of the software project. Depending upon the project time lines, cost and customer expectations, the SDLC methodology should be selected as each methodology has its own advantages and disadvantages.

High level Business Analyst role Business Analyst is a very prominent term in any successful organization. So the role of a business analyst is not simply understanding the business process but it extends its wings to other branches such as complete business process, understanding the nature of the business and its flow from bottom level to the top level. A business analyst has to take care of all aspects which can take the business to a top level and in a successful path. A business analyst will make the new processes and these processes and these processes have to be designed in a detailed way so that the other layers of the business can implement these new processes. These business analyst will have to consult on regular basis with al the key roles in the business unit and understand the process how the business is running. The main key persons that a business analyst will have contact are management, ie top layer, finance department, HR department, production department, sales department, marketing department, and has to understand the customer mentality with regards to this business etc.. On a regular basis a business analyst will have to change or modify the existing business process in order to improve the business profits and as well as customer satisfactin..

What is usecase diagram and how to draw it?

What is a use case? Definition of usecase .. Define use case..importance of use case diagram

Understanding use case is very easy, but to practice on how to draw use case diagrams may take little to no time. Use cases (use case diagram), as the name indicates they are really very useful cases in understanding the flow of the software application and the interaction between end user and the system.

Every step of use case defines the interaction between the two(user and system/application/product/etc..).

Do not get confused with different terminologies for almost similar meaning. In software industry the final software product is called in different ways, i.e. software product, software application, end product, system etc..

Well, come back to our use cases now. Use cases are very brilliant idea of representing the nature of the existing/future application in a pictorial way so that even a common man can understand the system and how it responds to the user interaction.

To speak in a very lay-man language, if a user clicks on a button, what happens next? Which screen will come, est.’s represented in use case diagram.

Every use case diagram consists of several use cases. Each use case indicates an individual functionality with in a system. I.e. a single use case indicates probably a step in the entire application.

Use cases are very near (conceptually) to requirements documents. Gathering software/system requirements, writing functional specification and drawing use case diagram are very dependable documents. One needs the help of other..

Relation between Requirements gathering, Use cases, FRS(functional requirements specification), TRS(technical requirements specification)

The order goes like this..

Gathering system requirements from the business users or SMEs (subject matter experts.

Prepare a FRS (functionally requirements specification) from requirements..

Prepare a use case diagram from the FRS

Prepare technical requirements specification (TRS) from FRS.

While testing the application, test cases are written based on use cases, FRS & TRS.

In a nut shell, we can describe a use case as a set of scenarios of the entire application.

There are particularly two elements that are used in drawing a use case diagram.

One is ‘ACTOR’ and other one is ‘Use case’.

Here Actor will represent an user and ‘use case’ will represent a single unit of process of the entire system. Actor will do something to the use case. And use case will respond for the actor’s action.

The simplest way to draw a use case diagram. An easy example of usecase diagram. Learn how to draw an use case.

The below simple use case diagram is also called as a UML diagram also. UML stands for Unified modeling language.

Here we go. How to draw a simple use case diagram step by step procedure.

For example, a Customer wants to open a bank account in a bank, bofa.(bank of America).

This is an activity, a process, of the entire banking application. So, we will discuss how we can write steps to write a use case diagram for the above activity.

1) Customer calls the bank information center (customer service) to know the procedure of opening an account.

2) Bank customer service people will explain him the process that includes the required documents to submit in order to open an account in their bank.

3) The Customer will contact the accounting department along with the required documents and does all the things that are told by accounts dept.

4) Bank accounts dept will review the Customer’s documents and if he qualifies, an account is granted on his name.

5) Bank personnel will send the new account details like atm card etc. to the customer’s address.

In this way, a simple use case diagram can be drawn. From the above use case diagrams, the requirements can be easily derived.

For any business analyst it is very important to know the differences between, use case diagrams and class diagrams. Also learn how to draw class diagrams and what is the use of class diagram..

State transitions diagram

We use state transition diagrams for object classes that have lot of dynamic behavior.

The button is on..The button is off. Generally to see the state of the object.

Mostly used ehn the objects are dynamic.

Component diagram:Every system will be made considering the physical world. That’s where this diagram comes into the picture. These diagrams illustrate organizations and dependencies among software components. Includes source code, runtime components etc..

Deployment diagrams:

When it comes to deploying the product then these diagrams come into picture. They show the process on the system and connections between them. It is a visual way of knowing what executables running in my system

What is Class diagram

Class diagram is an important one to know if you are a business analyst. Like use case diagrams, these class diagrams also explain the application in a pictorial representation, but in more technical way where a common user cannot understand by looking at these. A class diagram represents the relation between each class of the entire application. In one way it is a static representation of a structure of an application. It clearly tells the different classes and its attributes and relation between each class.

Normally for each member there will be few notations to tell more about the class member. These notations are placed before class. They are PUBLIC, PROTECTED, PRIVATE & PACKAGE.

In a nut shell, class diagrams can be defined as object oriented analysis and design documents. These class diagrams explain the relation between each class in a system and they properties, attributes, etc..

A typical class diagram will have three sections to represent each class.. In the below example I will explain one such class for your understanding.

In the above class diagram example, Customer is one class. And as each class is divided into 3 sections, under customer, there are attributes and under that there are methods. And there is a relation between each class.

A class is basically defined as a collection of objects that have the same structure, common behavior, relationship and semantics.

Alternatively defined as an instance of an object. We can find them by examining them in sequence and coloboration diagrams. They are represented in UML in rectangles.

Business Analyst Roles and responsibilities

Business analyst is a key person between business users(clients) and software engineers(typically technical & functional consultants & developers). They are the bridge between business users and technical people who will typically understand the business terminology & business language of the client and as well as technical language at the development place.

The essential duties of a business analyst is basically to gather the requirements of the client from business point of view and understand them thoroughly make a draft in MSWord (or some other form), and write use cases from that document in such a language that technical people will understand.

These use cases will be send to technical people from there they will make functional specification, technical specification, programming (coding, development) and finally testing of the product they made. Business analyst will not sit idle until this process completes. In the entire process of development, technical persons will get some or many questions regarding the business and what ever the problems they get, will be reported back to business analyst and the business analyst will intern contact business users to discuss about the issue and understand the logic from business point of view and make a documentation and will give it to technical people.This whole process will repeat until the product is completed or there are no questions from business understandability.

What is RUP (Rational Unified Modelling) ? with examples

Inception Phase:

Interacting with business users , developers and project manager to make business requirements by using tools like MS Visio and MS word. MS excel also used for some documentation purpose.

Using RUP (rational unified modeling) to make BRD (business requirement document) specifications.

Performing requirement analysis and design work with rational rose and analyzed, documented the system specifications, business requirements and detail design of the existing business by using a the tool requisite pro for the requirement tracking and analysis.

Elaboration Phase:

In this phase created Activity diagrams, sequence diagrams and collaboration diagram etc by using Microsoft tool MS Visio.

Documented the critical path analysis and extensively analyzing the ER diagrams (entity relation diagrams).

Also finding out the different opportunities and parameters that can improve the business process and performance.

Finally coordinating the project scheduling with IT development manager.

Construction Phase:

Developed a prototype for actual system and developed project blue print. Also developed a mock web page generation for a part of the system goal.

Writing use case specification for the given business requirements.

Identifying the actual network and human resources to utilize properly for development, documentation and training purposes.

Transition Phase:

In this phase we concentrate in vendor software compatibility , data base integrities and other performance issues.

Successfully deploying the finished product.

Configuration, implementation and deploying the developed software in various cross platforms to see the products efficiency.

Bug life cycle in testing

If a bug comes, we open the bug issue. It should look like below.

Open the Issue (bug/defect)

Delegate the bug/issue/

If from business side, then send to business dept.

If from IT site then send to Technical dept.

Resolve the bug by assigning it to concern developer.

Withdraw.

Finally Close the bug.

Test director is a good reporting tool used for generating the test reports

Who are Business users of the system

Business users and roles of to be system will be revisited while defining workflows.

Business user/role/usr grp

Location

Subject matter knowledge

Technical knowledge

Preferred environment

Background Other observations

Business requirements are simply states what system wants to be in the future. Benefits of the new system etc.

Business requirement 1

Requirement id Requirement type Use case #Description Rationale Source Source documentAcceptance criteria Global / local Specify IOPriority Change history

User requirement Specification (URS)The URS is a document produced b on behalf of the organization. This documents the purpose for which the system is going to be developed and its functional requirements . Also provides system requirements etc..eg: microsoft vista etc..

Some times URS and FRS will be same and some times they document separately.

Test case templateTest execution and execution log:

Prepared by: Prepared date:

Project name: Approved name:

Document intro: The purpose of this test case is to document the relevant details of collection of data detailing what occurred during testing.

Case Case description Test date Expected result Actual resultPass/fail Date executed comments

SSB/r1 Create a dail reports There should be no

Bundle type enter necessary prior day label and

Fields. Save and run bundle. Check box appar on

Submit page.

Class Diagrams.A class is basically defined as a collection of objects that have the same structure, common behavior, relationship and semantics.

Alternatively defined as an instance of an object. We can find them by examining them in sequence and coloboration diagrams. They are represented in UML in rectangles.

CMM levels (Capability Maturity Model).

CMM capability maturity model is a way to develop and improve a organizations process. CMM is a structure of several components that describe the characteristics of a successful business.

Level- I

Here the organizations process are ad-hoc and mostly an organization does not provide a stable environment. So, the success of these organizations depend upon the people in the organization and competitiveness, but not on the proven processes.

Level- II (Repeatable)

Here software development success are repeatable. The process may not be repeatable for all projects in the organization. Company may use some basic components.

Some times when in stress, companies may use the existing or past success processes in present to over come the problems.

Level- III (Defined)

Organization have a set of standard processes for its success. This is the basic principle/standard for level-III.

The difference between level-II & Level-III are scope of standards, process descriptions and also standards, procedures. At level-II the standards and procedures may be quite different from project to project. Where as in level-III, they will be same in most cases.

Level- V (Optimizing)

Level V focuses on improving technologies and innovative trends in terms of modernization and technology to meet the up to date industry standards. Quantitative process improvement objectives are established. The effect of deployed process improvements are measured and evaluated.

Collaboration diagram

Collaboration diagram. (business analyst) / Communication diagram.

Collaboration diagram: Displays object interactions organized around objects and their links to each other.

First thing you need to know is there is no much difference between collaboration diagram and communication diagram more or less thy are same. Communication diagram is little simplified diagram of the collaboration diagram.

A collaboration diagram is nothing but the relation between objects in a system. It is very easy to draw the collaboration diagram. Between each objects there is line that will be drawn with an arrow mark at the end of the line and a number is also indicated at the end of the line.

There are mainly 3 main elements in an collaboration object. 1) Object, 2) Relation 3) Message.

a) Object is the one that exist in the application.

b) Relation is the actual relation between two objects and the numbers 1, 2, 3 etc shows the sequence of the interactions.

c) Message is the functionality that is happening between object1 & object 2.

The main objective of this collaboration diagram is it gives the messages that will come between two objects for a particular use case or scenario. It is mainly used when there is a big scenario. This diagram is just a different view of a scenario. Sometimes sequence & collaboration diagrams are called as interaction diagrams.

Data Mapping & Data Modelling

Data model / Mapping document.

This section talks about how many tables are there and what data is lying in what table and what tables are there in production server? And also describes the relation between all the tables and how they are linked each other…etc..

Data Mapping:

It is basically the connection between deployment and production server. That is table names may differ in two servers but data will be same. Mapping between the tables that have the same data.

SQL queries:

There are two types of operations in SQL. One is retrieval and other is modification. Where as BA only works with retrieval and not with modifications.

Ex: select customer_name from CUST where dept = 10.

The above statement retrieves all customers from CUST table who belong to department 10.

Data model in database

Initially DBMS ---Database management system. Then RDBMS---Relational database management system. Data is organized in rows and columns.

1. Conceptual.:

It describes the semantics of an organization. i.e departments in the company and their relationship.

2. Logical:

XML, tags, logics in columns.

Eg: SSN, employee etc..

3. Physical.:

How the data is actually stored in physical warehouse.

Deliverables in SDLC and stages

Initiation stage: Problem definition, Approach and roles / Project plan.

Feasibility stage: Feasibility report / user’s requirement concept, Conceptual design, Project plan.

General design stage: General design of the project and preparing functional specifications and a detailed design plan of the project.

Development: Implementation report , user procedure manuals and training manuals.

Implementation: Completion of the project and approval notices.

Post installation: Gathering data for post installation. i.e after installing the software. And an evaluation report.

Tools used by business analyst

Software development methodologies.

Rational unified process (RUP), UML, SEI-CMM

Business modeling tools Rational rose, MS visio, MS Project.Requirements management tools Rational requisite proAutomation tools Rational robot, test manager, Win

runner, Load runner.Visual modeling tools Rational rose, MS visio, Snag ITTesting tools Win runner, QTPChange management tools Rational clear questReporting tools Crystal reports, SODA.

Rational Tools

RUP E-coach Process and templates Rational rose ModellingRational requisite pro Requirement gathering Rational clear case Configuration managementRational clear quest Change managementRational test director testing

BRD (Business requirement diagram)

Project name: abcd….

Current version Owner Date last updated

Last updated by Author Date created Approved by Approved date

Revision History

Version no Date updated Revision author Brief description of change

What is Q-gate ?

This is one of the many techniques employed in quality assurance. It is called as Q-gate or Quality gate. Q-gate when it is used in combination with project management helps to manage the balance between project cost, software cost, functionality and quality.

It acts as a process end phase for a particular phase and acts a s a gate from where the project moves from one phase to another phase.

The main benefits of Q-gate concept are:

Project stakeholders share the responsibilities with the project manager for the quality outcome of the product/project.

Q-gate provides as a easy assessment tool for the developers/testers tec…to see the quality of the product at each stage so that they can deliver a quality product at each stage.

Q-gate enhance project communications and there by improving the quality of the project.

Q-gate is a simple process that tells what already happens and what should have been happening and communicates it to all stake holders.

What is RUP ?

RUP (Rational unified Processing)

Inception phase:

In this phase the business case, business context, success formula, success rate, market competitions, expected revenue and expenditures will be evaluated.

Elaboration phase :

In this phase the base line of the project starts and takes a basic shape. The architecture of the project takes place here in this step.

This phase must pass the life cycle architecture milestone by meeting the below requirements.

A use case model where use cases and respective actors will be identified.

Description of the software architecture in a software system development process.

A development plan for he entire project.

In this phase even the project can not pass the life cycle mile stone, nothing will happen because we have time to change the design and architecture of the project. But after this phase any changes that are made have huge affect on the total architecture of the project and will be very difficult.

Construction phase:

In this phase lot of coding will be done and mainly focused on programming work. The external work of the project will be done. Mostly each use case will be done a s aseperate component to see the result.

Transition Phase:

In this phase the product will be moved form development environment to end users place. Here many activities take place such as training to the end user, beta testing, and all scenrios will be tested according to end user expectations.

What is sequence diagram and how to draw

Sequence diagram (role of Business Analyst)

Sequence diagram is one more very essential and yet important pictorial representation that a Business analyst needs to know.

UML Sequence diagram is mainly designed to tell the interaction between objects in an application in a sequential order, i.e. in the order that these interactions occur.

Normally existing use cases are split into two or more sequence diagrams in the requirement phase. There is an assumption that sequence diagrams are only meant for developers as the class diagrams. But in fact these sequence diagrams are useful for even business users and also for all personnel who ever uses the application. Sequence diagrams give an idea of existing system and how each functionality related to other in the application, and by that the business users can suggest future business changes and can know before hand that which objects may get influenced with the new changes.

The ultimate purpose of this sequence diagram is to explain the sequence of different events in an application which will result some sort of output.

In sequence diagrams, the main importance is given to the order of occurrence of the different actions/events, but not to what is actually happening in every event.

The typical sequence diagram will look like below:

In the above diagram, there are several events (objects, actions, functionalities) that pass messages from one event to other. The diagram exactly gives the order in which the actual application works.

For example, if you take a school:,

- Once the student eligibility process is passed, then only student will get admission.

- Once he gets the admission, then only he pays the fees and go to class.

- After attending the class only, he can write the exams.

- After writing the exams only, he will get marks cards (grade).

In this process, the whole school application works in an order, in a sequence of events that occur one after other. Then only the application works properly. This is where the sequence diagram plays an important role. Sequence diagram aims on these steps. It identifies the order of events that occurs in an application.

You can get more details on sequence diagram, in the below link.

http://www.ibm.com/developerworks/rational/library/3101.html

what are Deliverables in RUP and phases

Inception phase: Project plan, BRD, High level usecases.

Elaboration: UML diagrams, Change management & config management.

Construction: System code, QA testing cases, / test scripts, and a test plan.

Transition: Product delivery, Project documentation.

UML (Unified Modelling Language) DefinitionUnified modeling language (UML) is standardized specification for object modeling.

UML is a generalized language that represents a graphical notation that is used to create an abstract model of a system.

It is a standard language that visualizes, constructs, analyzes and documents the components of a system.

Activity Diagram

Activity diagram show the flow of control.

Use case diagramUse case diagrams are created to visualize between actors and use cases.

State transitions diagram

We use state transition diagrams for object classes that have lot of dynamic behavior.

The button is on..The button is off. Generally to see the state of the object.

Mostly used ehn the objects are dynamic.

Component diagram:Every system will be made considering the physical world. That’s where this diagram comes into the picture. These diagrams illustrate organizations and dependencies among software components. Includes source code, runtime components etc..

Deployment diagrams:

When it comes to deploying the product then these diagrams come into picture. They show the process on the system and connections between them. It is a visual way of knowing what executables running in my system.

Usecase example

Ucd id: A.1

Use case Name: Get paid for travel expense.

Objective: Getting paid for travel expenses.

Primary actor : The person who claims.

Scope: The Accounting department.

Stakeholders: 1. Claimant: (purpose: to get paid the max amount).

2. Accounts department (Purpose : To pay the minimum possible).

Trigger : The claimant submits(fires the event) the claim, (claim for travel

reimbursement)

Success scenario: 1. Claimant submits the claim with data.

2. Accounts department checks(validate) the submitted bills.

3. Department person verifies all bills if they are correct.

4. Accounts dept pays the claims.

Failure scenario: 1. Submitted data is not complete.

Solution: Accounts dept requests for missing data and claimant

submits the same.

2. Claimant does’t authorize to claim the travel expense.

Solution: Accounts dept declines the claimant and stops all

processing.

3. Travel violates basic traveling policies.

Solution: Acounts dept declines the process.

Usecase template with example

Author: David ryan Date: May 7th, 2007. Version :1

Use case name ATM USE CASE type

Business requirements : yes.Use case id ATM-WPriority HighSource Requirement-RATM-

WPrimary business actor

Customer/bank account/Card holder.

Other participating actors

Bank

Description The use case describes the withdrawl process of money from a ATM. It contains various steps that involve the verification of customer card and processing and generating receipt and giving money.

Pre condition The customer withdrawing money should have a bank account and a valid card.

Trigger The use case will be initiated when the user inserts card in the slot.

Typical flow of events

Actor Action

Step 1: The customer inserts the card.

Step 3: The customer will enter the PIN.

System Response

Step 2: The system will check the validity of the card and will prompt for PIN no.

Step 4: The system will check the database and validates the PIN no & customer acct.

Step5: Bank database confirms the correctness.

Step6: ATM asks the customer to enter the amount to be withdrawn.

Step7: Amount verified against the balance in cust acct.

Step8: ATM dispenses the amount

Step9: Receipt is printed.

Step10: Card is ejected.Alternate cources Alt step 2: If the customer inserts a invalid card or

improper insertion then system prompts a message to customer.

Alt step 3: Customer enters wrong pin, then system will show a error message.

Alt step 4: If the amount entered is more than balance them system shows a message.

Conclusion The use case concludes when the card is taken out of the slot.

Business rules The customer has a valid card with a bank account in the bank.

The machine has sufficient amount. The amount to be withdrawn is with in the limits set

for a day.

There is sufficient amount left in the account.(minimum required)

What is JAD session

JAD session:

1 It brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop.

2 JAD participants typically include:

o Facilitator – facilitates discussions, enforces rules

o End users – 3 to 5, attend all sessions

o Developers – 2 or 3, question for clarity

o Tie Breaker – senior manager. Breaks end user ties, usually doesn’t attend

o Observers – 2 or 3, do not speak

o Subject Matter Experts – limited number for understanding business & technology

3 Advantages:

o Shortening of the time.

o Improves the quality of the final product by focusing on the up-front portion of the development lifecycle.

o Reducing the likelihood of errors that are expensive to correct later on.

What is GAP analysis

Gap Analysis:

1 The process of determining, documenting, and approving the variance between business requirements and system capabilities.

2 The process of determining and evaluating the variance or distance between two items’ properties being compared.

3 The study of the differences between two different systems or applications, often for the purpose of determining how to get from one state to a new state.

4 A gap is sometimes spoken of as "the space between where we are and where we want to be." Gap analysis is undertaken as a means of bridging that space.

UAT (User Acceptance Testing):

1 Final phase in a software development process in which the software is given to the intended audience to be tested for functionality.

2 UAT is either done by making the software available for a free trial, typically over the Internet, or by using an in-house testing panel comprised of users who would be using the product in real-world applications.

3 UAT is done in order to get feedback from users to make any final adjustments to the programming before releasing the product to the general public.

4 UAT also is called beta testing, end-user testing or application testing

Daily duties of a business analyst

Daily job duties of a business analyst:

Probably you must be wondering what exactly a business analyst is. After all those stereotypical definitions of a business analyst, you still must have some questions as to what exactly does a business analyst do and how does he fit in a firm. Well, this article will let you know how a typical day looks like in the life of a business analyst.

A business analyst needs to have knowledge of both the business and the IT of the firm. Business would include policies, processes, business models and infrastructure while the IT part involves the implementation of these. When firm is facing a strategic or organizational obstacle- that is where the business analyst jumps into action. A business analyst needs to have the right blend of both in order to carry out his tasks effectively. Hence a BA is required to have both the IT skills to understand the current implementation and also knowledge of business to remodel it.

When a BA is presented with a case, the following would be the typical steps that he would take to solve it:

1. Defining the problem2. Staffing the team3. Working with the client4. Discoveries along the way5. Impact

Defining the problem will include doing the initial analysis of the case to give it more clarity and to eliminate possible miscommunications between the BA and the client. This would require setup of meetings with stakeholders either for clarification or follow-up, getting hold of relevant documentation pertaining to the problem and documenting your analysis and findings. Making a

business decision requires hard data along with wisdom and leadership. While defining the problem, the BA will require to couple quantitative analysis with strategic thinking in order to arrive at the way of approach to solution.

While staffing the team, one must remember that it is not necessary for the entire team to be present at one location. Teams could be divided by geographic location and time zones. In such cases, proper communication with all sub-teams forms an important part for everyone to stay in the same page. Another task of the BA would involve getting an heads-up from different teams in different time zones. Also while leaving for the day; they would have to inform the next set of duties for the team in a different geographic location. This show why being able to work in a team and proper communication is some of the required key skills in a BA.

A BA distills his discoveries into solutions creating an impact in the way the client organization will function from now on. A simple example of the role of the business analyst could be in the task of cost cutting. In the current economy, many organizations and firms would have implemented cost cutting in their business models in order to survive the bad times. A BA is the one who identifies the issues (in this case, the extravagant expenditures), forms various hypotheses and analyses, distill their conclusions into recommendations and present it to the client management who will incorporate that into their business. A BA could either work closely at the client side or at the parent organization, but in any case his job would be to get as much information about existing systems from the client, have brainstorming sessions with team to input ideas and help build effective solutions.

What is system analyst

System Analyst

Who is a systems analyst and how is he different from a business analyst? A person responsible for the different activities such as supporting the systems or applications, providing technical guidance to the business analysts, providing technical know-how for the new systems which are to be put in place and keeping the organizational strategic and business objectives in mind while doing the said activities. As per doing all these activities, the system analyst is a vital part of the software project life cycle. The main attributes which can be associated with a business analyst are strong technical skills, project management skills and analytical skills. Strong project management skills are required; because in essence, systems analysts actually lead some parts of the technical team as far as the technical know how goes and should have the flair to do this. Due to the strong technical skills, the system analyst can identify the issues with the current systems if any, provide guidance to the technical team during development or thrashing

out of the systems design and architecture. The system analyst should be familiar with the various programming languages, different software such as ERP systems, Reporting as well as Data bases. System analysts are also expected to be involved in the system, load and stress testing levels. They can also be responsible for documentations such as the technical specifications (while the functional specifications are done by the business analyst), technical manuals, instructions manual for the technical team which might include the batch jobs run, handling and backup of databases etc.

But also important are the soft skills like communication, taking the initiatives, leading the development team if required towards the right direction. The system analyst actually interacts with users at all levels starting from the end users and the stakeholders to the technical team and the functional analysts. System analysts play a vital role in interacting with the third party vendors or organizations and ensuring that they are on the same lines about the project. The costing analysis of each project is also the responsibility of the system analyst. They can also be looking into the technical feasibility study of a system while the business analyst does the functional analysis. So, actually the system and business analyst would be working on the same system but will be analyzing and evaluating it from different perspectives – the systems analysts evaluates whether its technically feasible to go forward with the project, system or enhancement while the business analyst evaluates whether the project will be in line with the business objectives and improve the business processes. So, the business and system analyst should always work hand in hand and have great communication skills between themselves. In some organizations, the role has even been merges so as to have a “business systems analyst” who performs the activities from both the system and business analyst perspectives. It’s finally the prerogative of the organization in which way the job profile of the system role will be defined, but we have given here an overview of his general activities!

UML tutorial part1

Visual Case Tool - UML Tutorial

Welcome to the Visual Case Tool – UML . An introductory overview to UML (Unified Modeling Language) is given in the following pages with the help of Visual Case. UML is considered to be complex and rich modeling language and this tutorial aims to give you an overview of the most common aspects of this language.

Unified Modeling Language (UML)is a graphical modeling language that is used to enhance the object oriented designs. The language has been standardized so that the artifacts and components can be specified for the development of a software system. UMLS should be considered as a notation and not a process. This is because UML does not provide with a single method or design process, but is considered as a standardized tool that can be used in a design process.

There are in total eight UML diagrams which you can go through in this tutorial. But before we start, download Visual Case(only the trial version - free of charge for 30 days) so to aid in the understanding of the tutorial and for hands – on experience.

The Use Case Diagram

Use case diagram is the first one in the design processes which most of the designers will start to work on while initiating a project. The use case diagram brings out the depiction of the high level user goals which are to be carried out by the system. Such high level user goals may not be necessarily actions or tasks, and on the other hand be specifications for the general systems functionalities.

Use Case

Technically defined, use case is actually a set of scenarios. Each of theses scenarios is actually an order of steps which define the interaction levels between an user and the system. A use case collates all the scenarios which implement a specific user goal.

A use case is a textual description of the scenario steps which are required for ideal or the positive flow and also any alternate scenario possible at each of the steps. Here, there is a sample use case which gives the flow as to how the keyword search is done on the website:

Ideal Flow:

1. The keyword is entered by the customer on the website2. The search button is clicked by the customer.3. Search is completed4. Search results are displayed

Alternative Flow: Search FailsIf the search fails at step 3, Redirect User to search screen at Step 1

With the help of the Visual Case tool which you have downloaded, the use case steps can be specified in the description field. To do so, you will have to right click on a particular use case and elaborate on the properties. A report can then be run by you and even printed or exported to HTML or ASCII text for evaluation and proofreading purposes. In totality, the use case diagram and its report include all of the use case details such as the scenarios and actors required for the system design process.

Actor

The use case diagram is used by the designer to graphically represent the use cases and the involved actors. An actor can be defined as a role which is played by a user in the system. The distinction of a user from an actor (or user role in a system) should be made more clearer. A system user can have different roles according to the action performed and an actor may be the role itself or even another system. An actor can be for e.g - a salesperson, support person, manager and even a web store system. In the physical world, the same user may be performing

two roles - a sales person and support person. Hence, while a use case diagram is being modeled, the roles and the action being performed by them should be concentrated on rather than the user or individual.

Associations

While modeling the use case diagram associations are usually drawn between the actors and use cases in order to depict the actor carrying out or performing the use case. There is a one to many relationship between a use case and an actor which can be explained as a use case which can be performed by many of the actors and vice versa.

As depicted in the above diagram, the stick figure shapes in green on the left are actors, the blue ellipses are the use cases, while the connecting lines in between them as the associations. The specifications for the system and user roles are done jointly by the developer and stakeholder while the model is created by the developer alone.

Includes

There are three other links through which the use cases can be related to one another. One of these is the use of “ Include” link which is depicted in the diagram below. The use cases invoice purchase and online purchase include the scenarios which is defined by purchase valuation and hence the <<include>> link. So, this link actually helps to minimize any scenario repetitions in case there are multiple use cases.

Generalization

A ggeneralizationh link is used when a use case describes a variation of another use case. As � �depicted in the below example, limit exceeded use case is a scenario is which the scenario of online purchase is not acted upon and hence the generalization link is shown from the former to the latter. Use cases which have a generalization link to another use case actually depict an alternative or exceptional scenario to the latter use case. Inspite of the generalization, the final goal remains the same for the use cases.

Extends

In some cases where the behavioral variation is to be described in a controlled manner, then you can define extension points in the extended use case. As given in the below example, search by name is extending search at the extension point of name. The extends link is more controlled in manner in comparison to the generalization link as the former link can be added only at the extension points.

Putting it all Together

While starting on the modeling of a use case, it is vital that the simplicity of the diagram is maintained. Firstly the system actors should be determined and only after that should the use cases being performed be finalized. It depends on you , whether the use case diagram is simple or complex but you should remember that the more simpler and uncluttered it is, the easier it will be for understanding purposes and will be better in capturing the system tasks. With the help of Visual Case tool, a use case can be exploded or drilled into a new use case diagram. For e.g, there may be further specifications which are required for the use case online purchase as we delve into the depth of the design process. A sub-diagram can be created within any of the

use cases in order to clarify and understand the sub tasks which are involved. It should be that a use case actually is the representation of a user goal and not any atomic programming operation. The point here is that there should be a simple use case design so as to clarify the user expectations for the system.

UML tutorial part 2

3. The Class Diagram

The class diagram is considered to be the core of the object-oriented design. The class diagram depicts the system object types and the prevalent static relationships between these objects..

Packages

Packages are used to break up a large number of objects into related groups. In many of the object oriented languages (e.g - Java), packages have been used in order to provide to the classes and interfaces more scope and division. In the UML diagrams, packages have a similar and in fact broader perspective.

In Visual Case, any of the UML diagrams can have packages. Each of these packages can contain any of the types and in any number of other UML diagrams, as well as the classes and the interfaces.

Classes

Class is the core element of a class diagram. In any object oriented system, system entities are represented by classes. These entities often relate to real world objects.

Given above is an example of a simple Contact class which stores the location information.

Classes can be classified into three categories:

Top: The name, package stereotype displayed in the upper section compartment of the class. In Visual Case, classes which do not belong to the same package are shown on a diagram with their entire path name. A stereotype can be optionally assigned to a class.

Center: In the center section of the class, the attributes are enumerated.

Bottom: The lower section contains the operations which a class can perform.

In a Visual Case class diagram, both the attribute and operations sections can be both hidden or shown as is required for all or individual classes. It is mostly used when you want your class

diagrams to be able to highlight only specific constructs of your system and the superfluous information such as operations and attributes can confuse and clutter the diagram.

Attributes

An attribute is considered as a property of a class. As shown in the above example, Contact class has the attributes such as an address, province, a city, country and a postal code. During the implementation of the class, functionality is provided in such a way so as to set and retrieve the information which has been stored in the attributes. The methods which are used to set and retrieve attribute data are known as accessor methods(also called as getting and setting methods) and are generally not shown as they can be inferred.

The format for the attributes of a class is given as follows:

visibility name: type = default Value

The visibility is as given below:

- Private

+ Public

# Protected

~ Package

During the process of object oriented design, most attributes are preferably kept as private so that the accessor methods can control access to the data. The most common exception to this preference are constants.

Visual Case allows you to specify the following properties for an attribute in addition to the name, data type,visibility, and default value,:

Array: an attribute can be set to be treated as an array of attributes and is displayed with square braces [ ]name.

Static: static attributes can exist only once for all of the class instances. As in the example given above, after city is set as static, if at any time the Contact class is used then the city attribute would always give the same value.

Final: final attribute's value cannot be changed i.e. its regarded as a constant.

Operations

The class operations represent the tasks or functions which can be acted upon based on the class data.

In the List class shown above, there are three operations and one attribute (an array of Objects)

The format for operations can be given as:

visibility name (parameters): type

The format for operations can be seen as very similar to the syntax for attribute except for the removal of a default value and the addition of parameters.

Parameters take the format:

direction name: type = default value

The direction can be one of the many options such as in, out, inout or it can be unspecified.

In Visual Case, the parameter list for one or all classes given can be shown or hidden. If the parameters list is hidden for an operation which has parameters, then it will be depicted as three dots (...) to indicate parameters do exist for the operations, but are now hidden. For some operations there are a number of parameters and hence they need not be shown all the time.

Generalization

Two classes can be linked with the generalization link in order to depict that one of the class has all attributes and operations of the other class, but also has additional ones.

Lets look at the above diagram in which the Contact class now has two child classes. So it can be said that the classes Client and Company have inherited, generalized or extended Contact class. In the child classes Client and Company, the attributes of Contact class (address, city, etc.) exists, but in addition there are other attributes. So, as is depicted in the above diagrams, Contact class is said to be the main class or superclass of child classes Client and Company.

The child classes may override the operations in the super class in some cases with the generalization link being used. In such cases, the child classes can include an operation which is actually defined in the superclass, but they can define a new implementation for the operation.

In the above diagram, OntarioTaxCalculator class diagram redefines or overrides the operation implementation in BasicTaxCalculator. That is , the operation is called in the same manner yet the code is different.

Sometimes the child classes need to be forced to override the operations of a parent class. In such a scenario the methods or operations in the superclass can be defined as abstract. The class can be defined as abstract if it has abstract operations. Each of the abstract methods and the classes have been shown in italics. But it is important to note that all of the operations in any of the abstract class don't have to be abstract.

The abstract operation calculateTaxes in AbstractTaxCalculator must be implemented in the child classes OntarioTaxCalculator and NovaScotiaTaxCalculator. As the operations has to be implemented, it is not essential to display them in the child classes, but its actually up to you. The key should be to have the diagrams as simple and clear as possible. The above diagram is simple and its meaning clear, but with the multiple levels of inheritance and more number of attributes and operations, you may choose to specify all of the methods that are overridden

Interfaces

MANY OF THE OBJECT ORIENTED PROGRAMMING LANGUAGES DO NOT ALLOW MULTIPLE INHERITANCE. THE INTERFACE CAN BE UTILIZED TO SOLVE THE LIMITATIONS POSED BY THIS PROBLEM. FOR E.G, IN THE CLASS DIAGRAM GIVEN EARLIER CLIENT AND COMPANY CLASSES GENERALIZE CONTACT CLASS AND ONE OF THE CHILD CLASSES MAY HAVE SOMETHING IN COMMON WITH A THIRD CLASS WHICH WE DO NOT WISH TO COPY IN MULTIPLE CLASSES.

The interface Sortable, is used in the above diagram to depict the child classes Company and Product can implement the operation sort. It can be said that Company and Product implement Sortable or they are Sortable. Because Product class already generalizes Contact, we cannot allow the same to generalize Sortable. So, we can make Sortable an interface and add a realization link to depict the implementation.

Interfaces are similar in structure and functionality to abstract classes but they do not have any attributes. All of the operations in an interface have no implementation, unlike that of a class. The child classes Company and Product are forced to implement the sort operation in it's totality.

ASSOCIATIONS

CLASSES CAN ALSO HAVE REFERENCES TO ONE ANOTHER. IN THE DIAGRAM BELOW, HE COMPANY CLASS HAS TWO ATTRIBUTES WHICH ACTUALLY REFERENCE THE CLIENT CLASS.

This is technically correct, but it can be more expressive to display the attributes as associations.

In the above diagram, the two associations have the exact same meaning as the attributes in the earlier version of the Contact class.

The first association (the top one) represents the old contactPerson attribute. There is one contact person in a single Company. The multiplicity of this association is one to one meaning that for every Company there is one and only one contactPerson and for each contactPerson, there is only one Company.

In the second (bottom) association, there are zero to many employees for each of the company. Multiplicities can be specified by you as anything such as given below:

0 zero

1 one

1..* one or many

1..2, 10..* one, two or ten and above but not

three through nine

At the end of each association , the arrows represent their navigability. In the above given examples, the Company class references the Client class, but the Client class does not have any idea of the Company. So, the navigability on either, neither or both ends of your associations can be set accordingly. If no navigability is to be shown then the navigability is unspecified in the diagram.

AGGREGATION AND COMPOSITION

The above given example displays an aggregation association and a composition association. composition is depicted by a solid diamond. The ProductGroup composed Products. This in turn means that in case a ProductGroup destroyed, the Products the group will be destroyed as well. The aggregation association can be depicted by a hollow diamond. PurchaseOrder is an aggregate of Products. Even if PurchaseOrder will be destroyed, the Products will still exist.

In case you have confusion regarding the difference between the composition and aggregation, all you have to do is to just think of the alphabet of the word Composition which means destroy and the letters 'c' and 'd' are right next to each other.

Dependencies

A dependency can exist between two elements in a way that in case there are any changes to one of the elements then it will also affect the other. For e.g, a class calls an operation in another class, then there is a dependency between the two classes. If the operation is changed, then the dependent class will also change. The goal should be to minimize the dependencies, while designing the system,

To help get clarifications on the dependencies in the design, you can draw a Package Diagram. A package diagram is nothing but a class diagram in which the packages and dependencies are displayed. Dependencies may exist between any of the components in the UML diagram. However at the highest level, dependencies will actually exist between packages. In a package, the dependencies can be numerous more than can be specified. But it's not that such numerous dependencies are okay. Even within a package its better to limit the dependencies, particularly between the packages and be strict about the number of dependencies which exist. In general, lesser the dependencies the more scalable and maintainable the system will be.


Class diagrams are considered to be the core of most object oriented designs so you will be finding yourself using them most of the times. Class diagrams actually closely relate to most of

the object oriented languages, so the basics such as the classes, the operations, the attributes, and generalizations, etc. should be fairly easy enough to be grasped. You should start with what you know and then probably move forward.

The most important thing which should be said about design is that you should not feel bogged down by it. In fact it will be better to have a collection of clear diagrams than many confusing and complex diagrams. In a previous example we saw the AbstractTaxCalculator was generalized by OntarioTaxCalculator and NovaScotiaTaxCalculator. If we tried to create a diagram with all ten of the Canadian provinces and three territories we would have built a huge and complex mess. In case we were designing a tax system for United States and suppose we tried to depict all of the states, we would land up in even more trouble. It will be clearer, and maybe just as expressive to show two or even three child classes and to add a note or comment to the diagram which explains that the other provinces and territories are to be implemented in the same way.

To keep the designs simple will allow you to be more productive and make your designs more usable and understandable. To add, as the system will be implemented and upgraded, the design should be kept in sync with your implementation. This will be far more easier with a simple and clear design of the key system concepts.

4. Interaction Diagrams - Sequence and Collaboration

After the use cases have been specified, some of the core system objects can be prototyped on class diagrams so that the designing of the system dynamic behavior can be done. If you recall the Use Case section of the tutorial, a use case encompasses an interaction in between a user and a system. Typically, an interaction diagram captures the behavior of a single case by depicting the collaboration of the system objects in order to accomplish the task. The diagram given below displays the system objects and the messages which are to be passed between them.

We can start with a simple example which is given above: that of a user logging on to the system. The Logon use case can be specified by the following steps:

Ideal Flow:

Log on dialog is displayed

USER NAME AND PASSWORD IS ENTERED BY THE USER

OK BUTTON IS CLICKED OR THE ENTER KEY IS PRESSED BY THE USER

THE USER NAME AND PASSWORD ARE CHECKED AND THEN APPROVED

THE USER IS ALLOWED TO LOG ONTO THE SYSTEM

Alternative Flow: Log on Failed

IF AT STEP 4 THE USER NAME AND PASSWORD ARE NOT APPROVED, ALLOW THE USER TO TRY AGAIN

We can now have a simple Use Case with which to work with and some of the classes involved in the interaction can now be specified.

The LogonDialog has public methods to display and hide the window, and a private method which can be called when the user clicks the OK button or presses enter. In our example (and most of the cases) you need not specify the interface dialog elements.

Our design also includes a LogonManager class that will include one method which returns true if the log on is successful, and false in case it fails..

A DatabaseAccess class will allow us to run queries for our database. A query string can be passed and a ResultSet of data will be returned.

Now that we have prototyped the classes involved in our interaction, we can begin to make our interaction diagrams.

UML tutorial part 4

Instances and Messages

Interaction diagrams mainly consist of instances and messages. An instance can be considered as the realization of a class. So if there is a class Doctor, then the instances of the class can be Dr. Jones, Dr. Smith, etc.. In any of the object oriented application, instances are what exists when you instantiate a class (that is create a new variable with the class as its data type).

In the UML diagram , instances can be represented as rectangles with a single label which is formatted as:

InstanceName: data type

You can also choose whether to name the instance or not. But the data type has to be specified at all times. After the name, the attributes and their values can be listed. In Visual Case tool, the attributes from your class can be mapped and new values specific to that instance can be entered. Attributes need to be shown only when they are vital and you don't have to specify and display all of the class attributes.

Messages actually represent operation calls. So, in case an instance calls an operation in itself or in another class, a message will be passed. Also, on the completion of this operation a return message will also be sent back to the instance which had initiated the call.

The format for message labels can be given as:

Sequence Iteration [Guard] : name (parameters)

Sequence: actually represents the sequence in which the message will be called. The sequence is redundant on the sequence diagrams, but is required on collaboration diagrams

Iteration: an asterisk (*) is shown to represent iteration if the message is called repeatedly

Guard: is an optional boolean expression (the result can either be true or false)

which actually determines if the message is called

Name: represents the operation which is called

Parameters: represent the parameters on the operation which is called

Sequence Diagrams

The two types of Interaction Diagrams are - Sequence and Collaboration. Sequence diagrams emphasize the sequence in which the things happen. On the other hand collaboration diagrams provide more flexibility in their layout. When drawing interactions you can choose between these two depending on your preference, since both show the same information.

An example of a sequence diagram for our logon collaboration is gicen as below:

Things which should be noted:

ｷ The flow of time is depicted from top to bottom, that is messages which are higher on the diagram occur before those which are lower down

ｷ The blue boxes are actually instances of the represented classes, while the vertical bars below them are the timelines

ｷ The arrows (or links) are the messageswhich are either the operation calls or return calls from operations

The hide and show messages use guards in order to determine which to call. Guards are always displayed in square braces [ ]and they represent the constraints present on the message (the message will be sent only if the constraint is satisfied)

ｷ The messages are labeled with the operation which is being called and parameters are displayed. It can be chosen whether to enter the parameters or not - this is dependent upon their importance to the collaboration which is being shown

THE SEQUENCE NUMBERS ARE NOT DEPICTED ON THE MESSAGES AS THE SEQUENCE IS INTRINSIC TO THE GIVEN DIAGRAM

Asynchronous Messages

A message can be specified as asynchronous in case the processing continues while the message is being executed. In the below given example, the asynchronous call does not block the processing for the regular call which is there right below. This is useful in case the operation which is being called is run remotely, or in another thread.

UML tutorial part 5

Collaboration Diagrams

Collaborations are more complex to follow rather than sequence diagrams, but they provide the added benefit of higher flexibility in terms of spatial layout.

Given above is a collaboration diagram for our logon interaction. You can probably notice that each of the messages is numbered in an order. This is because it is not obvious from the diagram, what the order of the messages is .

Lollipop Interfaces

Another advantage which can be given for the collaboration diagrams over the sequence diagram is that the former allows to show lollipop interfaces.

Lets say that our DatabaseAccess class implemented an interface which is called Queryable. In case the logon manager has access only to the interface, we can show that the message is being called through the interface by including a lollipop interface on the diagram. The stick of the lollipop indicates that the class DatabaseAccess realizes Queryable.


With the use of diagrams, the sequence of operation calls among objects used to complete a single use case can be clarified. While drawing these diagrams, you should try to keep them as clear and simple as possible. Sequence diagrams may be easy to read and follow, as they enforce a more standard layout on the diagram. Collaboration diagrams have the added benefit of interfaces and the freedom of layout, but they can be difficult to follow, understand and create.

It's important also not to confuse interaction diagrams with state and activity diagrams. Interaction diagrams are used in order to diagram a single use case. If you want to examine the behavior of a single instance over time then you should use a state diagram, and In case you want to have a look at the system behavior over time then you should use an activity diagram.

5. ACTIVITY AND STATE DIAGRAMS

Previously we have seen how the interaction diagrams demonstrate the behavior of several system objects while executing a single use case. When you want to display the order of events on a broader scale then you should use activity and state diagrams.

Activity Diagram

An activity can be defined as the execution of a task whether it be a physical activity or the simple execution of code. Simply put, the activity diagram depicts the sequence of activities. Like any simple flow chart, activity diagrams have the support for conditional behavior, but also have added support for parallel execution as well.

Start: each activity diagram has only one start (symbol above) at which the sequence of the actions begins.

End: each activity diagram has only one finish at which the sequence of actions ends

Activity: activities are to be connected together by transitions. Transitions are actually directed arrows which are flowing from the previous activity to the next activity. They can be optionally accompanied by a textual label of the form:

[guard] label

The guard is considered to be a conditional expression which when true indicates that the transition has taken place. The label is optional and is represented in free form.

To show conditional behavior you can use a branch and a merge. The top diamond is a branch and can have only one transition flowing into it but any number of mutually exclusive transitions flowing out. So, the guards on the outgoing transitions must resolve themselves in order that only one is followed. The merge is used to finish the conditional behavior. There can be any number of incoming transitions, and only one outgoing transition.

To show the parallel behavior you can use a fork and a join. The fork(placed at top) has only one transition entering and any number of transitions which are exiting, all of which will be taken in action. The join(placed at the bottom) represents the end of the parallel behavior and has any number of transitions entering while there is only one leaving.

State Diagram

The state diagram depicts the change of an object through a time period. Based up on the events that occur, the state diagram displays how the object can change from start to finish.

States can be represented as a rounded rectangle with the name of the state displayed as shown above. You can optionally include an activity which represents a longer running task during that state.

Transitions connect these states together. These represent the events which cause the object to change from one state to another. The guard clause of the label is mutually exclusive and must either be true or false. Actions represent the tasks which run so as to cause the transitions.

Actions are varied from activities in the way that their actions cannot be interrupted, while an activity can be interrupted by the incoming event. Both can actually display an operation on the object which is being studied. For example, an operation which sets an attribute would be considered an action, while a long calculation might be considered as an activity. The specific separation between the two depends actually on the object and the system which is being studied.

Like the activity diagrams, state diagrams have only one start and one end from which the state transitions can start and end respectively.


Activity diagrams are used to depict the work flow in parallel and also conditionally. They are useful while working out the order and the concurrency of a sequential algorithm and that too while analyzing the steps which are there in a business process and while working with threads.

State diagrams display the change of an object over time and are useful when an object exhibits interesting or unusual behavior - such as that of a user interface component.

As always, these diagrams should be used only so as to serve a purpose. You should not feel that a state diagram should be drawn for every system object and an activity diagram for every system process. You should use them only here they add value to your design. You may choose not to include these diagrams in your system design, and your work may well be considered to be complete and useful. The purpose of Visual Case Tool and of these diagrams is to help you to do your job. So if the diagram becomes too complicated and confusing, you and those working with you may lose focus of the task at hand.

6. Implementation Diagrams - Component and Deployment

So far, we've seen how the tasks which the system will perform can be diagrammed along with the details of the system classes, and the system dynamic behavior. But what about the big picture? There are two types of implementation diagrams which strive to provide the solution. With the deployment diagram, you can depict how the system components are physically related, and with the component diagram, you can display the components in the system which are organized.

You can combine the two diagrams if you wish:

Above, the nodes are given in green and the components in maroon. The nodes represent something upon which a component can run, and components are units of software.

On the diagram, nodes are connected with connections which displays the physical path of information with in the system. Components are connected with directed dashed lines which represent the communication between components. You can also use lollipop interfaces on components to depict which of the communication is actually through an interface.


The physical diagrams will help with the overall structure and distribution of the system. The component and deployment diagrams can be drawn separately or combined as you choose to do. Also, the components within the nodes need not be displayed as given above, although it will help in the overall understanding of what is being executed where.

Visual Case Tool - UML Tutorial

7. Summary & Further Reading

Now that you have the basics of each kind of UML diagrams, you're ready to begin. You can now Download the trial version of the Visual Case Tool and try some of the simple designs.

You should but remember what each UML diagram is and what each is used for:

Use Case diagrams help to specify the user goals that the system has to carry out.

Class diagrams depict the physical structure of the system objects and their static relationships.

Sequence and collaboration diagrams give the dynamic interactions between instances which are used to carry out a single use case.

State charts diagram depict an instance over time and the events that cause it to change.

Activity diagrams are good for giving details on high level processes that require conditional and parallel processing.

Physical diagrams give you an overview of the structure, distribution and implementation of your system.


You should not be overwhelmed with the semantics and detail. UML is a very rich and detailed language and you should remember that there is no need to master each and every bit of information at first. You should first strive to get comfortable with the basics.

Also, you should keep your diagrams very simple. Each of the UML diagram should have only one key concept or design feature which you're striving to explain. Further, that key concept or feature should be interesting enough. You don't need to design the very obvious features as you should not be redundant. You should express what needs to be expressed and move forward.

Finally, all of the diagrams in this tutorial have been created with Visual Case, so you should Download the trial and get started with your own system designs.

In order to get Further Information!!

You can browse the web for various resources such as message forums, other tutorials and more examples.

A good and very accessible book which should get you started is: UML Distilled Second Edition - A Brief Guide to the Standard Object Modeling Language

Author: Martin Fowler with Kendall Scott. Published: 2000 Addison-Wesley (http://www.visualcase.com/)

Requirements Gathering

Most of the projects run under a very tight deadline and successful completion within the specified time at the specified cost is required. To achieve this the system that is being built has to be built right the first time! It is often the inconsistency between requirements expected from client side and the one that is being understood by the system developing organization that causes projects to fail or extend. For this inconsistency to go away, there is only one solution- a perfect requirements gathering phase to kick start the project on the right note.

Requirements gathering in the normal terms, just stands accumulation of the customer’s requirements. But it is not as simple as it sounds, for the customer always knows what he wants but never expresses it as clearly as it should be. It is your responsibility as the Analyst to get into the customer’s shoes and see it from his perspective. Be it a very expressive client or one who just has fair idea as to what he wants- you should get a clear, complete, accurate requirement set from him. This should be perfectly giving you all the activity and event descriptions for the system design to proceed smoothly later.

The techniques:

The interviewing of the client, interaction with various users of the system, analysis of the present scenario- all of these are really essential skills for an analyst. The perspective in the form of representations required for clear idea has to run through his mind when he gets details from the customer. The requirements gathering is not just over with single talk with the customer. You can just improve and successively add up to the level of clarity by having your vacant spaces of activities and objectives clarified and filled with customer’s views on the scenarios. This will most often help you get the comprehensive requirement list.

The representation:

The depiction of the requirements into the Usecase models and UML diagrams are vital to have the concise account of the requirements. These diagrams can give lot more information than a 10 page document with all requirements in it. The underlying thing though, is that you have to what customer requires! The various requirements gathering tools available out there can make this transformation from text to pictorial representations easy and manageable. These can be the guide that can help everyone involved in the development throughout the life cycle.

Once every requirement is gotten and represented in the perfect manner, it is time to get the requirements prioritized and act on those accordingly during the design and developmental stages of the system. Requirements gathering can be very much efficient if there are presentations and discussions with the client showcasing the understanding from the Analyst’s side. This will make sure that both are on the right track. Prototyping is also seen as an effective way of storing the requirements information. But the tool and the manner of requirement representations mostly are tailored according to the system development methodology that is going to be pursued. Nevertheless

the underlying fact is the requirements have to be garnered and taken care off well for the entire project to be successful and in accordance with the customer’s expectations

Tools Required for a Business Analyst

The modeling of a business and strategic planning of the entire project gains much of the attention in huge projects. When it comes to an organization with widespread reach into technologies and various requirement sets it is often the job done by the Business Analyst that makes handling of the project simple and maintenance of project easy through time. Since the job of the Business Analysts involve lot of actions over data in terms of the inferences, versions, tracking and communication with a lot of other people, there has to be some way to make the process more intuitive and easily organizable. This is where the software tools come in. They are in essence the window for the B.As to observe the entire situation. Here we will be seeing some of the most useful software tools and suites that can come in handy for the Business Analyst.

Microsoft Word:

There is no denying that the Word generated documents are the communicating link between the customer and Business Analyst. The requirements are always given in with adequate pictures and information in form of the Word Document. Marketing or specific SRS are managed as MS Word documents with versions and comments from either side, developing organization and the customer. So its undeniably the no.1 tool that every B.A has to have in his computer.

UML and Use Cases:

The representations of flow of access and direct representation of customer’s requirement as Use cases help the understanding of concept and logic very clearly. It is maintained as the point of reference through both development and testing stages. A great tool like Microsoft Visio can make life much simpler for the Business Analyst by giving the most comprehensive tool set for UML and Use Case representation/generation. There are also other similar tools like ConceptDraw etc. The choice is subjective to one’s convenience.

The requirements can also be managed according to specific development methodology and there are specific tools which are suitable for each methodology. There is the Requisite Pro, IRise manager and IBM’s “Rational suite” each of which have their own style of implementing the different methodologies like Rational Unified Process etc. A research on the tool set and usage analysis will be useful and may give the Business analyst the best management tool to get his requirements organized.

Presentations and other Customer Interactions:

The Microsoft PowerPoint is one software that all the Business Analyst has to use most during a project. Be it in the initial design plan elicitation or in the conclusive test phase roll out, the Business

Analyst showcases the entire picture of the product through the slides. A slide is really worth 10 pages of detailed document, as it gives a better understanding through face to face presentations. In case of the testing phase, the testing script, overall results, performance and quality assurance figures are to be well-managed and easily accessible. For this phase the Business Analyst’s knowledge in Database management can come in handy. Some QA/Traceability tools like Mercury Quality centre and Test Director can come in really useful.

There are many tools that are out there for doing each of the above specified task, but it is really the B.A’s intellect and management skills that comes out through the effective usage of the tools. These tools are just the perfect add-ons that can make the efforts of management much effective and really fruitful.

Responsibility of a Business Analyst

The Business Analyst fills the gaps between business and technology, meaning that this person has to translate the commercial language to something that developers could understand, and vice versa, to present to the business department what advantages the IT industry can bring to maximize the profits. The stages or secondary roles of this main purpose can be split like this…

Study and collect the client’s business requirements

First of all the analyst must meet the partners or managers of the client company and discuss about the business, then study all available data about it including documents, records, tutorials, schematics and any relevant stuff. This is an important step because knowing the business is vital to its success.

Redesign the business

After gathering all the necessary data the Business Analyst must prepare new graphs and business models, make learning sessions with the employees, all for the purpose of solving the company’s problems. New ideas are used for the long term development of the entire business. The client must remain with a conclusion of what is good and what is wrong in the business.

Participate in the testing

The analyst must be fully involved in any launch of the innovations suggested, this means testing the ground and verifying if the new procedures work as expected in theory.

Make a final report

In the end, a report must be made about how all things worked and if everything is as it should be according to the designs. This should tell us what has been improved in the system and what benefits has this for the firm.

As a conclusion, to define the roles of a Business Analyst in a company in one single role we could say that he is like an interface between the financial management and the technical part, providing the best connections and helping businesses to prosper in long term. The analyst job covers many domains, each one different but they all serve one purpose: wealth.

Business Analyst Job Description

"Business Analyst" is no doubt the very important and significant role in any industry because he is the one who needs to know both technological skills/knowledge & Industry specific domain knowledge/Experience.

There are many Business Analysts who gets confused about their job description in the industry. To put in simple terms the job description is to improve the business in all possible ways. But if we elaborate the Business Analyst job description, it is going to take a while to understand the actual tasks that a business analyst has to take care of.

Business Analyst has to face challenges continuously on a daily basis, i.e everyday is a challenge for them in order to compete with competitors and to meet the latest demands of customers/consumers, and to meet the technological demands according to today’s speed world.

In old days System Analysts were taken the task of administering the daily tasks such as converting the paper work into electronic documents, but then when the real IT development comes into the picture, organizations started realizing that they are not meeting the goals as they intended. That is when they thought about the Business Analysts who are aware of both Business and IT development.

The term "Business Analyst Job Description" is a bit confusing because when you search for Business Analyst jobs in job boards, you get to see so many job profiles with various requirements and with various job titles such as Business Analyst, System Analyst, Requirements Professional etc.. etc..

They all come under one hut called Business Analyst, but in some firms, System Analyst is mostly sits in the IT section and takes care of IT issues, where as Business Analyst takes care of purely business needs. But to put in brief the average profile or job description of a business analyst are below:

1) Who should know domain / business knowledge (insurance, healthcare, banking, mortgage etc..)

2) Who should know little to medium technical knowledge such as programming languages, database, system architecture etc..

3) Should know how to design and draw use case diagrams, business model diagrams, flowcharts etc..(Should be familiar with MS visio tools).

4) Should be familiar with Rational rose suite such as clear quest, clear case, etc..

5) Should be familiar with version control tools such as subversion etc..

6) Should have enough knowledge of Bug reporting tools(Quality center), QTP, SDLC,

Test methodologies..

7) Should know full life cycle of software development.

Apart from the above, the main Job Descriptions of a Business Analyst are:

A) Understanding the client requirements and putting them on paper in a language that is understandable by developers.

B) The solution that is recommended by him should be really good to be accepted by all top management.C) Act as a bridge between Business team and technical team. Some firms needs Business Management qualification with technical skills, but a computer graduate with real time industry experience will also fits the bill

Testing knowledge required for BA

What is process in testing There are few phases for testing processes.

Creating a test plan.:Test plan includes waht to test and how to test and what are the expected results/actual results after test, and sample data which we give s input for testing etc..

Recording the application:The object in test has to be navigated as desired with respect to the functional specs/ user

requirements.

Enhancing the test:We can enhance the test by adding check points like text check, data base check, image check, bitmap check, text check, text area check etc..and also by parameterizing when same screens have to be tested with different input values. and by adding some modifications to the vb scripting like if conditions and while conditions and some functions etc..

Debugging the test:Debuggin is to find out any bugs while running the scripts, if any changes made to the application, a bug will araise and we need to change the scripts by running the application again and the same bug has to be reported to particular developer to resolve it. Any comments?

Running a test in a newer version of the software/ application.:

Analyzing and reporting defects.

QTP recording flow QTPQuick Test Professional

QTP is a functional testing tool. It is very case sensitive.

It has 3 levels of recording.

1) Normal recording2) Analog recording3) Low level recording

95% of it will be done on Normal Recording.

QTP has 3 panes.

1) Test pane2) Test details pane3) Debug viewer pane

Test pane has 2 views.

a) Expert view ( Where we Record, Run, Debug & Design)b) Tree view or Keyboard view (Where we do the Splits)

Test details pane – Action screen (where we can see the screen shots and the result as “Done” or “Pass”)

Debug viewer pane – Expressions & variables

Besides that it has Data Table View or Global sheet: - Parameterization

Start up

1 Click on QTP icon on your desktop.2 When the box opens make sure; - “Active x”, “Web” & “Show on start up” is checked.3 Click “OK”.4 “Record Run Setting” window appears.5 Click on the radio button “Open the following browser when a record & run session begins”.6 Check the box “Close the browser when the test is closed”.7 Write the URL on the address box and click “OK”.8 When the page opens up click on 3 or 4 links and “Stop” recording.9 Put “Comments”. To do that click on “Insert”,- “Comment” and then write the comment as “Type www.yahoo.com “and the main page opens and click on to “Auto”. In QTP both links come up on the first script so we have to mention both the links in the first comment. So on all the links will have link with main page and they all have to have comment.Ø Then we must “Design”. To design we click on to the icon “Start transaction” and write “Yahoo-Auto” and enter and same way “End transaction”Ø Go to Keyboard view/Tree view, highlight the “Action”, right click and “Rename” and save it. Also save the “file” with the same name.

What is break point in qtp In QTP we use “Break points” to stop the script. We apply Break points only on “Start transactions” or the link [Web URL]. If we put the Break point in wrong places then when we run it, it will stop at the next right place.

To watch the screen open up to a particular sight we put “wait (10)” statements to stop the screen for 10 seconds or “wait (5)” statement to stop the screen for 5 seconds before the “Start transaction”

What is split action in qtp? Split Actions in QTP

http://www.yahoo.com/

In QTP we record it as a whole and then we split.-That is Split Action.There are two kinds of “Splits”.1) Independent to each other.2) Nested Splits. After we record, run and design we go to “Keyboard view “and click on the place to highlight. Go to “Step” and click on “Split action” to split. Once we split we cannot undo it. We must save the action before we split it. Saving is a pre-requisite to split.

There can be “Multiple split actions” and they will be independent of each other.E.g. Yahoo > Autos > New Cars > Sedans > BMW > etc.E.g. CNN > World > Law > Health > Education > Politics > etc.

Nested Split

While clicking on to sights like World, Law, and Health we can have a bunch of clicks in “Law” like Civil law, Criminal law, Child law, Immigration law and we can put all those under “Law” and that is a nest and that split is called a “Nested split”.

What is parameterization Parameterization is replacing the original value with a parameter and the value has to be in the database.

Ø Record www.Walmart.com .Ø Go to the “zip code” box and type a valid zip code.Ø Click “find”. Then “Stop”.To Parameterize:Ø Click on “Tool”Ø Click on “Data driver”Ø Click on “Parameterize”Ø Click on “Data driver wizard”Ø Click on “Step by step parameterization”Ø Click on “Next”Ø Click on “Parameter name”Ø Change the parameter [08648] by highlighting and then replacing with “zipcode”.Ø Click “OK”Ø Click “FinishØ In Data driver, - click “OK”.An Excel sheet opens up with “zipcode” on top row.Ø Fill in other valid zip codes and an invalid zip code. If the zip codes start with “0” then:Ø Highlight the cellØ Right clickØ Highlight “Format”

http://www.walmart.com/

Ø Click on “Custom No:” delete the “General” and type 5 zeros.Ø Click “OK”Ø Go to “Test”Ø Click on “Settings”Ø Click on “Run”Ø In “Test settings” choose “Run from all rows”Ø Click “OK”Then run from the top. When we run from all rows it gives us as many results as the number of zip codes. For the invalid zip code there would be no sight and it should say “Please enter a valid zip code”.If we want to watch the pages closely we can put wait statement right in front of the “Start transaction” after the comment. E.g. wait (time).

Multiple Parameterizations

Let us take the example: www.Greyhound.com> anywhere> US.Then we fill up the form with starting city, destination, time, number of adults, children, seniors etc. After we fill up the form and run. We must parameterize every single area. For example:1) Start city2) End city3) Start month4) Start day5) Start time6) Adults7) Children8) SeniorsAll the values that we choose must be in the database in the exact same way we use it to give parameter. After we do that we run it the same way. Since we parameterize multiple values it is called multiple parameterizations.

What is check point in qtp Check Points

There are 6 major Check Points:

1) Standard check point: “Standard check point” looks only inside the area.2) Text check point: “Text check point” looks into the house and around.3) Text area check point: “Text area check point” can capture a whole block at once.4) Bitmap check point: “Bitmap check point” can capture whole or part of a picture. It is only for images.

http://www.greyhound.com/

5) Data base check point: Data base check point is used to retrieve data from the database by writing SQL Queries.6) XML check point: Used only for web application developed by Java, XML etc.

Standard Check Point:To try it in active screen:Ø Click on the link e.g. www.cnn.com. When the page opens keep the screen half and half.Ø In “Expert view” go to “Insert”Ø Go to “Check point”Ø Click on “Standard checkpoint”.In there you will get a hand symbol and where ever you want to activate, “Click”. You will be clicking on the “Radio buttons”, “Check boxes”, “Dropdown Lists”, “Web Edit boxes”, “Text area boxes” as well as for the “Text” also. Standard check points look inside the boxes.Ø “Run”Ø Go to “View”, - “Active screen” to check.All the properties will be in the “Object Repository”.

Text Check Point:

Text Check point will capture the text that we click on and let us know what is before and after.Ø In “Expert view” go to “Insert”Ø Go to “Check point”Ø Click on “Text check point”Then click on the “Text” part that you want to capture.To check the properties of the check point: in “keyboard view” highlight on the “Check checkpoint”, then right click. Then click on the “Checkpoint properties” and you can see all the properties.

Text Area Check Point

With “Text area check point” we can capture the whole block of text at once.We go to “Insert”>”Check point”> “Text area check point” and the curser turns into 4 sided arrows and then you click on the part of text you choose and drag it to the part that you want to capture. When we don’t have check points we can find changes made in the “Object repository”.

Bitmap Checkpoint

We use bitmap checkpoint to capture pictures. We go to “Insert”>”Check point”> “Bitmap check point” and click on the picture that we want. We can capture whole or part of the picture. To capture part of it we have to click first on the whole picture and then click on the “Selected area”. Then we capture the part that we want.

http://www.cnn.com/

Data Base Check Point

Data base check point is to retrieve a data by writing a query with SQL/Oracle statement.Ø “Insert”>”Check point”>”Data base check point”“Data base Query Wizard” will appear.Ø Click on “Specify SQL statements manually”Ø Click on “Next”Ø Click on “Create”Ø Click on “Machine data source”Ø QT_flight32Ø “OK”You are back on wizard. Type on SQL statement: “select * from orders:”Ø Click “finish”In the wizard the order form comes up. Then highlight the one you choose and “Finish”.Ø “Data base Query Wizard” will appear.Ø Click on “Specify SQL statements manually”Ø Click on “Next”Ø Click on “Create”Ø Click on “Machine data source”Ø QT_flight32Ø “OK”In the wizard the order form will come up.Type on SQL statement: “select * from orders: where customer_name = ‘Kim Smith’;”Ø FinishYou will get the information of the customer “Kim Smith”.

Integrated testing When we put together 2 or more actions and test it together we call it Integrated Testing. In QTP we cannot integrate 2 URLs [we can do that in Win runner & Load runner]. We cannot put together actions recorded in MSN & Yahoo in QTP. Also we have to come back to the homepage just like we start with it for all the actions that we want to integrate.E.g.: Yahoo>autos>new cars>BMW>yahoo…Action 1E.g.: Yahoo>autos>used cars>Acura>yahoo…Action 2E.g.: Yahoo>autos>sell my car>Blue book>yahoo…Action 3

There are two options in Integrated Testing.1) Copy of Action.2) Call to Action.

Copy of Action:

You can edit your scripts in there.Ø Go to “Insert”Ø Click on “Copy of Action”Ø Browse [from test….]Ø Clock on “Yahoo.BMW”, highlightØ Click “open”Ø Rename it.Ø Click “OK”Ø The script is locked.Ø “Run”Ø The reusable action becomes “External action”In the “Menu” it is there. As many as you copy they will be there.

Call to Action: Pre-requisite condition to “Call to action” is to make the script reusable.To make a script as a reusable action:Ø Open the scriptØ Go to “Step”Ø Click on “Action properties”Ø Check the button “Reusable action”Ø Click “OK”Ø “Save” (make sure).Now in the drop down menu it will be there. Once you call a “Reusable Action” it becomes “External Action”. It will be in the non-editable secured mode.Ø Go to “Insert”Ø Click on “Existing Action”In Keyboard view right click on the file”Rename the action”. In integrating scripts they have to be sequential not random. First we have to have a new file.Ø Go to “Insert”Ø Click on “Call to existing Action”Ø “Browse”Ø “Select action” click on.Ø Highlight which we want to integrate and click “Open”Ø Click “OK”To get the second oneØ Go to “Insert”Ø Click on “Call to existing Action”Ø “Browse”Ø “Select action” click on.Ø Highlight which we want to integrate and click “Open”Ø Click “OK”Ø When we are done “Run”.

To check the properties:Ø Click on just before the “check point”Ø Go to “Add/Remove”If anything changes you can catch from there.

QuickTest is a graphical interface record-playback automation tool. this is able 2 work wit any web, java or windows client application. Quick Test enables U 2 test standard web objects n ActiveX controls. In addition 2 these environments, QuickTest Professional also enables U 2 test Java applets n applications n multimedia objects on Applications as well as standard Windows applications, Visual Basic 6 applications n .NET framework applications...

Loadrunner complete flow step by step Load Runner is a performance testing tool.It also does functional testing.

Load Runner has 4 components:

Ø Virtual User Generator (VUGEN)Ø ControllerØ AnalysisØ Load Generator.

1) VUGEN:VUGEN is where wea) Record, b) Run, c) Debug & d) Design.They are called Vuser scripts.

2) Controller:Controller is where we apply the load. The Controller organizes drives, manages and monitors the load test.

3) Analysis:Analysis is where we analyze the performance results.

4) Load generator/Launcher:It is the local host [which is CPU]. Load generator generates the load by running virtual users.

Load Runner has 2 views:

1) Script view2) Tree view: It has 2 vies as well:- a) Page view & b) HTML view

To start:Ø Go to ProgramsØ Load RunnerØ Virtual User GeneratorØ Click on “New file”Ø Expand E BusinessØ Select “Web(HTTP/HTML)”Ø Click “OK”Ø Highlight “Action”Ø Click “Record”Ø Type URL[www.Macy’s.com]Ø Click “OK”

Then run from the top. Result summary appears. Status =”Passed”.On the left window expand the “Iteration” to watch the screens. Then close the result window.Delete cookies and design.To design we have write “Comments” and “Start” and “End” transactions.To write comments:Ø Go to “Insert”Ø Click on “Comment” and write the commentE.g. “Type www.Macy’s.com.” and the main page of Macy’s will open.”Then click on the icon “Start transaction” and write “Macy’s” and enter. At the end of that script click on the icon “End transaction” and it will automatically have “Macy’s”, just enter. Similarly we have to do it to every link. After we are done we have to run again and save the test case with a name.

Toggle Break point

Using the Toggle Break point we can stop the script where ever we want. But it has some limitations. We can use TBP only before “web_url” & “web_ txt”. Using the Toggle Break point we can do line by line debugging. After debugging we design the script.

There are 3 kinds of errors:

1) Syntax error: [ , ; : “ ) ] etc.2) Runtime error: Spelling error.3) Compiling error:

Syntax error and Runtime error are tester’s responsibility.Compiling error is programmer’s responsibility.Toggle Break point is only for Runtime error. The TBP looks like a hand symbol. If we put TBP anywhere besides web_url or web_txt the system won’t recognize it and it will run through

http://www.macy/

without stopping. After designing we can put Toggle Break Point before “LR_start_transaction”. If we put TBP before “LR_end_transaction” it will work but it is better to stop it at start. Sometimes we are not sure about some scripts whether to delete it or not. In that case first put it under comment and run. If it works then delete it. By using TBP we can do line by line debugging. Toggle Break Point is only for runtime error.We can check the Pass/Fail log in the “Replay log”Home | BA-Interview-Questions | Jobs | Resumes | BA-Dictionary | Books | Contact | Privacy PolicyTraining & Tutorials:*Roles and Responsibilities of a Business Analyst*What is System Analyst*What is SDLC and different Phases of it?*What is usecase diagram? & its Importance.*How to draw flowchart? And its uses?*What is RUP? Explain in detail.*What is UML explain in detail?*Business Analyst Tutorials*Business Analyst Interview Questions*Testing (QA) knowledge Required for BA*Business Analyst Healthcare domain Tutorials*Business Analyst Finance Domain Tutorials*Rational Rose Tools Interview Questions*Diagrams for Business Analyst*Resumes for Business Analyst*Jobs for Business Analyst*Interviews Tips *Other-Interview-Questions BA Interview Questions*BA Interview questions set 1*BA Interview questions set 2*BA Interview questions set 3*BA Interview questions set 4*BA Interview questions set 5*Business analyst Interview questions 6 *Business analyst Interview questions 7 *Business analyst Interview questions 8 *Resume writing tips for BA 9

*General business analyst interview questions 10*Mortgage related interview questions for BA 11 Business Analyst Tutorials*Responsibilities of a Business Analyst*What is Business Analysis*Sequence diagram Explained*Class diagram explained*RUP explained*UML(unified modelling language)*SDLC(systems development life cycle)*Insurance knowledge for BA*Health care knowledge for BA*Finance banking knowledge for BA*Role of a Business Analyst(high level)*Use case diagram step by step*Class Diagrams UML*Responsibilities of BA*What is RUP ?*RUP in SDLC process*SDLC*Bug Life cycle*BA Faq*Business Users of the system*Class diagrams*CMM levels*Collaboration diagram*Data Mapping & Data modeling*Data model in data base*Deliverables in SDLC*Tools used by BA*Q-Gate (quality gate)*RUP (rational unified processing)*Sequence diagrams*Deliverables in RUP*UML (unified modeling language)*Use case diagram*Use case examples*Use case template examples*what are JAD sessions?*What is GAP analysis ?*What is User acceptance testing (UAT)?*Daily duties of a BA*What is System analyst ?*UML Tutorial Part 1*UML Tutorial Part 2*UML Tutorial Part 3*UML Tutorial Part 4

*UML Tutorial Part 5*UML Tutorial Part 6*UML Tutorial Part 7*UML Tutorial Part 8 Testing Knowledge*Testing processes*QTP recording flow*Break points in qtp*Split actions in qtp*Parameterization*checkpointsinqtp*Integrated testing*What is QTP ?*Loadrunner step by step Business Analyst Finance *Business Analyst Finance domain Interview questions set 1*What is Fixed rate Loan? *What is home equity line of credit (HELOC) ?*What is Loan to value ratio ?*What is debt to income ratio & *What is lien Lien holder ?*What are mutual funds ? Interview questions*Trading of Stocks , what are stocks?*New york Stock exchange*What is NASDAQ ?*Stock exchanges in USA*Factors that will affect the change in price of STOCKS *How to buy a STOCK ?*What stocks are treated as equity while bonds as debt ?*Some more Finance related interview questions for Business analyst*Imp finance related interview questions for BA*What is SWAP and types of swaps*What are Options & Bonds and types Bonds in finance*what are Options in finance*what is a derivative and how it functions*Who is a broker dealer*Commercial bank in brokerage industry*Who is a market maker?*who is a specialist ?*What are bond and types of bonds*Steps for writing use case diagram

*What is SOX (Sarbanes Oxley act)*CMM Capability maturity model Business Analyst Health care :*BA Health Care Claims*SAS (statistical analysis system)*Clinical Trials*What are FACETS*Health care fraud detection*What is HIPAA*Medicare Procedures and policies*Health care Interview questions for BA

aa

Interview tips for business analyst

Much as you might hate to hear this – First impression IS the best impression. The best thing to do is some research about the dress code of the company through friends or online resources. General rule of the thumb is to dress in proper formal attire. Interviewers might view the first meeting as a way you would present yourself in a client meeting. Dressing in casuals like jeans is not advisable. Your attire should be one step nicer than the rest of the group. As much as you want the job, getting tensed before the interview could worsen your chances of cracking it. The key is to relax. Maintaining your calm gives you clarity of thought and will help you in answering the questions to the point. It also brings out the true personality in you. By getting tensed, you fail to show your true personality, which might go down as a negative point.

The next thing is its not wrong not to know about something. The interviewer doesn’t expect you to know everything. So it is perfectly fine if you admit it. But the last thing one would want is a person who pretends to know everything and tries to beat around the bush. You will be caught in a web of subsequent questions, which will finally end up in you accepting the truth of not knowing the answer in the first place. This will show you in a bad light. Hence be honest about what you know and bold enough to accept the things you don’t.

Another key point during the interview is about listening which is very relevant to the position which you are there for – business analyst. Wait for the interviewer to complete his question and take some time to frame your answer. Feel free to take notes and do ask for details if the question is unclear or if the data is insufficient. It is very important to understand the question fully, because an irrelevant answer to the question would make it appear that you did not think about the problem in a logical way. It ends up marking you as a candidate poor in communication, which is one of the key factors being looked for in a business analyst role.

One of the main strengths of a business analyst is the clarity of his thoughts and talk and hence, you should have clarity in your answers. Generally the questions could be some case studies or problem situations asking you how you would go about solving it, It is a good idea to let the interviewer know about your thought process, break down the problem into parts and explaining the rationale behind your approach. Then you could address each issue one by one, answering the interviewer’s questions as you go along. Breaking down the problem and analyzing the specifics gives the interviewer the confidence that you can look at different elements of the problem in an organized way and come up with a number of different creative ideas. Also remember that it is fine to take some time to organize your thoughts before you answer the question, so that you end up presenting all the important points and don’t miss out on any. It is also very important not to give redundant answers when the interviewer asks you for additional information. This gives the interviewer a picture that you cannot look at a problem in multiple ways. Also when you ask for additional details, do let the interviewer know why you need them. It shouldn’t appear that you ask for information about your role as a business analyst which is not relevant.

FMCG Retail Industry - Company1. What is reach and what is coverage?

Reach refers to the availability of the product to the customers whenever he needs it. This targeted consumer should have access to the product, the degree to which it is made possible is referred as Reach.

Coverage refers to the overall spread and presence established by the company through the products. The products have to be distributed across all the different vendor outlets, big and small, retail or wholesale. This is vital to company’s sustainability. Maximizing coverage should be top on priority.

2. How can you increase the ticket value of your product?

We can just calculate the exact profit margins meant for the different products. We can then try to add-on the complimentary gifts or combo packages at a lower rate, thereby increasing the value and maximizing sales and ticket value of our product.

3. How can you promote and market a new product that none is aware of?

The promotions that are initially done are vital for the product sales. The TV and other media have to be used well for ad campaigns. There should also be sufficient degree of confidence established in the consumer’s mind. In order to do that, free trials periods and free demonstrative product sales should be done.

4. What do you think are the important characteristics of FMCG?

The main characteristics associated with FMCG can be given in two perspectives. One, the marketer’s or company’s perspective:

● Huge volume or production.

● Low profit margin per piece.

● Stock maintenance crucial.

● Distribution and promotions has to be done continuously.

The other is the customer’s perspective:

● Frequently used products.

● Not much of a specific brand associated or adhered to.

● Prices are low, and brands are many.

5. Can you try to sell a failed product?

Unless it is a very harmful product, say it has failed due to the various marketing factors only, we can always try to sell the product. The product sales can pick up just without much of a boom. Gradual increase in sales through the various factors in the real world market, can actually mean a very stable and steady growth later. This is what we should aim for, even if there was initial setback.

6. What is secondary and primary sales?

The primary sales refers to the sale of products from the company or manufacturer to the intermediate layer of agents. Then these agents sell these products to the consumer directly or to the other distributor outlets. This is referred to as secondary sales.

7. How can establish the product when the specific area of concern is having a Discovery based retail system?

The promotions are vital here. Contacting the retailers and other chain of markets for inclusion of the specific product in the pamphlets, with indication of introductory offers and advantages of the products in a crisp way, is important. This is make the product visible to the real world.

8. How will you get the most out of the sales layer of executives?

We can adopt many different mechanisms for performance oriented incentives. These will help the sales executives to work toward the specific goal of appreciation. Also the increase of the incentives in a cumulative order with increase in sales numbers can prove really useful for both the marketing and sales teams.

9. What does it take to lead a team when it comes to the market of FMCG?

A leader has to master the trade characteristics and should be ready to act very fast on the changing trends. When it comes to FMCG, a slight detour can plummet the sales figures. You can also establish yourself in reasonable time. As a leader the confidence that one has in such prowess of the FMCG oriented market is really important, to lead others in his team in the right direction.

Functional vs Technical RequirementsFunctional requirements VS Technical requirements

Any system that has to be built by an organization/company starts just as documents. This requirements documents are the ones that speak out the customer minds. What is expected of the system? How is it going to be used? Who is going use it? What are the things that the system should support? What new “Out-of-the-box” features are expected now/in future? Well, you have all such questions answered by the customer in these documents.

Not all requirements are going to be handled by the programmers and System Analysts alike. Not all requirements makes sense in the same way! Some requirements can just give you idea what is to be built as system- this is helpful for the programmers- Whilst, some others can give you the requirements as facts that have to be true- these may be just the ones that can alter the entire requirement and technology usages. Formally taken these are the ones that are respectively called as the Functional and Technical requirements.

Functional requirements and uses:These are the ones that say what is expected from a system. They are the ones that get transformed into the UMLs and the UseCases. What exactly is the system going to achieve. It can be stated in informal terms like “the system should get input A and give output Ax”. This is just a plain practical usage description from the customer. We can make out easily that there is no specification from customer as to how this should be done. All we are worried about in case of the functional requirements are the higher level system interaction and behaviour. They describe the system!

Technical requirements and implications:

The technical requirements are giving the information to the developers as to what the system must adhere to. They are more often just facts that have to be true about the final system. Let us say for example “the system should handle 300 calls per second for over 8 hours”. Here we just are able to see what is expectation from customer. These are just guidelines that can have implications over on the developer’s way of developing a code. These are refinements that have to be considered when designing a system technically. Some software systems can come in with technical requirement as

“program should run on the Java platform”. In such a case the system to be built is meant for java, so has to be built compatibly.

Ideally, the technical requirements should give an insight as to what is being required basically from the client. More of the technical stuff just makes the requirement a constraint over the system. Most of the technical requirements can be converted to functional requirements by very good questioning. There are also some technical requirements that are put in to have a standard or to maintain a generality of operation. In such a case, the development should take in the requirement as one on which the other functional requirements are based. For a really successful development process identification of the correlation between the functional requirements and corresponding technical requirements/constraints is really important and that can happen when they are both stated and represented well to the team.

Life Cycle of a Business Analyst

The Business Analysts are the ones who have the comprehensive picture of a project in the real world environment. They deal with the business perspective as well as the developmental perspective. The skills that they should possess thus should be really wide. The basic understanding in every aspect of the product is necessary. Th life cycle of the project in the eyes of a BA is the one that can depict the success/failure in business as well as practically technical areas of operation. Here is how the BA goes through the life cycle of a project.

1. Scoping out of the prospects:

To start with, it is the responsibility of the Business Analyst to scope out and analyse the business areas associated with the project/system that is proposed for development. This includes analysis of the market and the prospects for a particular system. Project scope should also be discussed with all others who might be involved with the development in the future. A general agreement and consent on the base principle is thus required.

2. Requirements gathering phase:

This is where skills of the BA as a perfectly interactive and “to-the-point” person comes into play. By asking the customer or client, the right questions and analyzing/figuring out what exactly is in the customer’s mind the BA is expected to get the best possible, categorized and clear-cut requirements from the customer. This is then documented properly as textual and pictorial representations. The understanding of the various methodologies can give this phase a real boost, for there can be a chance to have a hypothetical prototyped version for the “System-to-be-built”.

3. Transfer of the requirements to the team:

The team which is going to be involved in the development of the system has to get the best possible representations of the Use cases and requirements on the whole. Technical inputs from the team can

come in too. The organization of effective, all-involved meetings is the responsibility of the Business Analyst. The review of the requirements and feasibility/alternatives should be discussed very clearly and in-depth from the requirements satisfaction point of view. This phase can clear the path in the future off the unwanted clumsiness in business layers.

4. Finally arriving at the solution:

With the continuation from the previous phase, the entire team would have acquired a very good knowledge of what is being expected from the system. Now it is the Business Analyst is the one who coordinates the entire team and gathers the input from every person in the team to formalize the final solution that will be aimed for. This can require some technical analysis from the BA side too. This ensures effective interaction between the team and BA during the solution generation phase.

5. Testing/Verification/Validation:

Having the best team for development and periodically organising review meetings can do the project a lot of good. But to keep the tab on the proceedings is in the hands of the Business Analyst. He tracks the proceedings with the traceability tools & QA tools. It cannot be better for anyone to keep this check on, for the BA is the one who has the complete info on what is required of the entire system as an entity in the business/practical world of operations.

As the life cycle depicts, the BA sure has a very busy schedule to keep up with throughout the project. But rather than the quantity of work, it is more the impact of the quality of his work that would eventually show up as the outcome of the project.

Business Analyst Explained

Documents

business requirements

business needs

business policies

business companies

business analystroles

business guides

business analysis

business analyst roles