Use Case Diagram

A Use Case Diagram (UCD) is used to describe the functionality of a system or describe a set of actions that some system can perform with one or more external users of the system. That is, rather than representing the details of individual features of your system, UCDs depicts pictorially all the available functionality. Each action provides some observable and valuable result to the actors of the system.

However the UCDs cannot replace sequence diagrams or flow charts because they are fundamentally different. UCD cannot be used

-          When you wish to represent a sequence of steps needed to complete a task or when a error occurs. Use Sequence diagrams.

-          When flow should be depicted in a linear time based way. Use Flow charts.

Use case diagrams are used to specify:

-          External requirements on a subject, required usages of a system - to capture what a system under construction is supposed to do;

-          the functionality offered by a subject – what system can do;

-          Requirements the specified subject poses on its environment - by defining how environment should interact with the subject so that it will be able to perform its services.

UCDs have only 4 major elements

1. The actor - specifies a role played by an external entity that interacts with the system, a human user of the designed system. All actors must have names according to the assumed role. Customer, Student, Passenger etc are sample actor names


2. The system – Describe a system/subject that does some business process. Examples of systems:  Web Site, Payment System etc


3. The use cases - Specifies behavior of a system by describing a set of sequences of actions performed by the system to yield an observable result of some value to actors of the system. Examples of use case names are Place Order, Update Subscription, Transfer Funds etc


4. The lines - Represent relationships between different elements of UCD.

Pictorial representation of Major elements of the use case diagram is:

Image Credit : Google

Once you have studied the main components of UCD, now it is time to build one UCD. The initial step is to identify all of the high-level behavior of the system you wish to depict through the UCD. Once you have described details in a high-level way you should get an idea of how to draw UCD. At every stage of development, the UCD will depict a complete description of the system's functionality. It may lack some detail, but it should cover most features of system. And if functionality or behavior is added or deleted over the life of your project, the scope of the change you need to make is proportional to both the scope of the change in the system itself, and the maturity of your model. You can continue to add detail by decomposing your use cases into more use cases which are used by the top-level use cases. Below is how a sample Use Case and Flow Chart will look for driving a car.

Image Credit : Google

Image Credit : Google

To Conclude UCD are best diagrams when you wish to depicts behavior of the system or structural relationships.





Reference

http://www.uml-diagrams.org/use-case-diagrams.html

http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html

SIPOC stands for suppliers, inputs, process, outputs, and customers

A SIPOC (sometimes COPIS) is a tool or template that summarizes the inputs and outputs of one or more processes in a tablular form. In other words it can be used to define a process before we begin to measure or improve it. The acronym SIPOC stands for suppliers, inputs, process, outputs, and customers which form the columns of the table.

This tool is used whenever some process management or improvement activity is planned because this tool helpsto get a high level understanding of the proces scope.  Mostly Kaizen events or "define" phase of the DMAIC process use SIPOC tool to define and understand the boundaries of process being worked on.

SIPOC use can be categorized base on the audience:

• To give high level overview for people unfamiliar with a process or act as a ready reckoner for refreshing the overview of system.


• To help define a brand new process

Before creating a SIPOC process, do the following:

1. Finalize the name of the process. Use a Verb + Noun format (e.g. Recruit Staff).


2. Identify the Outputs of the process. These are the tangible things that the process produces (e.g. a report, or letter).


3. Identify the Customers of the process. These are the people who receive the Outputs. Every Output should have a Customer.


4. Define the Inputs to the process. These are the things that trigger the process. They will often be tangible (e.g. a customer request)


5. Define the Suppliers to the process. These are the people who supply the inputs. Every input should have a Supplier. In some “end-to-end” processes, the supplier and the customer may be the same person.


6. Define the sub-processes that make up the process. These are the activities that are carried out to convert the inputs into outputs. They will form the basis of a process map.

Image Credit : Google

Some examples of SIPOCmodel are

Onsite – Offshore Coordination: The client (Supplier) sends the specification document. The documents are received by the onsite coordinator which serves as the input (Input). The inputs may be in the form of PPT, Un-standardized Flows, Process Narratives, etc. If any clarification is required to understand the business for drafting the flows, then a brain storming session is arranged with the coordinator to get the doubts clarified. Once the doubts are clarified then the business flows are drafted according to the methodology agreed by the team (Process). Then the finalized Business process flows are reviewed and sent to the Onsite coordinator (Output). The final report is sent to the Clients (Customer).

Account Activation in a Bank: Suppliers involved in account activation are Customers, New account activation system. So the suppliers send input information to the Customer Service Representative. The customer service representative gathers the Inputs in the form of Customer Account Number, Customer Identity details and Customer Relationship Type (Joint, Merchant, and Third Party etc), etc. So with the gathered information various processes are performed which form the core of account activation. After the processing is complete the Outputs in the form of Customer Notification, Card Activation status, Sales eligibility details, Account Activation status are sent to the Customers.

A SIPOC example in tabular form is

Process : Car Dealer Example
Suppliers	Inputs	Process	Output	Customers
Manufacture Gas Supplier Cars Fuels for Car Car Cleaners Meet Client Map their requirements to the car Present Options Identify Financing Options New Client Legal Contract				1.Car buyer2.Car Renter

Above is a simplified example of a SIPOC. In practice, you may need to include several other suppliers (e.g. Shops to supply spare parts, Credit Rating Agency to assess old cars) and other customers (Company, Government Departments).

Test Case Development

Today’s organizations rely heavily on information technology (IT) systems and are exposed to every kind of information flooding into the business world. Besides, there are reports of faulty systems and their associated problems, resulting in inconvenience, misinformation, loss of information etc. Like any other service or commodity used by us, the importance of quality is beyond question and software quality is no exception and needs to be addressed seriously. Software failures can be dangerous, costly and sometimes even result in loss of lives. Therefore, software development should always be accompanied by comprehensive & thorough testing to detect software failures and prevent faults from flowing through the final production system. In order to do an effective testing, an effective test case lays a very good foundation

Image Credit : Google

A test case is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test result. A test case is usually a single step, or occasionally a sequence of steps, to test the correct behavior/functionalities, features of an application. An expected result or expected outcome is usually given.

A test case is developed at a minimum for each business case from a functional viewpoint. There may be one or more uses cases per requirement.  There may be a need to write test cases for non-functional requirements. In effect one requirement may have many test cases, which map to it. A top down approach will be used in the development of test cases.

Additional information that may be included in while creating a test case document are:

• Test Case Identifier


• Test Case Name


• Priority


• Creator


• Date of creation


• Mapping to Requirement Number


• Test Type (Regression / BVT/ Deployment / Installation etc)


• Automation Flag


• Test Script ID


• Overview, Scope and Objective of Test Case


• Pre-requisites


• Test Case Steps


• Input Specifications


• Expected Result and Actual Result.


• Pass/fail


• Remarks

These steps can be stored in a word document, excel spreadsheet, database or tools such as Quality Center etc. A Important and commonly missed test cases are the conditions of negative testing. This is to determine that end users, cannot compromise applications and data that are created and handled by the applications. Functionality testing is designed to ensure that  applications do what they are supposed  to  do,  whereas  the  purpose  of  negative  testing  is  to  check  that applications do not do what they are not supposed to do.

To conclude, a test Case documents the functionality to be tested. The most time consuming part in the test case is creating the test data to test the case and modifying the cases when the system changes. Once the tests are done by testers, end-users or clients of the system test their own test case to ensure the developed system meets the requirements specified in the contract. The testers understanding of the system/business and proper documentation/testing of positive/negative test cases will result in a WIN WIN situation for all the stakeholders. .

Business Continuity Plan

Introduction

An unwarned threat or vulnerability can expose a business to financial disaster and reduced customer satisfaction.  But an effective Business Continuity Plan (BCP) can help business entities in providing essential and unique services to their customers without feeling the impacts of downtime.

Risk Assessment

The biggest challenge in writing an effective BCP is identifying the potential risks. Some of the source of risks can be

• community-wide hazardous events due to which support staff cannot come to office


• accidents or sabotage causing disaster


• Disasters such as floods, earthquakes, or acts of terrorism


• Security threats such as virus attack, network and communication failures


• disastrous application errors such as crash of primary database or wrong production fix

Once the potential risk has been identified, check

• The probable magnitude of error


• The frequency or probability of occurrence

The purpose of Risk Assessment is to identify the  exact  threats,  and  the  estimated  exposure  together  with  the  contingency  and mitigation actions required, and also the benefits arising out of covering the risk.

Developing a Plan

A typical business continuity plan should have separate plans for each of these: prevention, response, resumption, recovery, and restoration. Some of the essential items are

• Objective: The purpose of writing the BCP is stated. It also states the different phases the organization intends to have and their interpretation of the objective of each phase.


• Scope: The divisions of business that fall within the scope of the BCP are stated here. Also any special scenarios being handled must be stated here. It is possible that a organization can have BCP specific to events.


• Assumptions: The assumptions based on which the plan was formulated are stated here. For example, a team, which is trained to handle the BCP operations will be available to execute the BCP, or, alternate site in-case of calamity should be ready to use within ‘x’ hours etc. Apart from assumption, any limitation should be clearly documented.


• Team: The BCP team, their sub-teams, roles and responsibilities are stated here. It also mentions which team take care of which phase of the BCP process, i.e., response, recovery, etc.


• Goals: The firm should state its maximum permissible outage time and the furthest point to which data loss is permitted. These are stated here, along with the performance goals.

Some of the risks that are identified can be reduced by implementing measures that can reduce its occurrence.  Examples of the Preventive Safeguards that can be documented are

• Surveillance


• Access Control


• Authentication


• Anti-virus


• Filters


• Intrusion Detection systems


• Backup plans

Response

Whenever a disaster occurs there needs to be an initial response such as communication to all stakeholders.  The resource requirements for such initial emergency Response are listed in initial phase If hard copies of documents and forms are needed for any approval, they must also be mentioned here.

Once the initial list is ready, a detailed Notification documentation should also be prepared. The list will clearly state the position, whether primary/alternate, timeout duration for response, address, phone/cell numbers, email and any other possible modes of contact.



Before notifying the impact of disaster, it is important to assess the damage. The guideline for doing so should be documented  e.g., all the things that must be inspected, the kinds of evaluation to be done—whether salvage/replace, the reporting to be done, and the time required, among other activities.



Once the damage assessment is done, the conditions that must be met for the event to be declared a disaster should also be stated. The disaster scenarios should also be mentioned. This will make it easy to initiate the resumption and recovery processes. The circumstances under which the business continuity plan is activated are outlined here: e.g., the server will not be up before 24 hours, or the primary site cannot be restored before 48 hours, etc.

Resumption

The procedure for transition from the emergency response to business resumption is given here. The process of making decisions regarding operations, concerning where and how they would be deployed, and the activities to be   performed and to what extent, are described. Activities are assigned to the different sub- units in the BCP team and each group performs its assigned tasks. This part of the plan is also called the Business Resumption Plan (BRP).

Recovery

The procedures to perform recovery are stated here. This part of the plan is called the Disaster Recovery Plan (DRP). This section of the plan must be more like an operations manual. It should be a simple sequence of instructions that can be followed to perform recovery. Any dependencies among the activities must also be clearly stated. It must be fairly detailed to avoid mistakes that can result in time loss.

Restoration

The steps for restoring the original site for business are described here. Responsibilities are marked against each team/role. The process of performing the parallel run with the alternate  recovery  site  along  with  the  procedures  for  comparing  results  from  the alternate  site  with  the  restoration-in-progress  site  are  described.  The criteria for switching to the original site and dismantling the alternate site are also stated.  Appendices can be used to mention the vendor contracts, and the business continuity measures of these vendors, information that is needed because the success of the BCP depends on the availability of the vendors. Furthermore, a description of the alternate site facilities, addresses and phone numbers of the control centre, and the contact list for notification could be presented in the appendices.

Image Credit : Google

Conclusion

BCP planning and execution is done to be safe from the consequences of events that can impact business. Ultimately it is better to be plan rather than face the consequence of unplanned event.

References

Disaster Recovery Journal: http://www.drj.com/drj2/drj2.htm

Google.

what is involved in writing a proposal for a web solution

If you are an entrepreneur/freelancer, then setting up fancy website might be easy. But making more money by designing website needs another skill. That is the ability to express to prospective clients through a business proposal. A common scenario employed by employers looking for designers is to advertize on a website/newspaper or send out Request for proposal to prospective candidates.  In such case, the best way you can respond is by writing a detailed business proposal.

Image Credit : Google

The Web site design proposals should highlight the competencies/experiences of the designer and also the differentiation factor i.e USP (Universal Selling Point) compared to other applicants. The simplest proposal answer the basic questions such as the cost, time to build, past design examples, testimonials etc.  Depending on the expertise of prospective clients, it is possible that they might be looking for response in an email rather than a formalized document. Irrespective of the type of response, here are some basic information that should be part of each proposal



Company Name

This is an overview section that gives information about your company. You can mention your company mission, vision and core team. The major purpose of this section is to speak in few words positive points of the company that will remain in the mind of prospective client



Scope of Work and Deliverables

In this section you highlight your understanding of the clients requirements and the details of  how you will achieve the design requested. You can also have separate sections such as Preliminary Research, Web Design, Database Design, Front End Programming, Quality Assurance etc to explain the detailed step in which the final product will be built. i.e Each Project phase can be highlighted. This section can be helpful in highlighting your expertise as well as any assumptions that you are making while detailing the steps.



Fees

Here you state the cost that the clients need to pay for the work that you will be doing. Payment can be either based on project phases or upfront fees etc. It is advisable to state it clearly.



Estimated Delivery Date

You should indicate the timeline for completing each phase of the project and the deliverables in each phase.  It is possible that you might need some data from customer such as client company image etc. Any impact due to the missed deadline from the customer should be highlighted so that all stakeholders are clear on the impact.

Past Clients

In this section you can specify your experience with previous client. Testimonials or URL link to show your expertise will be helpful

Once you have put in the above information, you can highlight to clients the possible next steps and give him your contact information on which you can be reachable for any further queries. You can even schedule a meeting to discuss any further questions or clarifications after their initial review.



All the above sections, though look easy based on title, it might actually be not so. Before filling any of the above section, you need do your homework. Some of the points which can be considered for doing the pre-work are

Research the Client and their Requirements

You should be able to demonstrate that that you understand the client needs properly through your proposal.  Research the Client and their business needs well. Most of this information should be available on client website or through net. Remember competitors will also be doing the same so if possible go an extra mile and brainstorm.

State the Capabilities in Clear and Concise Way

Be specific on how you can solve the client’s problem so that client will make fewer assumptions and feel more secure about the proposal.


Summarizing the above proposal writing steps in a single line - The purpose of your web solution proposal is to show the prospective client that you understand their needs and then convince them that you are the best choice for the job.