Design iterativo

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O design iterativo é uma metodologia de design baseada em um processo cíclico de prototipagem , teste , análise e refinamento de um produto ou processo. Com base nos resultados do teste da iteração mais recente de um projeto, são feitas alterações e refinamentos. Este processo destina-se, em última análise, a melhorar a qualidade e a funcionalidade de um design. No design iterativo, a interação com o sistema projetado é usada como uma forma de pesquisa para informar e evoluir um projeto, à medida que versões sucessivas ou iterações de um design são implementadas.

História [ editar ]

O design interativo tem sido usado há muito tempo em campos de engenharia. Um exemplo é o ciclo planejar-fazer-verificar-agir implementado na década de 1960. A maioria dos programas de desenvolvimento de novos produtos ou de melhoria de produtos existentes têm um ciclo de verificação que é usado para fins iterativos. O DMAIC usa a estrutura Six Sigma e possui essa função de verificação.

Programação Orientada a Objetos [ editar ]

O design iterativo está conectado com a prática de programação orientada a objetos , e a frase apareceu na literatura da ciência da computação já em 1990. [1] A ideia tem suas raízes no desenvolvimento espiral , concebido por Barry Boehm . [2]

Processo de design iterativo [ editar ]

O processo de design iterativo pode ser aplicado em todo o processo de desenvolvimento de novos produtos . No entanto, as mudanças são mais fáceis e menos caras de implementar nos estágios iniciais de desenvolvimento. O primeiro passo no processo de design iterativo é desenvolver um protótipo . O protótipo deve ser avaliado por um grupo focal ou por um grupo não associado ao produto para emitir opiniões não tendenciosas. As informações do grupo focal devem ser sintetizadas e incorporadas na próxima iteração do projeto. O processo deve ser repetido até que os problemas do usuário sejam reduzidos a um nível aceitável.

Aplicação: Interfaces homem-computador [ editar ]

O design iterativo é comumente usado no desenvolvimento de interfaces homem-computador. Isso permite que os designers identifiquem quaisquer problemas de usabilidade que possam surgir na interface do usuário antes que ela seja amplamente utilizada. Mesmo os melhores especialistas em usabilidade não podem projetar interfaces de usuário perfeitas em uma única tentativa, portanto, um ciclo de vida de engenharia de usabilidade deve ser construído em torno do conceito de iteração. [3]

As etapas típicas de design iterativo em interfaces de usuário são as seguintes:

  1. Conclua um design de interface inicial
  2. Apresentar o design para vários usuários de teste
  3. Observe quaisquer problemas ocorridos pelo usuário de teste
  4. Refinar a interface para contabilizar/corrigir os problemas
  5. Repita as etapas 2-4 até que os problemas da interface do usuário sejam resolvidos

O design iterativo em interfaces de usuário pode ser implementado de várias maneiras. Um método comum de usar design iterativo em software de computador é o teste de software . Embora isso inclua testar a funcionalidade do produto fora da interface do usuário, um feedback importante sobre a interface pode ser obtido com o teste de versões anteriores de um programa. Isso permite que as empresas de software lancem um produto de melhor qualidade ao público e evita a necessidade de modificação do produto após seu lançamento.

O design iterativo em interfaces online (site) é um processo mais contínuo, pois a modificação do site, depois de liberada para o usuário, é muito mais viável do que no design de software. Muitas vezes, os sites usam seus usuários como sujeitos de teste para o design da interface, fazendo modificações com base nas recomendações dos visitantes de seus sites.

Uso de design iterativo [ editar ]

O design iterativo é uma maneira de confrontar a realidade das necessidades e comportamentos imprevisíveis do usuário que podem levar a mudanças radicais e fundamentais em um design. Testes de usuários geralmente mostram que mesmo ideias cuidadosamente avaliadas serão inadequadas quando confrontadas com um teste de usuário. Assim, é importante que a flexibilidade da abordagem de implementação do design iterativo se estenda o máximo possível no sistema. Os designers devem reconhecer ainda que os resultados dos testes de usuários podem sugerir mudanças radicais que exigem que os designers estejam preparados para abandonar completamente as ideias antigas em favor de novas ideias mais equipadas para atender às necessidades do usuário. O design iterativo se aplica a muitos campos, desde a fabricação de facas até foguetes. Como exemplo, considere o projeto de um circuito eletrônicoque deve executar uma determinada tarefa e, em última análise, deve caber em um pequeno espaço em uma placa de circuito . É útil dividir essas tarefas independentes em duas tarefas menores e mais simples, a tarefa de funcionalidade e a tarefa de espaço e peso. Uma placa de ensaio é uma maneira útil de implementar o circuito eletrônico de forma provisória, sem ter que se preocupar com espaço e peso.

Uma vez que o circuito funcione, melhorias ou mudanças incrementais podem ser aplicadas à protoboard para aumentar ou melhorar a funcionalidade do projeto original. Quando o projeto estiver finalizado, pode-se começar a projetar uma placa de circuito adequada que atenda aos critérios de espaço e peso. A compactação do circuito na placa de circuito requer que os fios e componentes sejam manipulados sem alterar suas características elétricas. Esse malabarismo segue regras mais simples do que o próprio projeto do circuito, e muitas vezes é automatizado . Na medida do possível , são usados ​​componentes prontos para uso, mas quando necessário por razões de espaço ou desempenho, podem ser desenvolvidos componentes personalizados.

Várias instâncias de design iterativo são as seguintes:

  • Wiki : Um wiki é um repositório natural para design iterativo. O recurso 'Histórico da página' permite o rastreamento de versões anteriores. As modificações são principalmente incrementais e deixam partes substanciais do texto inalteradas.
  • Direito comum : O princípio do precedente legal baseia-se na experiência passada. Isso torna o direito uma forma de design iterativo onde deve haver uma trilha de auditoria clara do desenvolvimento do pensamento jurídico.
  • Evolução : Existe um paralelo entre a teoria iterativa e a seleção natural . Ambos envolvem um processo de tentativa e erro no qual o design mais adequado avança para a próxima geração, enquanto os designs menos adequados perecem no esquecimento. Versões subsequentes de um produto também devem melhorar progressivamente à medida que seus produtores aprendem o que funciona e o que não funciona em um processo de refinamento e melhoria contínua .

Ferramentas de prototipagem rápida [ editar ]

Uma abordagem para o design iterativo é usar o mais alto nível de abstração para desenvolver um produto de primeira geração. O princípio aqui é que o desenvolvimento rápido pode não produzir código eficiente, mas obter feedback é mais importante do que a otimização da tecnologia. Exemplos dessa abordagem incluem o uso de código não funcional, bancos de dados de objetos ou plataformas de baixo código - eles permitem testes rápidos de projetos antes que os problemas de otimização sejam resolvidos.

Benefícios [ editar ]

Quando aplicado corretamente, o design iterativo garantirá que um produto ou processo seja a melhor solução possível. Quando aplicado no início do estágio de desenvolvimento, são possíveis economias de custo significativas. [4]

Outros benefícios do design iterativo incluem:

  1. Graves mal-entendidos ficam evidentes no início do ciclo de vida, quando é possível reagir a eles.
  2. Possibilita e estimula o feedback do usuário, de modo a eliciar os reais requisitos do sistema.
  3. Onde o trabalho é contratado, o Design Iterativo fornece um método incremental para envolver mais efetivamente o cliente nas complexidades que geralmente cercam o processo de design.
  4. A equipe de desenvolvimento é forçada a se concentrar nas questões que são mais críticas para o projeto, e os membros da equipe são protegidos das questões que os distraem e os desviam dos riscos reais do projeto.
  5. O teste contínuo permite uma avaliação objetiva do status do projeto.
  6. Inconsistências entre requisitos, projetos e implementações são detectadas antecipadamente.
  7. A carga de trabalho da equipe, especialmente da equipe de teste, é distribuída de forma mais uniforme ao longo do ciclo de vida.
  8. Essa abordagem permite que a equipe aproveite as lições aprendidas e, portanto, melhore continuamente o processo.
  9. As partes interessadas no projeto podem receber evidências concretas do status do projeto ao longo do ciclo de vida.

Desafio Marshmallow [ editar ]

Trabalho vencedor do desafio Marshmallow.

O Desafio Marshmallow é um desafio de design instrutivo. Envolve a tarefa de construir a estrutura autônoma mais alta possível com um marshmallow no topo. A estrutura deve ser concluída em 18 minutos usando apenas 20 palitos de espaguete, um metro de fita adesiva e um metro de barbante. [5] [6]

A observação e os estudos dos participantes mostram que os alunos do jardim de infância são regularmente capazes de construir estruturas mais altas, em comparação com grupos de graduados em escolas de negócios. Isso se explica pela tendência das crianças de colocar o marshmallow em cima de uma estrutura simples, testar o protótipo e continuar a aperfeiçoá-lo. Enquanto isso, os alunos da escola de negócios tendem a gastar tempo competindo pelo poder, planejando e, finalmente, produzindo uma estrutura à qual o marshmallow é adicionado. [7] O desafio ajuda a construir e desenvolver habilidades de prototipagem, trabalho em equipe, liderança e inovação e é uma atividade STEM popular . O desafio foi inventado por Peter Skillman da Palm, Inc. e popularizado por Tom Wujec da Autodesk .[8] [9] [10] [11] [12]

Veja também [ editar ]

Referências [ editar ]

  1. ^ Gossain, Sanjiv; Anderson, Bruce (1990). "Um modelo de design iterativo para software orientado a objetos reutilizável". Anais da conferência europeia sobre programação orientada a objetos em sistemas de programação orientada a objetos, linguagens e aplicativos - OOPSLA/ECOOP '90 . págs. 12–27. doi : 10.1145/97945.97949 . ISBN 0-89791-411-2. S2CID  551413 .
  2. ^ "Resumo do modelo espiral" (PDF) .
  3. ^ Nielsen, J. (1993). "Design de interface de usuário iterativo". Computador IEEE . 26 (11): 32–41. doi : 10.1109/2.241424 . S2CID 17748574 . 
  4. ^ Mantei, Marilyn M.; Teorey, Toby J. (1988). "Análise de custo/benefício para incorporar fatores humanos no ciclo de vida do software". Comunicações da ACM . 31 (4): 428–439. doi : 10.1145/42404.42408 . S2CID 2031965 . 
  5. ^ "O desafio do marshmallow" . O Desafio do Marshmallow . Recuperado 2010-08-10 .
  6. ^ "O desafio do marshmallow" . CA: BPWrap. 2010-04-22 . Recuperado 2010-08-10 .
  7. ^ Jerz, Dennis G. (2010-05-10). "O Desafio Marshmallow - Weblog de Alfabetização de Jerz" . Jerz.setonhill.edu . Recuperado 2010-08-10 .
  8. ^ Cameron, Chris (2010-04-23). "Marshmallows e espaguete: como os alunos do jardim de infância pensam como startups enxutas" . Readwriteweb. com. Arquivado a partir do original em 2010-08-21 . Recuperado 2010-08-10 .
  9. ^ "O desafio do marshmallow" . Engineeringrevision. com. 02-05-2010 . Recuperado 2013-08-10 .
  10. ^ "O desafio do marshmallow" . Programação Egoísta . Recuperado 2013-08-10 .
  11. ^ "Desafio Marshmallow | Faculdade de Ciências | Universidade de Calgary" . Ucalgary.ca. 13-12-2010 . Recuperado 2013-08-10 .
  12. Original Design Challenge (2014-01-27), Peter Skillman Marshmallow Design Challenge , arquivado do original em 2021-12-13 , recuperado em 2017-09-12
  • Boehm, Barry W. (maio de 1988) "Um modelo espiral de desenvolvimento e aprimoramento de software", Computer, IEEE, pp. 61-72.
  • Gould, JD e Lewis, C. (1985). Projetando para Usabilidade: Princípios Chave e O Que Pensam os Designers, Communications of the ACM, março, 28(3), 300–311.
  • KRUCHTEN, Philippe. O Rational Unified Process—Uma Introdução,
  • Kruchten, P. (2000). "Da cascata ao desenvolvimento iterativo - uma transição desafiadora para gerentes de projeto" (PDF) (White paper). Rational Software Corporation . Recuperado 2019-08-17 . {{cite journal}}: Cite journal requires |journal= (help)

Links externos [ editar ]