Pooja S Paudyal

My Graphic Design 1.9

My Graphic Design 1.8

I really love this flower Bougainvillea. Back in time I never cared for this flower but now I feel that its quite unique and different from rest of the flowers.

My Graphic Design 1.7 : A poster for my Fashion Blog

This is a poster or you can say an image I designed for my fashion blog..and as usual my software is Paint.net..

you can catch this article here

Snapshot of Business Analyst/Systems Analyst Profession

Generic/Broad Job Description

A business/systems analyst solves business problems by designing information systems which execute the strategy defined by the business. These IT solutions generally achieve one of the following goals for the business: implement a new/novel business process, increase efficiency and productivity of existing business processes, or reduce operating costs of existing processes.

The business/systems analyst gathers and analyzes new business requirements and weighs them against the existing business systems and processes. Working closely with the business stakeholders, the analyst guides the process of modeling and designing new systems which implement the goals of the organization as expressed by the business requirements.

Next, they document the solution, the blueprint of the new system, by creating documents and diagrams which specify system-user interactions, describe how data should flow through the system, and spell out the logical operations the new system must perform. They present their design to the business and, once approved, they work closely with the system architects and programmers to implement the solution.
Typical Work Activities

Most business and systems analysts are involved in creating, modifying, or maintaining some type of information system or software. Depending on the size and nature of the organization, work activities include, but are not limited to:

• Interacting with the business organization representatives, including executive management, to understand the business process and the needs of the business.
• Gathering business requirements from identified project stakeholders identifying potential solutions to the problems posed by the business needs and requirements.
• Translating the business requirements into functional requirements (what features should the system have).
• Creating functional specifications for new systems which solve the given business problems.
• Presenting solutions to business stakeholders and facilitate the iterative refinement of the system requirements.
• Working with the developers (programmers) to make sure the functional specifications are un-ambiguous.
• Creating (or helping others create) test scenarios and verifying the system

How does one become an analyst?

Effective analysts have comprehensive business knowledge in addition to the systems design skills. They generally become analysts in one of the two ways:

1. Earn a degree in a business related discipline (such as economics, finance, or accounting) and, on the job, continue their education by learning systems design skills and by getting involved as stakeholders in IT projects. Many such business practitioners attend additional courses in software design, use cases, modeling in order to round out their modern analyst skills.
2. Another very common path is to earn a degree in computer science or related field (such as engineering, information systems, etc.) and begin work as programmers, web designers, etc. Slowly, on the job, they acquire business domain skills from the projects they worked on as developers. Most developers take additional courses in communication, writing, requirements elicitation to round out their modern analyst skills.

What is Financial Ratio Analysis?

Financial Ratio Analysis is the evaluation and interpretation of a company’s financial data using standard financial ratios or accounting ratios to determine a company’s financial state or condition.  A financial ratio or accounting ratio is a ratio of two values that are taken for a company financial statements (Balance Sheet, Income Statement, Statement of Cash Flows, Statement of Retained Earnings )  There are many standard financial ratios used that have been identified as critical indicators of the financial performance of a business.  In addition to measuring a business’ health, they can be used for strategic planning and decision making.  Financial ratios can be grouped into categories based on the financial aspect of the business that they measure.  The categories are:

• Leverage/ Debt Ratios – disclose to what extent debt is used in a company’s capital structure which may indicate the company’s ability to repay long-term debt.
• Liquidity Ratios – reflect a company’s short term financial situation and availability of cash.
• Operational Ratios – indicate a company’s operational efficiency and how well assets are utilized.
• Profitability Ratios – measures the rate of return that a company achieves through the use of its assets and control of its expenses.
• Solvency Ratios - measure a firm’s ability to generate cash flow by converting its non-cash assets to cash in order to honor its financial obligations.

Financial ratio analysis is commonly used to compare a company’s current financial performance to its past performance, also called trend analysis, or it can be used to compare against other businesses within the same industry.  Comparison to businesses in different industries provides little value since different industries have different risks which may require different capital requirements.

How do you resolve an issue involving conflicting requirements from two or more stakeholders?

In order to determine what action should be taken to resolve conflicting requirements, the analyst must first determine the root cause of the conflict.  The causes of conflicting requirements are typically the same, time and time again.  Here are a couple of the more typical causes and how you might deal with them.

1) One or more of the stakeholders/groups misunderstand the higher level divisional or company goals which are driving their specific requirement.  This leads them to push for a process or system requirement that is not in line with the true needs of the business.

* Take some time to step back and level set everyone on the overall business case for the project.  Set up a meeting to discuss the project/business goals.  Avoid taking an approach of telling them in the meeting what the goals are, but instead ask the conflicting stakeholders/groups to reiterate the higher level goals themselves.  It will quickly become apparent that not everyone is on the same page.  Open conversation can then take place to gain consensus around the actual project goals.  If necessary, the group can go back to a project executive or sponsor for clarification.

2) Both stakeholders/groups understand the higher level divisional or company goals, but each group supports the company goals in very different ways.  Both have legitimate needs which are relevant, but they fail to realize that one group’s contributions to the company’s strategic vision may have less impact than the other.  This creates a difference in the way the needs of each group get prioritized at a company level.  So while one group may have a need which conflicts in some way with the other, one will almost certainly take precedence.

* This is where a predefined escalation path is necessary.  Both groups have a legitimate requirement to try and fulfill their own group’s need.  However, one will take higher priority over the other.  An unbiased mediator with knowledge of the higher level divisional or business goals can be engaged to break the stalemate.

3) Both stakeholders/groups have the same goal, but they disagree over the best course of action for meeting the goal.  They may disagree over the best way to revise a business process or the best user flow through a system.

* For a new business process, consider piloting the process with a select group of people for a short period of time.  Measure the results from the new process and compare it to the old process to determine the level of improvement.  Additionally, more than one potential process can be piloted, and the result of the two and be compared to determine the best overall process to implement.  Present the findings of the piloted process to the group.
* For determining the best user flow through a system, create a storyboard of screen mockups or even a usable prototype.  Schedule walkthroughs of the screens, storyboards, or prototype with end users of the new system.  As you walk through each screen, as questions such as:
o What do you expect will happen when you click on this button?
o Where do expect the system will take you when you click here?
o What screen do you think will come after this one?

Using the findings from the walkthroughs the team can gain consensus around the best possible system flow or UI design.

If the conflict is specifically around the design of individual screens, rely on UI best practices and usability patterns to develop the screen design.  Present information to the stakeholders describing why the usability pattern has been proven to work so well.  Remind them that UI design and usability patterns are documented because they have been proven to work well for many other companies and projects, so they have withstood the test of system users over time.

My Graphic Design 1.6

Very Tall Trees

by Laura J. Bobrow

One day I stood under a very tall tree.
The leaves were so high I could hardly see them, and I’m certain the
leaves couldn’t see me.
“Well,” I thought, “I’d like to be higher.”
So I went and got the wheelbarrow, a rickety old box,
and a rubber tire.
It took a lot if thinking to get them arranged just right,
And they almost reached to the very first branch … but not quite.
So then I got a telephone book, the watering can and a chair.
And when they were all together, I said to myself, “There.”
I said to myself, with one foot in the barrow,
“I’ll just climb up this tree and go visit a sparrow.”
There’s no trick to balancing on a rickety old box
If you know how to rick when the rickety box rocks.
If Mother could see me, I thought, on this tire,
“Why, where in the world are you going?” she’d inquire.
And I practiced my very most I-Don’t-Care look
As I stood on one hand on the telephone book.
But then, when I got to the watering can,
It wasn’t as easy as when I began.
I had one foot on the handle, and one on the spout,
And I wasn’t afraid. I was looking about.
I waved to the birds. I breathed some air,
And I could have made it up on to the chair,
When along came the breeze,
Which tickled my knees,
And I started to sneeze,
And kerplunk! I fell down as nice as you please.

Which is what is the matter with very tall trees.

Laura J. Bobrow is a versatile storyteller, who occasionally adds poems like this one to her performances. She has served in many varied roles, including festival organizer, conference keynoter, songwriter/lyricist. She currently resides in Leesburg, Virginia. To learn more about Ms. Bobrow, visit her webpage at www.storyteller.net/tellers/lbobrow

source : spiritoftrees.org

The Concept of Project Phase Model- Envision

The concepts of Phase Model

The project a global definition of the system is created which explains what the system aims to be and what is within the scope and what is not. This is one of the fundamental steps as it gives the developers some guidelines as to what the system will be without freezing any requirements. The scope can be documented in a vision statement. Another very important concept within this method is scope management. The scope needs to be managed throughout the project to prevent scope creeping which results in delays. The scope will be determined early and changes to the scope (like adding additional features which were at first considered beyond the scope of the project) will be evaluated and either accepted or rejected. Changes in the scope can be made but this will always be affected by trade offs between features, resources and time.

The phases of Project Phase Model

The model behind this method looks like this:

This model shows the five basic phases of the method. These phases will be explained in the following sections of this entry. The phases are: Envisioning, Planning, Developing, Stabilizing and Deploying. After this cycle has been completed a version of the system is ready and a new cycle begins to create a new version. The phases are explained in the following sections and are shown through a meta-modeling technique.

Envisioning phase process/data model

Read the rest of this entry »

Support Plan Template

Support or we can say that the maintenance process for a project is of importance for the smooth working of a project. I have worked mostly on support and maintenance projects so this support plan template will be useful for you.

The flowchart will explain the process flow and at which stage this support document is created and further used.

We have to define the Responsibility boundary definitions which are as follows :

1.  Networking :

Networking includes the management of networking , database and Desktop.

1.1    Networking
1.2    Database
1.3    Desktop

2.  Support Agreements :

Support Agreements includes and briefly describes the terms and conditions as per the project like hours of operation or vendor support.

2.0    Support agreements
2.1    Hours of operation
2.2    Contacts names and numbers
2.3    Up time expectation
2.4    Escalation process
2.5    Vendor support
2.6    Disaster recovery
2.7    User set up

3.  Training :

3.0    Training Sessions

4.  Approval and Initials :

4.0    Support Staff Signatures

Click here to download the sample template for Support Plan.

Statement Of Work

A statement of work (SOW) is a formal document that captures and defines the work activities, deliverables and timeline a vendor will execute against in performance of specified work for a customer. Detailed requirements and pricing are usually included in the Statement Of Work, along with standard regulatory and governance terms and conditions.

Overview :

There are many formats and styles of Statement of Work document templates that have been specialized for the Hardware or Software solutions being described in the Request for Proposal. Many companies create their own customized version of SOWs for use within their industry or vertical that have been either specialized or generalized to accommodate the typical request and proposals they receive.

It is important to note that in most cases the Statement of Work being agreed upon is a binding contract. Master Service Agreements or Consultant/Training Service agreements postpone certain work specific contractual components that are addressed in individual Statement of Work(s).

Areas addressed :

Areas that are typically addressed by an SOW are as follows:

Scope of Work :  This describes the work to be done in detail and specifies the hardware and software involved and the exact nature of the work to be done.

Location of Work : This describes where the work is to be performed. This also specifies the location of hardware and software and where people will meet to perform the work.

Period of Performance : This specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.

Deliverables Schedule : This part lists the specific deliverables, describing what is due and when.

Applicable Standards :  This describes any industry specific standards that need to be adhered to in fulfilling the contract.

Acceptance Criteria : This specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what criteria will be used to state the work is acceptable.
Read the rest of this entry »