Você projeta / esboço / desenhar uma solução de desenvolvimento de primeiro e depois desenvolvê-lo? Se sim, como? [fechadas]

Question

Eu trabalho muito com os tomadores de decisão olhando para usar a tecnologia melhor em seus negócios. Eu descobri que uma imagem vale mais que mil palavras e prototipagem de um sistema em um diagrama de alguns tipos sempre empresta muito para uma discussão. Eu tenho usado o Visio, UML (um pouco), Mind Maps, fluxogramas e zombavam Up WinForms para iniciar a visão para esses patrocinadores para garantir que todos estejam na mesma página. Eu sempre parecem estar olhando para esse processo comum pode ser usado para tricotar a visão de negócios para o processo de desenvolvimento para que todos acabam no mesmo fim " Algo funcional que resolve um problema ".

Eu estou procurando sugestões ou notas Cliff sobre como abordar o processo de projeto de tal forma que ele funciona para aplicações que só pode levar uma semana para se desenvolver, mas também pode ser usado para abranger projetos maiores também.

Eu sei que este mergulha na área da UML, mas eu descobri que eu tenho uma dificuldade em encontrar um guia para apropriadamente usar os vários tipos de diagramas, permitir que os usuários de negócios sozinho ajudar a entender os diagramas e se relacionar com eles.

O que você usa para capturar uma visão de um sistema / aplicativo para depois apresentar aos patrocinadores de um projeto? (Tudo antes de escrever uma única linha de código) ...

Answer 1

papel ou quadro branco!

Para o deveoper solitário, eu recomendo papel. Pelo menos no início, eventualmente, você pode querer formalizar com UML, mas eu não acho que é necessário.

Para um grupo de desenvolvedores que juntos trabalho (fisicamente), eu recomendo um quadro branco. Dessa forma, a sua visível para todos e todos podem melhorar e contribuir. Mais uma vez, você pode querer formalizar neste momento, mas eu ainda não acho que suas neces

Quando eu comecei a fazer OOP (ou projetar um algoritmo), eu faria tudo na minha cabeça, enquanto a codificação. Mas depois de fazer alguns projetos complexos razoáveis ??I definitivamente ver o benefício no desenho fora as interações entre diferentes objetos em um sistema.

Eu faço projetos por mim, então eu uso um monte de cartões de índice para a concepção de classes e do papel para suas interações. O ponto é que ele precisa ser fácil de mudança. Eu tenho jogado com Dia, um editor de diagramas, para fazer UML, mas fazer mudanças é muito difícil. Eu quero ser capaz de ser capaz de fazer mudanças rápidas, para que eu possa descobrir o que funciona melhor.

Vale a pena mencionar que TDD e fazendo "pico" [1] projetos pode ajudar na concepção de um sistema, também.

[1] De eXtreme Programming Adventures in C #, página 8:

"Pico" é um termo Extreme Programming que significa "experiement." Usamos a palavra porque pensamos de um pico como um rápida, quase experimento de força bruta destinado a aprender apenas uma coisa. Pense drving um grande prego através de uma bordo.

Answer 2

Para tarefas pequenas ou muito limitadas, eu acho que os desenvolvedores concordam quase universalmente que qualquer tipo de diagrama é um passo desnecessário.

No entanto quando se trata de um sistema maior, mais complicado, especialmente quando dois ou mais processos têm de interagir ou lógica de negócios complexos é necessário, processo Diagramas de Atividade pode ser extremamente útil. Usamos métodos ágeis bastante puros em desenvolvimento e encontrá-los quase são o único tipo de diagramas que usamos. É incrível o quanto você pode otimizar um projeto de alto nível apenas por ter todas as peças grandes na frente de você um conectando-os com linhas de fluxo. Eu não posso enfatizar o suficiente o quanto é importante para adequar o esquema para o seu problema, não o contrário, por isso, enquanto o link dá um bom ponto de partida, basta adicionar o que faz sentido para representar o seu sistema / problema.

Como para o armazenamento, quadro branco pode ser ótimo para o brainstorming e quando a idéia ainda está sendo aperfeiçoada, mas eu diria que eletrônico e um wiki é melhor uma vez que a idéia está tomando uma forma bastante final (OmniGraffle é o rei de diagramação se você tiver sorte o suficiente para ser capaz de usar um Mac no trabalho :). Tendo uma área onde você despejar todos estes diagramas pode ser extremamente útil para alguém novo para obter uma compreensão rápida em uma parte geral do sistema sem ter que cavar através do código. Também, porque os diagramas de atividades representam blocos lógicos maiores, não é a questão de sempre ter que mantê-los atualizados. Quando você faz uma grande mudança para um sistema, então sim, mas espero que provavelmente a utilizar o esquema existente para planejar a mudança de qualquer maneira.

Answer 3

Leia-se sobre do kruchten 4 + 1 Visualizações .

Aqui está uma maneira que você pode prosseguir.

1. casos de uso recolher em diagrama de caso de uso. Isto irá mostrar atores e casos de uso. O diagrama não começa com um monte de detalhes.

2. Priorizar os casos de uso para se concentrar em casos de uso de alto valor.

3. narrativas gravação. Se você quiser, você pode desenhar diagramas de atividades.

A descrição acima é completamente não-técnica. UML impõe algumas regras sobre as formas a serem utilizados, mas diferente do que, você pode descrever coisas na terminologia do usuário final.

1. Você pode fazer uma análise substantivo, desenhar diagramas de classe para ilustrar as entidades e relacionamentos. No início, estes serão na terminologia usuário. Sem conteúdo técnico geeky.

2. Você pode expandir os diagramas de atividades ou adicionar diagramas de sequência para mostrar o modelo de processamento. Isto irá iniciar com o usuário final, representações não-técnicas de processamento.

3. Você pode percorrer os diagramas de classe e atividade para passar da análise ao projeto. Em algum momento, você vai ter saído da análise e em modo de engenharia. Os usuários podem não querer ver todas estas imagens.

4. Você pode desenhar diagramas de componentes para a visão de desenvolvimento e diagramas de implantação para a vista físico. Estes serão também iterate como sua concepção dos expande e refina sistema.

Answer 4

Ao projetar um aplicativo (I principalmente criar aplicações web, mas isso se aplica para os outros), eu normalmente criar histórias de usuários para determinar exatamente o que o usuário final realmente precisa. Estes formam a típica "requisitos de negócios".

Depois das histórias de usuários são pregadas para baixo, eu criar fluxogramas para colocar para fora os caminhos que as pessoas vão ter ao utilizar o aplicativo.

Após essa etapa (que às vezes fica um processo de aprovação) Eu criar esboços de interface (caneta / lápis e papel gráfico), e começar a disposição dos bancos de dados. Isto, eo próximo passo são geralmente os mais processo demorado.

O próximo passo é tomar os esboços e transformá-los em wireframes limpo. Eu uso OmniGraffle para esta etapa - é anos-luz à frente do Visio

.

Depois disso, você pode querer fazer diagramas UML típicos, ou outros layouts objeto / organização funcionalidade, mas os homens de negócios não vão se importa tanto com esse tipo de detalhe:)

Answer 5

Quando eu estou colocando juntos um projeto, eu estou preocupado com a transmitir as idéias de forma limpa e fácil para o público. Esse público é composto de (tipicamente) diferentes pessoas com diferentes formações. O que eu não quero fazer é entrar em "modo de ensino" para um modelo de design particular. Se eu tiver que gastar um tempo considerável dizendo a minha cliente o que a seta com os meios de cabeça sólidos e como ele é diferente da que é oco ou o que um meio quadrados contra um círculo, eu não estou fazendo progresso - pelo menos não o progresso Eu quero.

Se for razoavelmente informal, vou esboçar-lo em um quadro branco ou em algum papel - bloco e setas simples, no máximo. O ponto do projeto áspero neste momento é ter a certeza que estamos na mesma página. Ele irá variar por cliente embora.

Se for mais formal, eu poderia retirar uma ferramenta UML e montar alguns diagramas, mas principalmente meus clientes não fazer software de gravação e são provavelmente apenas marginalmente interessante nas entranhas. Nós mantê-lo no nível "bolha e linha" e pode juntar algumas listas com marcas onde é necessário o esclarecimento. Meu cliente não quer ver os diagramas de classe ou qualquer coisa assim, normalmente.

Se precisamos mostrar alguma interação GUI, eu vou jogar juntos alguns protótipos simples janela em Visual Studio - é rápido e fácil. Descobri que o cliente pode se relacionar com isso com bastante facilidade.

Em poucas palavras, eu produzir desenhos simples (em algum formato) que podem se comunicar o projeto para as partes interessadas e as partes interessadas. Eu me certificar de que sabe o que eu quero fazer e mais importante - o que eles precisam fazer, e falar com isso. Ele normalmente não entrar nas ervas daninhas porque as pessoas se perder lá e eu não encontrá-lo um tempo bem gasto para diagrama de tudo à enésima potência. Em última análise, se o cliente e eu (e todas as outras partes interessadas) são na mesma página depois de falar com o projeto, eu sou um cara feliz.

Answer 6

Eu sou um cara Agile, por isso tendem a não colocar um monte de tempo para diagramação. Há certamente momentos em que desenhar algo em um quadro branco ou um guardanapo vai ajudar a garantir que você entender um problema ou exigência especial, mas nada realmente bate recebendo software trabalhando na frente de um cliente para que eles possam ver como ele funciona. Se você estiver em uma situação onde seus clientes aceitaria iterações e demos frequentes sobre up design da frente, eu digo para ela ir. É ainda melhor se eles estão bem para obter feedback precoce na forma de passar testes de unidade ou integração (algo como Fit funciona bem aqui).

Eu geralmente não gostam de protótipos, porque muito frequentemente o protótipo se torna o produto final. Eu tive a infelicidade de trabalhar em um projeto que foi estendendo-se, basicamente, uma oferta comercial que acabou por ser uma "prova de conceito" que foi embalados e vendidos. O projeto foi cancelado depois de mais de 1000 defeitos foram registrados contra a aplicação do núcleo (sem contar com quaisquer acessórios ou personalizações que estávamos trabalhando no momento).

Eu tentei usar UML, e descobriu que a menos que a pessoa olhando para os diagramas UML entende, eles são de pouca ajuda. Tela mock-ups geralmente não são uma má idéia, mas eles só mostram o lado da aplicação que diretamente efeitos do usuário, assim você não ficar muito quilometragem para qualquer coisa que não é apresentação. ferramentas Curiosamente, como o designer de fluxo de trabalho no Visual Studio produzir diagramas muito claras que são fáceis para não-desenvolvedores a entender, por isso faz uma boa ferramenta para a geração de fluxo de trabalho do aplicativo principal, se sua aplicação é suficiente complexa para benefício da mesma.

Ainda assim, de todas as abordagens que usei ao longo dos anos, nada bate um usuário colocar as mãos em algo para que você saiba o quão bem você entende o problema.

Answer 7

Eu sugiro ler artigos de Joel sobre "indolores especificações funcionais". Parte 1 é intitulado "Por que se preocupar?" .

Maquete Telas no trabalho ( "Quick and Easy tela Protótipos"). É fácil telas alter e os rascunhos deixar claro que este é apenas um projeto.

As maquetes são então incluídos em um documento do Word que contém a especificação.

Answer 8

De conceituais blockbusting: um guia para idéias melhores por James L. Adams:

blocos Intelectual resultar em um escolha ineficiente de táticas mentais ou uma escassez de intelectual munição. . . . 1. Resolver o problema usando um idioma incorreto (Verbal, matemática, visual) - como na tentativa de resolver um problema matematicamente quando pode mais facilmente ser realizada visualmente

(pg. 71, 3rd Edition)

Escusado será dizer que, se você optar por usar diagramas para capturar idéias que podem ser mais bem captados com a matemática, é igualmente ruim. O truque, é claro, é encontrar a linguagem certa para expressar tanto o problema ea solução também. E, claro, pode ser apropriado usar mais de uma linguagem para expressar tanto o problema ea solução.

Meu ponto é que você está assumindo que os diagramas são o melhor caminho a percorrer. Eu não tenho certeza de que eu estaria disposto a fazer essa suposição. Você pode obter uma resposta melhor (e o cliente pode estar mais feliz com o resultado) através de algum outro método de requisitos e projetos propostos enquadramento.

leitura By the way, Conceitual blockbusting é altamente recomendado.

Answer 9

O conselho UML funciona bem se você estiver trabalhando em um projeto grande e de aversão ao risco, com um monte de partes interessadas, e com muita contribuidores. Mesmo nesses projetos, ele realmente ajuda a desenvolver um protótipo para mostrar aos tomadores de decisão. Normalmente caminhando-los através da interface do usuário e uma história de usuário típico é suficiente. Dito isto, você deve tomar cuidado para que o foco sobre a interface do usuário para os tomadores de decisão tendem a torná-los negligenciar alguns problemas significativos de back-end, como validações, regras de negócio e integridade dos dados. Eles tendem a escrever estas questões fora como questões "técnicas" em vez de decisões de negócios.

Se, por outro lado, você está trabalhando em um projeto Agile onde é possível fazer alterações de código rapidamente (e erros de reversão rápida), você pode ser capaz de fazer um protótipo evolutivo com todas as obras. a arquitetura da sua aplicação deve ser suficiente maleável e flexível para apoiar a mudança rápida (padrão de design objetos por exemplo nuas ou MVC Rails-style). Ela ajuda a ter uma cultura de desenvolvimento que incentiva a experimentação, e reconhece que BDUF há preditor de trabalho software bem sucedido.

Answer 10

4 + 1 visões são bons apenas para pessoas técnicas. E somente se eles são suficientes interessados. Lembre-se daqueles últimos dúzia de vezes que você lutou para discutir diagramas de casos de uso com o cliente?

A única coisa que eu encontrei que funciona com todo mundo é na verdade mostrando-lhes telas de sua aplicação. Você mesmo disse: uma imagem vale mais que mil palavras

.

Curiosamente, há duas abordagens que funcionaram para mim:

1. Present aos utilizadores um manual do usuário completo (antes mesmo de desenvolvimento é iniciado), ou
2. Use maquetes que não se parece em nada com aplicativo acabado: Discutir principais telas de você primeiro aplicativo. Quando estiver satisfeito, prosseguir discutindo maquetes, mas um cenário de cada vez.

Para a opção (1) você pode usar o que quiser, isso realmente não importa.

Para a opção (2) que é completamente bem para começar com caneta e papel. Mas logo você é melhor fora de usar uma ferramenta de maquete especializada (assim que você precisa para editar, manter ou organizar suas maquetes)

Acabei escrevendo meu próprio volta ferramenta de maquete em 2005, tornou-se bastante popular: MockupScreens

E aqui está a lista mais completa de ferramentas maquete eu conheço. Muitos dos que são livres: http://c2.com/cgi/wiki?GuiPrototypingTools