1

My current process using asp mvc is:

  1. Talk to the client a few times to find out what they want
  2. Extract from m y notes a list of nouns, or entities that need to be tracked.
  3. Make a list of the business rules to be enforced.
  4. Build the database, based of the list of entities.
  5. Do a wireframe that roughly lays out all the UI screens.
  6. Start coding models/classes for each entity.
  7. Start coding the UI views
  8. Go back and forth tweaking, modifying, redoing bits that I forgot, etc
  9. Suddenly get done and verify all the business rules are in place.
  10. Ship it.

I feel my process is very inefficient, because I almost always get half way through and realize I have forgotten 3 tables, or some of the tables I have are not needed, or actually I am going to code this another way, etc, etc. Is this normal? I mean, if the architecture process is done correctly, can you foresee most, if not all, problems in the development cycle so there isn't so much redo?

I know architecting is an established profession / process. I guess I am wondering if I am close to a workable method and just need to tweak some things, or am I totally off and need to grab a good book?

  • 1
    Your process sounds pretty good to me. Do you obtain use cases? – Robert Harvey Aug 10 '16 at 21:35
  • @Robert - Not really,well kind of. I do talk to a couple different users to get a couple different perspectives, then I code to the common denominator. – BattlFrog Aug 10 '16 at 21:38
1

The answer you really need here is probably not related to the architecture, but rather to the development methodology. All steps do make sense, but you need to make the process iterative and draw the work breakdown structure so that some of the decisions can be done lately without major impact on overall system design. For that you can look at agile methodologies like SCRUM (if you are working alone, this will be more inspirational than really useful, but it helps to look at the process systematically). Also, you may consider some useful practices:

  1. Collect your notes from customer interviews in form of user stories: "as a some kind of user I want to... so that I'll get/achieve..."
  2. Besides nouns use also adjectives (they help to build hierarchies of classes) and verbs (which define user actions and operations).
  3. Test your wireframe prototypes on user stories (can they be achieved and how efficiently?) and log the results as customer journey maps to figure out gaps and obstacles for users to achieve their goals.
  4. Design your component architecture loosely coupled, so that late changes in requirements and/or your analysis will have minimal impact on your code.
  5. Work in small iterations, at the end of each, deliver working code that can be demonstrated to client ("Today I'll show you the shopping cart UI...") and tested. Early feedback is important.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.