wiki

GGI033 - Aula 02 - 2020-1

Estrutura de suporte ao software


  • Para que um software possa rodar numa máquina ...


  • Existem várias possibilidades:


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
        • Bots?
  • Software ...


Principais Problemas


  • Estimativas de prazo (meses, anos) e custo imprecisas
    • BP?
  • Produtividade da equipe abaixo do que era previsto
    • Metodologia?
  • Software de baixa qualidade (erros e não conformidades com requisitos que tiram a confiança do cliente sobre o produto)
    • User Experience?
  • 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.
    • Planejamento?
  • Falta de prospecção e planejamento de novas ferramentas, novas soluções, novas metodologias pode tornar o sistema obsoleto rapidamente.
    • 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.
    • Processo?
  • 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 como opção para o GI?
  • 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.
    • Custos após entrega não previstos


Causas

  • Gestores sem vivência em:
    • Projetos e seus marcos de evolução
    • Métodos efetivos de controle
    • Tecnologias que se modificam rapidamente
  • Desenvolvedores:
    • Pouca instrução formal, holística e defasagem nas técnicas de desenvolvimento e envolvimento com áreas de negócio.
    • Maus hábitos que resultam em qualidade e manutenibilidade deficientes.Cada dev aborda a tarefa de “escrever programas” com a experiência advinda de esforços passados. Alguns desenvolvem uma abordagem ordeira e eficiente mesmo por tentativa e erro.
    • Resistência às inevitáveis mudanças
  • Ironia:
    • Enquanto o hardware experimenta enormes mudanças, as pessoas da área de software responsáveis pelo aproveitamento desse potencial, muitas vezes se opõem a elas.


Evolução do Software


  • Uma abordagem referente ao Manifesto do Século XX
Erro ao criar miniatura: Arquivo não encontrado
  • No século XX, Meir Manny Lehman ja havia formalizado 8 leis em relação à evolução do software que ficou 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, um sistema financeiro, um sistema de telecomunicações e um sistema de defesa

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 radical 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.
  • De acordo com os atributos do processo e medidas do produto, essa evolução atinge seu patamar até que começa a decair
  • Neste processo, existe a necessidade de se fazer um sério planejamento de manutenção até o fim do ciclo.

IV - Conservação da estabilidade organizacional

Erro ao criar miniatura: Arquivo não encontrado
  • Durante o ciclo de vida de um programa,sua taxa de desenvolvimento é quase constante
  • Na curva de subida, a alocação de grandes equipes é improdutiva


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
  • É imprescindível que a equipe esteja sempre informada com as tendências tecnológicas que ocorrem ao longo do planeta


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

Erro ao criar miniatura: Arquivo não encontrado
  • 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árias 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.


Recentes evoluções


Pesquisa: E nas duas últimas décadas, o que aconteceu?
Pesquisador: Paloma
Data: 24/03


A evolução do software é o processo que lida com as modificações e adaptações dos softwares a novos ambientes e necessidades, que gerou a teoria das Leis de Lehman citadas a cima, a lei abandonou a noção de grandes programas em 1980 passando a usar a classificação SPE onde , S- programas (especificados) de tipo são produzidos a partir de uma estática especificação, P- programas (resolução de problemas) tenta resolver os problemas que podem ser formulados formalmente, mas que não são computacionalmente acessíveis e o E- programas do tipo (evolutivos) são reflexões de processos humanos ou de uma parte do mundo real, a sua última modificação em 1996.

Em 2000 foi criado o projeto FEAST que gerou algumas criticas as leis pela falta de formalização e ausências de definições, onde foi confirmada pelo estudo de validação feita com o Sistema de Defesa OS360/370 e o Kernel Linux de Gosfrey e Tu (2000) que foi considerado uma anomalia para Lehman como uma exceção que não encaixavam na evoluções indicadas por ele. A chamada anomalia gerou vários estudos em relações aos softwares livres ou de código aberto e se eles poderiam ser validados pelas leis, o caso do Kernel do Linux derrubou as leis por estar evoluindo em um ritmo acelerado confirmado em outros 19 projetos cinco aos depois por Robles (2005), porém em 2010 Israel e Feitelson com um estudo mais aprofundado confirmaram a maioria das Leis no Linux que circulava pelo instável e estável de acordo coma as mudanças feitas.

Por exemplo as leis relacionadas a crescimento e estabilidade, já as de complexidade crescente (diminui a partir de mais funcionalidades agregadas), conservação de familiaridade (é validada somente em casos de pequenas mudanças) e qualidade em declínio (qualidade aumenta) foram contestadas. Ou seja, o Linux começa a se encaixar em algumas das leias de acordo com o estágio encontrado de desenvolvimento e de manutenção passando para o modo linear de evolução. Outro estudo feito por Koch [2005; 2007], abordando a validade feito com uma amostra de 8621 projetos de SourceForge.net, um site de hospedagem para projetos de software livre. Ele encontrou a maioria dos projetos a crescer tanto linearmente ou com uma taxa decrescente, como previsto pelas leis. No entanto, em torno de 40% mostrou um padrão incompatível com as leis. Estes projetos foram geralmente grandes, em termos de tamanho do código, com um elevado número de participantes, e uma grande desigualdade no número de contribuições [Mockus et al. 2002].

Koch encontrou diferenças na evolução dos projetos de software livre de tamanhos diferentes [Koch de 2007], onde os pequenos que são desenvolvidos por uma única pessoa ou um pequeno grupo seguiam as leis, já grandes projetos que continham um grande número de participantes e uma elevada assimetria na divisão de atividades não seguiam. A principal conclusão do [Mockus et al. 2002], é que existem diferenças significativas na qualidade e na evolução do livre e software não-livre, onde podemos concluir que os projetos de diferentes tipos de software evoluem de forma diferente. A teoria geral evolução do software deve ser adaptado para enfrentar um princípio fundamental: o software não imutável, mas a forma como é produzido e sua manutenção também não é imutável.

Os custos com evolução ficam em torne de 85% a 90% dos custos de acordo com uma pesquisa da indústria, Erlikh (2000). Ela pode se fazer necessária por vários motivos como constantes mudanças empresariais, bugs, alterações de outros sistemas e pelo ambiente. Por exemplo uma razão de marketing pode fazer o software passar por mudanças, correções de erros ou a reengenharia de sistemas legados que necessitam se adaptar as mudanças melhorando sua estrutura e inteligibilidade podendo ser feita através de refatoração da arquitetura, redocumentação, mudança de linguagem entre outros.

As Leis de Lehman servem como um guia a longo prazo de que a mudança é continua e dão base para o estudo da evolução, mas deve ser lembrado que existem muitas variáveis internas e externas que podem interferir na evolução do software e de como ele é produzido, logo, nenhum software tem um padrão de evolução especifico a ser seguido, todo software e diferente um do outro, ou seja, também evoluíram de maneiras diferentes passando por estágios instáveis e estáveis durante a sua vida.

REFERÊNCIAS:

  • Sommerville, Ian; Engenharia de Software / Ian Sommerville ; tradução Ivan Bosnic e Kalinka G. de O. Gonçalves ; revisão técnica Kechi Hirama. — 9. ed. — São Paulo : Pearson Prentice Hall, 2011.
  • Ayelet Israeli and Dror G. Feitelson. 2010. The Linux kernel as a case study in software evolution. Journal of Systems and Software 83, 3 (2010), 485 – 501.
  • HERRAIZ, Israel - Technical University of Madrid, Spain; RODRIGUEZ, Daniel - University of Alcala, Madrid, Spain; GREGORIO ROBLES, Gregorio and M. GONZALEZ-BARAHONA, Jesus - GSyC/Libresoft, University. The evolution of the laws of software evolution. A discussion based on a systematic literature review.




Crise do Software


Pesquisa: Que evento foi esse, por que começou e qual o impacto para a área de TI?
Pesquisador: Paloma
Data: 24/03


Nas décadas de 60 e 70 os engenheiros estavam com dificuldade de escrever programas úteis e eficiente no tempo necessário o que foi chamado de a Crise do Software. A demanda e a complexidade cresciam, mas a capacidade de desenvolvimento de software não conseguia atender, a Conferência NATO software em 1968 e 9969 ajudou a identificar alguns problemas os mais comuns foram:

    • Estimativas de prazo e de custo imprecisas;
    • Produtividade das pessoas da área de software não acompanha a demanda;
    • Prazos ultrapassados;
    • Custos acima do previsto;
    • A facilidade de manutenção não era enfatizada como um critério importante, gerando assim custos de manutenção elevados;
    • Não atendimento dos requisitos do usuário;
    • 1/3 dos projetos eram cancelados;
    • 2/3 dos projetos extrapolavam o orçamento.


Um exemplo do que esses problemas podem gerar foi o desastroso primeiro voo não tripulado do foguete Ariane 5 em 1996, pela Agência Espacial Europeia que explodiu 39 segundos após o lançamento causando um prejuízo de US$ 370 milhões por um simples bug no software que gerou erros nos cálculos sobrecarregando o sistema com números mais longos do que a capacidade. A conferência também trouxe algumas possíveis soluções criando a engenharia de software onde se tem uma abordagem sistemática, disciplinada e quantificável fazendo o uso de técnicas, teorias, treinamento e ferramentas que busca seguir certas diretrizes como:

    • Redução no orçamento excedente de software;
    • A qualidade do software deve ser alta;
    • Menos tempo necessário para o projeto de software;
    • Experiência do membro da equipe de trabalho no projeto de software;
    • O software deve ser entregue.


Apesar de existir soluções para os problemas gerados na crise do software uma pesquisa feita pela organização internacional de consultoria em pesquisa com foco no desempenho de projetos de software a Standish Group, em seus relatórios anuais mostra que a taxa de sucesso ainda e muito baixa. Em 2009, 29% dos projetos tiveram sucesso, 53% foram contestados e 18% fracassaram e em 2015 a taxa de sucesso continuo a mesma e houve o aumento de 1% em fracassos (19%) deixando 52% dos softwares sendo contestados, o que indica que a crise do software ainda existe e deve continuar a ser trabalhada e solucionada.

REFERÂNCIAS:

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:


Disponível em “http://3.143.69.156/wiki/index.php?title=GGI033_-_Aula_02_-_2020-1&oldid=74219”