Академический Документы
Профессиональный Документы
Культура Документы
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.
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 Analyst
System 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 analysts 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 customers 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 customers terms into a programmers 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 analysts 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 customers perspective. He can really give the entire team the comfort levels by making a good sturdy base for operations.
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 systems 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 systems 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.
The technical definition of a USE CASE is that it is a description of a systems 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 systems 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 projects System Development Life Cycle, use cases help to understand the systems functionality.
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 wouldnt 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.
Connector in a flowchart.
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:
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 clients 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.
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 systems 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.
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.
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 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.
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.
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.
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 actors 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 Customers 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 customers 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..
Component diagram:
Every system will be made considering the physical world. Thats 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
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.
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.
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.
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.
Configuration, implementation and deploying the developed software in various cross platforms to see the products efficiency.
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
Business requirements are simply states what system wants to be in the future. Benefits of the new system etc.
Business requirement 1 Requirement id Description Rationale Source Acceptance criteria Global / local Priority Change history Requirement type Use case #
Document intro: The purpose of this test case is to document the relevant details of collection of data detailing what occurred during testing. Case Pass/fail Case description Date executed Test date comments Expected result Actual result
SSB/r1
Create a dail reports Bundle type enter necessary Fields. Save and run bundle.
There should be no prior day label and 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 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.
The above statement retrieves all customers from CUST table who belong to department 10.
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.
Software development methodologies. Business modeling tools Requirements management tools Automation tools Visual modeling tools Testing tools Change management tools Reporting tools
Rational unified process (RUP), UML, SEI-CMM Rational rose, MS visio, MS Project. Rational requisite pro Rational robot, test manager, Win runner, Load runner. Rational rose, MS visio, Snag IT Win runner, QTP Rational clear quest Crystal reports, SODA.
Rational Tools
RUP E-coach Rational rose Rational requisite pro Rational clear case Rational clear quest Rational test director Process and templates Modelling Requirement gathering Configuration management Change management testing
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.
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 tecto 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.
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.
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
Construction: System code, QA testing cases, / test scripts, and a test plan. Transition: Product delivery, Project documentation.
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.
Component diagram:
Every system will be made considering the physical world. Thats 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
Objective:
Scope:
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.
Failure scenario:
1. Submitted data is not complete. Solution: Accounts dept requests for missing data and claimant submits the same. 2. Claimant doest 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.
Actor Action
System Response
Step 1: The customer inserts Step 2: The system will the card. check the validity of the card and will prompt for PIN no. Step 3: The customer will enter the PIN. 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. Alternate cources Step10: Card is ejected. 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. The use case concludes when the card is taken out of the slot. 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.
1 2
Final phase in a software development process in which the software is given to the intended audience to be tested for functionality. 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. 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. UAT also is called beta testing, end-user testing or application testing
3 4
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.
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. Its 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!
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 website 2. The search button is clicked by the customer. 3. Search is completed 4. Search results are displayed
Alternative Flow: Search Fails If 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.
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 ehT :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 aa annt ttnT aa tT aTn ny tT ntTanT aa aa attae ya annt ttnTa aa a at aeT b nh aetatT tta Ta : [ ]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 1 1..* 1..2, 10..* zero one one or many 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.
The above given example displays an aggregation association and a composition association. composition is depicted by a solid diamond. The ProductGroup composed Productseh a a ntta . aTaaa nhan a aaT aProductGroup 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. Putting it all Together 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: dy ya a y a at aeT 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.
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
sTetTa T e a taaa
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
ehT attyba nyt a aw atT nhTmessagesbh h atT T nhTt nhT ytTtan ya a a yt tTntta a a atya ytTtan yaa
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
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.
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. Putting it all Together 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. Putting it all Together 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. Putting it all Together 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 customers 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 customers 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 customers 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 Analysts 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 customers expectations
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 Analysts 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.As 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.
Study and collect the clients 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 companys 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.
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
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.
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.
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
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 city 2) End city 3) Start month 4) Start day 5) Start time 6) Adults 7) Children 8) Seniors All 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.
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 dont 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.
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; Finish You 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>yahooAction 1 E.g.: Yahoo>autos>used cars>Acura>yahooAction 2 E.g.: Yahoo>autos>sell my car>Blue book>yahooAction 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 fileRename 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...
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.Macys.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 comment E.g. Type www.Macys.com. and the main page of Macys will open. Then click on the icon Start transaction and write Macys and enter. At the end of that script click on the icon End transaction and it will automatically have Macys, 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 testers responsibility. Compiling error is programmers 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 wont recognize it and it will run through
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 Policy Training & 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
*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
*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
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 interviewers 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 dont 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 shouldnt appear that you ask for information about your role as a business analyst which is not relevant.
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 consumers 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 marketers or companys 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 customers 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.
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.
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.