Where to start?

[Mark Salsbery]

John Simmons / outlaw programmer wrote:

To hell with documentation - write the code and then create a document that describes it.

Yeah! Spoken (written) like a true outlaw programmer. It's called run-n-gun programming around here! Saves all thos documentation re-writes. Mark

[Mark Salsbery]

Luis Alonso Ramos wrote:

Sometimes it is easy to forget that users will actually use your software.

Grow up. Users are the sales departments problem. Programmers would never get anything done if they had to worry about users! ;)

[Pete OHanlon]

Get a dictaphone, and talk through the requirements. Seriously, verbalising the requirements is a good way to get a feel for things and to identify possible problems early on. You don't have anybody to bounce ideas off, so the dictaphone is going to be your best friend. Whatever you do, don't jump in at the deep end and start database or object modelling. As Marc has suggested, get your ideas into some semblance of order (storyboarding) and go from there. Make sure that you understand the problem before you even think about the design. Once you think you have your ideas in place, I would do a walkthrough with the users to see that you have thought of everything, and check that the user requirements are accurate. You'd be surprised how often the requirements are incomplete/wrong/full of assumptions. Talking the users through it, and getting them on board from the start is the best way to keep them on your side. If possible, at some stage, you will want to mock up some screens that the users can play with. Here's a piece of advice that you don't get at Uni, make some deliberate screen mistakes or put something on the screen in a really awful position. Get the users to "suggest" areas for improvement and act surprised/grateful for them. Believe me, that buy in gets you some serious brownie points from your users, and makes them feel part of the process. This has never failed us.

Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.

[realJSOP]

:) Start by itemizing the requirements. After that, describe how you plan on implementing each requirement as if that was the only requirement in the program. As you go, you'll see holes in your approach, and making notes about how to tie it altogether. Finally detail how you plan to tie it all together. The more detailed you get, the more likely it is that you'll be able to spot problems in your design before you start writing code.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

[Fernando A Gomez F]

Well, thank you everybody for your suggestions, you've been very kind. I took note of all your comments, and I think it is clearer now. :)

A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site

[Chris S Kaiser]

Which tools do you use for modelling?

What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder

[PICguy]

You have competition. Look at what your competitor has done. Talk with their existing users if you can. Solve problems that your competitor has not solved. Prepare a sales speech for your device. Sell it to your potential customers. You may not be the one to give the speech, but preparing the speech will help you put the various components in order. Rework the sales speech into a software design review. (But NOT the all too common “we are all done so let’s have a design review” review.) Your team can now start detail design and you can put the sales speech / design review preparation into whatever kind of spec your bosses desire. Write as much of the user docs as you can before the applicable code is written. Or better, have your software team write user docs before they are allowed to write the corresponding code.

[Behzad Sedighzadeh]

At first i recommend perfectly read what users want i.e. List of requirements. Then start analysis i.e. think about gui,user's input and basic classes. at the same time think about database. with it i mean you should do them in parallel.With database design you should consider operation environment entities such as customer,food,orders etc. With this approach you would have a good perspective of both your final application and users' needs. The classes should reflect two aspects of the programs i.e. you should now know a bit about classes that hold responsibilities and classes that hold data. Now start design.you should use iteration approach.Iterate through user's requirements,Database and classes.complete class you had built and redesign them if necessary. I emphasize on iteration.each time refer to your requirement list and check if your on the right way and your design fulfill user's requirement. Of course there are some other considerations such as performance,user friendly forms,security etc. I also recommend you reading some good references for uml: 1. UML explained by Kendall Scott 2. Applying Use Cases: A Practical Guide by Geri Schneider, Jason P. Winters 3. Robert Martin 's articles on UML.they are free.Google them. and design and analysis: 1.Software reuse by Jacobson 2.object-oriented analysis and design using uml by Bennett et al. BTW,Programming is Thinking.You should always see,read,listen and Think.That's all. Best Regards Behzad behzad

[grava]

Looking at the answers given, it's the definitive answer to problems like this, there's no written solution, everyone starts with the more interested domain (DB detailed design, UML use cases, requirements documentation). Well, in a theoretical world where everything goes right, if you have no problems concerning time, team and budget (I don't think this case is ever possible even in big firms), well start with RUP or start with XP. My advice (PERSONAL) is to start with analyzing requirements, dividing them into smaller one, start to think to possible solutions, and produce some paper and ink concepts about your idea. After that start to analyze one by one those smaller requirements and write detailed use case, defining as well as possible actors, those will be your domain, keep in mind, modeling well your domain is a first step to the success. Good luck with your job ! :-D Grava

[Guy Shefer]

great discussion topic. the general path is requirements=>use cases=>input/output=>general design of data/objects. then specific module design according to requirements. in other words, a big "ditto" on what everyone said, but put together. p.s. does that mean there are cartesian bears roaming around somewhere?

sincerely Guy Shefer, IL

[Stan Klimoff]

I start by analyzing the requitements and writing out all the entities I come across. Then I draw the diagrams that represents the relationships between those entities. After that I'm looking on what to simplify and what to generalize; trying to find patterns that can be made external. After that work is done, I'm diving back into requirements and prove that my concept solves the problems decribed. That concept than gets a status of "buzzy-design-document-level-one" and used as a big picture for the development stage.

[Nitron]

Fernando A. Gomez F. wrote:

It's a system for managing restaurants.

Do you have sufficient domain knowledge? i.e., do you know how to run a restaurant, or is that what you do now? If not, I suggest getting your hands dirty in the restaurant first and learning how they do things. Take notes and pay close attention to the logistics, i.e. how the server takes an order, how that order is processed, inventory management, prep work, etc. Once you identify the inefficiencies in the current system, then address those with your software. On a personal note, the last thing I would want is someone coming in with a software suite that doesn't have a clue how I work. Story boards and use cases will flow from this, then you can start designing. IMO, the last thing you want to be doing is coding the final system; make some prototypes and subsystems first.

~Nitron.

---

ññòòïðïðB A
start

[Dfygrvty]

First off - How much time do you think you have for the project? that is a loaded question, but true. To me, it sounds like you have time. Also, this is the first time your superiors gave you free reign, so get them a document they can read and feel like they were 'right' in letting you go on your own. Just because they like what they read doesn't mean it helps you code. Make a second document that fits your brain perfectly. this second document can be considered "for your eyes only." Other people of course can read it, but this second document does not have to make sense to them. Send them to the first document if they complain. Spend an hour a week updating both as you go, at least.

Learn to Fly

[Dfygrvty]

First off - How much time do you think you have for the project? that is a loaded question, but true. To me, it sounds like you have time. Also, this is the first time your superiors gave you free reign, so get them a document they can read and feel like they were 'right' in letting you go on your own. Just because they like what they read doesn't mean it helps you code. Make a second document that fits your brain perfectly. this second document can be considered "for your eyes only." Other people of course can read it, but this second document does not have to make sense to them. Send them to the first document if they complain. Spend an hour a week updating both as you go, at least. ~D

Learn to Fly

[JLengi]

Strongly agree with the importance of the database design. Perhaps even more important would be exchange formats (e.g., XML export/import). Once you put them out there, people use them. And those data files live forever, so you'll be stuck supporting those data formats forever. But you should start at a much higher level. For a large/scalable/complex system, I think you should start with what I call a host-process architecture. How many concurrent threads of execution are required by the system, and where do they run? Figure out the general responsibilities of each host and process, and try to assign responsibilities in such a way that the interfaces are as small as possible. This might be pretty simple, but there are still a lot of important questions to answer. How many system tiers are required? Are app servers required? Is some kind of system management/monitoring service required? How thick/thin will the clients be? Are intermediate data caches necessary or desirable? Then work on the more detailed design of each of the interoperating pieces. For large or complex systems, agile processes need to extend beyond code. Requirements analysis and design can also be done iteratively. I'm not saying that an exhaustive requirements analysis must be complete prior to starting design or that a detailed design must be completed prior to starting implementation, but requirements analysis should be more advanced than the design, and the design should be more advanced than the code, but all can be going on concurrently. The rationale is that it's much easier to refactor requirements than design and to refactor design than code. This also allows what you learn in implementation to feed back into the ongoing design, etc. Targeted prototypes can be used to mitigate risks.

[nicknotyet]

Check out the competing product. Find out what they do well and copy it. Find out what they don't do well and do it better. Define your feature set and use cases before you even begin to worry about technical design. Most importantly, find another human being to collaborate with even if its just your significant other listening to you spew every night. The mental process of articulating the problem is invaluable.

[jhoga]

That's very good advice. I have had to rewrite applications in the past, because I did not full understand the business processes I was automating.

[mfhobbs]

Don't start with any database. Don't start with any functioning code. Don't start with any modeling tool as you don't have a model. Ignore all the latest buzzwords and industry 'trends' for now. - Instead, start with some dummy (prototype) semi-functioning screens (at least so that a button click opens up the next screen). - Show the prototype to your bosses and they can decide whether the workflow is correct and get them thinking about business requirements! - Accept the new business requirements document from your bosses graciously. - Only once you are happy that all workflow is specified up-front, only then you write your tech doc (for approval), schedule your project, and worry about your language and persistence choices. Now you have a baseline to write to. - Choose at random and incorporate two of the latest buzzwords/trends 'technologies' to keep your bosses happy and encourage continued pay increases. - Have fun.:)

[Lost User]

Sell the laptop and buy a grocery store or a Subway franchise. Jaryd lost weight through aids.

computers are for dicks

[micmanos]

This is a big trap for a single reason. Because you can't fully design an application in paper. This is not good or bad, it's just how things are. The reasons however may vary. 1. You're not a good programmer or profficient enough in the selected language/technology. 2. You have too little experience over the particular type of application. 3. You find a glitch/bug in the language/toolware/middlewear you use. 4. Things just don't work as you have planned them in your mind. 5. During development you discover (from codeproject :laugh:) another way much better and faster. 6. You discover a severe security risk in your design nearly after completion of the code. 7. ...... a bunch of more reasons that now can't think of. As for the database issue posted by the others, i agree. It's of the outmost significance, to have made the db long before you write code because whether you like it or not, the structure of data accuratelly reflects the way the program and the user will have to work. A complex (meanning badly designed) database will enforce a complex program and GUI/user experience. Designing a DB though (and hitting the bullseye with the first try) is almost impossible even for the most experienced programmers and developers. My suggestion as i too deal with this problems is .. 1. Resist the urge to sit down and write endless UMLs, papers, ... etc. 2. Resist the urge to take the keyboard and start writting tons of code. 3. FIRST and most importand, break your application into 5..10 parts that can be worked with as little prequisitions as possible. 4. Draw lines connecting each part but make sure that there is NO circular links for ex. Part A uses part B, Part B uses part C and Part C uses part A. In simpler terms, make the design look like a tree and not like a closed loop. ----- GOOD, Now do the followings. 1. Don't pick the childs (parts with no other parts beneath them). 2. Pick the first parent that has as little childs (at least 1). 3. Develop it. 4. Move to the childs it has. 5. Develop it. 6. Test it (you have the parent already developed) 7. Repeat for all the childs of this parent. 8. Move to the next parent. It may sound a bit foggy and unclear :confused: all this but if you do that, it will get you working at no time :cool: and it will save you the time of revising / changing your design document at every little change and problem you encounter. It's very frustrating, believe me. X|