Exercícios de Engenharia de Software-parte01-Visão Geral da Engenharia de Software e Processo de Software

Introdução ao curso

O curso "Engenharia de Software" é o curso básico do curso de engenharia de software. É um curso abrangente que usa métodos de engenharia para orientar o desenvolvimento, manutenção e gerenciamento de software. O conteúdo envolve a teoria e a tecnologia relacionadas à análise, design, implementação e manutenção e gerenciamento de projetos. , métodos e ferramentas CASE.

programa do exame

⚫Engenharia 重点掌握de software 基本概念e 基本原理;
⚫Com base nas necessidades atuais das empresas de software da China para desenvolvimento de software, domine e seja capaz de 运用engenharia de software, 基本原理prática 软件开发技术e básica 管理技术;
⚫Disciplina 了解de engenharia de software 知识结构.

⚫(1) Conceitos de engenharia de software e elementos básicos da engenharia de software
⚫(2) Processo de software
⚫(3) Requisitos de software e especificações de requisitos de software
⚫(4) Especificações do sistema e projeto de software
⚫(5) Teste de software
⚫(6) Engenharia de software Gerenciamento⚫
(7) Qualidade de Software, Características de Qualidade e Garantia de Qualidade de Software⚫
(8) Engenharia de Software Auxiliada por Computador Ferramentas CASE e Ambiente

Conceitos de Engenharia de Software e Elementos Básicos de Engenharia de Software

modelo em cascata

Modelo de produto de software:

Modelo de Processo de Software:

O modelo de processo de software é tradicionalmente também chamado de modelo de desenvolvimento de software, que é a estrutura estrutural de todo o processo, atividades e tarefas de desenvolvimento de software. Processos de software típicos incluem modelo em cascata, modelo incremental, modelo de evolução (modelo de protótipo, modelo espiral), modelo de fonte, modelo de desenvolvimento baseado em componentes e modelo de método formal, etc.

Modelo de Projeto de Software:
Modelo de Teste de Software:

Modelo V Modelo W Modelo X Modelo H Modelo Ágil

Elementos de Qualidade de Software de Suporte CMM

A CMM acredita que os elementos que suportam a qualidade de software incluem três aspectos: processo, produto e pessoal.
Produto, processo e pessoas
Por exemplo,
o processo exige que os desenvolvedores desenvolvam software de acordo com o processo estabelecido,
o produto exige que os desenvolvedores produzam produtos que atendam às especificações
e o pessoal exige que os desenvolvedores tenham habilidades e experiência suficientes.
A combinação orgânica desses elementos pode garantir a alta qualidade do software.

A qualidade da engenharia de software depende principalmente de três fatores: métodos, ferramentas e processos, referidos como os três elementos da engenharia de software.
Method é um método técnico para concluir várias tarefas de desenvolvimento de software e fornece tecnologia "como fazer" para o desenvolvimento de software.
Uma ferramenta é um ambiente de suporte de engenharia de software automático ou semiautomático fornecido para a aplicação de um método.
O processo é a estrutura de uma série de tarefas que precisam ser concluídas para obter software de alta qualidade. Ele especifica as etapas de trabalho para concluir cada tarefa, como combinar métodos de engenharia de software com ferramentas de software e desenvolver software de maneira razoável e oportuna .

Uma declaração sobre o modelo de desenvolvimento incremental

Integrando os componentes básicos do modelo em cascata e os recursos iterativos da implementação do protótipo, várias versões disponíveis podem ser lançadas e as funções principais geralmente são concluídas primeiro. Com base nisso, haverá novos lançamentos incrementais em cada rodada de iterações e o funções principais podem ser obtidas.Totalmente testado. Enfatize que cada incremento libera um produto operacional.
Como uma variante do modelo em cascata, o modelo incremental tem todas as vantagens do modelo em cascata. Além disso, tem as seguintes vantagens:

O custo e o tempo necessários para a primeira versão entregável são pequenos; o risco assumido para desenvolver um pequeno sistema representado por um incremento é pequeno;
como a primeira versão é lançada rapidamente, há menos mudanças nos requisitos do usuário; Investimento quantitativo, ou seja, no início do projeto, você só pode investir em um ou dois incrementos.

O modelo incremental tem as seguintes desvantagens:

Se não houver planejamento para os requisitos de mudança do usuário, o incremento inicial pode causar a instabilidade do incremento subsequente;
se os requisitos não forem tão estáveis ​​e completos quanto o pensamento inicial, então alguns incrementos podem precisar ser re-desenvolvidos e relançados;
O gerenciamento dos custos incorridos, programação e complexidades de configuração pode exceder os recursos da organização.

A descrição incorreta do modelo de processo de software parece que deveria ser B

A diferença entre o modelo cascata e o modelo fonte

Atividades de Engenharia de Software:

Modelo em cascata: estipula várias atividades de engenharia de software e sua sequência fixa de conexão descendente e mútua, como uma cachoeira de água caindo passo a passo. Estudo de viabilidade, análise de requisitos, projeto geral, projeto detalhado, codificação, sistema de teste de unidade, aceitação de teste, operação e manutenção de teste, modelo de fonte: o modelo de fonte

é usado principalmente para descrever o processo de desenvolvimento orientado a objetos e a palavra "fonte" reflete o processo iterativo e contínuo do recurso de desenvolvimento orientado a objetos. Iteração significa que as atividades de desenvolvimento no modelo geralmente precisam ser repetidas várias vezes, cada repetição adicionando ou esclarecendo algumas propriedades do sistema de destino, mas não alterando substancialmente os resultados do trabalho anterior. Implícito ininterrupto significa que não há limite claro entre as atividades de desenvolvimento (como análise, design, programação), mas cada atividade de desenvolvimento pode cruzar e prosseguir iterativamente.

Modelo de Desenvolvimento de Software:

Em primeiro lugar, existem várias classificações principais de modelos de desenvolvimento: modelo de protótipo, modelo estruturado, modelo orientado a objetos, modelo de Jackson, etc. Esses são conceitos vagos de classificação sem padrões claros de divisão.
É importante saber distinguir entre o modelo protótipo e o modelo estruturado, pois os dois são complementares, e os outros precisam apenas apreender suas especificidades, por isso não entrarei em detalhes aqui.

Referência: https://blog.csdn.net/Biu_Destiny/article/details/116893974

Os processos básicos do ciclo de vida incluem

As atividades que podem ser executadas durante o ciclo de vida do software são divididas em

Existem 5 processos básicos,
9 processos de suporte
e processos organizacionais 7.
Cada processo do ciclo de vida é dividido em um grupo de atividades e cada atividade é dividida em um grupo de tarefas.

Processo básico
Atividades diretamente relacionadas à produção
1. Processo de aquisição: atividades definidas para o lado da demanda, start-up, licitação, contrato, supervisão de fornecedores, aceitação, etc.; 2. Processo de suprimento: atividades
definidas para o fornecedor, start-up , preparação Licitação, assinatura do contrato, planejamento, execução, entrega e conclusão;
3. Processo de desenvolvimento: atividades definidas para o desenvolvedor: requisitos, projeto, codificação, teste, instalação, aceitação;
4. Processo de operação: definido para o operador Atividades: teste operação, operação do sistema, suporte ao usuário;
5. Processo de manutenção: atividades definidas para a parte de manutenção: análise de problemas e modificações, implementação de modificações, revisão/aceitação de manutenção, migração, processo
de suporte ao descomissionamento de software

processo de organização

A que nível do CMMI pertence a preparação do orçamento e do cronograma?

A edição de orçamentos e cronogramas é uma prática dedicada da área de processo "Planejamento de Projeto" de nível gerenciado do CMMI√

Definição dos cinco níveis de CMM

1) Nível inicial (Inicial): Ocasionalmente, haverá confusão no processo de desenvolvimento de software, apenas alguns processos de trabalho são estritamente definidos e o sucesso do desenvolvimento geralmente depende da sabedoria e dos esforços de uma determinada pessoa.
2) Nível Repetível (Repetível): O processo básico de gerenciamento de projetos foi estabelecido. Projete recursos passo a passo, rastreie custos e desenvolva de acordo com os cronogramas do projeto. Para projetos semelhantes, as peças que já foram desenvolvidas com sucesso podem ser reutilizadas.
3) Nível Definido (Definido): As atividades de engenharia e as atividades de gerenciamento do desenvolvimento de software são documentadas e padronizadas e integradas ao processo de desenvolvimento padrão de uma organização. O desenvolvimento e a manutenção de todos os projetos são customizados com base neste padrão.
4) Nível Gerenciado (Gerenciado): O processo de desenvolvimento de software e os detalhes do teste de qualidade do produto são bem resumidos, e tanto o produto quanto o processo de desenvolvimento podem ser decompostos e controlados quantitativamente.
5) Nível de otimização (Optimizing): Através do estabelecimento de um mecanismo de feedback quantitativo no processo de desenvolvimento, novas ideias são constantemente geradas e novas tecnologias são utilizadas para otimizar o processo de desenvolvimento.

Consulte o seguinte neste artigo: Expansão 4.CMMI

Tecnologias não utilizadas pelo RUP

Referência: Unified Software Development Process (RUP)
RUP é o processo de desenvolvimento unificado do Rational Unified Process. As tecnologias utilizadas são:

O RUP orientado a casos de uso incrementais e iterativos é uma estrutura de processo de software iterativa e incremental centrada em arquitetura e orientada a casos de uso que fornece um recurso evolutivo.

As técnicas não utilizadas são:

Test-Driven Development
Test-Driven Development, nome completo em inglês Test-Driven Development, conhecido como TDD, é um novo método de desenvolvimento diferente do processo tradicional de desenvolvimento de software. Requer escrever o código de teste antes de escrever o código de uma determinada função, e depois escrever apenas o código da função que faz o teste passar e promover todo o desenvolvimento através do teste. Isso ajuda a escrever código limpo, utilizável e de alta qualidade e acelera o processo de desenvolvimento.

o que é software

O software é o objeto de pesquisa da engenharia de software e também é a forma de produto e a existência objetiva da engenharia de software.
Engenharia é a ciência de aplicar teoria e tecnologia à prática, com o objetivo de resolver problemas práticos de forma econômica.

Software = programa + dados + documento

Programa: Um computador que aceita uma sequência de instruções que, quando executadas, fornecem a funcionalidade e o desempenho necessários
Dados: Uma estrutura de dados que permite a um programa manipular informações apropriadamente.
Documentação: Materiais gráficos que descrevem o processo de desenvolvimento, métodos e uso do programa.

Software tem complexidade, consistência, variabilidade e invisibilidade, etc.

O que é o CMMI e, na expressão contínua do CMMI, em quais níveis estão divididos os níveis de habilidade?

O nome completo do CMMI é Capability Maturity Model Integration, ou seja, Capability Maturity Model Integration. O CMMI é a versão mais recente do modelo CMM.
O nome completo do CMMI é Capability Maturity Model Integration. Existem cinco níveis de certificação CMMI:
CMMI nível 1, nível de conclusão; CMMI nível 2, nível de gerenciamento; CMMI nível 3, nível de definição; CMMI nível 4, nível de gerenciamento quantitativo; nível CMMI 5, nível de otimização.

Nos modelos CMMI, para suportar o uso de representação contínua, todos os modelos CMMI refletem os níveis de capacidade em seu design e conteúdo . Os quatro níveis de capacidade do CMMI são designados como nível 0 a nível 3, e cada nível é um nível que serve como base para a melhoria contínua do processo.

CMMI nível 0. Nível incompleto
CMMI nível 1. Nível executado
CMMI nível 2. Nível gerenciado
CMMI nível 3. Nível definido
CMMI nível 4. Nível quantitativo de gerenciamento
CMMI nível 5. Nível de otimização

O CMMI baseado na expressão contínua tem um total de 6 (0-5) níveis de capacidade, correspondendo ao nível inacabado, nível executado, nível gerenciado, nível definido, nível gerencial quantificado e nível otimizado. Cada nível de capacidade corresponde a um objetivo geral e a um conjunto de meios gerais e específicos de implementação. Nível de capacidade 0 significa que o processo não é executado, indicando que um ou mais objetivos específicos da área de processo não foram atendidos; nível de capacidade 1 significa que o processo produz produtos de trabalho de saída identificáveis, transformando produtos de trabalho de entrada identificáveis, com foco no específico objetivos da área de processo. Conclusão dos objetivos; nível de capacidade 2 refere-se à institucionalização do processo como um processo gerenciado, visando a capacidade de uma única instância do processo; nível de capacidade 3 refere-se à institucionalização do processo como um processo definido, com foco sobre a padronização e implantação do processo em nível de organização; o nível de capacidade 4 refere-se a O processo é institucionalizado como um processo de gerenciamento quantitativo; o nível de capacidade 5 refere-se ao processo como um processo otimizado institucionalizado, indicando que o processo é bem executado e melhorado continuamente .

O que é software de código aberto, com exemplos

O chamado código-fonte aberto, "fonte" refere-se ao seu código-fonte, código-fonte aberto significa que o criador do software fornece o código-fonte ao usuário gratuitamente e exige que o usuário siga certas especificações de código-fonte aberto. Por exemplo, linux é um software de código aberto

Projete 6 fluxos de trabalho de engenharia principais e 3 fluxos de trabalho de suporte principais em cada ciclo de iteração do RUP, descreva os nomes e os principais objetivos dos 6 fluxos de trabalho principais

Referência: Compreensão aprofundada dos 6 fluxos de trabalho do processo principal e dos 3 fluxos de trabalho de suporte principais do modelo de desenvolvimento bidimensional iterativo.

modelagem de negócios modelagem de negócios: a modelagem de negócios descreve como desenvolver uma visão para uma nova organização de destino e, com base nessa visão, definir as funções e responsabilidades do processo da organização em um modelo de caso de uso de negócios e um modelo de objeto de negócios requisitos de análise requisitos: requisitos objetivos do fluxo de trabalho
É uma descrição do que o sistema deve fazer, e desenvolvedores e usuários não chegaram a um consenso sobre essa descrição. Para atingir esse objetivo, a funcionalidade e as restrições dos requisitos são extraídas, organizadas e documentadas; mais importante, a definição e o escopo do problema a ser resolvido pelo sistema são compreendidos.Defina as funções do sistema e a interface do usuário, o principal resultado desse fluxo de trabalho é a especificação dos requisitos de software.
Análise e projeto Análise e projeto: O fluxo de trabalho de análise e projeto é transformar os requisitos no projeto do sistema futuro, desenvolver uma estrutura robusta para o sistema e ajustar o projeto para fazer com que o restante do ambiente de implementação corresponda e otimize seu desempenho. Os resultados do projeto de análise são um modelo de projeto e um modelo de análise opcional.
Implementação: O objetivo da implementação do fluxo de trabalho é definir a estrutura organizacional do código na forma de subsistemas hierárquicos, implementar classes e objetos, realizar testes de unidade nos componentes desenvolvidos e integrar os componentes de um único desenvolvedor para torná-lo um executável sistema .Defina a estrutura organizacional do código, implemente o código, teste de unidade e integração do sistema.
Teste Teste: Depois de concluir o desenvolvimento da captura de requisitos, análise, projeto, implementação e outras etapas, e obter o código-fonte, é necessário começar a procurar possíveis erros e defeitos no produto de software.Verifique se todos os requisitos são implementados corretamente, garantindo que todos os erros e defeitos sejam encontrados antes do lançamento.
Implantação: O objetivo é gerar uma versão e distribuir o software aos usuários finais. O fluxo de trabalho de implantação descreve: empacotar o software, produzir outros produtos além do próprio software, instalar o software e fornecer assistência aos usuários.

Gerenciamento de configuração e mudança: O fluxo de trabalho de gerenciamento de configuração e mudança descreve como controlar um grande número de artefatos em um projeto de vários membros. Os fluxos de trabalho de configuração e alteração fornecem diretrizes para gerenciar várias travessias em um sistema em evolução, seguindo vários lançamentos no processo de software. Fluxo de trabalho descreve como desenvolver em paralelo, desenvolvimento distribuído e como criar projetos automaticamente. Ao mesmo tempo, também explica o motivo, a hora e o pessoal da modificação do produto para manter os registros de auditoria.

Gerenciamento de projetos: os objetivos incluem fornecer uma estrutura para gerenciamento de projetos e diretrizes para planejamento, pessoal e execução.

Ambiente: O objetivo do fluxo de trabalho do ambiente é fornecer um ambiente de desenvolvimento de software, incluindo processos e ferramentas, para uma organização de desenvolvimento de software

As atividades que podem ser executadas no ciclo de vida do software são divididas em 5 processos básicos, quais são os 5 processos básicos e a qual lado do projeto de software cada processo básico está relacionado.

5 processos básicos:

1. Processo de aquisição: atividades definidas para o lado da demanda, start-up, licitação, contrato, supervisão do fornecedor, aceitação, etc. 2.
Processo de fornecimento: atividades definidas para o fornecedor, start-up, preparação de propostas, assinatura de contratos, preparação de planos, Execução, entrega e conclusão
3. Processo de desenvolvimento: atividades definidas para o desenvolvedor: requisitos, projeto, codificação, teste, instalação, aceitação
4. Processo operacional: atividades definidas para o operador: teste de execução, operação do sistema, suporte ao usuário
5. Processo de manutenção: atividades definidas para a parte de manutenção: análise de problemas e modificações, implementação de modificações, revisão/aceitação de manutenção, migração, descomissionamento de software

9 processos de apoio:

1. Processo de documentação
2. Processo de gerenciamento de configuração
3. Processo de garantia de qualidade
4. Processo de verificação: O processo de determinar se os produtos de software atendem aos requisitos e condições impostos a eles em atividades anteriores. Verificação de Contrato, Verificação de Processo, Verificação de Requisitos, Verificação de Design, Verificação de Codificação, Verificação de Integração, Verificação de Documento
5. Processo de Verificação: O processo de determinar se os requisitos e o sistema construído final ou produto de software atendem ao uso específico pretendido. Este processo inclui as seguintes tarefas:

1. Preparar requisitos de teste selecionados, casos de teste e especificações de teste para análise dos resultados do teste
2. Garantir que esses requisitos de teste, casos de teste e especificações de teste reflitam requisitos específicos para um determinado uso pretendido
3. O teste inclui força, limite e exceção teste de entrada

6. Processo de revisão conjunta: avaliar o status e os produtos de uma atividade de um projeto, revisão de gerenciamento de projeto, revisão técnica
7. Processo de revisão: determinar conformidade com requisitos, planos e contratos, conforme apropriado
8. Processo de solução de problemas
9. Processo de usabilidade

7 Processos Organizacionais

1. Processo de gerenciamento: as atividades básicas definidas para o gerenciamento no processo do ciclo de vida, incluindo gerenciamento de projetos
2. Processo de infraestrutura: as atividades básicas definidas para estabelecer a infraestrutura do processo do ciclo de vida
3. Processo de melhoria
4. Processo de recursos humanos
5. Processo de gerenciamento de ativos
6 . Processo de gerenciamento do programa de reutilização: atividades definidas para o diretor do programa de reutilização da organização, iniciação, avaliação de domínio, avaliação de reutilização, planejamento, execução e controle, revisão e avaliação 7. Processo de engenharia de domínio: atividades e tarefas dos engenheiros de domínio, análise de domínio, design de
domínio , provisionamento de ativos, manutenção de ativos

expandir

1. Descreva resumidamente as diferenças conceituais entre processo de software, ciclo de vida do software e modelo de processo de software (modelo de ciclo de vida do software).

Processo de software: é a atividade envolvida em uma série de processos relacionados no ciclo de vida do software. Um processo é uma coleção de atividades; uma atividade é uma coleção de tarefas; uma tarefa é uma operação que transforma entrada em saída.
Ciclo de vida do software: o processo do software desde o nascimento até a morte. Pode ser dividido em três ciclos de definição, desenvolvimento e operação, incluindo as etapas de análise de viabilidade, planejamento do projeto, análise de demanda, projeto de software, codificação e teste, operação e manutenção.
Modelo de processo de software: é uma representação abstrata de um processo de software; expressa um processo de uma perspectiva específica e geralmente usa gráficos intuitivos para representar o complexo processo de desenvolvimento de software. O modelo de processo de software é estabelecido principalmente de acordo com vários fatores, como o tipo e a escala do software, especialmente o método de desenvolvimento de software e o ambiente de desenvolvimento.

Diferença:
O ciclo de vida do software é um processo, o corpo principal é o software;
o processo de software é o processo desde o nascimento do software e seu ciclo de vida, e é uma série de atividades envolvidas nesse processo; o
modelo de processo de software é o série de atividades (Representação abstrata de um processo de software).

2. O processo de software é o processo de desenvolvimento de software? Por que?

não. O processo de desenvolvimento de software é apenas um estágio no processo de software. O processo de software é dividido em três categorias de acordo com o corpo principal que realiza o trabalho de desenvolvimento de software: processo básico, processo de suporte e processo organizacional. O processo básico é dividido em processo de aquisição , processo de fornecimento e processo de fornecimento de acordo com diferentes assuntos no processo. Processo, processo de desenvolvimento, processo de operação, processo de manutenção, portanto, o processo de desenvolvimento de software é apenas uma parte do processo de desenvolvimento de software.

3. Modelo de teste de software

Referência: https://blog.csdn.net/WeirdoGiraffe/article/details/124883325
Assim como o modelo de desenvolvimento, o teste de software pode adotar diferentes O modelo de teste implementa atividades de teste para orientar o arranjo das atividades de teste de software.
Modelos comuns na indústria:

1. Modelo V
2. Modelo W (modelo V duplo)
3. Modelo X
4. Modelo H
5. Modelo ágil

modelo V

O modelo V é o modelo mais conhecido de todos os modelos de teste de software. É um modelo de teste desenvolvido a partir do modelo de P&D em cascata, conforme mostrado na figura.

O processo do modelo V é de cima para baixo, da esquerda para a direita
① Os engenheiros de teste executam testes de unidade nas funções de código gerado durante o processo de programação do pessoal de P&D
② Os testes de integração são executados após a aprovação dos testes de unidade
③ Os testes de sistema e aceitação são executados depois que os testes de integração são aprovados no teste

Desvantagens do modelo V:

Defeitos no início do projeto são descobertos mais tarde

modelo W

O modelo W evoluiu com base no modelo V e é geralmente chamado de modelo V duplo. No modelo V, quando as atividades de P&D não são concluídas e não há saída, os engenheiros de teste não podem realizar o trabalho de teste, relativamente falando, as atividades de teste ficam seriamente atrasadas. Para resolver as deficiências do modelo V, o modelo W apresenta o conceito de atividades de teste paralelas e atividades de P&D e aumenta as atividades de verificação e confirmação durante a evolução do processo de produção.

O modelo W começa com os requisitos do usuário. A equipe de P&D realiza atividades como análise de requisitos, design de esboço, design detalhado e desenvolvimento de codificação de acordo com os requisitos do usuário. A equipe de teste realiza testes de aceitação, testes de sistema, testes de integração e design de teste de unidade com base sobre os requisitos do usuário. O trabalho de teste é separado das atividades de P&D, permitindo operações paralelas. As atividades de teste são acompanhadas por todo o processo de P&D, não apenas após a saída dos resultados de P&D.
O modelo W enfatiza que as atividades de teste não incluem apenas códigos-fonte de software produzidos por atividades de P&D, mas também consideram vários documentos, como documentos de requisitos, documentos de projeto geral, documentos de projeto detalhado, códigos, etc.
O modelo W exige que as atividades de teste sejam envolvidas desde o estágio de requisitos do usuário, o que é propício para encontrar problemas o mais cedo possível. Durante o processo de implementação do modelo, as atividades de validação e verificação são sempre realizadas

modelo X

O pano de fundo do modelo X também está relacionado ao modelo V. A desvantagem do modelo V é que as atividades de teste ficam para trás das atividades de pesquisa e desenvolvimento, e as atividades de teste não podem ser realizadas o mais cedo possível. O modelo X, como o modelo W, foi originalmente proposto para resolver as deficiências do modelo V.
A ideia básica do modelo X foi proposta por Marick e aprimorada por Robin F.Goldsmith. O modelo X é mostrado na figura.

O lado esquerdo do modelo X indica codificação independente e atividades de teste para fragmentos de programas individuais n, considerando isso como o processo básico, iteração contínua e, finalmente, tornando-se programas executáveis ​​por meio de atividades de integração e, em seguida, testando esses programas executáveis. O produto finalizado que passa no teste de integração pode ser empacotado e enviado para o link de teste do sistema ou diretamente para o usuário. Múltiplas curvas paralelas indicam que mudanças podem ocorrer em várias partes.
O modelo X apresenta o conceito de teste exploratório. O teste exploratório é diferente dos métodos de teste convencionais. Ele não precisa fazer um plano de teste ou design com antecedência. Engenheiros de teste experientes podem encontrar mais erros de software fora do plano de teste de acordo com suas próprias atividades de pensamento e compreensão do objeto testado. No entanto, o teste exploratório geralmente é usado apenas como um complemento a outros métodos de teste. Como consome mais recursos de teste e está sujeito à experiência dos engenheiros de teste, não pode ser um método de teste independente.

modelo H

O modelo H separa as atividades de teste dos demais processos de P&D.As atividades de teste são divididas em duas partes: preparação do teste e execução do teste, o que facilita a definição das atividades de design e execução do teste, conforme mostrado na figura. As atividades de preparação de teste incluem análise de requisitos de teste, planejamento de teste, design de teste, codificação de teste, verificação de teste, etc. A execução de teste inclui execução de teste, relatório de teste, análise de resultado de teste, teste de regressão de confirmação, etc.

Assim como o modelo W, o modelo H revela que a atividade de teste de software deve ser um processo de produção de software independente ao longo de todo o ciclo de vida do software. A atividade de teste deve ser preparada e executada o mais cedo possível. As atividades de execução de teste podem ser realizadas sem sujeitos a atividades de pesquisa e desenvolvimento.

modelo de teste ágil

Enfatize o teste da perspectiva dos clientes;
concentre-se no teste iterativo de novos recursos, desenfatize a fase de teste
Teste o mais cedo possível, teste continuamente e teste quando as condições forem atendidas Enfatize o
feedback contínuo
Prevenir defeitos é mais importante do que descobri-los

Modelos Evolutivos e Modelos Protótipos

O modelo evolutivo também é um método de desenvolvimento de prototipagem, que é ligeiramente diferente do modelo de prototipagem rápida.

No modelo de prototipagem rápida, o objetivo do protótipo é conhecer as reais necessidades dos usuários, uma vez que as necessidades são deficientes, o protótipo é descartado.
O processo de desenvolvimento do modelo evolutivo é um processo gradual desde o modelo inicial até o produto de software final.

Ou seja, o modelo de prototipagem rápida é um método de prototipagem "descartável", enquanto o modelo evolutivo é um método de prototipagem "gradual".

4.CMMI

Referência: https://deepmind.t-salon.cc/article/6396
Uma explicação detalhada dos 5 níveis e 22 áreas de processo do CMMI Capability Maturity Model, marque e aprenda os
fundamentos da engenharia de software e recomende
a relação entre CMM e Informações CMMI
Fanfeng CMMI-DEV (visão de desenvolvimento)

O nome completo do CMMI é Capability Maturity Model Integration, ou seja, Capability Maturity Model Integration. O CMMI é a versão mais recente do modelo CMM.
O nome completo do CMMI é Capability Maturity Model Integration. Existem 5 níveis de certificação CMMI:

Nível CMMI1, nível de conclusão; nível CMMI2, nível de gerenciamento; nível CMMI3, nível de definição; nível CMMI4, nível de gerenciamento quantitativo; nível CMMI5, nível de otimização.

No CMMI, cada modelo de assunto CMMI tem duas representações:

Representação encenada e representação contínua.
Modelos de representações diferentes têm estruturas diferentes. A notação contínua enfatiza a capacidade de uma única área de processo, e a melhoria da linha de base e dos resultados da medição é examinada da perspectiva da área de processo. O termo-chave é "capacidade", enquanto a notação em estágios enfatiza a maturidade da organização
. A perspectiva coletiva examina os estágios de maturidade do processo de toda a organização, sendo o termo-chave "maturidade".

área de processo CMMI

O CMMI V1.3 possui um total de 22 áreas de processo, área de processo (PA): descreve o problema de um determinado aspecto que deve ser focado ou melhorado em todas as atividades de melhoria do processo, estabelece metas para cada processo e pratica de acordo com o metas. Cada área de processo tem metas claras (Meta) e prática (Prática), metas e práticas incluem:

GG (Generic Goals), o nome chinês é o objetivo geral, correspondente a GP (Generic Practices), o nome chinês é a prática geral, e é aplicado à dimensão de capacidade, portanto, é aplicável a todas as áreas-chave do processo.

SG (Objetivos Específicos), o nome chinês é objetivos específicos, correspondendo a SP (Práticas Específicas), o nome chinês é práticas específicas, aplicadas à dimensão do processo, e só podem ser aplicadas a uma área-chave específica do processo.

Os níveis, áreas de processo, objetivos e práticas do CMMI estão relacionados a seguir:

domínio de prática CMMI

O domínio da prática é um conceito importante na estrutura CMMI (Capability Maturity Model Integration), que se refere a um conjunto de práticas padrão reutilizáveis ​​que se mostraram eficazes em um campo específico.
Os domínios de prática costumavam ser chamados de "domínios de processo", por exemplo, gerenciamento de configuração, agora são chamados de "domínios de prática". Para a versão 2.0, existem 25 áreas de prática aplicáveis. Assim como nas versões anteriores do modelo CMMI, os "Domínios de Prática" apresentam os requisitos e as descrições das principais atividades que definem a intenção da prática.

O domínio da prática do CMMI é dividido em dois níveis: domínio da prática geral e domínio da prática específica. As áreas de prática genérica incluem gerenciamento de projetos, engenharia, suporte a processos e produtos, e essas práticas são projetadas para oferecer suporte à melhoria de processos e gerenciamento de projetos em toda a organização. Domínios de prática específica são algumas práticas específicas formuladas de acordo com diferentes áreas de negócios e indústrias para melhor responder a várias necessidades especiais.

Por exemplo, para o campo de desenvolvimento de software, as áreas de prática específicas do CMMI incluem gerenciamento de requisitos, gerenciamento de design, gerenciamento de teste e assim por diante. Essas práticas podem ajudar as organizações de desenvolvimento de software a estabelecer um melhor gerenciamento de requisitos, gerenciamento de design e mecanismos de gerenciamento de teste, melhorar a produtividade do desenvolvimento de software e otimizar os processos de desenvolvimento de software.

Resumir

Esta série de blogs está relacionada à engenharia de software. Este artigo é a primeira parte da visão geral da engenharia de software e dos exercícios de processo de software.