Wonderful definitions of designations at office

1. Project Manager is a Person who thinks nine Women can deliver a baby in One month.

2. Developer is a Person who thinks it will take 18 months to deliver a Baby.

3. Onsite Coordinator is one who thinks single Woman can deliver nine babies in one month.

4. Client is the one who doesn’t know why he wants a baby.

5. Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.

6. Resource Optimization Team thinks they don’t Need a man or woman; They’ll produce a child with zero resources.

7. Documentation Team thinks they don’t care whether the child is delivered, they’ll just document 9 months.

8. Quality Auditor is the person who is never happy with the PROCESS to produce a baby. And lastly……………..

9. Tester is a person who always tells his wife that this is not the Right baby.

Meaning of HR

After 2 years of selfless service, a man realized that he has not been promoted, no transfer, no salary increase no commendation and that the Company is not doing any thing about it. So he decided to walk up to His HR Manager one morning and after exchanging greetings, he told his HR Manager his observation. The boss looked at him, laughed and asked him to sit down saying. My friend, you have not worked here for even one day.

The man was surprised to hear this, but the manager went on to explain.

Manager:- How many days are there in a year?

Man:- 365 days and some times 366

Manager:- how many hours make up a day?

Man:- 24 hours

Manager:- How long do you work in a day?

Man:- 8am to 4pm. i.e. 8 hours a day.

Manager:- So, what fraction of the day do you work in hours?

Man:- (He did some arithmetic and said 8/24 hours i.e. 1/3(one third)

Manager:- That is nice of you! What is one-third of 366 days?

Man:- 122 (1/3×366 = 122 in days)

Manager:- Do you come to work on weekends?

Man:- No sir

Manager:- How many days are there in a year that are weekends?

Man:- 52 Saturdays and 52 Sundays equals to 104 days

Manager:- Thanks for that. If you remove 104 days from 122 days, how many days do you now have?

Man:- 18 days.

Manager:- OK! I do give you 2 weeks sick leave every year. Now remove that14 days from the 18 days left. How many days do you have remaining?

Man:- 4 days

Manager:- Do you work on New Year day?

Man:- No sir!

Manager:- Do you come to work on workers day?

Man:- No sir!

Manager:- So how many days are left?

Man:- 2 days sir!

Manager:- Do you come to work on the (National holiday )?

Man:- No sir!

Manager:- So how many days are left?

Man:- 1 day sir!

Manager:- Do you work on Christmas day?

Man:- No sir!

Manager:- So how many days are left?

Man:- None sir!

Manager:- So, what are you claiming?

Man:- I have understood, Sir. I did not realise that I was stealing Company money all these days.

Moral - NEVER GO TO HR FOR HELP!!!

Have a Nice Day.

HR = HIGH RISK

Solid Business Plan

Getting into business is costly, and that is the bare truth. There are many entrepreneurs in this sea of people around us, but only with ideas in their head. Nothing in terms of actual businesses!

But then, they do not know where to look. If you see carefully, there are a lot of investors out there who are looking out for just some entrepreneurs like these – entrepreneurs, who have good ideas for business, but do not have the capital to make the required start. If you can manage to catch their eye, you will get the capital you want for your business, and then there is no saying to what heights you can reach.

But it is important to impress these investors. You can very well guess that there will be hundreds of thousands of entrepreneurs wanting to forward their business plans to investors, so that they can get the break in life that they want. Do all of them get it? Hardly! The success ratio for getting a business investment is about 1 in 1000, or even less, as the number of prospective business investment applications is piling up. So where do you stand a chance? The truth is, you have to have a very powerful business plan – something that will impress the investors so greatly that they will consider your application and keep it on top of the heap in their 'IN' tray.

If you strategize carefully, you can really achieve that singular glory. Getting considered by investors for starting your business is no mean achievement, and is possible only with long hours of work. And a power-packed business plan. But before you even start out with making a business plan, you must know about the different kinds of business investors out there. They are of two main kinds – the angel investors and the venture capitalists.

Angel Investors – Angel investors are usually individual people, or sometimes groups of people, who have so much wealth in their coffers that they have nothing better to do with it than take risks by investing in business. In the very least, they get someone to manage their money. At the most, they get a share in a future corporate business. Though the name suggests so, there is nothing divine about angel investors. They will want a share in your company, and will want a part of the profits too. But, since angel investors usually operate individually, there can be many differences here in the way they operate.

Venture Capitalists – Venture capitalists are the more common type of investors for businesses, since angel investors are few and far between. Venture capitalists, or VCs as they are endearingly called by potential business investment seekers, operate in forms of organizations. They adopt businesses of a special kind, and rarely venture out of the genre. They will also want high stakes of ownership in the business they are investing, and will want minute reports of progress. It is much more difficult to catch a VC's eye than an angel investor's. But your business plan can do the trick. Here are some expert ideas on making a very effective business plan that could catch the eye of even the most discerning of investors.

Tips on Making a Successful Business Plan

Tip # 1 – Be perfectly sure of what your business is set out to do

You will be surprised to know the large number of people out there who want to enter business and even have a germ of an idea in their mind, but do not know what exactly they want to do with their business when asked. Such are the people who fail terribly when they submit their proposals to the investors. VCs are highly trained to weed out such vague proposals. When you are making your business plan, begin with the Executive Summary. The whole success of your business plan will depend on this, because it is here that the initial impressions will be formed. In this section, you should mention clearly what the intent and purpose of your business is. Make a very clear mention of why the market needs your business, and who your target market will be. If the investor gets convinced there is a market out there for your business, it is half the battle won.

Tip # 2 – Make clear projections

It is actually funny to see sometimes how some entrepreneurs put in their profit projections in their business plans. Reading something like 'If we have about 1000 customers in the first three months, we could surely be touching be 50 million mark within the year' makes for interesting reading; but it is surely not going to hold any water with the ever-so skeptical investors. When you are making a projection, be realistic. How did you arrive at the conclusion that you will get 1000 customers in the first three months? What are your marketing plans for achieving that? Will you have production enough to meet the sales if they come up? Write clearly about all these factors. And avoid using conditional sentences that begin with 'if' in your projections.

Tip # 3 – Be realistic about the risks

There is no business without risks and venture capitalists know this only too well. When proposals come to them, they are the ones to first assess the risks of the proposals. So, you will do very well if you mention the risks beforehand in your business plan. That will give a realistic flair to your report. Otherwise, it will appear like a fantasy novel, nothing else. That will not go any good when your VC is considering all the potentialities of your business plan. In fact, you must keep a separate section, perhaps in the Marketing Analysis topic to mention all the risks that are associated with your business. Make it also a point to clearly elucidate what resources your business has, or will have, to counter these risks.

Tip # 4 – Keep your language simple

You must remember that your business plan is not a blueprint you are going to hand out to your engineers. This is a business plan, and it will be read by an investor. The investor, though quite wealthy, might not be very proficient at language. You must know that a large number of business plans are rejected just because the investors fail to understand what the proposer was getting at. So, you need to be very clear-cut in your language, and not use any difficult phrases. It is better to use points and bulleted formats wherever you can.

In conclusion, being frank and honest with your business plan always works. Come to the point directly, and do not beat around the bush. Investors have very little time, and chances are that they will only skim through your business plan. You have just about a few seconds to impress them into making an investment for your business. Keep that in mind, and you will probably be setting a date for inaugurating your business venture!

The 5 Most Common Mistakes Made By Startups

Entrepreneurs are no strangers to mistakes. Mistakes will happen - with considerable frequency - and the value in making those mistakes is learning from them and avoiding them in the future. You can also study the mistakes of others that came before. Plenty of successful entrepreneurs are quite open about mistakes they’ve made, why they made them and what they learned. We don’t need to keep repeating each other’s mistakes over and over.

But, that’s quite often the case. When it comes to startup mistakes you’ll see many companies making the same ones over and over.

Here are 5 of the most common mistakes made by startups:

1. Staying in Stealth Mode Too Long. New startups seem quite fond of stealth mode (or its newer cousin “ninja mode”), when they’re hiding under the radar but still hyping just enough to try and pique interest. But stay in stealth mode too long and you run the risk of disappearing off the radar. Never mind the fact that you can’t sell your new product or service while in stealth mode and therefore can’t generate any revenue. There are plenty of reasons why startups launch too slowly; really you need to force yourself to launch and get past all the excuses.
2. Not Focusing on the User. Who are you building your new product for? Who is the precise target? Many startups can give a generic answer to that question, but very few of them are really honed in on the specific wants of their “perfect user.” This is a combination of too little research and too much enthusiasm for what they think is “the next killer idea.” This mistake is compounded if you’re building something that you wouldn’t use yourself. Building something you would use makes things easier - you’re the target user. Otherwise you need to take a much more pragmatic approach.

   As well, many startups take the approach of “being everything to everyone.” That strategy never works. You end up being nothing to anyone.

3. Trying To Do Everything. If a task isn’t core to your business try and outsource it. Entrepreneurs are extremely fond of saying they wear many hats (which is true!) but there’s a limit to what’s reasonable in the hat-wearing department. Lots of things can be outsourced, and although you’ll be paying someone else to do the work, you’ll be freeing up precious time of your own. That time will be infinitely more valuable than the money you spend.
4. Not Having Enough Infrastructure. Many startups don’t have the proper tools in place to start their business. Primarily, money and time. It’s getting cheaper and cheaper to start companies nowadays but it’s never free. Lots of people start companies without realizing how much money it’s actually going to take. When they clue in, and decide they don’t have the money to invest (or they’re not willing to part with it), they’re in trouble.

   Startups face similar challenges with time. People often start companies while working full-time jobs. It’s doable but damn hard. And as soon as the startup gets a bit rocky or other interests come into play, the startup company gets shelved or delayed. Paul Graham comments on this beautifully in The 18 Mistakes That Kill Startups. His theory is that people get into startups half-heartedly and that’s what kills them. I think that’s part of the answer. The other side of that coin is that people truly do care and believe in what they’re doing, but they don’t have the infrastructure and bandwidth in place to make it happen.

   Infrastructure issues are also related to a startup’s lack of connections and resources to find good vendors, good hires, mentors and people to rely on. A couple guys in a garage may have a great idea and tons of talent but when they need help securing a loan or handling a business-related task they may not have the network or foundation in place to support them.

5. Forgetting About Branding, Marketing and Sales. I know there are examples of companies succeeding with a “build it and they will come” approach. Some people argue if you build something people want they’ll find it and plunk down their hard-earned money. It happens. But more often than not you need to develop real, actionable and savvy branding, marketing and sales strategies. You might have a great product and the wrong message. Or a killer software application that no one knows about. It’s rare to have a startup where the founders (or one of them) has real experience in branding, marketing and sales. The result is either all the founders do it (and often poorly) or they all pass the buck.

   You can take a “build it and they will come” approach and hope for the world to pick up your scent and fall in love with you, or you can figure out how you’ll get the message out, what that message will be and how you’ll generate leads. Go with the latter.

The good news is that almost every mistake can be undone, and it’s rare that one mistake kills a startup completely. So feel free to make them - but skip those listed above…

Top 10 Steps for Success

Logically, every business owner or executive manager strives to succeed. For the benefit of the company, the employees, the product and last but not least, for themselves. Certainly, sometimes the order that i listed changes as little. I ran into a listing of the top 10 steps to succeed in business. Evaluate yourself, does your company do what's described below? Do you have room for improvement?

Here we go:

1. Develop a strategic plan. Many business owners measure their success by how hard they work and whether there is enough money to cover payroll, but in reality they operate best with a strategic plan and methodology for measuring and executing that plan.

2. Stay flexible to changes in the strategic plan. A strategic plan should be a work in progress that evolves in accordance with long term goals. Although flexibility is important, it does not mean that a business should be run without a strategic plan.

3. Transform yourself from company expert to master strategist. Focus on planning the future business success by creating a leadership team and delegating duties. This strategy might require an extensive role change, but will help to obtain more control for the future success of the company.

4. Focus on short-term growth. Key company goals should be monitored daily and weekly rather than monthly. By focusing on business growth in the short term there will be far less concern over the long term.

5. Develop reporting systems. Strategies cannot be implemented without reporting systems that track critical numbers. A daily review helps to measure and clarify where company efforts need to be enhanced as well as holds each employee accountable for performance.

6. Hold a daily management meeting. A daily meeting creates the intensity and focus needed for business owners to identify problems and issues before they get out of control. Meetings should focus on one key issue.

7. Control costs by budgeting percentages. Control costs by measuring a percentage rather than an absolute basis. Daily or weekly percentage increases and decreases should signal change and help to determine why inconsistencies might exist.

8. Offer incentives to key business drivers. All employees have the ability to drive or stall the business. Creative incentives that drive should contribute to both the profitability and mission of the company. Fair incentives should be tied to specific measurable items that each employee has control over.

9. Create a new management model. Creating a new management model allows for updating as well as preparing the business for positive change. Incorporate all levels of employees in both the thought and implementation process.

10. Play to win. These guidelines are easier and more enjoyable to adhere to when a company aims high and plays to win. A business that survives is the one that plans to innovate, allows for constant change and plays to win.

Found something that you're already doing? Anything that you're doing that leads to consequent success but is not mentioned here? Add it to the list, the more tips we can compile in this thread, the better it is for the community.

ESRI's ArcWeb Services

ESRI's ArcWeb Services are a collection of tools that enable users to integrate mapping, routing, and geographic reporting into their Web sites, mobile devices, and desktop applications. As businesses grow and enterprise needs evolve, ArcWeb applications can be expanded without the need for additional tools or software reconfiguration. ArcWeb capabilities are built on ESRI's industry-leading GIS (Geographic Information System) software. ESRI, with decades of experience and proprietary knowledge in the GIS industry, provides sophisticated analytical GIS tools to solve spatial problems.

Developer resources are available to integrate ArcWeb services into any application. These services allow users to perform a variety of spatial query and proximity searches on a host of datasets provided by Tele Atlas, as well as on custom datasets uploaded and maintained by users. ArcWeb Services also allow users to create simple or multipoint routes, base maps and color-coded maps, and demographic reports. They also allow users to upload their own data, add it as a layer to an existing map service, and share it with other members of the enterprise.

Serial UART, an introduction

An UART, universal asynchronous receiver / transmitter is responsible for performing the main task in serial communications with computers. The device changes incomming parallel information to serial data which can be sent on a communication line. A second UART can be used to receive the information. The UART performs all the tasks, timing, parity checking, etc. needed for the communication. The only extra devices attached are line driver chips capable of transforming the TTL level signals to line voltages and vice versa.

To use the UART in different environments, registers are accessible to set or review the communication parameters. Setable parameters are for example the communication speed, the type of parity check, and the way incomming information is signalled to the running software.

Serial UART types

Serial communication on PC compatibles started with the 8250 UART in the IBM XT. In the years after, new family members were introduced like the 8250A and 8250B revisions and the 16450. The last one was first implemented in the AT. The higher bus speed in this computer could not be reached by the 8250 series. The differences between these first UART series were rather minor. The most important property changed with each new release was the maximum allowed speed at the processor bus side.

The 16450 was capable of handling a communication speed of 38.4 kbs without problems. The demand for higher speeds led to the development of newer series which would be able to release the main processor from some of its tasks. The main problem with the original series was the need to perform a software action for each single byte to transmit or receive. To overcome this problem, the 16550 was released which contained two on-board FIFO buffers, each capable of storing 16 bytes. One buffer for incomming, and one buffer for outgoing bytes.

A marvellous idea, but it didn't work out that way. The 16550 chip contained a firmware bug which made it impossible to use the buffers. The 16550A which appeared soon after was the first UART which was able to use its FIFO buffers. This made it possible to increase maximum reliable communication speeds to 115.2 kbs. This speed was necessary to use effectively modems with on-board compression. A further enhancment introduced with the 16550 was the ablity to use DMA, direct memory access for the data transfer. Two pins were redefined for this purpose. DMA transfer is not used with most applications. Only special serial I/O boards with a high number of ports contain sometimes the necessary extra circuitry to make this feature work.

The 16550A is the most common UART at this moment. Newer versions are under development, including the 16650 which contains two 32 byte FIFO's and on board support for software flow control. Texas Instruments is developing the 16750 which contains 64 byte FIFO's.

What is NMEA?

The National Marine Electronics Association is dedicated to the education and advancement of the marine electronics industry and the market which it serves.

It is a non-profit association composed of manufacturers, distributors, dealers, educational institutions, and others interested in peripheral marine electronics occupations (quoted from a promo in "NMEA News")

What is an NMEA standard?

For the purposes of this article, an NMEA standard defines an electrical interface and data protocol for communications between marine instrumentation. (They may also have standards for other things.)

More about NMEA?

NMEA 0183 (or NMEA for short) is a combined electrical and data specification for communication between marine electronics and also, more generally, GPS receivers.

The NMEA 0183 protocol is a means by which marine instruments and also most GPS receivers can communicate with each other. It has been defined by, and is controlled by, the US based National Marine Electronics Association.

The NMEA 0183 standard uses a simple ASCII, serial communications protocol that defines how data is transmitted in a "sentence" from one "talker" to one or more "listeners". The standard also defines the contents of each sentence (message) type so that all listeners can parse messages accurately:

• Each message starting character is a dollar sign.
• The next first five characters identify the type of message.
• All data fields that follow are comma-delimited.
• The first character that immediately follows the last data field character is an asterisk.
• The asterisk is immediately followed by a two-digit checksum.

NMEA is a standard protocol, use by GPS receivers to transmit data. NMEA output is EIA-422A but for most purposes you can consider it RS-232 compatible. Use 4800 bps, 8 data bits, no parity and one stop bit (8N1). NMEA 0183 sentences are all ASCII. Each sentence begins with a dollar sign ($) and ends with a carriage return linefeed (). Data is comma delimited. All commas must be included as they act as markers. Some GPS do not send some of the fields. A checksum is optionally added (in a few cases it is manatory). Following the $ is the address field aaccc. aa is the device id. GP is used to identify GPS data. Transmission of the device ID is usually optional. ccc is the sentence formatter, otherwise known as the sentence name.

Unified Modeling: What, Why & How?

Executive Summary

The use of Unified Modeling Language (UML) has been taken as one of the most important parts of software developments in the last couple of years. It is supposed to be a big step towards sorting out silly conflicts over notation. It’s important to know that creating a UML diagram involves a cost, and a UML model is not something that fundamentally matters to a customer. Customers are always interested in the working software that meets its requirements, not pictures & models. Hence the cost of creating a UML model for the system is always bearable by the developing organization only. Yet it is important to avoid the silly mistakes in system analysis and to save resources & time by avoiding conflicts & inconsistencies. Being UML modeling so important, one needs to know the focus of modeling & how to meet this focus. This collection of words includes about how to move with UML for system analysis & deployment before jumping into its development.

What's a Model:

A model may be taken as a form of abstraction that omits undesired details and allows the designer to look into the more important aspects and elaborate them with proper consideration. A model allows a designer to look into all the aspects of the systems so that no important phase or point or detail is left without discussion and consideration that may cause failure of development in later stages where the remedy actions are either impractical or they are too costly & time consuming. A model is used for understanding a system properly before its actual implementation so that the product may be developed in a cost effective and efficient manner. Also the systems developed with proper understanding are much more maintainable and feed to user requirements for long time.

To build complex systems, they need to be simplified first so that they may be properly understood & then developed in a maintainable way. For this the designer needs to watch the system from different focus points with abstract details. These focus-points give different “Views” of the system. These views of the system give a “Model” of the system.

Why Modeling?

While designing a system, we need to analyze and understand it from different angles & view points. So many different conceptual, logical, physical and other types of complexities need to be solved. For this we use different design strategies and models. Modeling creates a base for implementation of the system and its testing. It gives specifications for its use by customer. It explains the design idea in a presentable form. A Model explains the system at different levels of abstraction. At a time, it provides a selective aspect study of the system. The designer can use it to explain the architecture to the professionals and abstract and relevant details to others. Modeling it a strong tool to plan the steps in development of the system and check the feasibility of ideas before final actions on it. Modeling also provides a base for testing and testability of the system before the system is actually implemented. Moreover, modeling reduces the complexity of the system and hence saves resources.

It is important to mention here that the design is only a concept that describes the system understanding of the designer. It tells the thinking of an experience-holder about the strategy to be adopted for development of the system in hand. Now all human does not think in the same way. Some may have better understanding in textual form while others may prefer graphic notations of the design. Here the model efforts to bring them on an almost common platform where the conflicts of the design may be resolved and some consistent design for implementation may be proposed. Model is also important to remove the silly mistakes while developing the system and also creates a scale for evaluation while development. Its output is something more than a simple software system with its better understanding, documentation and maintenance tips.

OOMD & UML

Object-Oriented Modeling & Designing (OOMD) is an innovation for Inception, Elaboration, Construction and Transition in Software Development Life Cycle (SDLC). This is a way for analyzing, designing and developing a software system using concepts having direct correspondence with the real world entities. We use graphic notations for Object-Oriented construction of systems. Visual Modeling is one way for generating these notations. Visual modeling creates Object-Oriented-Models (OOM) for a system under construction for its analysis, designing & implementation in an object-oriented language. We create OOMs for complex systems under construction for their better understanding and a better & efficient designing. We use different graphical notations with lots of documentations for a proper & unambiguous understanding of the system. For such modeling of the systems, we can use a globally accepted media known as Unified Modeling Language (UML). UML gives a set of graphical notations prescribed for different entities & terms used in Object Oriented Modeling of any system.

How to start: Static Analysis

The system development life cycle starts with a problem statement using which a use-case model is created which is important to state the understandability & usability of the system. Here the system is represented at the highest level of abstraction i.e. (generally) as a single unit that can be used for some purpose. It includes all possible conversations (termed as use cases) between a user (termed as actor) and an operator in the system during any task. Sequence of occurrence of the dialogues is not important to be mentioned in a use case model. Also it is not required to show how the system is performing its task. It only shows how a system interacts with its environment/user.

The Next Step

Once the system & its interaction with its environment are understood, the analysis part of system development life cycle (SDLC) is almost complete. The next step is for designing the system. This design is later implemented in terms of some high level codes, which are then to be converted into executable modules and installed in the environment of the system. Hence designing creates a base framework to move forward towards implementation. In unified modeling, class diagrams are created for this step of SDLC. The appropriate classes can be found from problem statements from the list of nouns used in the problem statement. These classes interact with each other in terms of message passing. The classes create templates for objects in the system and hence we need to show the attributes as well as methods involved in the template clearly. Class diagram creates a base for implementation of the system in any Object-Oriented language. Lacking a proper description of types or interactions of classes in the class-diagram not only can weaken the base of quality of the system but can also introduce many inconsistencies in the system. So we need to clearly describe all required templates and interactions between them. For more clarity this analysis is done on different levels of abstractions from top to bottom.

Dynamic Analysis

Static analysis is followed by analysis of dynamic behavior of the system. Here the unified-model members include sequence diagrams & state diagrams. For software implementation point of view, the state diagram may not be of direct use but they serve for understanding the system dynamicity in terms of some finite number of states. This finite state analysis helps the developer to avoid many inconsistencies and exceptions at run-time. The state diagram clearly state the transitions of states on occurrence of some event or message passing between two classes. State diagram is highly important in concurrent processing or multithreading system designing & enhancing their performance.

Next in System Dynamics

System dynamic analysis includes another important analysis what we call ‘sequence analysis’. Sequence analysis talks about sequence of occurrence of events & operations. Sequence analysis gives direct information for implementation of a function or method. While creating a sequence diagram for a task or some function, it should be kept in mind that sequence analysis might be taken as the boundary of designing & implementation phases of SDLC from where we might be able to see both sides of the boundary. This means that a sequence diagram should be able to describe the direct mapping for the design to its coding in the programming language. Hence the sequence diagram can be understood like a graphical representation of the algorithm to implement a task in the system. The sequence analysis is important for each and every task. At the lowest level of abstraction, all the functions and methods included in a class are analyzed for occurrence of sequences of operations in it. This sequence can then be taken as it is and implemented in the chosen high level (Object-Oriented) programming language for the required function. The best sequence diagrams are expected to describe all the required programming instructions in the form of message-passing events.

Unified Modeling for System Deployment

After static & dynamic analysis and designing of the system, the software is implemented for the system in programming language. After that, the system needs to be installed in its working-environment including other interacting software, hardware and user interfaces. To analyze it before system implementation, deployment views in UML are used to show other interfaces, software & hardware, communication media and communication buses present in the environment. In deployment diagram, the information about the type of communication buses, server configuration, database architectures, type of interfaces with other used hardware and software etc. should be clearly mentioned.

Closure

No doubt that designing is one of the most crucial and resource consuming phase in SDLC and that’s too the one which has nothing of direct interest of the consumer. The developing organization itself is expected to bear the net cost of designing & modeling. In such a scenario, Unified Modeling has rapidly become the standard notation for modeling software-intensive systems. Companies today are interested in the entire project development life cycle and how it ties into the Unified Modeling. In most cases, the various methodologies will easily adapt to it. Unified Modeling provides a complete modeling at almost every stage of SDLC right from the beginning of requirement analysis till deployment of the system covering implementation model and dynamic behavior model also. For those of us who have built software and designed databases for many years, unified modeling will also remove additional risk from the development process. Although the unified modeling is not a SDLC process, it offers a concise and workable notation that can be applied to any domain.

UML definitions

Introduction

Some general definitions to key concepts in the process space.

Activity

A unit of work a role may be asked to perform.

Activity diagram

Represents a special case of a state machine that is used to model processes involving one or more classifiers.

Actor

Represents someone or something, outside the system, that interacts with the system.

Aggregation

Shows an association that models a whole-part relationship between an aggregate (the whole) and its parts.

Analysis & design

A discipline in the Unified Process, whose purpose is to show how the system's use-cases will be realized in implementation; (general) activities during which strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

Analysis class

An abstraction of a role played by a design element in the system, typically within the context of a use-case realization. Analysis classes may provide an abstraction for several roles, representing the common behavior of those roles. Analysis classes typically evolve into one or more design elements; for example, design classes and/or capsules, or design subsystems.

Application Programming Interface (API)

Represents a software interface that enables applications to communicate with each other. An API is the set of programming language constructs or statements that can be coded in an application program to obtain the specific functions and services provided by an underlying operating system or service program.

Architecture

Represents the highest-level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization, or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components, and subsystems.

Artifact

A piece of information that:

1. Is produced, modified, or used by a process,

2. Defines an area of responsibility, and

3. Is subject to version control.

An artifact can be a model, model element, or document. A document can enclose other documents.

Association

Represents a relationship that models a bi-directional semantic connection among instances.

Boundary class

A class used to model communication between the system's environments and its inner workings.

Business actor

Represents someone or something, outside the business, that interacts with the business.

Business entity

A business entity represents a significant and persistent piece of information that is manipulated by business actors and business workers.

Business use-case

A business use-case defines a set of business use-case instances, where each instance is a sequence of actions a business performs that yields an observable result of value to a particular business actor. A business use-case class contains all main, alternate workflows related to producing the "observable result of value".

Business use-case model

A model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.

Class

A description of a set of objects that share the same members.

Component

It represents a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function. A component should conform to and provides the realization of a set of interfaces.

Component diagram

A diagram that shows the organizations and dependencies that exist among components in a system.

Composition

Represents a form of aggregation association with strong ownership and coincident lifetime as part of the whole.

Deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them.

Development case

The software-engineering process used by the performing organization. It is developed as a configuration, or customization, of the Unified Process product, and adapted to the project's needs.

Discipline

A discipline is a collection of related activities that are related to a major 'area of concern'. The disciplines in RUP include: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Document

A document is a collection of information that is ‘intended to be represented’ on paper, or in a medium using a paper metaphor. Web pages may serve as documents.

Elaboration

Represents the second phase of the Unified Process where the product vision and its architecture are defined.

Entity class

A class used to model information that has been stored by the system, and the associated behavior. It typically defines a set of entity objects, which participate in several use-cases and typically survive those use-cases.

Environment

Represents a discipline in the software-engineering process, whose purpose is to define and manage the environment in which the system is being developed. Includes process descriptions, configuration management, and development tools.

Executable architecture

An executable architecture is a partial implementation of the system, built to demonstrate selected system functions and properties, in particular, those satisfying non-functional requirements.

Extend-relationship

An extend-relationship from a use-case class A to a use-case class B indicates that an instance of B may include (subject to specific conditions specified in the extension) the behavior specified by A. Behavior specified by several extenders of a single target use-case can occur within a single use-case instance.

Feature

An externally observable service provided by the system which directly fulfills a stakeholder needs.

Inception

The first phase of the Unified Process, in which the seed idea, request for proposal, for the previous generation is brought to the point of being (at least internally) funded to enter the elaboration phase.

Layer

A layer represents a horizontal slice through an architecture.

Milestone

Represents the point at which a given iteration formally ends.

Model

Represents a description of a system from a particular perspective, which describes the system in such a way that no additional information is required to understand the system (from that perspective).

Model element

Represents an element that is an abstraction drawn from the system being modeled.

Node

A node is a classifier that represents a run-time computational resource, which generally has at least a memory and often processing capability. Run-time objects and components may reside on nodes.

Package

Represents a general-purpose mechanism for organizing elements into groups.

Refinement

Depicts a relationship that represents a fuller specification of something that has already been specified at a certain level of detail.

Relationship

Represents a semantic connection among model elements.

Requirement

A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed documents.

Risk

Represents an ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.

RUP

Rational Unified Process

Scenario

Represents a specific sequence of actions that illustrates behaviors.

Service-Oriented Architecture (SOA)

A service-oriented architecture is a conceptual description of a the structure of a software system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services, and connections between components.

Software requirement

A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment.

Stakeholder

Represents an individual who is materially affected by the outcome of the system.

Stakeholder need

Represents the business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.

Template

Represents the predefined structure for an artifact.

Traceability

The ability to trace a project element to other related project elements.

Use-case

Represents a description of system behavior, in terms of sequences of actions.

Use-case diagram

Represents a diagram that shows the relationships among actors and use-cases within a system.

Vision

The user's view of the product to be developed specified at the level of key stakeholder needs and features of the system.

Enterprise Application Solution: A Component Based Approach

1. INTRODUCTION

The trend of Information Technology has taken a big aspect over the whole world. It has got the trust of various types of users, especially of business organizations by offering the way to optimize the business processes.

To achieve high performance with respect to information technology, it’s obvious that a company should contain a well organized computer based information system, containing an application solution that reflects the business strategies, business processes, business models and core processes derived from these strategies. Since in real business world, business processes and models changes frequently, so the computer application solution must be designed in a manner that, it can also be changed quickly to meet the current business requirement [6].
Each business organization contains some strategic goals, on which the organizational decisions made by the proper positioned person. To do that certainly s/he should get the correct, appropriate and relevant information at the right time. Besides focusing on core business, the authority desires proper support for customer and partner contact management, monitoring employee’s activities and improving relationship with them. Considering these facts, a computer application solution should offer a great deal of performance and business application integration.
Enterprise Business Application is $200 billion industry and growing. 10,000+ companies are providing solutions that cost $0-$1 million.

2. ENTERPRISE ARCHITECTURE

2.1 What is Enterprise Architecture?

Enterprise architecture identifies the core components of the organization or a sub-set of it (such as its information systems) [1, 9]. Considering the target as the defined business objective, these components work together. These components contain staff, business processes, technology, information, financial and other resources, etc. If the architecture is engineered enough to ensure the selection of the desired components and to specify how they will operate together smoothly and efficiently, the corresponding enterprise will be benefited [1, 4, 9]. But if the overall architecture is not well engineered enough, the result is likely to be duplication of effort and resources, poor coordination and control, problems with management and business performance, inability to share important resources such as information, and inefficiencies in operation [3, 5].

2.2 Advantages of Enterprise Architecture:

Computer based enterprise architecture should be considered as an investment for the future. From the point of view of a paying client of an application solution, initially it may seem costly but considering long term duration, it will provide some real benefits. The facts that considered as the advantages of enterprise architecture can be described as follows [5-10].

· It provides efficient, appropriate and timely support for business processes - including achieving fast time to market or operation for new business endeavors.

· It facilitates the interoperability between separately developed application systems both within and outside the enterprise (e-business, joined-up government).

· Necessary business process re-engineering becomes easier.

· Maximum longevity/reuse of infrastructural components can be ensured

· It maximizes the opportunities for exploitation of corporate information/data assets (such as for customer relationship management or improved decision-making).

· Ensuring the survivability of information/data

· Ensuring suitable support to users, whether internal or customers, including appropriate availability and ease of use

· Reduces the cost of execution.

2.3 Real-Time Enterprise Architecture:

Although in developed countries, many organizations started to get the benefit of Enterprise Architecture, but most company processes today are not integrated, rather run in separate process. Feedback from one process to another is costly. An organization may contain a software system that independently process whatever has to be concerned with in the corresponding department: purchasing concentrates on purchasing, production on production, and so on.
To survive competitively it is essential to know one's customers' needs and be able to respond to these quickly. This requires an overall integration of all business processes.

Organizations who can support not just separate business information processing, but who can also achieve consistent business process integration in a flexible way with suppliers, partners and customers, even across whole organization boundaries, can be denoted as real-time enterprises [1-3]. A real-time enterprise can respond to customer needs and market changes effectively and quickly. It concentrates on its core objectives, while extensively integrated, strategic partners focus on selected activities. The high availability and security of the business-critical applications gets the considerable attention [1, 4].

2.4 Key Features:

Considering Web-based solutions, the key features of modern, enterprise-wide application architecture include [8- 10]:

· Dividing the application into several tiers, at least for presentation, business logic and data storage tier (n-tier concept).

· Use of Web browsers (for stationary and some special mobile terminals) and WAP micro browsers (for mobile terminals) as a primary user interface with support for the standards HTTP and HTML or WAP and WML, respectively.

· Use of de facto and Internet standard based protocols and data formats, such as TCP/IP, FTP, SMTP, SQL, ODBC, LDAP, SSL, etc.

· Component technologies such as Microsoft COM+ Services/ .NET Enterprise Services and Enterprise JavaBeans (EJBs) can be used.

· Dedicated, function-optimized server technologies such as Web Servers, Portal Servers, Contact Servers, Application Servers, Integration Servers, Database Servers and Directory Servers can be used.

3. COMPONENT BASED MODEL: A CASE STUDY

We know, “Cost ¥ Software Customization” - that is cost is proportional to customization with respect to software development, which tells that the more you want to customize software according to your company strategy, you have to consider more cost.
The corresponding software manufacturer can further extent the component for the user, who is able to provide more money and want to customize software according to exactly, fit their whole business process.
By surveying several corporate computer users, according to their requirements, here are some key facts that should reside in a real-time enterprise application solution component.
A typical enterprise organization consists of the following major section:

· Human Recourse Management (HRM)
· Supply Chain Management (SCM)
· Customer Relationship Management (CRM)
· Accounts

These four facts are briefly described below:

3.1 Human Recourse Management (HRM):

In any organization or company a number of people are involved to achieve the desired goal or target of the organization. In an enterprise company there are more than hundred to thousand peoples are employed. So from this view we can say Human Resource Management (HRM) is a very important part of the organization that is concerned with the working people in that organization. So the Human Resource is one of the driving force for product as well as service oriented organization.

The main objective of HRM department is to make a good balancing way to distribute all employees in the company in such way so that right person is on right position.
Since in future a company may need more employees or to change its employees depends on the requirement or situation, the HRM procedure is ongoing procedure that always tries to fulfill the requirement of human resource in the enterprise organization.

Basic features of HRM are as:

· Recruitment and Selection
· Training and Development Skills
· Performance appraisal
· Maintenance and Motivation

3.2 Supply Chain Management (SCM):

Supply Chain Management is the process which keeps track of the products that are imported, the supply of the product that’s produces by the current company. The SCM section will provide the facility that keeps track of information how the product supply, keep track of current status of goods etc.

3.3 Customer Relationship Management (CRM):

For a business organization customers plays a very important role. So, the goal of a CRM strategy is to create a long term, profitable relationships with the customer. This can be achieved when company understand who their customers are, what their needs in different segment and economical means to meet the needs of each segment. CRM includes a series of business function that contribute to the successful management of the customer and company relationships. The basic functionality provided by the CRM section is let the employees see the behavior of the customer and organize their time better, identify opportunity and turn them into close deals, account history is used to check out previously purchased products, to check how the customers satisfy with the level of service or the quality of products, to analyze and making perfect decision.

3.4 Accounting:

Generally each company contains account section, which summarizes the financial data about the business and organizes this information into useful form. The facts that are relevant to an account section are making Balance Sheet, Income Statement, Share Statement, Yearly profit or loss, etc. by dealing with paying salary to all employee, rent charge, production cost, total amount of money by selling goods or service, total due in the market, equipment cost and wages, paying taxes, advertisement cost, purchase discount, purchase return, investment, inventory, account payable & receivable, net income, net loss and other relevant tasks.

4. UTILIZING BEST PRACTICES

Business organizations can be benefited from low cost pre-built solutions that are based on industries best practices. A best practice is a business process with demonstrated ability to achieve superior results. For Example sales forecasting is a business, while triangulated sales forecasting is best practice business process. Best practices can be derived only from successful, extensive experience in selling, marketing and service. Usually to use such systems requires just business skills and management of such systems is also simple. Mainly users adopt their business and learn to do the business that every one agrees. Organization achieves maximum business impact from ERP/CRM implementation by applying best practices to their business process. Since the internet thing is emerging one can participate just by utilizing ERP/CRM. A new genre of business consultant will emerge by learning and utilizing industries best practices.

5. CONCLUSION

In several cases, the customized software’s that ware built to meet the requirements of business organizations, by software manufacturers, contains several bugs and some sort of inefficiency to process and provide information. The cause that lies beneath this problem is lack of proper awareness of well engineered software application solution that contains proven design methodologies and architecture. Developing a well engineered real-time enterprise application solution component is a challenging task. The best approach for such activity will be to participate in a mature open source project. There are several open source projects available that uses different programming platforms like PHP, Java or .NET. Some of the tools are even free. Universities could take lead for such research and development activities. Industries participation will definitely strengthen our commitment to IT development and establishing high tech call centers even in remote places in our country.

Requirement Analysis Steps while Developing Software

Introduction

This article provides a basic outline to discover, document requirement documents for a given software project. Some of the steps can be ignored if the application requirements are pretty simple or small.

The Steps

Research on Application Requirements

This document includes the URL’s that are the web application and similar to the current project, which will be used to elicit the requirements. It also contains the necessary user name and password for the research sites, along with the research report where required. This type of document can also include the user questionnaires interviews if necessary.

Research on Technical Issues [developer view]

This document includes the list of technical issues that are relevant to the current project, along with the useful URL and the research report.

Application Basic Features [user view – top level]

This document includes the basic key features for the current project. This describes the application from very top level point of view, so that any one can understand about the system very quickly and easily. It also helps the developer to identify and articulate the development process from very early stage.

Use Cases [user/developer view – top level]

This includes text and diagrams that illustrate how all the application features and sub-features are acting and communicating thru various stage of usage and work flow. It helps the user and developer to understand and identify system process from basic, initial and top level point of view.

User Interface Specification [user/developer view – mid level]

This document is useful while building the application. Thru this specification the client get an initial idea about what the system is and it comes easy for the client to verify and confirm whether they are going to get all the required features. We can use Microsoft doc (for wire frames) or simply static html lay-outs to illustrate the UI.

User Requirements Specification [user/developer view – low level]

This document includes the detail specification of the application. Basically this is the detail description of the basic features that has been identified.

Architecture

· Security model

· Skinning and page settings

· Global data transfer among pages

· Identifying the modules & module boundaries [top level]

It describes the basic, core modules that are being considered to be developed. This is especially useful while working with large scale projects. Although this is used to define the system boundaries from top level view, by defining the sub-modules as well as, makes the future development process more requirement specific and makes the complex task to integrate the modules and identity the module communication in the design time easy.

Data Fields [user/developer view – low level]

The data fields of the application have been identified in this step. Database schema, relation and data fields are recognized and validated with the client to ensure the current requirement analysis grabs all the required things.

Time Estimation [manager view]

• According to modules
• According to development steps
• According to developer expert level
• According to logical tiers (as well as level of engineering)