O desenvolvimento de software é uma atividade complexa que requer pensamentos de vários tipos. Já existe um pensamento projetual na Engenharia de Software, porém, este pode ser enriquecido com o pensamento projetual de outras disciplinas, como o Desenho Industrial, Arquitetura e Educação.
7. Vantagens da tradução
•Desmistificação: não é um método mágico de
criatividade vindo do exterior
•Analogia: o pensamento projetual está para o
Design assim como pensamento jurídico está para
o Direito
•Pluralidade: assim como existem vários
pensamentos jurídicos (grego, romano, moderno,
contemporâneo) existem também vários
pensamentos projetuais
8. Pensamentos sobre projetos
•Para a Arte, projeto é uma obra
•Para a Arquitetura, projeto é uma forma
•Para a Engenharia, projeto é um método
•Para o Desenho Industrial, projeto é um processo
•Para a Educação, projeto é um motivo
•Para a Computação, projeto é um problema
•Para a Administração, projeto é um recurso
9. A Arte é o berço do pensamento projetual
(Vênus de Willendorf, 25 mil anos A.C.).
22. O pensamento projetual era um conhecimento tácito que só
podia ser aprendido pela vivência no ateliê de projetos.
23. A vivência do ateliê de projetos continuava depois da
Universidade em escritórios especializados.
24. A partir dos anos 1990, empresas como IDEO contrataram
profissionais de outras áreas para compor seu ateliê.
25. O programa TV Nightline (1999) mostrou ao mundo como a
multidisciplinaridade no ateliê gerava inovação.
26. Na época, a industrialização chinesa forçava os EUA a
inovar na economia de serviços.
27. Propagava-se a ideologia neoliberal de que empresas devem
assumir os problemas capciosos que o estado ignora.
28. IDEO percebeu a oportunidade de vender serviços para
além do escopo do desenho industrial (Brown, 2009).
29. IDEO fundou a IDEO.org para atuar no terceiro setor e
disseminar seus métodos e abordagens.
30. Brainstorming no estilo
IDEO
•Cada ideia em um post-it
•Ideias malucas são bem vindas
•Críticas não são bem vindas
•Ideias devem ser misturadas e transformadas
•Ninguém deve monopolizar o processo criativo
•Quantidade de ideias é melhor do que qualidade
31. Variações do método
A. Com anotador(a)
B. Com post-its monocromáticos
C. Com post-its coloridos
D. Com pensamento visual
E. Em silêncio
F. Em pé
G. Com figurinos excêntricos
H. Com votação por pontos
32. Hasso Plattner da SAP financiou a fundação da d.School na
Stanford com apoio da IDEO (2005).
33. A fundação da d.School em Stanford e em Postdam formou
multiplicadores que espalharam o "design thinking".
34. "Design thinking" tornou-se uma abordagem genérica para
inovação fundamentada na cocriação multidisciplinar
(Sanders & Stappers, 2008).
35. A partir do modelo da d.School (2010), surgiram variantes
que reduziram o pensamento projetual a um método.
36. Design Sprint, por exemplo, prometeu resolver qualquer
problema em uma semana (Knapp, 2015).
37. O método dá a impressão falsa de qualquer pessoa pode
pensar e resolver problemas tão bem como um designer.
38. Além disso, desconsidera a importância da vivência no
ateliê de projetos para o pensamento projetual.
39. O método é apenas um ponto de consolidação na evolução
do pensamento projetual (Dubberly, 2005).
40. Mais importante do que saber
aplicar um método, é compreender
seu pensamento subjacente. Isso
permite rejeitar, adaptar e criar
novos métodos mais adequados.
42. O pensamento projetual sistemático se baseia na técnica
da redução conceitual (Van Amstel, 2015).
43. Pensamento projetual sistemático
•Definir requisitos antes de começar a projetar
•Projetar módulos ou componentes em separado
•Criar sistemas que conectem todos os
componentes
•Evitar o erro e a falha
•Tomar decisões baseadas em quantidades
•Projetar com restrições explícitas
44. Bibliografia sobre pensamento projetual sistemático.
Software Engineering & Systems Development
Taking a learn-by-doing approach, Software Engineering Design: Theory and
Practice uses examples, review questions, chapter exercises, and case study assign-
ments to provide students and practitioners with the understanding required to de-
sign complex software systems. Explaining the concepts that are immediately rele-
vant to software designers, it begins with a review of software design fundamentals.
The text presents a formal top-down design process that consists of several design
activities with varied levels of detail, including the macro-, micro-, and construction-
design levels. As part of the top-down approach, it provides in-depth coverage of
applied architectural, creational, structural, and behavioral design patterns. For
each design issue covered, it includes a step-by-step breakdown of the execution of
the design solution, along with an evaluation, discussion, and justification for using
that particular solution.
The book outlines industry-proven software design practices for leading large-scale
software design efforts, developing reusable and high-quality software systems,
and producing technical and customer-driven design documentation. It also:
• Offers one-stop guidance for mastering the Software Design
& Construction sections of the official Software Engineering
Body of Knowledge (SWEBOK®
)
• Details a collection of standards and guidelines for structuring
high-quality code
• Describes techniques for analyzing and evaluating the quality
of software designs
Collectively, the text supplies comprehensive coverage of the software design
concepts students will need to succeed as professional design leaders. The section
on engineering leadership for software designers covers the necessary ethical and
leadership skills required of software developers in the public domain. The section on
creating software design documents (SDD) familiarizes students with the software
design notations, structural descriptions, and behavioral models required for SDDs.
Course notes, exercises with answers, online resources, and an instructor’s
manual are available upon qualified course adoption.
ISBN: 978-1-4398-5168-5
9 781439 851685
90000
Software
Engineering
Design
Theory and Practice
Carlos E. Otero
Otero
K12371
www.auerbach-publications.com
SoftwareEngineeringDesign
www.crcpress.com
K12371 cvr mech.indd 1 5/7/12 2:37 PM
45. Jogo
1001 Maneiras de ir de A a B
•Definir vários pontos As e pontos Bs no espaço
•Desenhar caminhos diferentes entre cada A e
cada B
46. O pensamento sistemático transforma o problema mal-
estruturado em problema estruturado (Simon, 1973).
47. Problemas estruturados
•O problema pode ser definido claramente
•As variáveis do problema podem ser identificadas
•As variáveis podem ser combinadas para gerar
várias soluções
•Pode ser computado
(Simon, 1973)
48. O pensamento projetual reflexivo se baseia na prática da
reflexão-na-ação (Schön, 1983).
49. Pensamento projetual reflexivo
•O projeto se desenvolve à partir de um conceito
que surge da inspiração de uma pessoa
•O conceito é visualizado através de esboços, que
se transformam em alternativas e modelos
•A resistência à implementação do conceito
provoca reflexão e consequente redefinição do
conceito
•O conceito precisa ser forte para convencer os
outros de que vale à pena implementar
50. O pensamento projetual reflexivo é muito comum na Arte,
Arquitetura e Desenho Industrial.
52. Jogo dos 15...
• Cada jogador escolhe um
número entre 1 e 9 no seu
turno
• Os números não podem
ser repetidos
• O primeiro que somar 15
ganha
• Como jogar esse jogo sem
falar e sem escrever
números?
53. ...mesma coisa que: jogo da velha
• Cada jogador escolhe uma
posição no seu turno
• As posições não podem
ser repetidas
• O primeiro que marcar
três posições em linha
ganha
4 3 8
9 5
7
1
2 6
54. ...mesma coisa que: jogo da velha
• Cada jogador escolhe uma
posição no seu turno
• As posições não podem
ser repetidas
• O primeiro que marcar
três posições em linha
ganha
4 3 8
9 5
7
1
2 6
55. O pensamento reflexivo reenquadra o problema dado sob
uma outra perspectiva (Schön, 1983).
56. Problemas capciosos
•O problema não pode ser definido claramente
•A complexidade só aumenta com a investigação
•Um problema está ligado a outro problema
•Não há uma solução satisfatória
•A solução é julgada em termos éticos e não em
termos técnicos
(Rittel & Webber, 1972)
58. Pensamento projetual expansivo
•Está constantemente incluindo novas pessoas e
novos problemas
•Busca uma visão ampla, holística dos fenômenos
•Leva em consideração execução e experiência de
uso como parte do projeto
•Atitude é mais importante do que processo.
Exemplo: pensar com as mãos através de
protótipos ajuda a pensar junto
59. O pensamento projetual expansivo é comum na Arte, no
Desenho Industrial e na Computação.
61. Ex: Jogo Silencioso
•Jogo divido em turnos, em absoluto silêncio
•Cada pessoa constrói em seu turno uma estrutura
abstrata com 4 peças de Lego
•Deve-se buscar compreender e continuar a ideia
do último jogador
•Após algumas rodadas, os parceiros
compartilham suas intenções e surpresas
62. O pensamento expansivo busca a origem de problemas e
soluções: a contradição (Van Amstel, 2015).
63. O que é uma contradição
•Uma tensão acumulada na sociedade
•Um embate entre duas forças opostas
•Nenhuma das forças pode ser eliminada
•Pode ser superada pela criação de uma terceira
força que contém as outras duas numa nova
configuração
(Lefebvre, 1954; Engeström, 1987)
66. Contradições já estudadas
•Consistência do sistema X Diversidade de pessoas
•Complexidade crescente X Vontade de controlar
•Indivíduos e interações X Processos e
ferramentas
•Programação como arte X Programação como
ciência
67. Contradições que gostaria de estudar
•Divisão do trabalho X Integridade conceitual
(Brooks, 2009)
•Responder a mudanças X Seguir um plano (Wang
et al, 2008)
•Considerações técnicas X Impacto social
(Friedrich, 1996)
•Suporte de práticas X Mudança de práticas (Ehn,
1988)
•Situações complexas X Situações conflituosas
(Mathiassen & Munk-Madsen, 1986)