Enjoy the money laundering investigation, and say good bye to ever leaving your country again.
139 karma · joined July 30, 2010
I have taken three major groups: System, testing, support. Each of these will change the timeline and cost of the project. Support is an after-delivery agreement, they may want testing, or run into problems that I have the answer for. This is also the cost of producing the manual.
There is testing, I estimate this system should be tested over 5 days with different stresses.
The system is broken into hardware and software groups. Hardware expenses are quite obvious: networking, connecting devices, the server/machine it runs on. Your needs may be greater if you are in the hardware world, but all professional projects I'm involved in are software-based.
The software is broken into the OS configuration, tools related to the platform (like setting up Apache), and the application we are creating. The application will be composed of logic and storage.
The logic will require specific things such as a framework, a UI, system inputs, and debugging. The storage exists of either a DB design, a flat file design, and any reporting requirements.
I found it best to draw the above as a hierarchy. I then estimate time for each seperate component, and if there's something I don't know how to estimate I need to clear it up.
The difference? My "geek estimate" (as posted by frossie) was about two weeks, and after doing this above method, it actually is looking like 2 months and 2 weeks of time. I built the time requirements using a gantt chart.
You know, a funny joke? Haha?
WOOSH.
>Avoid both of those.
I'll keep it short and sweet. Family, religion, friendship ... these are the three demons you must slay if you wish to succeed in business.
Design your program from high-level and iterate through phases into low-level. So for instance, I want you to make a program that, lets say, is a customer database.
High level 0: I need a customer database
Level 1a: I have these storage requirements.
Level 1b: I need these inputs
Level 1c: I need data to exit the system in these ways.
Level 2: Diagram of work-flow processes (how it interacts with real people).
Level 3: Diagrams of how the database will look, identify what types of objects you will need to work with (of course, this specific action gears you into OOP design and not functional).
Level 4: Problems. Spend some time bad-mouthing everything and how it works, go back to level 2 and when you're tired of crying about the thing go onto the next level.
Level 5: Document how it works. This is your Manual.
Low Level 6: Write the code, and when you need guidance, RTFM.
Level 7: Throw the thing into the trash and start over, they wanted an inventory management system, another tribute to the synergistic perspicacity of business people and software engineering's verbal constipation.
If you have a reason to spend that money, and it better be a damn good one, , then spend it. None of this "to be a success I need a really bitchin desktop with 18 monitors and a new Joop Suit."
If I write my own code from scratch, but I'm using the library from Jquery, it's running on apache, it connects to mysql, it does whatever, that's fine I'm using that software as part of the box I wish to re-sell because I didn't modify and re-sell that software, I'm selling the configuration of the server and my code?
>DataTables is dual licensed under the GPL v2 license or a BSD (3-point) license.
Does this mean I pick one to use? I'm having a hard time accepting/realizing that there is one product with my choice in licences.
What REALLY bothers me is things like credit cards.
http://www.merriampark.com/anatomycc.htm
There's encoded data on something that's supposed to be a UUID thing: Industry, Issuer (card company), Lender (banking institution), Account number, and Checksum
This is a good way to prevent fraud? Or have they just given me the keys to generate "valid" credit cards?
http://www.darkcoding.net/credit-card-numbers/
Slap a name from the phonebook on there and see what you can purchase. Now we have PCI compliance trying to tell people to somehow lock this crap down? So they invent the CV2 codes, a 1 in 1000 hit-or-miss, I don't think my odds are too bad when I can generate any creditcard. Dates will also only fall into a specific range of time anyway. Yeah, we keep putting up bandages to creditcard security processing, but why do we need to? Honestly, the world of standards sucks.
Just look at the airline industry. IATA, ICAO, ISO, all competing and separate, all with insane and bat-shit psychotic rules and conventions (eg, IATA lets multiple airlines have the same "two letter designator" [by the way, it's sometimes three, but you never know for sure] if they operate on different parts of the globe and 'rarely if ever will confuse an operator'). When the hell did computers need human-understandable designation short-hand codes for things? What the hell was wrong with 1 - American Airlines, 2 - Air Canada, 3 - Delta, 4 - SAS, 5 - That small one that flys between A and B once a year you've never heard of. Why the HELL do we have a system that has "AA" and "AA*" ? This is basically the worst thing you can do for normalization of global data. Travel GDSs are even worse, they don't actually follow along with these standards because they cannot, so while you take your "AA" flight number 123456 (oh, by the way, we recycle flight numbers instead of archive forever historical tickets) from airport zzz to xxx (by the way, depending on the standard they came from, your airport might not even exist), which are actually city codes for airports, so when you're flying to a city with multiple airports you have two cities in the GDS just to deal with this.
We can't even agree on how to measure distance, it's like we're stuck in the stone ages. What the hell is wrong with measuring in kelvin degrees? Why do we have MORE THAN FIVE separate standards for systems of measurme for what most people think is one (the metric system)?
Fact: We do not live in 1950 or any time before then, computers don't give a flying rats ass if the letters make sense to you as a short-hand abbreviation, you should just number them. That's what databases are for, to relate data. Major airports alone have several names people call them anyway, some airlines go by a few names (for example, SAS airlines is actually "Scandinavian Airlines").
Fact: We do not need to encode data about the data into the primary key of our data. For example, we do not need to generate employee numbers like "Q100-5-TR-9" where Q is the building they work in, 100 is their pay grade, TR is their last name's first two letters, 9 is that number we introduced for separating all duplicates of Q100-5-TR. This is just stupid, stop this insanity NOW.
People working on global standards, you should be ashamed. Do you have ANY idea how much time is wasted because we do not have UUIDs for so many things, even something as simple as an airport? There's only 50,000~ of them, and we have duplicates? Did we run out of beads on the abacus??