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
To hell with documentation - write the code and then create a document that describes it.
"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 -
To hell with documentation - write the code and then create a document that describes it.
"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 -
To hell with documentation - write the code and then create a document that describes it.
"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/2001John Simmons / outlaw programmer wrote:
write the code and then create a document that describes it.
That's why God invented doxygen! :->
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
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
Fernando A. Gomez F. wrote:
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?
Start with storyboarding the UI and user interactions. On paper. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
To hell with documentation - write the code and then create a document that describes it.
"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:-D:-D:-D I'm really tempted to do so. However, the customer is requiring full documentation of everything :( and so my bosses.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
Fernando A. Gomez F. wrote:
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?
Start with storyboarding the UI and user interactions. On paper. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
On paper.
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
To hell with documentation - write the code and then create a document that describes it.
"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/2001Well for me the time requirement usually prohibits me from ever spending any effort on documentation or planning so I usually start a new project by 5 to 10 consecutive days where I write 1000 or more lines of new code each day. From there I discover what problems need further looking into and what optimizations need to be made. Then in a few weeks a prototype is made and a demo is given then new requirements are given to me and I spend time working on the changed specifications. Then debugging starts...
John
-
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 would start by extracting out in as few words as possible, in point format, all the TASKS that the users want to accomplish, then look for parallels between them and try to compact it into as few tasks as possible. The game is to find ways to accomplish all the needs of the users in as few tasks as possible. Once that point was reached I would mock up a UI on paper considering different ways to fulfil the uers needs to accomplish those tasks in as few steps as possible. I.E. "How can I get the user from starting the program to accomplishing the task in as few steps as possible?" Rework that over and over until you have the smallest possible user interface that accomplishes the tasks the users need to as simply as possible. Make that into a mock up of some kind you can present back to the users so they can see the flow of the different tasks being accomplished and get their approval on it. Then sit down and extract out all the business objects you will need to accomplish those tasks. Do not touch a database at this point or think at all about the data itself, only in the sense of abstract business objects required. When you've whittled it down to as few business objects as possible, only then think about the data required and at that point you're pretty much ready to start coding. The worst possible mistake is to take an initial set of requirements and start making a database for them, this is why a code generation tool that works off a database schema makes such crappy software and why it should be avoided at all costs. Users don't think in terms of data, they think in terms of tasks, jobs they need to get done as quickly and easily as possible. Programmers often think of data first and that will limit them to writing software usable only by other programmers. What you get when you design by user task is a program that the user finds easy to use, intuitive and you will find much easier to maintain. It breaks you away from thinking like a programmer and producing a bloated hard to use program that has a UI tied way too tightly to the technical underpinnings of the system and instead an elegant UI tied to the way the user is already thinking.
-
Marc Clifton wrote:
On paper.
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
but I thought you were a Visio buff.
Well, I am, once I've got a plan in mind. I often find it easier to do initial design work on paper, especially UI storyboarding.
Jeremy Falcon wrote:
this does leave me wondering if it's really good for anything outside of code generation.
I actually don't use Visio for code generation. :) Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
There seems to be quite a few of those. I actually submitted my resume a while back to a similar company. Never heard from them. If you have the user requirements, come up with a couple of test scenarios to see how the system will work and create a couple of use cases for that. Seems to me that the number of use cases for that is pretty simple, even though the number of input and output parameters probably isn't.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." - George Bernard Shaw Web - Blog - RSS - Math - LinkedIn - BM
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
-
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
Although you are to create a system from scratch, this is not always the best way forward for any organisation as it can become very disruptive, and this disruption doesn't get better should the company think that abruptly ending one system and starting a new one is the way forward. You have the requirements for this user. Even though you are to create a system from scratch, do your user requirements show any inheritance or dependency from any pre-existing system, if yes, consider starting from that viewpoint. Then establish use cases that encompasses the existing system (as an actor) and establish from user requirements the other actors. From that point you should have a general overview of the system to develop after which you can consider the verbs and nouns found in the user requirements from which you might be able to create proposed classes and sub-classes. Everything said above can be done either using a pen/pencil + paper or using a UML diagramming tool such as StarUML. Take your time, don't rush else errors and mistakes are guaranteed will happen.
-
I would start by extracting out in as few words as possible, in point format, all the TASKS that the users want to accomplish, then look for parallels between them and try to compact it into as few tasks as possible. The game is to find ways to accomplish all the needs of the users in as few tasks as possible. Once that point was reached I would mock up a UI on paper considering different ways to fulfil the uers needs to accomplish those tasks in as few steps as possible. I.E. "How can I get the user from starting the program to accomplishing the task in as few steps as possible?" Rework that over and over until you have the smallest possible user interface that accomplishes the tasks the users need to as simply as possible. Make that into a mock up of some kind you can present back to the users so they can see the flow of the different tasks being accomplished and get their approval on it. Then sit down and extract out all the business objects you will need to accomplish those tasks. Do not touch a database at this point or think at all about the data itself, only in the sense of abstract business objects required. When you've whittled it down to as few business objects as possible, only then think about the data required and at that point you're pretty much ready to start coding. The worst possible mistake is to take an initial set of requirements and start making a database for them, this is why a code generation tool that works off a database schema makes such crappy software and why it should be avoided at all costs. Users don't think in terms of data, they think in terms of tasks, jobs they need to get done as quickly and easily as possible. Programmers often think of data first and that will limit them to writing software usable only by other programmers. What you get when you design by user task is a program that the user finds easy to use, intuitive and you will find much easier to maintain. It breaks you away from thinking like a programmer and producing a bloated hard to use program that has a UI tied way too tightly to the technical underpinnings of the system and instead an elegant UI tied to the way the user is already thinking.
John Cardinal wrote:
Programmers often think of data first and that will limit them to writing software usable only by other programmers.
Boy, howdy, is that ever true. And even there, "usable" is being kind - you might just find the programmers writing SQL instead of using your interface...
-
Marc Clifton wrote:
On paper.
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
Jeremy Falcon wrote:
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Visio tends to suck the enjoyment out of the early design phase. A pencil and paper are still the best tool for thrashing out thoughts and ideas. Visio is very useful when you want to start formalising the design.
Michael CP Blog [^] Development Blog [^]
-
I would start by extracting out in as few words as possible, in point format, all the TASKS that the users want to accomplish, then look for parallels between them and try to compact it into as few tasks as possible. The game is to find ways to accomplish all the needs of the users in as few tasks as possible. Once that point was reached I would mock up a UI on paper considering different ways to fulfil the uers needs to accomplish those tasks in as few steps as possible. I.E. "How can I get the user from starting the program to accomplishing the task in as few steps as possible?" Rework that over and over until you have the smallest possible user interface that accomplishes the tasks the users need to as simply as possible. Make that into a mock up of some kind you can present back to the users so they can see the flow of the different tasks being accomplished and get their approval on it. Then sit down and extract out all the business objects you will need to accomplish those tasks. Do not touch a database at this point or think at all about the data itself, only in the sense of abstract business objects required. When you've whittled it down to as few business objects as possible, only then think about the data required and at that point you're pretty much ready to start coding. The worst possible mistake is to take an initial set of requirements and start making a database for them, this is why a code generation tool that works off a database schema makes such crappy software and why it should be avoided at all costs. Users don't think in terms of data, they think in terms of tasks, jobs they need to get done as quickly and easily as possible. Programmers often think of data first and that will limit them to writing software usable only by other programmers. What you get when you design by user task is a program that the user finds easy to use, intuitive and you will find much easier to maintain. It breaks you away from thinking like a programmer and producing a bloated hard to use program that has a UI tied way too tightly to the technical underpinnings of the system and instead an elegant UI tied to the way the user is already thinking.
:applause: (what? no applause emoticon?) Sometimes it is easy to forget that users will actually use your software. You have to take their point of view every step of development. Great post, my 5! :cool:
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Jeremy Falcon wrote:
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Visio tends to suck the enjoyment out of the early design phase. A pencil and paper are still the best tool for thrashing out thoughts and ideas. Visio is very useful when you want to start formalising the design.
Michael CP Blog [^] Development Blog [^]
-
Jeremy Falcon wrote:
I have to admit I'm surprised you say this. Not that I disagree, but I thought you were a Visio buff. Seeing that I've never used Visio (I'd rather put my money in a diff dev tool), this does leave me wondering if it's really good for anything outside of code generation.
Visio tends to suck the enjoyment out of the early design phase. A pencil and paper are still the best tool for thrashing out thoughts and ideas. Visio is very useful when you want to start formalising the design.
Michael CP Blog [^] Development Blog [^]
Michael P Butler wrote:
Visio tends to suck the enjoyment out of the early design phase.
I'll have to keep that in mind. :laugh:
Jeremy Falcon "It's a good thing to do and a tasty way to do it." - Wilford Brimley[^]
-
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'd disappear down to the pub and wait for the reorganisation:-D It sounds like you're living the Dilbert life.
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.
-
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
Write the user manual first, with screenshots (mockups). This can be shown to the end user to confirm what he asked for, and it can be understood by management.
-
To hell with documentation - write the code and then create a document that describes it.
"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/2001John 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
-
:applause: (what? no applause emoticon?) Sometimes it is easy to forget that users will actually use your software. You have to take their point of view every step of development. Great post, my 5! :cool:
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
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! ;)
