Para isso, existem três etapas fundamentais:

Definição

Nesta primeira etapa é desenvolvida uma análise prévia do sistema e a modelagem de processos.

Desenvolvimento

Já, neste segundo momento, questões de desenvolvimento são o foco. Ou seja, codificação, prototipagem, testes, design, integração, entre outros.

Operação

Por fim, na operação o software já está num estágio mais avançado, em uso pelos consumidores. Então, é necessário atuar corrigindo falhas, adaptando o sistema a novas funcionalidades e o que mais for necessário enquanto ele não for descontinuado.

Modelo cascata

Um dos mais antigos e conhecidos, desenvolvido entre as décadas de 1960 e 1970. Entretanto, apesar de antigo, ainda é utilizado nos dias atuais.

Neste modelo, as etapas são sequenciais, portanto, entende-se que antes de prosseguir para as próximas fases, a atual deve ser completada.

Consequentemente, é necessário prezar pela análise e definição de objetos, além de planejar e estruturar o projeto de desenvolvimento com antecedência, etc.

Neste sentido, o grande ponto positivo é que ele é fácil de entender e de executar. No entanto, ele é muito mais rígido do que os mais atuais, e adaptar mudanças pode ser um problema considerável.

Modelo espiral

Criado no final da década de 1980, e seus princípios básicos se distinguem bastante do modelo anterior.

Isto porque ele funciona na forma de uma espiral, ou seja, cada volta é uma etapa cumprida no projeto, sem fases fixas, sendo tudo tratado como cíclico.

Tornando-se importante a divisão da espiral em setores. Entre eles, por exemplo, a definição de objetivos, a análise de riscos, a prototipagem de funcionalidades, a escolha do modelo de desenvolvimento, a avaliação dos resultados, etc.

Uma similaridade com o anterior é que ele também é considerado rígido e com pouca margem para mudança. De forma complementar, há aqui uma necessidade de contato constante da equipe para definir as etapas.

Modelo incremental

Este modelo também foi desenvolvido durante a década de 1980, com a finalidade de aprimorar o modelo cascata.

Seu objetivo era maximizar a satisfação do cliente, mantendo um contato constante entre ele e a equipe de desenvolvedores.

Uma das principais adições ao modelo antigo é que, uma vez que uma etapa é finalizada, o cliente deverá receber uma amostragem do funcionamento do software.

Como consequência, o feedback do cliente é constante, o que tende a aumentar a sua satisfação. Outro ponto positivo é que se houver um erro, é relativamente fácil de consertar, pois basta descartar a última atualização.

Modelo evolutivo

Da mesma forma que o modelo anterior, no evolutivo há um contato constante com o cliente. Neste sentido, ele é bastante flexível e também permite melhorias a cada feedback realizado, sem tanta rigidez como nos modelos anteriores.

Ela estabelece uma estrutura comum para os procedimentos de desenvolvimento de software e aquisição, com o objetivo de orientar as empresas a compreender todos os elementos envolvidos na aquisição, desenvolvimento e distribuição de software, a fim de que elas possam estabelecer contratos e executar projetos de maneira mais eficiente.

Um processo é um conjunto de tarefas relacionadas, sendo uma sequência de ações executadas para um determinado objetivo/resultado.

O processo envolve técnicas, técnicas, ferramentas e pessoas. Um processo pode ser descrito de duas formas: por objetivo ou resultado e por atividade. Uma tarefa é um conjunto de tarefas.

Uma tarefa é uma ação que envolve entradas e saídas. Pode ser uma exigência (deve, shall), recomendação (deve, should) ou permissão (pode, may)

Além disso, a norma não tem nenhuma relação com métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Essa determinação é benéfica para permitir que a norma seja difundida globalmente e para monitorar o progresso da Engenharia de Software em diferentes culturas empresariais.

Os procedimentos da ISO/IEC 12207 são modulares, ou seja, são altamente coesos e de baixa acoplagem. Isto quer dizer que todos os elementos de um processo estão fortemente ligados, mas a quantidade de interfaces entre os processos é baixa, o que diminui a dependência de forma que possam ser implementados sem maiores dificuldades.

Os processos são organizados/categorizados, por uma questão de organização, de acordo com a sua natureza, ou seja, o seu objetivo principal no ciclo de vida de software. Essa organização resultou em quatro categorias distintas de processos, que são:

• Os processos cruciais;

• Método de suporte;

• Processos de organização;

• Processos de adaptação e adaptações.

• Aquisição: adquirir o produto e/ou serviço que satisfaça suas necessidades.

• Fornecimento: fornecer produtos e/ou serviços;

• Criação: transformação de um conjunto de requisitos em um produto ou sistema de software.

• Operação: operar o produto no seu ambiente e dar assistência aos clientes.

A manutenção consiste em modificar o programa e, em seguida, liberá-lo para uso.

• Documentação: fornecer e manter registros de dados do software.

• Gerência de Configuração: assegurar a integridade de todos os produtos de trabalho (artefato) de um processo do projeto.

• Garantia da Qualidade: assegurar que os produtos e processos estejam de acordo com os requisitos (padrões/normas) pré-definidos.

• Verificação: confirmar se os produtos e/ou serviços atendem aos requisitos especificados.

• Revisão Conjunta: manter o entendimento (gerencial comum com os investidores)

• Auditoria: avaliar independentemente a conformidade dos produtos e procedimentos com os requisitos estabelecidos.

• Resolução de Problemas: garantir que todos os problemas levantados sejam avaliados e resolvidos. Aumentar a facilidade de utilização dos produtos e/ou serviços. Realizar e manter procedimentos de gerenciamento de mudanças.

• Avaliação do Produto: assegurar, através de análise e medição sistemáticas, que o produto e/ou serviços atendem às necessidades especificadas (explícitas) e implícitas dos clientes.

Os seguintes são:

• Gerência: organizar, monitorar e controlar a iniciação e o desempenho dos processos;

• Infraestrutura: manter uma infraestrutura estável e confiável;

• Melhoria: estabelecer, avaliar, controlar e melhorar um processo de ciclo de vida de software;

• Recursos Humanos: prover e manter recursos humanos adequados mantendo as suas capacitações consistentes com o negócio.

• Gestão de Ativos: abrange desde a concepção até a desativação;

• Gestão de Programa de Reuso: gerenciar, estabelecer, monitorar e monitorar os programas de reuso;

• Engenharia de Domínio: criar e manter modelos, arquiteturas e ativos relacionados a esse campo..

  
  

O SPICE leva em conta tanto a melhoria dos procedimentos dentro da própria empresa quanto a determinação da habilidade do processo. Sendo assim, a norma tem requisitos para modelos de referência de processos (PRM) para descrição de processos, bem como para modelos de avaliação de processos (PAM) com critérios e métodos para a sua avaliação.

A dimensão de maturidade, que divide um processo de desenvolvimento em seis estágios de "incompleto" a "otimizado", é vista como um elemento extremamente útil para a prática. Desde 2015, a ISO tem repassado o conjunto de regras em dez partes para a nova série de normas ISO/IEC 330xx.

O SPICE apresenta um modelo de referência que serve como guia para a avaliação. Este modelo é um conjunto de processos fundamentais que orientam uma boa engenharia de software. Este modelo é dividido em cinco grandes categorias de processo: Cliente-Fornecedor, Engenharia, Suporte, Gestão e Organização. Todas essas categorias são detalhadas em procedimentos mais específicos. A norma ISO/IEC 15504 descreve detalhadamente tudo isso.

• Fornecedor do cliente;

• Engenharia;

• Suporte;

• Gestão;

• Organização.

ALMEIDA, Washington. T.I em foco: ISO/IEC 12207. Disponível em: https://blog.grancursosonline.com.br/t-i-em-foco-iso-iec-12207/. Acesso em 23 abr. 2024.

CMMI (Capability Maturity Model Integration). Disponível em: https://www.devmedia.com.br/cmmi-capability-maturity-model-integration/3530. Acesso em 23 abr. 2024.

ISO/IEC 15504. Disponível em: https://pt.m.wikipedia.org/wiki/ISO/IEC_15504#:~:text=Este%20modelo%20é%20um%20conjunto,detalhada%20em%20processos%20mais%20específicos. Acesso em 23 abr. 2024.

Certificação ISO/IEC 15504 (SPICE). Disponível em: https://www.dqsglobal.com/pt-br/certifique/certificacao-iso-iec-15504-spice. Acesso em 23 abr. 2024.

ISO/IEC 12207. Disponível em: https://pt.wikipedia.org/wiki/ISO/IEC_12207. Acesso em 23 abr. 2024

O primeiro passo é identificar, através de um método criado pelo SEI (SCAMPI – SEI Members of the Assessment Method Integrated Team, 2001) e conduzido por um avaliador credenciado, o estágio em que a organização está no presente; uma vez que este indica um nível de maturidade a ser alcançado pelas companhias, com o objetivo de ajudá-las no desenvolvimento e manutenção dos projetos de software, bem como melhorar a capacidade de seus processos.

Após a verificação do estágio da organização, é possível determinar qual a próxima etapa a ser cumprida e quais as competências que devem ser adquiridas neste processo. Essa etapa é crucial, pois possibilita alcançar êxito e, consequentemente, aprimorar a qualidade dos serviços e produtos oferecidos pela área de tecnologia da empresa.

CMM’s são diferentes em:

• Disciplina (e.g., software engineering, system engineering);

• Estrutura (e.g., staged, continuous);

• Definição de maturidade (i.e., process improvement path).