Melhorias de Processos de Software

Melhorias de Processos de Software

1. Processo: usa sequência de etapas que caracterizam o comportamento de uma pessoa, ou uma equipe de pessoas, no desenvolvimento de um sistema;

   • Roteiro: usa sequência de etapas que caracterizam o comportamento de uma pessoa, ou uma equipe de pessoas, no desenvolvimento de um sistema;
   • Metodologia: que contém um conjunto de atividades, tarefas, eventos e práticas, realizadas de maneira ordenada.
   • Conjunto de atividades de Processo
     • Pressman e Maxim (2020)
       • Comunicação; Planejamento; Modelagem; Construção; Entrega.
     • Sommerville (2019)
       • Especificação; Desenvolvimento; Validação; Evolução

2. Artefatos: são os programas, os documentos e os dados produzidos de acordo com a metodologia adotados no desenvolvimento

3. Modelo Prescritivo de Processo de Software: um conjunto de elementos que inclui ações de Engenharia de Software, produtos de trabalho e mecanismos que garantam a qualidade e o controle de modificações em cada projeto necessárias para o desenvolvimento de um sistema de software (PRESSMAN; MAXIM, 2020).

4. Metodologia Cascata

   • É um modelo de desenvolvimento documentado por Winston Royce, em 1970. Estabelece uma abordagem sistemática linear para o desenvolvimento de software, que começa no nível de sistema e avança por meio das fases de análise, projeto, codificação, testes e manutenção. Essa metodologia foi a primeira a ser proposta e é conhecida como metodologia clássica ou tradicional. As atividades são realizadas de forma linear e sequencial. Quando uma fase de desenvolvimento estiver completa, o desenvolvimento prossegue para a próxima fase, e não há retorno.
     • É fácil de entender e planejar; Funciona para projetos pequenos e bem compreendidos; A análise e o teste são simples e diretos.
     • Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe. As iterações sempre ocorrem e não são devidamente tratadas nessa metodologia; A prática tem mostrado que é raro o cliente conseguir declarar todas as exigências (requisitos e restrições), de forma explícita, na primeira fase dessa abordagem. O método cascata exige isso e impõe dificuldades de acomodar a incerteza natural que existe no começo de muitos projetos; O sistema não estará disponível até um a fase final do cronograma do projeto. Caso um erro grave não tenha sido detectado até a etapa final, pode ser desastroso. Um retorno à fase inicial terá um alto custo.

5. Metodologia Incremental e Interativa

   • Nesse modelo de desenvolvimento, o fluxo das atividades já conhecidas no modelo cascata é repetido a cada incremento, gerando versões intermediárias. Essa prática permite que, ao término de cada versão, o cliente tenha a possibilidade de analisar o que foi feito naquela entrega. Eventualmente, podem ser solicitadas alterações na versão apresentada, inclusive prevendo adicionar novas funcionalidades. Essas atividades se repetem de forma cíclica, até a versão final entregue ao cliente.
     • É útil quando não há mão de obra disponível para uma implementação completa dentro do prazo comercial de entrega estabelecido pelo projeto; O custo de acomodar as mudanças nos requisitos do cliente é reduzido.
     • O processo completo não é visível, tornando algumas métricas e medidas de progresso imprecisas. Isso pode afetar o cronograma e o custo, dificultando a gestão do projeto; A estrutura do sistema tende a degradar, aumentando o risco de o sistema se tornar uma “colcha de retalhos”; Além das mudanças no código-fonte, com estruturas de dados e algoritmos utilizados, aumenta a dificuldade de documentar e rastrear sistematicamente as alterações.

6. Prototipação

   • O modelo de prototipação é semelhante ao incremental, que vimos no item anterior, com a diferença de que os protótipos são criados para ajudar na compreensão dos requisitos e depois devem ser descartados. A metodologia de prototipação é própria para desenvolver um produto que pode evoluir ao longo do tempo. As atividades são organizadas em um fluxo que começa com a definição de objetivos gerais, identificação de áreas que precisam de mais definições e realização de um projeto rápido (protótipo), concentrando-se mais nos aspectos visíveis do sistema. A cada iteração, o protótipo será usado para melhorar o entendimento das necessidades do cliente e refinar os requisitos. Para criar rapidamente o protótipo, além dos conjunto reduzido de requisitos de cada interação, podemos utilizar ferramentas que aceleram o desenvolvimento, tais como geradores de código, de relatórios e de telas. Notamos também que as atividades são prescritivas.
     • O impacto das alterações aos requisitos é reduzido;O cliente se envolve bastante e desde o início; Funciona bem para projetos pequenos; A probabilidade de rejeição do produto é reduzida.
     • O cliente vê o que parece ser uma versão executável, mas não vê que o funcionamento é precário; Em geral, um protótipo não se preocupa com qualidade ou manutenibilidade em longo prazo; Cliente e desenvolvedor devem concordar que o protótipo será construído para definir os requisitos e, depois, descartado; Existe o risco de liberar para a produção um produto instável, já que a equipe pode ser pressionada a fazer ajustes no protótipo e liberá-lo em vez de construir a versão final, O modelo dificulta a previsão de término do projeto e a gerência do processo, já que é difícil avaliar quando cada fase foi efetivamente concluída e quantas fase serão necessária até que os usuários estejam satisfeitos.;

7. Metodologia Espiral

   • Um dos pioneiros na Engenharia de Software, Barry Boehm, propôs uma metodologia que herda conceitos da prototipação e do modelo sequencial. O modelo em espiral tem uma natureza incremental e organiza o desenvolvimento em um processo que combina interação e prototipação com os aspectos controlados do modelo sequencial. Nessa metodologia, é utilizada a prototipação para reduzir os riscos em qualquer estágio da evolução. Os desenvolvedores mantêm a abordagem do ciclo de vida clássico incorporada em uma estrutura iterativa, além de exigir a consideração direta dos riscos antes que se tornem problemas. Alguns autores, como Sommerville, classificam como modelo dirigido por riscos. É uma abordagem realista para sistemas de grande porte, que permite que se reaja aos riscos em cada nível do software.
     • Um dos pioneiros na Engenharia de Software, Barry Boehm, propôs uma metodologia que herda conceitos da prototipação e do modelo sequencial. O modelo em espiral tem uma natureza incremental e organiza o desenvolvimento em um processo que combina interação e prototipação com os aspectos controlados do modelo sequencial. Nessa metodologia, é utilizada a prototipação para reduzir os riscos em qualquer estágio da evolução. Os desenvolvedores mantêm a abordagem do ciclo de vida clássico incorporada em uma estrutura iterativa, além de exigir a consideração direta dos riscos antes que se tornem problemas. Alguns autores, como Sommerville, classificam como modelo dirigido por riscos. É uma abordagem realista para sistemas de grande porte, que permite que se reaja aos riscos em cada nível do software.
     • Gerenciamento de Riscos no Núcleo: Cada ciclo da espiral começa com uma análise detalhada dos riscos técnicos, gerenciais ou financeiros. Isso evita surpresas desagradáveis nas fases finais.Alta Flexibilidade de Requisitos: Mudanças e novas necessidades dos clientes são incorporadas facilmente de um ciclo para o outro sem a necessidade de reestruturar todo o sistema.Envolvimento Constante do Cliente: As partes interessadas avaliam os protótipos e versões parciais ao final de cada iteração, garantindo que o produto final atenda às expectativas reais do negócio.Ideal para Projetos Complexos e Grandes: A divisão do sistema em partes menores e progressivas facilita o controle de projetos de missão crítica, como softwares médicos ou sistemas aeroespaciais.Aprendizagem Contínua: O Modelo Espiral no Desenvolvimento de Software trata o projeto como um processo de evolução, onde decisões técnicas tornam-se mais precisas a cada volta da espiral.

8. Modelo baseado em componentes

   • compõe aplicações a partir de componentes previamente preparados. A modelagem e a construção começam com a identificação dos componentes candidatos. Os componentes podem ser projetados como módulo de software de ambientes de desenvolvimento ou pertencentes a repositórios especializados em aplicações para domínios específicos. Permite que um projeto tenha atividades em paralelo e, por utilizar componentes testados, consome menos tempo na fase de testes.
     • Redução de até 70% do prazo do ciclo de desenvolvimento; 84% de custo menor do que um projeto desenvolvido com métodos convencionais;
   • Métodos formais
     • esse modelo abrange um conjunto de atividades que levam à especificação matemática formal do software de computador. Utiliza notações matemáticas que permitem a especificação, o desenvolvimento e a verificação de softwares. Esse modelo permite a eliminação de muitos dos problemas difíceis de serem resolvidos pelos outros paradigmas da Engenharia de Software, como ambiguidade, inconclusão e inconsistência.
       • esse modelo abrange um conjunto de atividades que levam à especificação matemática formal do software de computador. Utiliza notações matemáticas que permitem a especificação, o desenvolvimento e a verificação de softwares. Esse modelo permite a eliminação de muitos dos problemas difíceis de serem resolvidos pelos outros paradigmas da Engenharia de Software, como ambiguidade, inconclusão e inconsistência.

Imagens e arquivos do mapa