Crisis Management

Its been a while and despite a lot of requests i have missed out on updating this Blog for a while... though i hope i could do better now and continue to update this page more regularly...

SO talking of crisis management... i have certainly got a crash course if not and elaborate one on Crisis management, Though i guess the precise definition of crisis mangaement might make it sound more like a natural disaster, i honestly think working as a business analyst, one has to encounter & manage Crisis management more then once for sure, crisis could be uncalled for or even a foreseen one, where we know we are heading towards it, but there is little or no control in a BA's hand to avoid it, how ever i think an analyst is amongst the first (And i whole heartedly agree to this) to be singled out for a failed project / task, though a successful task usually goes unnoticed or should i say unappreciated... Though thinking on a larger level, the argument can be made that the whole team has to work together to make any team / project successful, how ever it is more or less in the hands of a functional person, who of course is leading the project / BA /dev teams, to make sure of the team is going awry then to steer it to the correct path. By hook or by crook, Job on hands has to be taken care of for sure...

so first, lets see how crisis management can be avoided in a project management situation -

1. Weekly goal definitions / milestone checks should provide a good indication of progess, how ever these could be deceiving too.

2. Burn down charts - A brainchild of SCRUM Methodology, sounds and looks way complicated, but is rather a simple chart which when used effectively could help you identify your most and least productive resources

3. Refactoring - No project is perfect, no coding will ever give you an output which will please every one, either the client has more expectations or the testing team is much more efficient then expected, in any case one should be prepared, I have seen in general for most projects 20-25% of the total time should be allocated to refactoring... trust me you will need it.

4. Meeting expectations - One of the most common grievance the client side / management / stakeholders seem to have is that final output of project leaves these people with a lot of questions and unmet expectations, which might or might not have been conveyed to the project team, best way to ensure this is by elaborating on the requirements to granular level, outlining each step that will be taken and if possible getting the stakeholder to sign off on the same (Even though a functional spec should take care of this, in the world i work i have seen this issue coming back to haunt us)

5. Scope creep - It is important to understand that nothing that has been planned for should be worked on unless it is of critical nature or the BA has messed it up in requirement gathering, its easier said then done, how ever working on things which haven't ever been planned and also asking the team to work on requirements that were never discussed is not only a distraction, but also affects the productivity and output of the entire team

6. learning to say NO - It sounds difficult and of course more often then not its at the cost of giving yourself a bad name, how ever saying NO to recurring change requests from the stakeholders is not just about saying NO, its more about explaining the person responsible for such changes that either this change will have to take priority over any other ongoing development or it will delay the entire process / project, its important to make sure when you say NO, the connotation should be positive. The best way to convince a stakeholder is by explaining the consequences rather then threating about the same.

7. Be prepared to put in the extra effort

8. Team involvement

9. Do not Tinker the process

10. Do not PANIC

To be a Good listener...

So we need to talk to people a lot .. that involves good communication skills.. but is good communication all about talking ?

Not its not, its also about understanding, listening and talking altogether.. if you keep on talking and be an impatient listener there is something serious that is lacking in your communication skils..

So being a good listener is an integral part of one's persona as a BA.. just like i mentioned communication is important.. If we talk about the main ingredients of one's communication skills, Askking the right questions & Being a good listener would actually be equally important.

Well not only for a BA but in general life too one needs to be a good listener,
Going by experience, i had a friend's friend visit us, he was deeply involved in a conversation with us and all of a sudden his phone rang and leave apart the fact that he did answer the call,he didnt even bother to excuse himself from the conversation or anything, simply answered the phone and kept talking loudly for atleast another 5 minutes.. Trust me there cant be anything more annoying then this..

After that i didnt even wish to start a conversation with that dude.. i wish he would read this blog some day and gain atleast some listening skills or of the least some social etiquettes...

Here is a blog which would explains a few ways to be a better litener http://tynerblain.com/blog/2006/01/27/top-five-ways-to-be-a-better-listener/

so Coming back to our specilzation, For a BA it is definatelty essantial to ask the right questions and conduct the interview to get the best possible outcome
http://tynerblain.com/blog/2006/01/15/how-to-interview-when-gathering-requirements/
The above link also by the same author is really helpful again..

BA A.K.A Waiter.... ?????

So discussing BA's roles & responsibilties with some one who has been a BA himself and is into training potential Business Analysts these days, some thing came up which was'nt totally digestable , so its related to food if you cant digest it, right..??
yeah you bet..
Yeah so as a waiter co-ordinates between the customer and cook passing on the requirement of the customer to the cook in whatever requirement gathering format (usually a pen and a pad)..similary the BA does the co-ordination effort passing on the exact information regarding the requirements of the customer to the the client and developers / coders/ testers etc..

Right.. Nothing wrong with that example..but why it made me write it in the blog was coz of my personal experience when i was going to school... . i worked in an indian restraunt in Redmond,WA for a few days.. before i realised it wasnt my cup of tea and i was made for more delicate jobs rather then 12 hour long hardships...

Ironically (??) life has almost come a full circle from a waiter to a Business Analyst... i Never thought about it alright but well... way to go perhaps...
Just that this example made me smile and recall those moments.. Yeah..

"Are you ready for the order yet"
"Would you like some thing to drink"
"Shall i get you a ToGo box? "
"Here is your cheque sir"

Right... didnt i learn all those terminology and more by heart... yeah am a diligent worker.. weather a BA or a Waiter, after all job is job and one has to keep performing and improving the skills...

A Few more Software Construction Methods..

Synchronize and Stabilize method

It is a Systems Development Life Cycle methodology in which teams work concurrently on individual application modules. They frequently synchronize their code with that of other teams, and debug or “stabilize” their code regularly throughout the development process.

This method combines the advantages of the spiral model with technology for overseeing and managing source code. This method allows many teams to work efficiently in parallel.

This approach was defined by David Yoffie of Harvard University and Michael Cusumano of MIT.

They studied how Microsoft Corp. developed Internet Explorer and Netscape Communications Corp. developed Communicator, finding common threads in the ways the two companies worked. For example, both companies did a nightly compilation (called a build) of the entire project, bringing together all the current components.

They established release dates and expended considerable effort to stabilize the code before it was released. The companies did an alpha release for internal testing; one or more beta releases for wider testing outside the company, and finally a release candidate leading to a gold master, which was released to manufacturing. At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs.

Both Microsoft and Netscape managed millions of lines of code as specifications changed and evolved over time. Design reviews and strategy sessions were frequent, and everything was documented. Both companies built contingency time into their schedules, and when release deadlines got close, both chose to scale back product features rather than let milestone dates slip

Spiral Model

This SDLC methodology that combines features of Prototyping with the Waterfall Methodology. The spiral model is often favored for large, complex projects.

Steps in the spiral model include:

• The new system requirements are defined. This usually involves interviewing a number of users representing all the end users of the system.
• A preliminary system design is created.
• An initial prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the final product’s characteristics.
• After evaluating the strengths, weaknesses and risks of the first prototype, a second prototype is developed and tested.
• If the risk is considered to be too great, the client may choose to terminate the project at this point. Risk factors to be considered include development cost overruns, operating-cost miscalculation, etc.
• Subsequent prototypes are developed until the customer is satisfied that the latest prototype represents the desired product.
• The system is constructed, based on the final prototype.
• The final system is evaluated and tested. Routine maintenance is carried out continually to prevent large-scale failures and to minimize downtime.

Prototype Model:

Yeah right.. i am sure u know what a prototype is.. better meet the client and understand what he wants and all the freakin steps which i have written over the past year but wait before begenning the whole stuff ask the developer to prepare a Proto type Model of the orignal work planned.. yeah the only missing part would be functionality and according to a senior software developer (Quote Unquote ;-) ) Not only Prototype Models helps the developer but it also reduces the chances of errors in the final product/software drastically, also despite the common belief that Prototype model might actually increase the Project / SDLC Length, Mr. Jajoo believes it will actually reduce it and make the End result better...

So actually Prototype model could be and as i have found with experience should be actually used along with any other SDLC methodology used..

Adios..

RAD methodology

James Martin, in his book first coining the term, wrote, “Rapid ApplicationDevelopment (RAD) is a development lifecycle designed to give much faster development and higher-quality results than those achieved with the traditional lifecycle. It is designed to take the maximum advantage of powerful development software that has evolved recently.

RAD method has a task list and a work breakdown structure that is designed for speed. Among the most important techiques in RAD:

Prototyping - an approach based on creating a demonstrable result as early as possible and refining that result. The refinement is based on feedback from the business, the eventual users of the system. Prototyping requires an open approach to development, it also requires an emphasis on relationship management and change management.

Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in hand.

Timeboxing - is a management technique that focuses attention on delivery above all else. Under a timebox scope can change but delivery cannot.

Thus It is a process through which the development cycle of an application is expedited. It enables quality products to be developed faster, saving valuable resources

R U P again

Right no more passing on of personal experience lets get technical for the not so technical job...

Talking about RUP , it is an iterative software development process created by the Rational Software Corporation, now bought over by IBM. The RUP is not a single concrete prescriptive process, but rather an adaptable process framework. As such, RUP describes how to develop software effectively using proven techniques. While the RUP encompasses a large number of different activities, it is also intended to be tailored, in the sense of selecting the development processes appropriate to a particular software project or development organization. The RUP is recognized as particularly applicable to larger software development teams working on large projects. The software by Rational provides tools and technology for customizing and executing the process.

Overviews of the Rational Unified Process

• The Inception phase : During the inception phase the core idea is developed into a product vision. In this phase, we review and confirm our understanding of the core business drivers. We want to understand the business case for why the project should be attempted. The inception phase establishes the product feasibility and delimits the project scope

• The Elaboration phase : During the elaboration phase the majority of the Use Cases are specified in detail and the system architecture is designed. This phase focuses on the "Do-Ability" of the project. We identify significant risks and prepare a schedule, staff and cost profile for the entire project.

• The Construction phase : During the construction phase the product is moved from the architectural baseline to a system complete enough to transition to the user community. The architectural baseline grows to become the completed system as the design is refined into code.

• The Transition phase : In the transition phase the goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. This phase is often initiated with a beta release of the application. Other activities include site preparation, manual completion, and defect identification and correction. The transition phase ends with a postmortem devoted to learning and recording lessons for future cycles.

Examination or Milestones:

In RUP there are four major milestones or Examination that correspond to the four phases(Above). If the milestone criteria are not met, the project can be stopped or run in a new iteration to revisit the bottlenecks. Milestones are connected to a Deliverable. This meta-model of a milestone emphasizes the links between phases, iterations and milestone completion/ Examination


Iterations :

To understand even a bit of RUP it is important to know about Iterations.
Basic Defination : An iterative method attempts to solve a problem (for example an equation or system of equations) by finding successive approximations to the solution starting from an initial guess
Accorsing to WiKipedia a typical project using the RUP will go through several iterations. Dividing the project into iterations has advantages, such as risk mitigation, but it also needs more guidance and effort than the traditional sequential approach.
The RUP defines a Project Management Discipline that guides the project manager through iteration management. Using iterations, a project will have one overall phase plan, but multiple iteration plans. Involvement from stakeholders is often encouraged at each milestone. In this manner, milestones serve as a means to obtain stakeholder buy in while providing a constant measure against requirements and organizational readiness for the pending launch.

R U P & A C R O N Y M S

isnt it RUP ? yeah right it is.. how ever a few days back speaking to a Product Manager (and yeah am not gonna quote him) he got offended on use of acroynms like RUP / SAP /RAD and so on not being said as three diffrent words like R -- U -- P & S -- A-- P but just like RUP ,SAP & so on.. so in defrence to him and obviously trying to be more intelligent after that conversation i'll surely avoid using Acronyms from now on ..

Some lesson Huh.. ;0)

Adios

P.S. : Had a long day so never mind the RUP things.. will talk about it next time for sure...

Software Construction Methods

yeah now lets get back to business and talk stuff related to job and BA's rather then discussing things a BA should know or shouldnt.. i am sure anything mentioned here wont harm a BA. I know that even if a BA doesn's even know all these stuff he can survive.. yeah he can survive in IT industry alright/... but well never mind.. lets talk about software construction methods :

To mention a Few related to and important for BA's :

• Waterfall Method
• Rational Unified Process (RUP)
• RAD methodology
• Synchronize & Stabilize Methodology
• Prototype Model

Waterfall Method :
Here development is seen as flowing steadily downwards (like a waterfall) through the various phases of (SDLC) requirements analysis, design, implementation, testing (validation), integration, and maintenance. The term was introduced in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software development. Royce originally proposed what is now known as the waterfall model as an example of a system that he argued "is risky and invites failure"

The following phases are followed PERFECTLY in order in waterfall method:

1. Requirements specification

2. Design

3. Construction (aka: implementation or coding)

4. Integration

5. Testing and debugging (aka: verification)

6. Installation

7. Maintenance

Anyhow this method has recieved severe crticism, just follow a couple of links to know how much people love (?) Waterfall... (seems this waterfall has made a lot of people wet ;-) )

http://jeffsutherland.com/scrum/2004/10/waterfall-method-colossal-blunder.html
http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

Do read them.. even if one loves it or hates it.. one should surely know what are the aspects that could be be crticised or appreciated... what say..

enough blogging for the day.. or night? yeah pretty late.. lets call it a night

Its NOT just about COMMUNICATION

welll software construction methods, Development, analysis & design, testing.. and why the heck is a BA supposed to know all that..

so for all those who wonder a BA has to be a non technical person here comes the eye opener, a BA has to know all about the Software construction, development, design, testing.. ie all stages of the SDLC.. so its not just about the communication and requirement gathering.. i have found many people think that a guy with excelent communication skills can handle the BA job with perfection but the point is not that, good communication skills are important for sure but deep knowldege about the SDLC, about development team & their capabilities (shortcomings too) software construction methods and all other aspects of client needs..

so i concur that Communication is a very important part but having a hold over othe stuff mentioned is also very important as it would only help a BA through out the project...

P.S: ANYWAYS I HAVE NEVER MET OR SEEN A BA WITH POOR COMMUNICATION SKILSS, SO IF YOU ARE NOT CONFIDENT ENOUGH ABOUT YOUR COMMUNICATION SKILSS................... BETTER TRY ANOTHER JOB :-(

JAD Session

So another important aspect of a BA's life is JAD session.. though it is pretty important i have to say its not really some thing a BA has to deal with every day.. probably coz its an exhaustive exercise and people have to fly over from all over the country.. so it does become expensive an proposition..

So wondering what the heck am i talking about... ok lets begin with some general explainations about JAD, to begin with a rather funny one i found on Expert knowldegeBase

JAD stands for Joint Application Development. It's one of those software engineering techniques that some folks with lots of time on their hands sat around and dreamed up. All the design methodologies like this are complicated replacements for a huge dollop of common sense. Sit down with the client and design a paper UI that they can see what the application will look like and behave like. Give the user a chance to work through common scenarios and see if the application will work for them. Keep refining until the user feels the application is doing what they want it to do. As you get functionality implemented, bring the user in and have them work through those scenarios and see if it still works.

On a more serious note, According to Wiki "JAD is a popular Fact-finding technique that brings users into the development process as active participants"

A Typical JAD session agenda:

Project leader: 1) Introduce all JAD team members 2) Discuss ground rules, goals, and objectives for the JAD sessions 3) Explain methods of documentation and use of CASE tools, if any

Top management : Explain the reason for the project and express top management authorization and support.

Project Leader: 1) Provide overview of the current system and proposed project scope and constraints 2) Present outline of specific topics and issues to be investigated.

Open discussion session, moderated by project leader: 1) Review the main business processes, tasks, user roles, input, and output 2) Identify specific areas of agreement or disagreement 3) Break team into smaller groups to study specific issues and assign group leaders.

JAD team members working in smaller group sessions, supported by IT staff: 1) Discuss and document all system requirements 2) Develop models and prototypes.

Group leaders: 1) Report on results and assigned tasks and topics 2) Present issues that should be addressed by the overall JAD team

Open discussion session, moderated project leader: 1) Review reports from small group sessions 2) Reach consensus on main issues 3) Document all topics

Project leader: 1) Present overall recap of JAD session 2) Prepare report that will be sent to JAD team members

Typical JAD's :

• Business Process Modeling JAD
• Business Rules Definition JAD
• Business Data Modeling JAD
• Requirements Gathering JAD
• Quick Fix Design JAD
• Test Planning JAD

To sum it up :

Joint Application Development (JAD) enables a group of people to grasp complex issues quickly and make informed decisions.

The core component of JAD is a structured, facilitated workshop that focuses on creating specified deliverables based on the group's input.

It is an effective tool for planning a project, designing a solution, defining requirements, or any other process that requires consensus-based decision making across functional areas.

Source / Credits :Wiki, Requirementsolution.com, expertanswercenter.com, Brainstorming-that too alone ;-)

Requirements...

Requirement gathering A.K.A. Requirement Analysis

Requirements analysis, in systems engineering and software engineering, encompasses all of the tasks that go into the instigation, scoping and definition of a new or altered system. Requirements analysis is an important part of the system design process; whereby requirements engineers, business analysts, along with systems engineers or software developers, identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.

In short Identifying the needs for a new project i.e. the main job of a BA or the most vital part of the whole deal is to gather the RIGHT requirements, thus it should be done with utmost care and precision. If there is a mistake in this process the end product may also end up screwed .. (aint that obvious..)

Different Types of requirements :

• Feasiblitly
• Schedulable
• Affordable
• Legality
• Ethical issues

Requirement Gathering Techniques:

Interviews- Involves interviewing stakeholders and all the people involved, it may result in interviewing a lot of people but will help gather sound requirements and understand customer needs.

Requirement workshops - To bring the main stakeholders in the system together in order to analyse the system and develop the solution. These workshops are more properly termed Joint Requirements Development (JRD) sessions, where requirements are jointly identified and defined by stakeholders

Contract-style requirement lists - One way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of page, but it will provide a general checklist of requirements

Software Requirements Specification - A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software

Prototypes A.K.A. Mock up's
Prototypes are mock ups of the screens of an application which allow users to visualize the application that isn't yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built

Brainstorming - This involves identifying as many ideas as possible and ranking the ideas into those considered most useful by the group

Use Cases - This is a picture of actions a system performs, depicting the actors. It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques

Role of BA in the system development life cycle

Role of BA in the system development life cycle

The BA plays a central role in the system development life cycle (SDLC). In general terms, the SDLC contains well-defined phases which are executed by the project team:

• A business idea or request,
• Feasibility (business case)
• Planning (business requirements, functional requirements)
• Delivery (Coding, execution of activities)
• Testing (test cases, unit testing, integration testing, user acceptance testing)
• Implementation (roll out of the idea or request)
• Close out (documentation, post implementation review)

This is also known as project methodology. A version of the SDLC is part of many different Project Methodologies such as RAD, SDM, Rational Unified Process.

The BA will provide different services during the SDLC:

• Assisting with the Business case
• High level feasibility
• Gathering of the requirements
• Designing and/or reviewing test cases
• Processing change requests
• Tracing the requirements during implementation (traceability matrix).
• Manage scope
• Acceptance, Installation, deployment

SDLC

System Development Life Cycle (SDLC)

It is used by a systems analyst/ Business Analyst to develop an information system, including requirements, validation, training, and user ownership through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. An SDLC should result in a high quality system that meets or exceeds customer expectations, within time and cost estimates, works effectively and efficiently in the current and planned information technology infrastructure, and is cheap to maintain and cost-effective to enhance.
SDLC is a systems approach to problem solving and is made up of several phases, each comprised of multiple steps,Namely:
(Also Known as-Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method)

• Requirement Gathering : The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel
• Analysis and Design : New system requirements are defined, proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues
• Implementation and Testing: Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
• Deployment: he system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once
  
• Maintainence: Exhaustive evaluation. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

Credits: Wikipedia, Computerworld.com,techtarget.com & Ofcourse myself ;-)

Role of Business Analyst

Role of a Business Analyst

Lets discuss the Role of B.A. in an IT enviornment... so according to WiKipedia :

The role of BA is to apply analytical skills to business requests (which are often high-level or lacking in detail) and communicate these business wants/needs in a clear and unambiguous manner. A key part of this is ensuring these requests or requirements are consistent and not in contradiction with each other. The emphasis in the role is to understand the requirements from the business perspective and translate them into a form that can be understood and acted on by a service provider. This often takes the form of ability statements, smaller sub-requirements, functions, tasks, etc. These can be used by a project manager in a WBS(Work Breakdown Structure). The analysis may consist of several areas such as business/subject knowledge, IT capabilities, feasibilities, costs, relevance, data, and dependencies across other business or project areas.

Other popular definations and roles of BA:

A key role of the business analyst is the identification and reconciliation of the practical and ‘people’ problems that can delay the best planned of projects. The move towards balancing the ‘hard’ and ‘soft’ skills in delivering business change initiatives is becoming increasingly important as organisations strive towards world class standards in change project delivery.

Stress management (negative) and personal growth (positive) are now on the corporate agenda. Business analysis can have a key role in delivering change initiatives that are positive in approach and enhance individual expertise

According to Boston Uni :

The role of the business analyst is to identify business needs and communicate them to software developers. As such, the analyst is a liaison between key business decision makers and programmers.

A business analyst who works effectively, providing software developers with complete and correct requirements, can create a competitive advantage by helping programmers develop software that is ideally suited to the organization. As a result, the analyst can have a significant impact on development costs and help the business minimize project delays.

So the bottom line comes up that a BA basically passes on the functional and non functional requirements to the IT developers who can betetr understand what is required out of them and hence produce an end product which will be what the customer is actually looking for.

What Next...

So we know a lot of stuff what a BA does... and actually stuff he needs to carry on his job and all that.. but is it easily understood for some one naive towards all those jargons?? to be honest a couple of years back i would have been baffled if some one asked me what RUP was or JAD session.. or WBS / Use Case / UML... all that was something i hadnt heard.. but then i did.. and i learned.. and boy dont i like it now...

Any How lets discuss all the stuff i mentioned a BA does point by point and am sure i'll be helping some folks who might wana have a brief tutorial for Business Analyst...

Lets begin with the Role of Business Analyst...

BA--- What does a Business Analyst does...2

So how to do all the above... and what all we are gonna be discussing in detail to get into a BA's pants... some stuff...

• Software Construction Methods
• Waterfall Method
• Rational Unified Process (RUP)
• RAD methodology
• Synchronize & Stabilize Methodology
• Prototype Model

· Distinction between Waterfall & RUP

· Understanding Use Cases

· Creating Use cases

· Creating Use Case Narratives

· Creating Functional Requirement Document

• UML Methodology
• Use Case Diagrams
• Activity and Sequence Diagrams
• Collaboration Diagrams
• State Chart Diagrams
• Class and Component Diagrams
• Object Diagrams
• Deployment Diagrams

· Artifacts Delivered at Each Phase of RUP

· Change Management & Version Control Using Rational Clear Case

· Build Management

• Requirement Gathering Tools
• Rational Requisite Pro
• Caliber RM
• DOORS

· Business Modeling, Requirement Analysis & Designing Tools

• Rational Rose
• MS Visio

· QA Methodology

• Role of BA in Testing
• Creating Test Cases
• Creating Test Scripts
• Creating Test Plans

• Different Testing Methods
• Functional and Regression testing
• White Box and Black Box Testing
• Positive and Negative Testing
• GUI and Unit Testing
• User Acceptance Testing

· Testing Tools :

(1)Win Runner

(2) Load Runner

(3) Test Director

BA--- What does a Business Analyst does...

So.. what are the job functions.. roles.. responsibilites.. tools.. basically what the heck a BA does..
Lets try and figure out the broader aspects of a BA's routine life...

Role of a Business Analyst

• Structure of Development Team
• System Development Life Cycle (SDLC)
• Requirement Gathering
• Analysis and Design
• Implementation and Testing
• Deployment
• Requirement gathering.
• Different Types of Requirements.
• Requirement Gathering Techniques
• Role In SDLC
• Understanding of various Software construction Methods
  
• Typical Deliverables :
• Business Requirements
  
• Functional Requirement
• Non-Functional Requirements
• Report Specifications
• Tracebility Matrix

So this is what a BA does... but how does he do all these things and what the heck do they mean???

Business Analyst

BA.. isnt that a word we hear pretty often now a days..

anyways lets make this blog more into stuff what a BA does and how...

ok lemme first clear.. its an IT-BA...

about me.. i just finished my MBA and am working as a BA... doesn't that sound the same,... lol.. have been a BA now for a while.. and now just wanted to put some thing of relevance on this blog...