Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
This forum is in permanent archive mode. Our new active community can be found here.
IT Project Management
I've been doing some ready lately on how to manage a Software design project. From the top level not from the version control level. One of the biggest mistakes alleged by some of the documents I've been reading is that Software developers and their clients tend to get together and only address the needs of the client and are ignorant of the desires of the client's customers. For example: Say a University creates an online application that let's students enroll in courses. The point of this is so that the university puts asses in seats and can collect money and eliminate the overhead of having to pay people to do it manually. So if the system is designed from that perspective the system will allow the student to do a search on classes and then plug those into their rosters.
This system probably will not do:
1) Allow the student to organize their schedule
2) search by their own degree requirements
3) easily see how a particular class satisfies elective requirements(ie, does it count as writing intensive, Art, humanities?)
4) ... ect (we could go on but this is only an example)
Here is an example of something done right: The iPhone. There is a lot of attention to detail here. From the clicking sounds to the way the menus are presented to the user and I think even the weight of the product -- not too heavy, not too light, has been managed. (it's not perfect but you can feel the attention to that has been paid.)
I think that research must be done on the client's users or customer prior to embarking on a plan to design an information system. The client is often distracted by it's overwhelming desire to collect money and inflict it's own vision of how the IS should be -- which may not jive with it's users.
Your turn!
This system probably will not do:
1) Allow the student to organize their schedule
2) search by their own degree requirements
3) easily see how a particular class satisfies elective requirements(ie, does it count as writing intensive, Art, humanities?)
4) ... ect (we could go on but this is only an example)
Here is an example of something done right: The iPhone. There is a lot of attention to detail here. From the clicking sounds to the way the menus are presented to the user and I think even the weight of the product -- not too heavy, not too light, has been managed. (it's not perfect but you can feel the attention to that has been paid.)
I think that research must be done on the client's users or customer prior to embarking on a plan to design an information system. The client is often distracted by it's overwhelming desire to collect money and inflict it's own vision of how the IS should be -- which may not jive with it's users.
Your turn!
Comments
I had some friends who would be insulted if you critiqued their programming skills, because they were IT people (and what the fuck is the point of software development?). Similarly, I had friends that would be aghast if asked to setup and maintain Apache on a Linux server, because they were Software people (and who gives a shit about running a server, anyway?).
Thread name aside, I'm not sure there is any good way to evaluate best practices in a super general way. I would strongly encourage anyone embarking upon a software engineering project to keep modularity in mind and avoid spaghetti code. When it is discovered the product doesn't provide the correct services, well written, modular code is much easier to update and fix. When all the moving parts are distinct and easily interchanged, new moving parts that do the right thing are easier to install than revamping all the code (starting from scratch).