Where to start?
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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.
-
A competitor for this[^] software. It's a system for managing restaurants. :)
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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 -
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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
-
I'm doing something similar... and it can be quite complex. I would recommend for you to: 1. fully understand the user requirements 2. design the input-output part (know what you're expecting from your users and what are they expecting from you) 3. sit down and draw, sketch a couple of designs with others... until you refine it to your needs. I would say that the database part would be the most important because if you design it the wrong way you have to make structural changes later... which could prove to be one of the hardest things. Also seek for help from others that did something similar or check out similar software's. It's pretty hard to design something if you haven't done that before.
company, work and everything else www.netis.ro
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.
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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.
-
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 -
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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.:)
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
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|
-
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.:)
If non-IT related people are involved in the decision proccess or in supervision (sadly that's mostly the case) then i have to admit that you do have a point ... :laugh: Otherwise i believe it's a waste of time. I am currently working under this very situation and i've chosen to skip the prototyping part completelly and only meet with them to discuss the functionality / operation part of the software. This is mostly because of time pressure.
-
Hello fellows. Last week, the company I'm working on finally decided to create a new system from scratch. However, because of compromises with other projects, I've been left alone to design this new system. The bosses told me to start today (I already have the user's requirements for the application). So here I am, sitting at my laptop. And I have no clue where to start. Shall I start making UML diagrams, or should I start by making a document with the specification? What would be your advise? Where to start? Thanks for your comments. [EDIT] Uh, by the way, hope this is not taken as a programming question :~ [/EDIT]
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
Middle Out has always worked for me - the middle being defined as that part of the system that you least understand, whiteboard it, prototype it, breadboard it whatever - but most of all talk about it, especially to yourself and others if there are any. A common characteristic with most (DIS all) formal methods is that there's a tendency to become emotionally attached to their form, even thoogh the substance therein maybe rubbish. Try to get a whiteboard that you can plug it to your laptop, or at least one whith a print feature - you might be able to lease one for a coupla months if you cant commandeer one internally. good luck