Do you first design / sketch / draw a development solution and then develop it? If so, how?

Question

I work a lot with decision makers who want to better use technology in their business. I found that a picture is worth a thousand words , and prototyping the system on a diagram always attaches great importance to the discussion. I used Visio, UML (several), Mind Maps, Flow Charts, and Mocked Up WinForms to start seeing these sponsors so that everyone is on the same page. It always seems to me that this general process can be used to connect the business vision with the development process, so that we all find ourselves at the same end. Something functional that solves the problem .

I am looking for Cliff’s suggestions or notes on how to approach the design process so that it works for applications that can take a week, and can also be used to cover large projects.

I know this goes into the UML realm, but I found it hard to find guidance on the proper use of different types of diagrams, not to mention helping business users understand and relate to diagrams.

What do you use to capture the vision of a system / application and then introduce it to project sponsors? (all before writing one line of code) ...

Answer 1

Paper or board!

For a single dev, I would recommend paper. At least in the beginning, you might want to formalize it using UML, but I don’t think it is necessary.

For a group of developers who work together (physically), I would recommend a board. Thus, its visible to everyone and everyone can improve and contribute. Again, you may want to formalize at this point, but I still don't find it necessary

When I first started doing OOP (or developing an algorithm), I would have done all this in my head during coding. But after completing some reasonable complex projects, I definitely see an advantage in developing the interaction between the various objects in the system.

I make projects myself, so I use a lot of index cards to develop classes and paper for their interaction. The fact is that it needs to be easily changed. I played with Dia, a chart editor for UML, but making changes is too complicated. I want to be able to make quick changes, so I can figure out what works best.

It is worth noting that TDD and spike projects [1] can also help with system design.

[1] From extreme software adventures in C #, p. 8:

"Spike" is an extreme programming term which means "experience." We use the word because we think of the surge as a quick, almost crude experiment aimed at studying only one. Consider pulling a large nail through the board.

Answer 2

For small or very limited tasks, I think developers almost universally agree that any diagram is an unnecessary step.

However, when working with a larger and more complex system, especially when the interaction of two or more processes or complex business logic is required, process activity diagrams can be extremely useful. We use fairly simple agile methods in development and find that this is almost the only type of diagram we use. It's amazing how much you can optimize a high-level design by simply having in front of you all the big pieces connecting them to the flow lines. I cannot stress enough how important it is to adapt the diagram to your problem, and not vice versa, so as long as the link provides a good starting point, just add a meaning representing your system / problem.

As for storage, the board can be useful for brainstorming and when the idea is still being clarified, but I would say that the electronic and wiki are better if the idea takes on a rather final form (OmniGraffle is the king of diagrams if you are lucky enough to use a Mac at work :). Possessing the area where you dump all of these charts can be very useful for someone new to quickly grasp the common part of the system without having to dig code. In addition, since activity diagrams are large logical blocks, there is no need to constantly update them. When you make big changes to the system, then yes, but hopefully probably using the existing chart to plan for change anyway.

Answer 3

From Conceptual Lock: A Guide to the Best Ideas of James L. Adams:

Intelligent blocks lead to an ineffective choice of mental tactics or a lack of intellectual ammunition. ,, 1. The solution to the problem using the wrong language (verbal, mathematical, visual) is like trying to solve a problem mathematically, when it can be easier to do visually

(p. 71, 3rd edition)

Needless to say, if you decide to use diagrams to capture ideas that can be better captured by mathematics, this is also bad. Of course, the trick is to find the right language to express both the problem and the solution. And, of course, it may be advisable to use several languages ​​to express both the problem and the solution.

I want to say that you think that charts are the best way. I am not sure that I will be ready to make this assumption. You can get a better answer (and the client can be happier with the result) using any other method to meet the requirements and proposed projects.

By the way, it is recommended to use conceptual locking.

Answer 4

Read on Kruchten 4 + 1 Views .

Here you can continue.

• Collect usage examples in a usage diagram. This will show participants and usage examples. The diagram does not start with a lot of details.

• Use case precedence to focus on high value use cases.

• Write stories. If you want, you can draw activity diagrams.

The above is completely non-technical. UML imposes a few rules on the shapes that will be used, but you can also portray things in end-user terminology.

• You can analyze nouns by drawing class diagrams to illustrate entities and relationships. First it will be in user terminology. No geeky technical content.

• You can expand action diagrams or add sequence diagrams to show the processing model. This will begin with end-users, non-technical processing descriptions.

• You can iterate over class diagrams and operations to move from analysis to design. At some point, you will move from analysis to technical mode. Users may not want to see all these photos.

• You can draw component diagrams for development and deployment diagrams for the physical view. They will also be repeated as your system concept is expanded and refined.

Answer 5

When developing an application (I mainly create web applications, but this applies to others), I usually create user stories to determine exactly what the end user really needs. They form typical "business requirements".

After the user stories were nailed, I create flowcharts to build the paths that people will use when using the application.

After this step (which sometimes gets the approval process), I create the interface sketches (pen / pencil and graphic paper) and begin the layout of the databases. This is the next step, usually the most time-consuming process.

The next step is to make sketches and turn them into peeled frames. I use OmniGraffle for this step - it is several years ahead of Visio.

After that, you may want to make typical UML diagrams or other object structures / functionality, but business people will not care so much about this detail :)

Answer 6

When I assemble a design, I’m interested in conveying ideas that are clear to the audience. This audience consists of (usually) different people with different backgrounds. What I do not want to do is enter the “training mode” for a particular design model. If I have to spend a lot of time telling my client what a solid-headed arrow means and how it differs from that which is empty or what a square means compared to a circle, I have not made progress - at least not progress I want.

If this is informal enough, I will draw it on the board or on paper blocks and simple arrows at most. The point of rough design at this point is to make sure we're on the same page. However, it will be different from the customer.

If it is more formal, I can pull out the UML tool and collect some diagrams, but basically my clients do not write software and are probably only slightly interesting in internal relationships. We keep it at the bubble and line level and can collect some bulleted lists where clarification is required. My client doesn't want to see class diagrams or anything like that, as a rule.

If we need to show some kind of interaction with the GUI, I'm going to put together some simple window prototypes in Visual Studio - it's quick and easy. I found that the client can relate to this quite easily.

In short, I produce simple drawings (in some format) that can convey the design to interested parties and shareholders. I make sure I know what I want, and more importantly, what they need to do and talk about it. Usually this does not fall into the weeds, because people get lost there, and I do not find that this time spent on the chart is all to the nth degree. Ultimately, if the client and I (and all other interested parties) are on the same page after talking about design, I’m a happy guy.

Answer 7

I am an agile guy, so I try not to spend a lot of time on the chart. Of course, the times when sketches of something on a white board or napkin will help you understand a specific problem or requirement, but nothing beats getting the working software in front of the client so that they can see how it works. If you are in a situation where your customers will take frequent iterations and demos for front-end design, I say, go after it. It’s even better if they can get early feedback in the form of passing unit tests or integration (something like Fit works well here).

I don’t like prototypes at all, because too often a prototype becomes an end product. I had the misfortune of working on a project that basically distributed a commercial proposal that turned out to be a “proof of concept” that was packaged and sold. The project was canceled after more than 1000 defects were registered against the main application (not counting any improvements or settings that we were currently working on).

I tried using UML and found that if the person looking at the diagrams does not understand UML, they do not help much. Screen layouts are usually not a bad idea, but they only show the side of the application that directly affects the user, so you don’t get much mileage for anything that is not a presentation. Oddly enough, tools such as the Workflow Designer in Visual Studio create fairly clear diagrams that are not easy for developers to understand, so it makes a good tool for creating a workflow for core applications if your application is complex enough to capitalize on it.

However, of all the approaches that I have used over the years, nothing prevents the user from getting something so that you know how well you understand the problem.

Answer 8

I suggest reading Joel’s articles “Stainless Functionality.” Part 1 is called "Why bother?" .

We use Dummy screens in the workplace (“Quick and easy screen prototypes”). It is easy to change the screens, and the screen shows that this is just a design.

Then the layouts are included in the Word document containing the specification.

Answer 9

The UML tip works well if you are working on a large, risk-free project with a large number of stakeholders and a large number of participants. Even in those projects, it really helps to develop a prototype to show to decision makers. Usually they go through the user interface, and a typical user story is sufficient. However, you should beware that focusing on the user interface for decision makers will tend to make them ignore some important issues, such as checks, business rules, and data integrity. They tend to write these issues as “technical” rather than business solutions.

If, on the other hand, you are working on an Agile project where you can quickly make code changes (and rollback errors), you can create an evolutionary prototype with all the work. Your application architecture must be flexible and flexible in order to support a quick change (for example, a bare-object design template or Rails-style MVC). This helps create a development culture that encourages experimentation and recognizes that BDUF is not a predictor of successful software.

Answer 10

4 + 1 views are only good for technical people. And only if they are interested enough. Remember those last dozens of times you tried to discuss usage patterns with a client?

The only thing I found that works with everyone is showing their screens of your application. You yourself said: a picture is worth a thousand words.

Curiously, there are two approaches for me:

• Provide users with a complete user guide (prior to development), OR
• Use layouts that do not look like a finished application. First, discuss the main screens of the application. When this is done, continue discussing the layouts, but one scenario at a time.

For option (1) you can use whatever you want, it does not matter.

For option (2) it’s quite normal to start with a pen and paper. But soon you better use a specialized layout (as soon as you need to edit, save or organize layouts)

In 2005, I wrote my own mock tool, it became quite popular: MockupScreens

And here is the most comprehensive list of layout tools that I know of. Many of them are free: http://c2.com/cgi/wiki?GuiPrototypingTools