GGI033 - Aula 02 - 2019-2

Componentes do Software

• Componentes do Software
  • Um sistema informatizado é formado por dois tipos de componentes:
    • Executáveis em máquina e
    • Não executáveis em máquina
  • Os componentes do software devem mapear as exigências do cliente em código executável.

• Conceitos:
  • Hardware: Estrutura computacional composta por circuitos eletrônicos (processador, memória, portas de entrada/saída, etc.) e periféricos eletro-óptico-mecânicos (teclados, mouses, discos rígidos, unidades de entrada e saída como USB, HDMI, etc.).
    • Questão: É importante que o GI tenha conhecimentos sobre capacidade, processamento e escalabilidade de hardware?
  • Software: Produto que profissonais de software desenvolvem, para o qual dão suporte no longo prazo. Abrange programas executáveis em um computador de qualquer porte ou arquitetura, conteúdos (apresentados à medida que os programas são executados), informações descritivas tanto na forma impressa (hard copy) ou na forma virtual, abrangendo praticamente qualquer mídia eletrônica.
    • Questão: O GI deve conhecer os aspectos de PaaS, SaaS, NaaS, etc?
  • Firmware: Conjunto de instruções operacionais que são programadas diretamente no hardware de equipamentos eletrônicos.
    • Questão: Noções de firmware são fundamentais para o GI?

Categorias

• Software de Sistema:
  • Desenvolvidos para atender a outros programas
    • Compiladores, IDEs, utilitários, drivers, bibliotecas, componentes de SO
      • GIT?

• Software de Aplicação:
  • Programas que solucionam uma necessidade específica de negócios
    • Financeiro, planilha, contabilidade, Folha de pagamento, etc
      • Evolução para ERP?

• Software de engenharia/científico:
  • Ampla variedade de programas de "cálculo em massa"
    • Astronomia, biologia molecular, análise genética, meteorologia, etc
      • Performance?

• Software embarcado:
  • Residente num sistema ou produto e utilizado para implementar e controlar características ou funções para o usuário e para o próprio sistema.
    • Painel de micro-ondas, computador de bordo de automóveis, firmware de equipamentos telecom, etc
      • IoT?

• Software para linha de produtos:
  • Projetado para prover capacidade específica de utilização por muitos clientes diferentes
    • Controle de inventário, bancos, saúde, público, Tele-atendimento, etc
      • Acesso simultâneo?

• Aplicações Web/Mobile:
  • Categoria de software voltada às redes, navegadores e software residente em dispositivos móveis
    • Apps, Aplicações em HTML, CSS, PHP, etc
      • Nativo, responsivo??

• Software de Inteligência Artificial:
  • Faz uso de algoritmos não-numéricos para solucionar problemas complexos que não são passíveis de computação ou de análise direta
    • Robótica, Sistemas especialistas, reconhecimento de padrões, Machine Learning, redes neurais, prova de teoremas e jogos
      • Complexo?

• Software ...

Principais Problemas

• Estimativas de prazo (meses, anos) e custo imprecisas
  • BP?
• Produtividade abaixo da praticada pelo mercado
  • BP?
• Software de baixa qualidade (erros e não conformidades com requisitos que tiram a confiança do cliente sobre o produto)
  • Satisfação do usuário?
• Não se dedica tempo para coletar dados sobre o software e seu processo de desenvolvimento. Com poucos dados históricos como guia, as estimativas têm sido “a olho”, com resultados previsivelmente ruins.
  • Figura
• Sem nenhum indicador sólido de produtividade, não poderemos avaliar com precisão a eficácia de novas ferramentas, métodos, padrões ou processos.
  • Inovação?
• A insatisfação do cliente com o sistema “concluído” ocorre muito freqüentemente.
  • Perda do cliente, seja interno ou externo
• Os projetos de desenvolvimento de software normalmente são levados a efeito apenas com um vago indício das exigências do cliente.
  • Constrangimento na entrega
• A comunicação entre o cliente e o desenvolvedor de software freqüentemente é muito fraca.
  • Metodologia?
• A qualidade do software freqüentemente é suspeita. Somente agora estão começando a ser seguidos conceitos quantitativos sólidos de confiabilidade e de garantia de qualidade de software.
  • Clientes cada vez mais exigentes
• Só recentemente começamos a entender a importância dos testes de software sistemáticos e tecnicamente completos.
  • Gestor de Qualidade?
• O software existente pode ser muito difícil de manter. A tarefa de manutenção de software devora a maioria de todos os recursos financeiros destinados a ele. A capacidade de manutenção de software não foi enfatizada como um critério importante para a aceitação do software.
  • Altos custos pós-entrega

Causas

• Gerentes sem vivência em:
  • Projetos e seus marcos de evolução
  • Métodos efetivos de controle
  • Tecnologias que se modificam rapidamente
  • Os programadores ou engenheiros de software têm pouca instrução formal, holística e estudam pouco as técnicas de desenvolvimento e as áreas de negócio.
  • Cada pessoa aborda a tarefa de “escrever programas” com a experiência advinda de esforços passados. Algumas pessoas desenvolvem uma abordagem ordeira e eficiente, mesmo por tentativa e erro, mas muitas criam maus hábitos, que resultam em qualidade e manutenibilidade deficientes.
  • Resistência às inevitáveis mudanças
  • É irônico que enquanto o hardware experimenta enormes mudanças, as pessoas da área de software responsáveis pelo aproveitamento desse potencial, muitas vezes se oponham à mudança quando ela é discutida e resistam a ela quando ela é introduzida.

Evolução do Software

• Uma abordagem referente ao Manifesto do Século XX

No século xx, Meir Manny Lehman ja havia formalizado 8 leis em relação à evolução do software que começaram a serem descritas na década de 70 (conhecido como o manifesto do século xx). Tais leis apresentavam uma abordagem condizente à época, não falava de pessoas, detinha-se a uma abordagem técnica.

• As oito leis de Lehman

A formulação das leis de Lehman foi baseada inicialmente na evolução de dois sistemas operacionais (IBM OS/360 e ICL VME Kernel), um sistema financeiro (Logica FW), um sistema de telecomunicações (Lucent) e um sistema de defesa (Matra BAE Dynamics).

Década de 70: Formulação das três primeiras leis:

• • I - Mudança contínua

Esta primeira lei explica que os sistemas devem se comportar de modo que seu processo de desenvolvimento deve levar como princípio a capacidade de adaptação e adequação. Uma comparação que podemos fazer é que os sistemas sofrem o mesmo processo que os humanos de envelhecimento por estarem inseridos no domínio do mundo real que apresenta contínua evolução.

• • II - Complexidade crescente

Se o software for alterado sem se preocupar com seu nível de complexidade (manter ou reduzir) ao longo das transformações, a cada mudança a estrutura original se tornará mais fragmentada, e o custo de novas mudanças aumentará gradativamente, até o momento em que estes custos não mais serão viáveis. Caso isso aconteça será necessário uma reestruturação do software para que a complexidade diminua.

• • III - Autorregulação

A curva de evolução de um software é auto regulável e se assemelha a uma distribuição normal. Portanto, de acordo com os atributos do processo e medidas do produto, essa evolução atinge seu patamar até que começa a decair. Os controles de retorno positivos e negativos dos pontos de controle são um exemplo de mecanismos de estabilização.

Década de 80: Formulação das duas seguintes:

• • IV - Conservação da estabilidade organizacional

Durante o ciclo de vida de um programa,sua taxa de desenvolvimento é quase constante. Alocação de grandes equipes é improdutivo, pois o overhead de comunicação predomina.

• • V - Conservação da familiaridade

A taxa de evolução de um software tende a seguir o nível de domínio do assunto que a equipe profissional possui. Portanto é imprescindível que a equipe esteja sempre informada com as tendências tecnológicas que ocorrem ao longo do planeta.

Década de 90: Formulação das últimas três:

• • VI - Crescimento contínuo

Durante o ciclo de vida do software, todo seu conteúdo funcional deve ser continuamente ampliado para manter a satisfação dos usuários. Vale ressaltar que essas mudanças podem ser correções de erros, adições de novas funcionalidades ou melhorias em funções pré-existentes.

• • VII - Qualidade decrescente

O software criado para um determinado fim atenderá àquela demanda naquele momento. Pelo fato do mundo não ser estático, mudanças sempre serão necessária para atender a novas demandas. Caso tais mudanças não sejam feitas, a qualidade do software irá ficar cada vez mais comprometida dentro de seu ciclo de vida útil.

• • VIII - Sistema de retorno (feedback)

Manter o software em funcionamento pleno com seus requisitos funcionais e não funcionais operantes, requer um sistema de retroalimentação de informação capaz de suprir a necessidade pela busca de perguntas como "O que melhorar?"; "O software está acompanhando a evolução tecnológica do mercado ?".

• Leitura complementar

No final do século XX, o mundo passava por uma inovação tecnológica jamais vista fazendo com que houvesse a necessidade dos softwares terem uma abordagem mais humana, pois ele deixou de ser algo restrito apenas às grandes empresas tendo importante papel estratégico em todas além de estar presente na vida das pessoas. Por essas razões, tornou-se mais interativo, envolvente e sofisticado, para que pudesse ser amplamente comercializados.No início do século XXI uma nova vertente no processo de evolução de software ganhou destaque na literatura e ficou conhecida como "Manifesto Ágil".

O Manifesto dizia: "Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:"

- Indivíduos e interação entre eles mais que processos e ferramentas;

- Software em funcionamento mais que documentação abrangente;

- Colaboração com o cliente mais que negociação de contratos;

- Responder a mudanças mais que seguir um plano.

Se o que está procurando é um contexto histórico da evolução do software, destaco uma das páginas ativas aqui do Wiki para complementação dos estudos: ESOF - 02/03/11

• Referências usadas na pesquisa:
  • Livro: Software evolution and Feedback: Theory and Practice[1]
  • Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson Education, 2011.

Crise do Software

O que é crise de software? O termo “Crise de Software” foi dado por alguns participantes da primeira Conferência de Engenharia de Software da OTAN em 1968 em Garmisch, Alemanha. Além disso o termo é usado nos primórdios da ciência da computação pela dificuldade de escrever programas de computador eficientes no tempo hábil.

Causas da Crise do Software

- Projeto que ultrapassa o valor do orçamento - Projeto em execução acima do prazo estipulado - O software prova ser ineficiente - O software geralmente não atende ao requisitos - Manutenção do código difícil - O software nunca entregue

No final da década de 1960, os custos de hardware haviam caído exponencialmente, enquanto o custo do desenvolvimento de software aumentava na mesma velocidade.

Casos que ocorreram relacionado a crise do software:

1) O apagão (blackout) de 2003 foi uma queda de energia generalizada que ocorreu em partes do Nordeste e Meio-Oeste dos Estados Unidos e em Ontário, Canadá ocorrido em 14 de agosto de 2003. Totalizando 55 milhões de pessoas que foram afetadas pelo apagão sendo 10 milhões no Canadá e 45 milhões nos Estados Unidos. Foi determinado que a principal razão por trás da falha era um bug no sistema de monitoramento e gerenciamento de energia. Prejuízo estimado: $7 - $10 bilhões de dólares

2) Bug do Milênio - O ano 2000 (Y2K) refere-se às dificuldades no processamento das datas após o ano 2000. As raízes do problema Y2K começam em 1960 quando os desenvolvedores encurtaram o formato de data de 4 dígitos como 1972 para um formato de 2 dígitos como 72 por causa da memória limitada. Naquela época, eles não perceberam que o ano 2000 será encurtado para 00, o que é menos de 72. Na década de 1990, os especialistas começaram a perceber essa grande deficiência na aplicação do computador e aproximadamente 200 bilhões de dólares foram gastos para lidar com esse problema.

3) Em 1996, o foguete espacial desenvolvido pela Airbus chamado de Ariane 501, desenvolvido ao custo de US$ 7 Bilhões ao longo do período de 10 anos, foi destruído em menos de um minuto após seu lançamento. O acidente ocorreu porque havia um bug no sistema de orientação de foguetes.

Depois de alguns casos citados acima, existe a crise do software atualmente?

Há 25 anos, o Standish Group estuda projetos de TI. Ao longo desse tempo, a pesquisa CHAOS já estudou mais de 70 mil projetos de TI realizados. É uma organização internacional de consultoria de pesquisa com foco no desempenho de projetos de software. Eles lançam relatórios anuais que analisam o estado da indústria de desenvolvimento de software. Eles estudam todos os tipos diferentes de projetos de software de todo o mundo e analisam uma ampla gama de informações sobre cada projeto (CHAOS).

Uma das coisas que eles olham é a taxa de sucesso dos projetos. Eles classificam os projetos em três categorias: bem-sucedidos, desafiados e fracassados. Desafiados significa que o projeto foi entregue, mas houve problemas significativos devido ao custo, cronograma ou por algum outro motivo. Em 2004, 29% dos projetos foram bem sucedidos, 53% foram desafiados e 18% falharam. Em 2015, os resultados foram essencialmente os mesmos, com 29% tendo sido bem sucedidos, 52% considerados desafiados e 19% tendo falhado (Hastie).

O fato é os mesmos problemas existiram desde a década de 1960 e a taxa de sucesso do software não teve quase nenhuma melhora ao longo dos anos, tornando a crise do software existindo principalmente depois do surgimento da Internet até os dias atuais, pois a falta do avanço significativo no desenvolvimento do software impede um alinhamento o que torna a crise do software tão evidente são a demanda das empresas por dados gerados por pessoas com dispositivos móveis, sensores, aplicativos e os ataques cibernéticos.

Erro ao criar miniatura: Arquivo não encontrado

Ataques Cibernéticos em 2018

---

Referências: Livro: Engenharia de Software - Roger S. Pressman Standish Group - http://www.standishgroup.com Checkpoint - https://research.checkpoint.com

Material de apoio

• Original :))
  • PRESSMAN, Roger S. MAXIM, Bruce R. Engenharia de Software. Uma abordagem profissional. 8a. edição. 2016.
  • REZENDE, Denis A. Engenharia de Software e Sistemas de Informação. BrasofBrasport. 3a. edição. 2005.
• Cópias :((
  • www.inf.pucrs.br/~michael/aulas/espe_gest_ti/IntroEngSW.pdf
  • file:///home/lclaudio/Downloads/Engenharia%20de%20Software.pdf
  • 177.8.219.7:8081/sites/professor/pastas/andrea/.../aula1.ppt
  • www2.dbd.puc-rio.br/pergamum/tesesabertas/0210500_04_cap_03.pdf

Colaboração na Wiki

• Edição a vontade de complementações ao conteúdo da Aula 02
  • Atenção para a formatação do texto
• Valendo pontos:
  • Evolução do Software: Aluno selecionado: Igor Fernando Ferreira
  • Crise do Software: Aluno selecionado: Alex M. K. Wai

Questões

• 01. Para qual das situações abaixo, podemos pressupor que temos um bom software? Por quê?
  • A. O Facebook teve seus dados invadidos, copiados e enviados para vários destinos.
  • B. Muito calor, os discos ficaram sobreaquecidos mas ainda assim o sistema continuou funcionando normalmente.
  • C. Software que faz a programação de velocidade da escada rolante acelerou subitamente.
  • D. Desenvolvedor mudou de empresa e quem assumiu não conseguiu entender a documentação para dar sequência ao trabalho.
  • E. Incêndio na matriz que mantém os servidores provocou parada generalizada nos sistema de usuários no mundo todo.
  • F. Funcionário alterou seu salário e no final do mês recebeu além do que deveria.
  • G. Saldo ficou gravado de forma incorreta porque a energia apagou na hora da atualização.
  • H. Atendente foi registrar paciente mas sistema não funcionou porque link estava fora do ar.
  • I. Sistema que controla o enchimento das garrafas de refrigerante colocou quantidade de líquido abaixo do exigido.
• 02. Qual o meio-termo entre Software de Prateleira e Software-Taylor-made?
  • R:
• 03. Qual a diferença entre software livre e software open-source?
  • R: