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

Sp02 Final Exam Review: Explain the Design Methodology

The usual process to get user input is to go thru a standard form of analysis of the user's problems and requirements. After which a architectural design will be made to suit/solve the customer's needs. Detail design will be done last, which goes into details of how methods will be made. The XP's way is to have their customer be with them the whole time and write user stories for the programmers to estimate. The formal design part is almost left out as XP programmers believe that it is all in the codes. Code repository helps to keep code version recorded properly, and is a way to ensure that everyone is working with the newest codes. On the one hand, usually the programmers document their codes in detail so that the other programmers will understand their codes better. On the other hand, XP programmers don't believe in documenting their codes as they believe that with good coding practice, their codes are literate and self explained, and that they will only document their codes if after all the effort to make it readable/understandable is not enough. Frequent integration is important for projects to be successful, and Unit testing is the way to go to facilitate integration. Using principals of least astonishment also helps to make the codes more readable and programmer-friendly.
And the question asker responds, "WAIT! I'm totally confused. I asked you THREE questions and you give me a buzzword-compliant paragraph! Slow down, please, and answer my questions!"
I think I'd have to agree with the above answer for A. However for B, it's been the experience of our 2335 group that you can enforce good modular design in Java through proper use of interfaces. You give the other coders a well-documented interface for your code, and force them to use that rather than the actual class.

Mitch, re-read the question.

A.What are some ways of getting the development team to understand the customers' problems?
1.I think surveys and feedback help analyzing customer problems and then CRC cards would help break the problem into much easier solutions.
2.XP way of story telling is another way of understanding customer's problems.

B. How do they allow their teams to work separately and yet have easy integration?
If they are using objecy oriented language like squeak then the input and output for the part that every team should be defined in the design process. That way no matter what other teams code or how they code, it wouldnt effect the integeration process. Even better if the each teams method names are defined as well.

C. How do they improve the readability of their code?
1. One of the most common used in past is commenting. Intuitive debug statements help just as comments in improving readability.
2. XP has brought out a new style of pair programming where one person reads the code while other one codes. Each partner in the pair makes sure that the code is readable. I think the another fact that in XP programming they change pairs to work on a piece of code helps ensuring the readability of code.


Please respond and let me know of any more ideas that you might have.

Gaurav Batra
Q: What are some ways of getting the development team to understand the customers' problems?

A: Use case scenarios jump to mind as one of the best ways to relate what the customer will want to do, to how the program will accomodate them. If the scenarios are clearly described, then the development team should build the program to suit those needs. If there are not specific requirements from the customer, someone who has an idea of what is possible as far as implementation should meet with the customer and begin to lay out the system that the customer invisions, step by step, and relay that to the development team.

Q: How do they allow their teams to work separately and yet have easy integration?

A: The team must work together in the design stages to create an overview of the system, and how each part will specifically integrate into that system. The crc cards are a prime example, as they show a class's responsibilities and collaborators, which is really showing What does this piece contribute to the overall picture, and what does other pieces are important for its functioning. Having all of this clearly mapped out in a uml class diagram is essential before any release targeted code is written. As the implementation begins, if any team member needs to change how a certain piece fits into the puzzle, the design should be re-evaluated and each other team member should be made aware of the changes and how they might affect other parts of the system.

Q: How do they improve the readability of their code?

A: Comments are the obvious answer here, but comments can only go so far in clarifying poorly chosen names for classes and methods. Consistent naming conventions must be followed, down to the point of having a set of names for temporary or throw-away variables. In choosing the method names, it is sometimes better to think about how the code would look when this method is used on an instance of the class, instead of just what the method does.

Hank Wilde

Here are a few alternatives to the answers given above:

A:
The most obvious thing to do here is to ask the user. This usually does not give you all the information you need, but it's a good place to start. Another method is to observe the user as they work, this gives you an idea of how they solve problems using the current system.

B:
The others mentioned a good design that is kept up to date, that's an important part. Another way to keep implementation somewhat simple is to do it very often, maybe even every day.
C:
A good way to keep code readable that is used by many companies now is a fairly strict coding standard that programmers must stick to when coding. This keeps everyone's code within a similar framework so that it is easier for everyone to read. Code reviews are useful in keeping everyone up to par as far as the coding standard goes.

Bill Branan

A: Some ways of getting the development team to understand the customers' problems?
To help understand the customers' problems you might want to create a UML use case diagram, user stories, or you may even do a CRC card walk through.
B: How do they allow their teams to work separately and yet have easy integration?
Unit testing ,good OO design, and good communication between the team members can help to easy integration.
C: How do they improve the readability of their code?
By developing coding standards, commenting confusing parts or code, setting coding guidelines, and doing team programming the readability of the code can be improved.
Eric Soto


Bill brought up two very good points that were overlooked in the previous posts.

A.
The user may not always be able to explain what they do.
Sometimes they just do it. Observation of the user and
asking questions are very important. This does bring up the
issue that while one is observed they act differently. Maybe
using multiple users or spending enough time with the user
so they feel comfortable is the answer. The "usual" methods
that require the user to answer questions seems like a good
starting point, but can be insufficient.
B.
I think the XP guys have this one in the bag. Daily stand-up
meetings are very valuable. From experience, no matter how
well a project is designed and layed out, something is always
missing. By using frequent team contact and refactoring, it
seems to me that the whole process can move much faster. The
other thing that really works is the CRC cards or some other
way of defining the function headers.
C.
This one is hard to answer. Can we assume that the reader is
familiar with the language? If so, then function names and
variable names are great. If not, comments may be needed in
places where the language itself can be confusing. The best
way to do this is have someone else read through the code.
That person should be representative of the grooup you want
to be able to read your code.

These are just my thoughts. Let me know what I got wrong.

Randy Rockinson
For readability, we talked about pair programming, refactoring mercilessly, and literate programming. Mark Guzdial

www.3d-sky.com

Link to this Page