Jeff a écrit : > Thanks for the quick responses. > > I was really hoping to avoid an entirely web-based app, for a few > reasons, not the least of which is that I've been working almost > entirely on web apps for the past few years, and I am getting mighty > sick of it. A lot of that is due to the language (PHP, which I have > since grown to hate) I had to use. I've worked on a site for my self > in Python (using Pylons, actually--which is excellent) which was > vastly easier and more fun. But I'd really like to try something > different. > > Now, of course, that's not enough reason to force such a thing onto my > clients (when I say clients, I mean the ones that are paying for this, > but they're really within my same department, so they actually have > working technical knowledge.) Some reasons for them would be (in no > particular order): 1) More responsive and user-friendly interfaces,
You could explore something like a custom-made GUI client app communicating thru the http protocol with a web-server app. http is just a protocol, and it doesn't necessarily imply using html and a browser... IIRC, some GUI toolkits uses XML description files for the UI. (snip) > 3) Easier to "lock down" who's using the program by only > installing it on certain machines. Not a very reliable security scheme IMHO !-) (snip) > Which leads me to the discussion of planning: (snip) > This system will be used, often, to figure out how much people should > be paid (and then interface directly with the University's payroll > system), and store lovely things like SSNs, and will also have to have > somewhat crazy business logic to track when hourly workers are > eligible for raises, if they took enough training classes, etc. There > are a lot of people with a stake in this system, and I will need to > work with them very closely on how this should work, and they sure as > hell don't want any surprises. My manager even wants use cases (if > you've never had to deal with use cases, consider yourself a lucky, > lucky person) which I am going to attempt to argue as that is even > going *too* far. > > So, long story short (too late), no Extreme Programming for me. Extreme Programming doesn't mean "no preparation", and makes heavy use of use cases. Of course you need to have some - hopefully accurate - functional specs. The point was mostly along the lines of "don't try to have full-featured detailed design before you start coding, because chances are it will be wrong". > Hopefully, the amount of planning will be somewhere in between that > and the bureaucratic nightmare of documenting up front what each > module, class and function will do. Which would be totally non-sensical. I don't believe anyone on earth could come up with such a thing - done right - *before* the application is written. -- http://mail.python.org/mailman/listinfo/python-list
