How can I start?
Author
Hello,
My boss wants me to design a fairy basic Electronic Digital Automation tool for his business. The requirements is as follows:
1. Should include electronic digital symbols(for circuit board design)
2. Should be able to scale those symbols (like visio)
3. Should be able to auto-align those symbols.
4. Should include design grid (like MS visual studio's design view. it has grid layout so that designers know the exact poistion of the
control)
5. Should be able to validate the digital symbols that whether they can be joined together or not. If joining two digital symbols against the "LAW", then an error message or action shall be taken.
6. Programming in C++, tool: visual studio c++.net or 6.0
I am a computer science student. I dont have any clue on how to design such a program. If anyone knows, could you please let me know how can i start this project. or any open source/sample project or books/website/forums i can take a look as a reference. by the way, since i am pretty new in designning GUI applicaiton. Which programming language platform should i choose. .NET or C++, if its C++, I should use MFC or Win32?
By the way, I had experience on C#, but NOT quite familiar with MFC and Win32. The application I described above (if successful) will expand its scope to a more sophisticated area. So for long run, which language platform I should choose?
I am so frustrated b/c I am lack of skills on REAL application development.
Thank you
Richard
I'd personally suggest you use C# for this project. The .Net framework + Windows.Forms should save you a lot of trouble in making a gui application
Quote:I am a computer science student. I dont have any clue on how to design such a program. If anyone knows, could you please let me know how can i start this project. or any open source/sample project or books/website/forums i can take a look as a reference. by the way, since i am pretty new in designning GUI applicaiton.Google for model-view-controller. It's pretty much the baseline for how object-oriented GUI applications are designed.
how can you start? I just finished a course in Extreme programming, and must say that I prefer it over the waterfall model of software engineering.
I have to second the motion for C#. WinForms is precisely 314159 times better and easier than Win32 and MFC.
Okay, in the extreme programming methodology, you have "iterations". An iteration is a single cycle of developement, lasts only a few weeks (in your case let's say 3).
For each iteration, you will assign a "Project velocity" which is the total number of hours you will devote to coding on this project (just coding, this does not include research).
For each iteration, your customer (your boss) defines a set of "stories" which are distinct units of functionallity that should be implemented (your bullet points make a good set of stories).
You will make a guess as to how long you think each story will take, and assign that estimate to each story. Your customer will select stories with estimates that add up to your project velocity. If there are more stories than can be done given the project velocity, then it is up to the customer to decide which ones s/he wants done RIGHT NOW. Don't expand the project velocity to accomodate.
Don't worry about being wrong in your estimate, either. If you are wrong, because of the short length of time of each iteration, you can never end up weeks behind on the developement schedule.
Once the customer has selected the stories, you define "tasks" which are discrete steps that you will have to take in order to make the "story" become a reallity. Again, for each task, you make an estimate of time. don't try to make the tasks add up to the story estimate. Instead, adjust the story estimate to match the tasks. If, at this point, you are over or under your project velocity, renegotiate with the customer.
Then, START CODING THE TASKS. I suggest working on the GUI stuff first, so you have something to show the customer RIGHT AWAY. The application could take months to complete, but you COULD have something to show the customer within the first 3 weeks.
Again, your stories are:
There are some other aspects of extreme programming that I didn't go over, such as test driven developement and pair programming, but to me those are more of a matter of taste.
Remember, whatever you come up with as an estimate will PROBABLY BE WRONG. However, the XP process makes being wrong okay, because it never effects you more than a couple of days work. With traditional lifecycle, if things go wrong, you could wind up weeks, or even months behind. With XP, the concept of "on time" is constantly changing, because you are only concerned with completing the iteration. Once the next iteration starts, you wipe the slate clean and do the planning again. Any stories that you completed get removed from the board, any stories that you didn't stay, and new stories get put on the board. The customer then selects more stories for the next iteration. so, every 3 weeks, no matter how far behind you are, you automatically become "on time" again.
I have to second the motion for C#. WinForms is precisely 314159 times better and easier than Win32 and MFC.
Okay, in the extreme programming methodology, you have "iterations". An iteration is a single cycle of developement, lasts only a few weeks (in your case let's say 3).
For each iteration, you will assign a "Project velocity" which is the total number of hours you will devote to coding on this project (just coding, this does not include research).
For each iteration, your customer (your boss) defines a set of "stories" which are distinct units of functionallity that should be implemented (your bullet points make a good set of stories).
You will make a guess as to how long you think each story will take, and assign that estimate to each story. Your customer will select stories with estimates that add up to your project velocity. If there are more stories than can be done given the project velocity, then it is up to the customer to decide which ones s/he wants done RIGHT NOW. Don't expand the project velocity to accomodate.
Don't worry about being wrong in your estimate, either. If you are wrong, because of the short length of time of each iteration, you can never end up weeks behind on the developement schedule.
Once the customer has selected the stories, you define "tasks" which are discrete steps that you will have to take in order to make the "story" become a reallity. Again, for each task, you make an estimate of time. don't try to make the tasks add up to the story estimate. Instead, adjust the story estimate to match the tasks. If, at this point, you are over or under your project velocity, renegotiate with the customer.
Then, START CODING THE TASKS. I suggest working on the GUI stuff first, so you have something to show the customer RIGHT AWAY. The application could take months to complete, but you COULD have something to show the customer within the first 3 weeks.
Again, your stories are:
Quote:Original post by Foeyshell
1. Should include electronic digital symbols(for circuit board design)
2. Should be able to scale those symbols (like visio)
3. Should be able to auto-align those symbols.
4. Should include design grid (like MS visual studio's design view. it has grid layout so that designers know the exact poistion of the
control)
5. Should be able to validate the digital symbols that whether they can be joined together or not. If joining two digital symbols against the "LAW", then an error message or action shall be taken.
There are some other aspects of extreme programming that I didn't go over, such as test driven developement and pair programming, but to me those are more of a matter of taste.
Remember, whatever you come up with as an estimate will PROBABLY BE WRONG. However, the XP process makes being wrong okay, because it never effects you more than a couple of days work. With traditional lifecycle, if things go wrong, you could wind up weeks, or even months behind. With XP, the concept of "on time" is constantly changing, because you are only concerned with completing the iteration. Once the next iteration starts, you wipe the slate clean and do the planning again. Any stories that you completed get removed from the board, any stories that you didn't stay, and new stories get put on the board. The customer then selects more stories for the next iteration. so, every 3 weeks, no matter how far behind you are, you automatically become "on time" again.
Extreme Programming has always struck me as more of a cult doctrine than a rational methodology. When I hear "it's okay to be wrong" in conjunction with engineering (software) practice, I get very afraid. Very.
Iterative software development predates XP. It's taught in every software engineering course in every computer science program in pretty much the world. XP is just a bunch of embellishments for people who are not meticuluous. "Project velocity"? We call those projections of how much programming resource will be devoted to the project. "Stories"? Sounds like milestones to me. "Tasks" have always been called tasks.
Excuse me while I sneeze. I'm allergic to bullshit.
Requirement 5 is a little more interesting. It says that you need to model the properties of each component and then perform a simulation of its operation. The best way to do this is to model each component at input and output, and have connections serve strictly to pass the output from the previous component to the input of the next one. This allows you to validate each component individually/independently, making program operation much more efficient. The logical time to perform this validation is when a component is added to the grid and all its inputs connected.
Based on the above elaborations, you should be able to lay out algorithms (simple step sequences) that define the fulfillment of each requirement, and a "Super Algorithm" that defines when each of these algorithms runs within the context of the application as a whole.
Oh, yeah. Requirement 6 says you stick with MSVC++, but the option to use .NET means that you can still take advantage of Windows.Forms and the superior designer, which I heartily recommend.
Get busy!
Iterative software development predates XP. It's taught in every software engineering course in every computer science program in pretty much the world. XP is just a bunch of embellishments for people who are not meticuluous. "Project velocity"? We call those projections of how much programming resource will be devoted to the project. "Stories"? Sounds like milestones to me. "Tasks" have always been called tasks.
Excuse me while I sneeze. I'm allergic to bullshit.
Quote:Original post by FoeyshellRequirement 1 says that you need to have a symbol palette from which the application user can drag and drop icons onto the gridded workspace (requirement 4). Requirement 2 says that it's best to implement the icons using vector drawing, so that they scale seamlessly. Requirement 3 says that each icon should have a means of specifying "connection points", and that the application should be able to align series of connected components.
1. Should include electronic digital symbols(for circuit board design)
2. Should be able to scale those symbols (like visio)
3. Should be able to auto-align those symbols.
4. Should include design grid (like MS visual studio's design view. it has grid layout so that designers know the exact poistion of the
control)
5. Should be able to validate the digital symbols that whether they can be joined together or not. If joining two digital symbols against the "LAW", then an error message or action shall be taken.
6. Programming in C++, tool: visual studio c++.net or 6.0
Requirement 5 is a little more interesting. It says that you need to model the properties of each component and then perform a simulation of its operation. The best way to do this is to model each component at input and output, and have connections serve strictly to pass the output from the previous component to the input of the next one. This allows you to validate each component individually/independently, making program operation much more efficient. The logical time to perform this validation is when a component is added to the grid and all its inputs connected.
Based on the above elaborations, you should be able to lay out algorithms (simple step sequences) that define the fulfillment of each requirement, and a "Super Algorithm" that defines when each of these algorithms runs within the context of the application as a whole.
Oh, yeah. Requirement 6 says you stick with MSVC++, but the option to use .NET means that you can still take advantage of Windows.Forms and the superior designer, which I heartily recommend.
Get busy!
Since your task is to design the tool, I don’t think you should get bogged down in choosing any development language yet.
At this stage I would ask "What exists already?"
A Google search turned up this:-
http://ceu.fi.udc.es/SAL/Z/1/index.shtml
which seems to offer a good start.
I’d suggest downloading a few of these, some with source code, and learn how others do what you want, then pick the best (or nearest to what your boss wants) and go from there.
No need to re-invent the wheel (unless your boss is paying you by the hour, of course!)
At this stage I would ask "What exists already?"
A Google search turned up this:-
http://ceu.fi.udc.es/SAL/Z/1/index.shtml
which seems to offer a good start.
I’d suggest downloading a few of these, some with source code, and learn how others do what you want, then pick the best (or nearest to what your boss wants) and go from there.
No need to re-invent the wheel (unless your boss is paying you by the hour, of course!)
Quote:Original post by Oluseyi
Extreme Programming has always struck me as more of a cult doctrine than a rational methodology. When I hear "it's okay to be wrong" in conjunction with engineering (software) practice, I get very afraid. Very.
Please, and you can know how something is really going to be implemented until you start implementing it? Or, you know how someone else is going to implement your class diagrams? Creating Use-Case diagrams and Class diagrams may be pretty things that the customer can look at, but what actual use are they? Creating a class diagram without considering the implementation of that class is meaningless, you end up rewriting the class diagram when it doesn't match the code you wrote.
I agree that XP is not perfect, for example I can't stand pair programming, I think it's more detrimental than good, first you are wasting half of your developement time, and second the so called bidirectional "communication" that is supposed to take place between the developers doesn't really happen if there is a large disparity in skill between the developers.
Test Driven Developement, at first I thought was bass akwards. Then I went through "the process" and reallized that TDD is bass akwards. TDD is just as bad, if not worse, than class diagramming. How can you test for an unknown? You just end up wasting half of your developement time, again, writing code before you ever write the real code. You write the tests, then try to write code to make the tests pass, and then rewrite the tests to fit around the code. Stupid, stupid. Testing AFTER the fact is much better, to prove that your code does what it says it will do.
Plus, the iterative nature delays consideration of features until they are absolutely necessary, and of course, nearly impossible to integrate into the current code base.
I guess I'm saying, XP and traditional lifecycle are equal pie slices of suck, just from different suck pies.
Quote:
Iterative software development predates XP. It's taught in every software engineering course in every computer science program in pretty much the world. XP is just a bunch of embellishments for people who are not meticuluous. "Project velocity"? We call those projections of how much programming resource will be devoted to the project. "Stories"? Sounds like milestones to me. "Tasks" have always been called tasks.
True, true, and true, but the difference is that the customer gets to select the stories that get implemented. If, between feature A, B, and C, the customer really wants feature A, but it will take as long as B and C combined, and there is only time for A or B and C, then the decision is left to the customer so that they get what they want.
Quote:
Excuse me while I sneeze. I'm allergic to bullshit.
I really don't understand why you makes statements like this...
Could fork Dia - the GPL half-assed copy of Visio. Its already got many of the features you describe.
Of course, then your product would be GPL, I think. Pretty sure Dia is GPL. Still, its possible to sell GPL products for cash - to an end user, it might be more trouble than its worth to hack together a free reimplementation using your source and custom grapics libraries.
Of course, then your product would be GPL, I think. Pretty sure Dia is GPL. Still, its possible to sell GPL products for cash - to an end user, it might be more trouble than its worth to hack together a free reimplementation using your source and custom grapics libraries.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
