View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Summer 2003 Design Process

Design Process

You are the consultant brought in to correct the design process at a large company. What comments would you have for each of the following past failures and what would you suggest as improvements?

a. We used the waterfall method of development on our last project and gathered requirements by asking users questions for 2 days and delivered the software after 1 year and found that they didn't want to use the software.

The problem with the waterfall method is that users usually don't know what they want. If they've never experienced with the software, they won't know they will use it (in what situations and how often). Also, technology changes; thus, the users' needs change. What users want one sec might not be what they want to use a year later. One solution would be to deliver the software sooner so that the users will still be interested in it. Another solution is to deliver the software in pieces so that as you keep working on it, users will be using the software. ~Sabina Karkin

What is it is called when you deliver the software in pieces? Does it work to just ask users questions for 2 days? Should you do anything else? Barbara Ericson

The users should be involved through out the design process. A company's needs can and will change dramatically during 1 year. You software must change with their needs. - badle

What should they do instead? Barbara Ericson

XP programming or use HCI standards and create a prototype without the back-end functionality implemented then have them try that first, Ryan

What does XP says you should do for development cycles? You can also storyboard (draw pictures) and try that on the user first, but if you then go away and deliver the softare a year later they still might not be able to use it. Barbara Ericson

b. We don't have the money to buy lots of expensive UML tools for doing UML, so we didn't do any UML diagrams. You should be able to
figure out the design from reading the code.

You should not expect the users to figure out anything. Users like seeing the information right in front of them, and they like seeing something that would clarify the design. A lot of people do not understand code; thus, reading it wouldn't help. This would be ignoring the process of understanding the user, their skills and limitations. Knowledge should be visible because the user doesn't want to waste time trying to figure out the design. UML does not cost a lot, so some diagrams and explanations should be available to the user (use cases and sequence diagrams at minimum). ~Sabina Karkin

I am more after what good are the diagrams? You wouldn't show UML diagrams to users necessarily. I don't agree with your choice of minimum diagrams. Barbara Ericson

UML diagrams are supposed to help visualize how the program works/will work. This helps programmers so they don't go all do their own thing and then have incompatible code to deal with. I don't like UML for the most part because the diagrams we are forced to create in 2335 and 2340 are not bottom-up friendly. I think implementation specific scenarios would be helpful in some cases in telling others how the program works, but when you go implementation specific, you have to rewrite the documentation when you change the implementation. (little off-topic:) I've seen code when people are trying to get the slide instance from within a message to the slide instance(!) (like trying to go back to the slideshow and find the current slide in the array), which is not pretty. timmy

Not all UML diagrams help you visualize how the program works. What is the most important diagram to help you understand the design of a program or system? Barbara Ericson

Well first linux has free UML tools, Kazaa also has copies 2nd, how about a Use-Case Diagram Ryan

There are two types of use case diagrams. One is high-level and shows the names of the use cases for all the actors. This is nice for showing the functionality that the users want and what group of users wants it. Another use case diagram shows the structure of a use case. But, I still don't see anybody mentioning the most important diagram to understanding the design of the system. Barbara Ericson

Is it a class diagram? Starting with a class diagram forces you to think how you want to distribute the responsibilities and whether you are going to do Model-View-Control or another paradigm. This affects how reusable and maintainable your code will be. ~Sabina Karkin

Yes, Sabina, one of the most important UML diagrams is the class diagram. It shows the static structure of the system (the classes, their attributes and methods, and the relationships between the classes). It conveys lots of information in a picture. XP programmers would just use the CRC cards but I think you get a better overall picture from the class diagram. For example, you may notice common attributes in a class diagram that you wouldn't notice in CRC cards and be able to pull out a parent class. Barbara Ericson

I think class diagrams are the least important. All they show is what classes, methods, and variables you have. Any tool can generate that from code and it doesn't tell you anything about how objects communicate. The closest thing to what I mentioned above is a use case, which tells you how things talk to each other. timmy

timmy you are correct in that a class diagram doesn't tell you how the system should work. That is what use cases are for. Use cases are written in english. They are not UML diagrams. You can create a use case diagram for every use case but I usually wouldn't bother with that. The use case diagram doesn't show how the objects in the program interact. Sequence or collaboration diagrams do that. I also wouldn't bother to do those unless working with beginners or to hash out a complicated interaction. I do like to have a top-level use case diagram that shows the high-level use cases and the actors that want them. Barbara Ericson

c. We don't want to refactor the system because we are afraid we will break something.

In this case, you can set up unit tests (regression tests) and test everything while you refactor the system to keep making sure that everything still works. This way the code is less complex, it's easier to make changes, probability of error decreases, code doesn't get duplicated, and it becomes easier for other people to understand. ~Sabina Karkin
Good answer, Sabina Barbara Ericson

d. We keep finding methods and attributes that we will need when we do the user scenarios and we don't know which class to put them in.

You can create CRC cards so you can know the responsibilities of each class and delegate the methods that way. Big Kang & Dennis Antonio Delgado

Yes, Big Kang and Dennis, knowing the responsibilities helps to determine where the attributes and methods should go. How do they help? Barbara Ericson

Link to this Page