How to develop Business Applications?

[Tommy_M]

Hi,

I've been on here once before, a while ago!

Im an ex college student from Sheffield, UK and the Apps i was developing there were just assignments, things like Sorting Football Teams Results, BMI with graphics, and really simple programs.

Now that ive finished college, I need to start to develop Business Applications and earn some real pounds or dollars (depending where you are!).

The problem lies in my skill set, I can code but i dont know how to go about developing proper business applications!

I have studied SSADM to degree but only for Access

Like the title says, how would I go about start developing a business application?

Any help would be appreciated


Tom

[Hack]

The number of different ways to develop a business application is as vast as is the number of businesses.

You would not develop an application for a insurance company the same way would you develop an application for a manufacturing plant or the same way you would develop an application for the aerospace industry.

This an impossibly generic question to answer with anything specific.

The first step would be to pick a business. What business do you want to develop the application for?

Next, how does this business do business? What business rules do they follow that governs them?

Does this business have, at the moment, a business process that is manual that they (the business) could benefit from by having it automated.

[Merrion]

A business application is a model of (all or part of) the operation of a business.

So - within a business there are things (customers, employees, stock, etc.) and there are operations (open new account, withdraw funds, add funds, add stock etc.)

To model the things you need a data model. In nearly every case a relational database is used to implement the model so the design methodologies for relational databases are often applied to the data model...however all you really need to have in your data model is the identifier (type) of the things and the properties that you need to store about that thing.

For example if you have a fleet of cars then the type of the thing might be "CAR" and the properties you need to store about each car instance might be {registration number, colour, engine capacity, fuel type} .

To model the operations you need to list the things involved in the operation, the restrictions on the operation and the state change(s) due to the operation. For example the operation "sell item" would involve the things {stock items, customers, customer accounts} and the restrictions would be {stock item.stock level > 0}, {customer exists} {customer.accounts.credit >= stock item.cost} and the state changes wouyld be {stock item.stock level decremented by 1} and {customer.accounts.credit decremented by stock item.cost}

Finally you need to expose the things and the operations to the system user in a way that allows them to select the items to go in to the operation and to cause the operation to be performed. This is in the user interface description (although it does not always have to have a user - for example a timer based or batch process still an interface of sorts)

[Shaggy Hiker]

It doesn't sound like you are trying to build a random app, but are trying to build a specific business app for a specific business. It also sounds like somebody has said something like, "Build an app to do this....."

If those assumptions are correct, both of the previous posts are good descriptions, but I would add:

First, talk to the people who want the app. Find out as specifically as you can what they want the app to do, and how they want to interact with it. You can start with the assumption that they are pathological liars, because by the time you finish, you will be suspecting that anyways. This is how you "determine the specs". From this, you can create a spec document, which is basically a reasonably detailed description of what the program should do, and how it should do it. If it bore any relationship to what people actually wanted, it would allow you to decide how to set up the data storage, and how to create the interface to most efficiently and effectively meet the users desires. Unfortunately, the user would mostly prefer a program that does everything correctly without requiring them to even be conscious, let alone sober.

Therefore, while it is good to get as much information about the task as possible before starting any actual coding, you should keep in mind that anything you learned is subject to change. If the program is anything more complicated than a single button, you can be certain that it will be too complex for half of the users to be able to either understand, or use correctly. Therefore, your design should be developed to gracefully handle completely irrational situations. If the situation is completely irrational, you will simply have to inform the user of their error, and prevent them from doing further damage. This could involve a politely worded message, a sarcasticly worded message, or, in extreme cases, castration.

Also, if the project is in any way non-trivial, you will spend a fair amount of time on the project, and put a fair amount of thought into it. Be assured, nobody cares! The user interface IS the program as far as the end user is concerned. Nobody cares whether you had some kind of clever binary manipulation to get that data onto the screen. If it is there, great. For example, I wrote a DB front end for simplifying data entry on a laptop. I was called about a problem with the program. After discussing the matter for a few minutes, I realized that the person had the program on one computer, and the database on a different computer (which was turned off and stored in a closet), and couldn't figure out why the queries weren't showing anything.

The user ONLY sees the interface, and they want it dead simple, but not too simple. That's why the next step will be sales/training. Since the user wants an intuitive interface, anything you produce may be too complex for them. If your program deals with weather forecasting, the answer '42' may seem to be too simple an output, but for most users, that's at LEAST one digit too many. That's why you need to do some training. The user is a timid beast. If you were to simply put a program on a computer in front of them, they are likely to stampede blindly until they either run out of energy, run into a wall, or fall off a cliff. Effective management alone would take hours to round them up if this happens, so you need to be able to gently persuade them that the program will work (sales), and show them how (training).

Keep in mind, though, that this is a delicate time for the end user. They are nervous about new things, and anything startling is liable to cause them to flee in panic. This is why you need to test THOROUGHLY before deployment. A bug is a VERY traumatic thing to the end user. Seeing just one may not be enough to cause them to flee, but it will put them into a state of nervous tension where another bug, or even an errant mouse click, could send them into a blind sprint.

Also, you probably should avoid doing the training yourself if you can avoid it. After all, the sentence for murder in most countries is severe enough that it would look fairly bad on a resume. Getting an actual user to show others how to use the app will save you considerable stress. It may not be enough, though. When you have put effort, thought, time, and creativity into this work of art, hearing somebody say "then you hit this thingy here." may be more than you can take for any length of time. Therefore, my final bit of advice is that you should distance yourself from the training process. Tahiti, whiskey, or tranquilizers are usually sufficient, though in some cases you will want to mix all three.

Ok, I realize that a bit of this was tongue in cheek, but I think everybody who has ever written an app for another person can relate to pretty much every piece of it. You will too.

[vincentg]

Hmmm making business application requiers also knowledge in programming and as well as the business part...

Try studing Sales and Inventory first
Then Accounts Receivable..
then Accounts Payable...
Payroll...
Tax System..
Accounting Process

Just take it one step at a time....
so...its worthy when you knew it...


Combination of programming and business knowledge!

-vince

[Hack]

Hmmm making business application requiers also knowledge in programming and as well as the business part...

Not necessarily. I've working in the insurance industry, manufacturing, advertising, casino industry, the banking industry, the utilities industry and those are only the ones the immediately come to mind.

I don't know squat about the business aspect of any of them, but I always worked with a business analysist that did, and could translate the business language into programmer specs that I could understand.

In the ideal world, you would know both, but that would almost require you to be a full time employee at a company. If you ever do any free lance contracting, you will find yourself in work environments that you know absolutely nothing about.

[Tommy_M]

Hi again,

Thanks for the great response!

To answer your questions:

What business do you want to develop the application for?

The type of business is variable, ill want to start doing programming for people from www.rentacoder.com, mainly starting off in Visual Basic/VB.NET moving to C++/C#.

I would want to program anything from a Database to a network app.

Thanks Again