1. Uma visão hegeliana do passado da engenharia de software
1.1. Tese dos anos 1950: Engenharia de Software é como Engenharia de Hardware
1.1.1. O processo de desenvolvimento de software SAGE (1956)
1.1.1.1. processo de 1956 é equivalente ao modelo V para desenvolvimento de software.
1.1.1.2. O projeto de processamento de informações mais ambicioso da década de 1950 foi o desenvolvimento do Semi-Automated Ground Environment (SAGE) para a defesa aérea dos Estados Unidos e Canadá.
1.1.2. Outra indicação da orientação da engenharia de hardware dos anos 1950 está nos nomes das principais sociedades profissionais para profissionais de software: a Association for Computing Maquinário e o IEEE ComputadorSociedade.
1.2. Antítese dos anos 60: Criação de Software
1.2.1. fenomenologia do software diferia da fenomenologia do hardware
1.2.1.1. software era muito mais fácil de modificar do que o hardware e não exigia linhas de produção caras para fazer cópias do produto.
1.2.1.1.1. diferença de software era que o software não se desgastava.
1.2.1.2. Revisões Críticas de Projeto que os engenheiros de hardware realizaram antes de se comprometer com as linhas de produção e dobrar o metal (medir duas vezes, cortar uma vez).
1.2.1.2.1. abordagem da engenharia de hardware era que a rápida expansão da demanda por software ultrapassava a oferta de engenheiros e matemáticos.
1.2.2. Nem toda a década de 1960 sucumbiu à abordagem codificar e corrigir, a família de programas OS-360 da IBM, embora cara, atrasada e inicialmente difícil de usar, fornecia serviços mais confiáveis
1.2.3. Infraestrutura muito melhor. Poderosos sistemas operacionais de mainframe, utilitários e linguagens maduras de ordem superior, como Fortran e COBOL, tornaram mais fácil para os não matemáticos entrar no campo.
1.2.4. Criação de departamentos de informática e - Codificar e corrigir informática de universidades, com ênfase crescente em software.
1.2.5. Cada vez mais aplicativos grandes e orientados para a missão. Alguns tiveram sucesso como com OS / 360 e Apollo acima, mas muitos outros não tiveram sucesso, exigindo um retrabalho quase completo para obter um sistema adequado.
1.2.6. conferências marcantes de “Engenharia de Software” em 1968 e 1969
1.2.6.1. Essas conferências forneceram uma base sólida de compreensão do estado da prática da engenharia de software que as organizações da indústria e do governo poderiam usar como base para determinar e desenvolver melhorias. Ficou claro que métodos mais bem organizados e práticas mais disciplinadas eram necessários para dimensionar os projetos e produtos cada vez maiores que estavam sendo encomendados.
1.3. Síntese e antítese dos anos 1970: formalidade e processos em cascata
1.3.1. programação estruturada
1.3.1.1. uma mistura menos formal de métodos técnicos e de gerenciamento, “programação estruturada de cima para baixo com equipes de programadores-chefe”, lançada por Mills e destacada pelo aplicativo NewYork Times liderado por Baker
1.3.1.2. “métodos formais” que focava na correção do programa
1.3.1.3. muitas outras abordagens “estruturadas” aplicadas ao design de software
1.3.1.3.1. Princípios de modularidade foram reforçados pelos conceitos de acoplamento de Constantino (a ser minimizado entre os módulos) e coesão (a ser maximizado dentro dos módulos)
1.3.1.3.2. Uma série de ferramentas e métodos que empregam conceitos estruturados foram desenvolvidos, como design estruturado
1.3.2. paradigma de fabricação dos anos 1960 foi fornecida pela versão de Royce do modelo "cascata"
1.3.2.1. Ele adicionou os conceitos de confinar as iterações a fases sucessivas e uma atividade de prototipagem “construa duas vezes” antes de se comprometer com o desenvolvimento em escala total.
1.3.2.1.1. Abordagens Quantitativas
1.3.2.1.2. No entanto, no final da década de 1970, os problemas estavam surgindo com a formalidade e os processos em cascata sequenciais. Os métodos formais tinham dificuldades com escalabilidade e usabilidade pela maioria dos programadores menos especializados
1.4. Síntese de 1980: Produtividade e Escalabilidade
1.4.1. resolver os problemas da década de 1970 e melhorar a produtividade e escalabilidade da engenharia de software.
1.4.2. Ferramentas de software
1.4.3. Processos de Software
1.4.4. Reutilização de software
1.4.4.1. A reutilização de software de infraestrutura comercial evitou muita programação e longos tempos de resposta.
1.4.4.2. A melhor arquitetura e engenharia de domínio possibilitaram uma reutilização muito mais eficaz de componentes de aplicativos, apoiados tanto por estruturas de reutilização como Draco e por linguagem de quarta geração de negócios específicos de domínio (4GLs), como FOCUS e NOMAD
1.4.4.3. linguagens de programação e ambientes como Smalltalk, Eiffel, C ++ e Java estimularam o rápido crescimento do desenvolvimento orientado a objetos, assim como uma proliferação de métodos de design e desenvolvimento orientados a objetos convergindo por meio da Unified Modeling Language (UML) na década de 1990.
1.5. Antítese dos anos 90: Processos Concorrentes vs. Sequenciais
1.5.1. Os métodos orientados a objetos foram fortalecidos por meio de avanços como padrões de projeto
1.5.1.1. a mudança para produtos interativos com o usuário com requisitos emergentes em vez de pré-especificáveis, levou as organizações a abandonar os processos em cascata
1.5.1.2. O modelo espiral orientado a riscos foi planejado como um processo para apoiar a engenharia simultânea, com os riscos primários do projeto usados para determinar o quanto a engenharia de requisitos simultâneos, arquitetura, prototipagem e desenvolvimento de componentes críticos eram suficientes.
1.5.2. arquiteturas de software e linguagens de descrição de arquitetura
1.5.2.1. Desenvolvimento de código aberto
1.5.2.1.1. forma significativa de engenharia simultânea com forte contribuição na década de 1990 foi o desenvolvimento de software de código aberto. De suas raízes na cultura hacker da década de 1960, estabeleceu uma presença institucional em 1985 com o estabelecimento de Stallman da Free Software Foundation e da GNU General Public License
1.5.2.2. Usabilidade e interação humano-computador
1.5.2.2.1. aumento da usabilidade de produtos de software por não programadores.
1.5.2.2.2. Uma pesquisa séria em interação homem-computador (HCI) estava acontecendo já na segunda fase do projeto SAGE na Rand Corp na década de 1950
1.5.2.2.3. final dos anos 1980 e 1990 também viu o campo de HCI expandir seu foco do suporte computacional de desempenho individual para incluir sistemas de suporte de grupo
1.5.3. desenvolvimento de UML. A expansão contínua da Internet e o surgimento da World Wide Web fortaleceram os métodos OO e a criticidade do software no mercado competitivo.
1.6. Antítese e síntese parcial de 2000: agilidade e valor
1.6.1. os anos 2000 viram uma continuação da tendência de rápido desenvolvimento de aplicativos e uma aceleração do ritmo de mudança na tecnologia da informação, em organizações, em contramedidas e no meio ambiente
1.6.2. Métodos Ágeis
1.6.2.1. O final da década de 1990 viu o surgimento de uma série de métodos ágeis, como Desenvolvimento Adaptativo de Software, Crystal, Desenvolvimento de Sistemas Dinâmicos, Programação eXtreme (XP), Desenvolvimento Orientado a Recursos e Scrum.
1.6.2.1.1. Indivíduos e interações sobre processos e ferramentas.
1.6.2.1.2. software que trabalha sobre uma documentação completa.
1.6.2.1.3. Colaboração do cliente durante a negociação do contrato
1.6.2.1.4. Resposta à mudança seguindo um plano.
1.6.2.1.5. O método ágil mais amplamente adotado foi o XP
1.6.2.2. A análise das "bases" relativas dos métodos ágeis e orientados a planos descobriu que os métodos ágeis eram mais viáveis em pequenos projetos com resultados de risco relativamente baixos, pessoal altamente capaz, requisitos em rápida mudança e uma cultura de prosperar no caos vs. pedido
1.6.3. Engenharia de software baseada em valor
1.6.3.1. A ênfase dos métodos ágeis na melhoria da usabilidade por meio de incrementos curtos e conteúdo de incremento priorizado por valor também respondem às tendências nas preferências do cliente de software.
1.6.3.1.1. Um desejo recorrente da organização de usuários é ter uma tecnologia que se adapte às pessoas, e não vice-versa. Isso se reflete cada vez mais nas atividades de seleção de produtos dos usuários, com critérios de avaliação cada vez mais enfatizando a usabilidade do produto e o valor agregado vs. uma forte ênfase anterior nos recursos do produto e custos de compra
1.6.3.2. É claro que o surgimento de requisitos é incompatível com práticas de processos anteriores, como modelos de processos em cascata sequenciais orientados por requisitos e cálculos de programação formal; e com modelos de maturidade de processo enfatizando repetibilidade e otimização
1.6.4. Criticidade e confiabilidade do software
1.6.4.1. a dependência geralmente não é a principal prioridade para os produtores de software. Nas palavras do Relatório PITAC de 1999, “A indústria de TI gasta a maior parte de seus recursos, tanto financeiros quanto humanos, para colocar rapidamente os produtos no mercado”.
1.6.4.2. O software de código-fonte aberto, ou o software reutilizado ou legado de uma organização, é menos opaco e menos provável de ficar sem suporte. Mas eles também podem ter problemas com interoperabilidade e evolução contínua.
1.6.4.2.1. software e hardware de código-fonte aberto, reutilizado e legado geralmente apresentam deficiências em usabilidade, confiabilidade, interoperabilidade e localização para diferentes países e culturas.
1.6.5. Desenvolvimento Orientado a Modelos
1.6.5.1. o surgimento de arquiteturas corporativas e desenvolvimento orientado a modelos (MDD) oferece perspectivas de melhorar a compatibilidade.
1.6.5.2. O MDD capitaliza a perspectiva de desenvolver modelos de domínio (de bancos, automóveis, cadeias de suprimentos, etc.) cuja estrutura de domínio leva a arquiteturas com alta coesão de módulo e baixo acoplamento entre módulos, permitindo o desenvolvimento rápido e confiável de aplicativos e a evoluibilidade dentro do domínio.
1.6.5.3. O desafio adicional para as abordagens MDD atuais e futuras é lidar com as mudanças contínuas na infraestrutura de software (distribuição em massa, computação móvel, objetos da Web em evolução) e reestruturação de domínio que estão ocorrendo.
1.6.6. Interagindo software e engenharia de sistemas
1.6.6.1. O impulso para integrar modelos de domínio de aplicativo e modelos de domínio de software no MDD reflete a tendência dos anos 2000 em direção à integração de engenharia de software e sistemas.
1.6.6.2. os engenheiros de sistemas estão descobrindo tardiamente que precisam acessar mais habilidades de software à medida que seus sistemas se tornam mais intensivos em software.
1.6.6.3. A importância da integração de sistemas e engenharia de software também tem sido destacada em relatos de experiência de grandes organizações que tentam escalar métodos ágeis usando equipes de equipes
1.6.6.4. Descobriram que, sem a engenharia de sistemas e formação de equipe iniciais, ocorrem dois modos de falha comuns.
1.6.6.4.1. é que as equipes ágeis estão acostumadas a fazer a arquitetura de sua própria equipe ou a decisões de refatoração e há uma escassez de líderes de equipe que possam satisfazer tanto as preferências da equipe quanto as restrições desejadas ou impostas pelas outras equipes
1.6.6.4.2. é que as equipes ágeis tendem a se concentrar nas primeiras coisas mais fáceis nos primeiros incrementos, para tratar os requisitos de qualidade de nível de sistema (escalabilidade, segurança) como recursos a serem incorporados em incrementos posteriores,
2. Uma visão de 2010 e além
2.1. Antíteses e Sínteses Parciais de 2010: Globalização e Sistemas de Sistemas
2.1.1. A conectividade global fornecida pela Internet e as comunicações globais de baixo custo e alta largura de banda fornecem grandes economias de escala e de rede que impulsionam as estratégias de produto e processo de uma organização
2.1.2. Uma visão ainda mais forte é obtida pelo livro best-seller, The World is Flat: A Brief History of the 21st Century.
2.1.2.1. Ele pinta um quadro do mundo futuro que foi “achatado” por comunicações globais e serviços de entrega noturna que permitem que as peças de trabalho sejam terceirizadas de maneira econômica em qualquer lugar do mundo.
2.1.2.1.1. Os vencedores competitivos neste mundo achatado são aqueles que se
2.1.2.1.2. concentram em suas competências essenciais; proativamente inovador dentro
2.1.2.1.3. e nas extensões emergentes de suas competências essenciais; e desconstruir
2.1.2.1.4. com eficiência suas operações para permitir a terceirização de tarefas não
2.1.2.1.5. essenciais para fornecedores aceitáveis de menor custo.
2.1.3. Assim como acontece com ferrovias e telecomunicações, uma infraestrutura baseada em padrões é essencial para uma colaboração global eficaz
2.1.3.1. A maioria dos pacotes de software é orientada para o uso individual; apenas determinar a melhor forma de apoiar os grupos exigirá muita pesquisa e experimentação.
2.1.3.2. Sistemas de sistemas com uso intensivo de software
2.1.3.2.1. Historicamente (e até recentemente para algumas formas de métodos ágeis), os processos de desenvolvimento de sistemas e software e modelos de maturidade têm sido receitas para o desenvolvimento de sistemas autônomos
2.1.3.2.2. Durante a década de 1990 e início de 2000, normas como a International Organization for Standarization (ISO) / International Electrotechnical Commission (IEC) 12207 e ISO / IEC 15288 começaram a surgir sistemas situados e processos de projeto de software dentro de uma estrutura empresarial. Ao mesmo tempo, arquiteturas corporativas, como International Business Machines (IBM) Zachman Framework, Modelo de Referência para Open Distributed Processing (RM-ODP) [127] e US Federal Enterprise Architecture Framework, têm se desenvolvido e evoluído, junto com vários pacotes comerciais de Enterprise Resource Planning (ERP).
2.1.3.2.3. A chave para o desenvolvimento de SOS bem-sucedido é a capacidade de tomar decisões oportunas com um conjunto potencialmente diverso de partes interessadas, resolver rapidamente as necessidades conflitantes e coordenar as atividades de vários fornecedores que estão atualmente trabalhando juntos para fornecer recursos para o SOS, mas muitas vezes são concorrentes em outros esforços de desenvolvimento do sistema
2.1.3.3. Rational Unified Process
2.1.3.3.1. 1. Fases de Iniciação e Elaboração mais longas do que o normal, para simultaneamente projetar e validar a consistência e a viabilidade da operação, requisitos, arquitetura, protótipos e planos; selecionar e harmonizar os fornecedores; e desenvolver especificações e planos de linha de base validados para cada incremento validado.
2.1.3.3.2. 2. Incrementos curtos e altamente estabilizados da fase de construção desenvolvidos por uma equipe dedicada de pessoas que são boas em construir software de forma eficiente e eficaz para um determinado conjunto de especificações e planos.
2.1.3.3.3. 3. Um esforço dedicado e contínuo de verificação e validação (V&V) durante a fase de construção por pessoas que são boas em V&V, fornecendo feedback rápido sobre defeitos aos desenvolvedores.
2.1.3.3.4. 4. Um esforço simultâneo de rebaselining ágil por pessoas que são boas em se adaptar rapidamente a mudanças e renegociar as especificações e planos para o próximo incremento de construção.
2.2. 2020 e além
2.2.1. Tendências de abundância computacional
2.2.1.1. Supondo que a Lei de Moore se mantenha, outros 20 anos dobrando o desempenho do elemento de computação a cada 18 meses levará a um fator de melhoria de desempenho de 220 / 1,5 = 213,33 = 10.000 em 2025. Fatores semelhantes se aplicarão ao tamanho e ao consumo de energia dos elementos concorrentes.
2.2.1.2. desafios de engenharia de software para especificar suas configurações e comportamento; gerar os aplicativos resultantes; verificar e validar suas capacidades, desempenho e confiabilidade; e integrá-los em sistemas de sistemas ainda mais complexos.
2.2.1.3. a abundância computacional possibilitará abordagens de engenharia de software novas e mais poderosas. Ele permitirá um software de auto monitoramento novo e mais poderoso e computação por meio de coprocessadores on-chip para verificação de asserção, análise de tendência, detecção de intrusão ou verificação de código de prova.
2.2.1.3.1. níveis mais altos de abstração
2.2.1.4. ferramentas de software e engenharia de sistemas mais poderosas que fornecem feedback aos desenvolvedores com base
2.2.1.4.1. no conhecimento de domínio,
2.2.1.4.2. conhecimento de programação,
2.2.1.4.3. conhecimento de engenharia de sistemas ou
2.2.1.4.4. conhecimento de gerenciamento.
2.2.1.5. os benefícios adicionais da abundância computacional deve superar significativamente os desafios adicionais
2.2.2. Wild Cards: Autonomia e Bio-Computação
2.2.2.1. Agentes inteligentes cooperativos que avaliam situações, analisam tendências e negociam cooperativamente para determinar os melhores cursos de ação disponíveis.
2.2.2.2. Software autônomo, que usa técnicas de controle adaptativo para se reconfigurar para lidar com situações de mudança.
2.2.2.3. Técnicas de aprendizado de máquina, que constroem e testam modelos de situação alternativos e convergem em versões de modelos que melhor guiarão o comportamento do sistema.
2.2.2.4. Extensões de robôs em escalas convencionais à nanotecnologia com recursos de autonomia, como os acima
2.2.2.5. As combinações de biologia e computação incluem:
2.2.2.5.1. Computação baseada em biologia, que usa fenômenos biológicos ou moleculares para resolver problemas computacionais além do alcance da tecnologia baseada em silício.
2.2.2.5.2. Aprimoramento baseado em computação das capacidades físicas ou mentais humanas, talvez embutidas ou anexadas a corpos humanos ou servindo como hospedeiros robóticos alternativos para (porções de) corpos humanos.
2.2.2.6. os principais benefícios que podem ser derivados de tais capacidades
2.2.2.6.1. como trabalho artificial, compensação de déficit humano
2.2.2.6.2. controle adaptativo do ambiente ou redesenho o mundo para evitar os problemas atuais e criar novas oportunidades.
2.2.2.7. o histórico de previsões da inteligência artificial mostra que é fácil superestimar a taxa de progresso da IA. Mas uma boa parte da tecnologia de IA está em funcionamento hoje e, como vimos com a Internet e a World Wide Web, também é fácil subestimar as taxas de progresso de TI. É provável que as previsões mais ambiciosas acima não ocorram até 2020, mas é mais importante manter os potenciais positivos e negativos em mente na experimentação orientada ao risco com capacidades emergentes nessas áreas curinga entre agora e 2020.