Habilidades profissionais em design de arquitetura de sistema·Engenharia de software

Índice de artigos da série

Habilidades avançadas em design de arquitetura de sistema · Conceitos de arquitetura de software, estilos de arquitetura, ABSD, reutilização de arquitetura, DSSA (1) [Arquiteto de Sistema]
Habilidades avançadas em design de arquitetura de sistema · Atributos de qualidade de sistema e avaliação de arquitetura (2) [Arquiteto de Sistema]
Habilidades avançadas em projeto de arquitetura de sistema · Análise e projeto de confiabilidade de software (3) [Designer de arquitetura de sistema]

1. Conceito de Engenharia de Software★

Ciclo de vida de desenvolvimento de software:

Período de definição de software : inclui estudo de viabilidade e processo detalhado de análise de requisitos . A tarefa é determinar o objetivo geral que o projeto de desenvolvimento de software deve concluir. Pode ser dividido em definição de problema, estudo de viabilidade, análise de requisitos, etc.
Período de desenvolvimento de software : É o projeto e implementação de software, que pode ser dividido em projeto de esboço, projeto detalhado, codificação, teste , etc.
Operação e manutenção de software : Significa entregar produtos de software aos usuários .

Documentação do sistema de software:

A documentação do sistema de software pode ser dividida em duas categorias: documentação do usuário e documentação do sistema . A documentação do usuário descreve principalmente as funções e o uso do sistema , não como essas funções são implementadas; a documentação do sistema descreve vários aspectos do design, implementação e teste do sistema .

O processo de engenharia de software refere-se aos seguintes quatro aspectos de atividades (PDCA) para obter produtos de software :

P (Plano) - especificação do software : especifica as funções do software e suas limitações de tempo de execução.
D(Do) - Desenvolvimento de Software : Desenvolver software que atenda às especificações.
C (Verificar) - Confirmação do software : Confirme se o software desenvolvido pode atender às necessidades dos usuários.
A (Ação) - Evolução do software : O software é continuamente melhorado durante a operação para atender às novas necessidades dos clientes.

As ferramentas do sistema de software geralmente podem ser divididas em ferramentas de software de acordo com as atividades do processo de software :

Ferramentas de desenvolvimento de software : ferramentas de análise de requisitos, ferramentas de design, ferramentas de codificação e depuração, ferramentas de teste, etc.
Ferramentas de manutenção de software : ferramentas de controle de versão, ferramentas de análise de documentos, ferramentas de base de informações de desenvolvimento, ferramentas de engenharia reversa e ferramentas de reengenharia.
Ferramentas de gerenciamento de software e suporte de software : avaliação e seleção de ferramentas de gerenciamento de projetos, ferramentas de gerenciamento de configuração, ferramentas de avaliação de software e ferramentas de desenvolvimento de software.

Existem quatro atividades no design de software :
design de dados, design de arquitetura (estrutura de sistema), design de interface homem-computador (interface) e design de processo .

1.1 Crise de Software

2. Modelo de maturidade de capacidade de software

Modelo de maturidade de capacidade para software (CMM)

Nível de habilidade	Características	principais áreas de processo
nivel inicial	O processo de software é caracterizado por ser desorganizado e às vezes caótico, com poucas etapas claramente definidas, e o sucesso do projeto depende inteiramente dos esforços dos indivíduos e do papel de figuras centrais heróicas .
nível repetível	Processos e práticas básicas de gerenciamento de projetos são estabelecidos para rastrear custos, cronogramas e recursos do projeto, e as disciplinas de processo necessárias estão em vigor para repetir sucessos anteriores em projetos semelhantes.	Gerenciamento de configuração de software, garantia de qualidade de software, gerenciamento de subcontratos de software, acompanhamento e supervisão de projetos de software, planejamento de projetos de software, gerenciamento de requisitos de software
nível definido	Os processos de software tanto em gerenciamento quanto em engenharia foram documentados, padronizados e integrados em processos de software padrão para toda a organização de desenvolvimento de software . Todos os projetos utilizam processos de software padrão modificados de acordo com as condições reais para desenvolver e manter software .	Revisão por pares, coordenação entre grupos, engenharia de produtos de software, gerenciamento integrado de software, esboço de treinamento, definição de processos organizacionais, foco em processos organizacionais
Já gerenciado	São desenvolvidas métricas detalhadas para o processo de software e a qualidade do produto . Ter compreensão quantitativa e controle dos processos de software e da qualidade do produto.	Gestão de qualidade de software e gestão de processos quantitativos
Nível de otimização	A análise quantitativa foi fortalecida e o processo pode ser continuamente melhorado através do feedback da qualidade do processo e do feedback de novos conceitos e novas tecnologias .	Gestão de mudanças de processos, gestão de mudanças tecnológicas e prevenção de defeitos

Modelo de estágio de integração do modelo de maturidade de capacidade para software (CMMI)
.O CMMI é desenvolvido com base no CMM e se concentra na maturidade da organização.

Nível de habilidade	Características	principais áreas de processo
nivel inicial	O processo é imprevisível e carece de controle
Já gerenciado	O processo atende ao projeto	Gerenciamento de requisitos, planejamento de projetos, gerenciamento de configuração, supervisão e controle de projetos, gerenciamento de contratos de fornecedores, medição e análise, garantia de qualidade de processos e produtos
nível definido	O processo serve a organização	Desenvolvimento de requisitos, soluções técnicas, integração de produtos, verificação, validação do foco de processos organizacionais, definição de processos organizacionais, treinamento organizacional, gestão integrada de projetos, gestão de riscos, equipes integradas, análise de decisões e soluções, ambiente organizacional integrado
Gestão quantitativa	O processo é medido e controlado	Desempenho de processos organizacionais, gerenciamento quantitativo de projetos
Nível de otimização	Foco na melhoria e otimização de processos	Reforma e implementação em nível organizacional, análise de causa e efeito e soluções

3. Modelo de processo de software

3.1 Modelo em cascata

O modelo em cascata (SDLC), também conhecido como método de ciclo de vida, é o modelo de desenvolvimento mais comumente usado no método de ciclo de vida.O desenvolvimento de software é geralmente dividido em: análise de viabilidade (plano), análise de requisitos, design de software (design de esboço, projeto detalhado), As etapas de codificação (incluindo testes unitários), testes, operação e manutenção, etc., estipulam sua ordem fixa de cima para baixo e interligadas entre si, como uma cachoeira, caindo passo a passo. Como mostrado na imagem:

Características do modelo cascata:

• Aceita como entrada os objetos de trabalho desta atividade da atividade de desenvolvimento anterior .
• Usando esta entrada, implemente o trabalho que deve ser realizado pela atividade.
• Os resultados do trabalho desta atividade são fornecidos e passados ​​para a próxima atividade de desenvolvimento como saída.
• Revise os resultados da implementação desta atividade. Se os resultados do trabalho forem confirmados, continue com a próxima atividade de desenvolvimento; caso contrário, retorne à atividade anterior ou ainda mais anterior. Minimize as repetições entre vários estágios. Desenvolva software com um custo relativamente pequeno

O modelo em cascata é propício à organização e gestão de pessoal no processo de desenvolvimento de software em larga escala e à pesquisa e uso de métodos e ferramentas de desenvolvimento de software, melhorando assim a qualidade e a eficiência do desenvolvimento de projetos de software em grande escala. No entanto, a prática de desenvolvimento de software mostra que as atividades acima não são totalmente de cima para baixo, mas são mostradas em um diagrama linear. Portanto, o modelo em cascata apresenta sérias falhas:

• Como o modelo de desenvolvimento é linear, os usuários não podem ver os efeitos do software quando os resultados do desenvolvimento não foram testados. Dessa forma, o intervalo de tempo entre o software e o usuário é maior, o que também aumenta alguns riscos.
• Quando erros que não são descobertos nos estágios iniciais do desenvolvimento de software são disseminados para atividades de desenvolvimento subsequentes, eles podem se espalhar, o que pode levar ao fracasso de todo o projeto de software.
• Na etapa de análise de requisitos de software é difícil, ou mesmo impossível, determinar completamente todas as necessidades do usuário.

3.2 Modelo protótipo

O modelo de prototipagem visa principalmente o desenvolvimento de software onde os requisitos não podem ser totalmente definidos com antecedência.Com base no rápido desenvolvimento de um protótipo , o protótipo é aprimorado e uma nova versão do protótipo é obtida com base no feedback e sugestões fornecidas pelo usuário no processo de chamada do protótipo. Este processo se repete até evoluir para o produto de software final .

O método do protótipo acredita que quando é difícil apresentar de uma só vez as necessidades do usuário de forma completa e precisa, o protótipo deve ter as seguintes características:

• Prático e viável .
• Possui as características básicas do sistema final .
• A estrutura é conveniente e rápida e o custo é baixo . A característica do método de protótipo é que o método de protótipo responde dinamicamente às necessidades do usuário e as incorpora gradualmente .

Sobre métodos/modelos de prototipagem:

Um protótipo de software é uma implementação parcial de um novo produto proposto. O principal objetivo do estabelecimento de um protótipo é resolver o problema de requisitos incertos nos estágios iniciais do desenvolvimento do produto. Seu objetivo é esclarecer e melhorar os requisitos, explorar opções de design e evoluir para o produto final. Os modelos de protótipo são mais adequados para projetos cujos requisitos não são suficientemente claros .

Existem muitas maneiras de classificar protótipos. Dependendo se implementa funções , os protótipos de software podem ser divididos em dois tipos : protótipos horizontais e protótipos verticais . Protótipos horizontais, também chamados de protótipos comportamentais, são utilizados para explorar alguns comportamentos específicos do sistema esperado e atingir o propósito de refinar requisitos. Os protótipos horizontais geralmente são apenas uma navegação de funcionalidade sem realmente implementá-la. Protótipos horizontais são usados ​​principalmente em interfaces . Protótipos verticais, também chamados de protótipos estruturados, implementam parte da funcionalidade. A prototipagem vertical é usada principalmente em implementações de algoritmos complexos .

Do ponto de vista do resultado final do protótipo , os protótipos de software podem ser divididos em protótipos descartáveis ​​e protótipos evolutivos . Um protótipo descartado também é chamado de protótipo exploratório, o que significa que o próprio protótipo é abandonado após o propósito esperado ser alcançado. Protótipos descartáveis ​​são usados ​​principalmente para resolver incertezas, ambiguidades, incompletudes, ambiguidades da demanda, etc. Os protótipos evolutivos fornecem a base para o desenvolvimento de produtos incrementais e fazem parte do modelo espiral e do processo de desenvolvimento de software orientado a objetos. Os protótipos evolutivos são usados ​​principalmente em projetos que devem ser fáceis de atualizar e otimizar, e são adequados para projetos Web .

Alguma literatura divide os protótipos em tipos experimentais, exploratórios e evolutivos. O objetivo da prototipagem exploratória é esclarecer os requisitos do sistema alvo, determinar os recursos desejados e explorar a viabilidade de múltiplas soluções. Antes de protótipos experimentais serem utilizados para desenvolvimento e implementação em larga escala, avalie se o plano é adequado e se as especificações são confiáveis. O objetivo da prototipagem evolutiva não é melhorar as especificações, mas construir o sistema para ser fácil de mudar e, no processo de melhoria do protótipo, evoluir gradualmente o protótipo para o sistema final.

Alguma literatura também divide os protótipos em protótipos descartáveis, protótipos evolutivos e protótipos incrementais.

O método de prototipagem é adequado quando os usuários não possuem um conteúdo claro para determinar suas necessidades. Primeiro estabelece um modelo original baseado nos requisitos dados e analisados, um modelo que pode ser modificado (no método do ciclo de vida, após a análise dos requisitos em documentos, geralmente não são necessárias mais modificações).

Em cada estágio do desenvolvimento de software, informações relevantes são realimentadas entre si até que o modelo seja modificado, tornando-o gradualmente mais perfeito. Neste processo, a participação do usuário e a tomada de decisão são fortalecidas e o resultado final é mais adequado às necessidades do usuário.

Este tipo de tecnologia de prototipagem pode ser dividida em três categorias: descartável, evolutiva e incremental. A chave para o sucesso e eficiência deste método de protótipo está no estabelecimento do modelo e na velocidade da modelagem.

3.3 Modelo incremental

O modelo incremental combina os componentes básicos do modelo em cascata (aplicação repetitiva) com as características iterativas da implementação do protótipo . O modelo incremental usa sequências lineares que variam ao longo do tempo, com cada sequência linear produzindo um “incremento” liberável do software. Ao usar o modelo incremental, o primeiro incremento geralmente é o produto principal, o que significa que o primeiro incremento implementa os requisitos básicos , mas muitos recursos adicionais ainda não foram lançados. O uso e a avaliação de cada incremento pelo cliente servem como novos recursos e funcionalidades lançados no próximo incremento. Este processo é repetido após cada liberação incremental até que o produto final polido seja produzido.

O modelo incremental enfatiza que cada incremento libera um produto operacional . Como mostrado na imagem:

Modelos incrementais, como modelos de implementação de protótipos e outros métodos evolutivos, são de natureza iterativa . Mas, diferentemente da implementação de protótipos, o modelo incremental enfatiza que cada incremento libera um produto operacional . Os primeiros incrementos são versões “destacáveis” do produto final, mas fornecem funcionalidade para atender aos usuários e fornecem uma plataforma para avaliação do usuário. A característica do modelo incremental é que ele introduz o conceito de pacotes incrementais, não há necessidade de esperar a liberação de todos os requisitos , o desenvolvimento pode ser realizado desde que o pacote incremental de um determinado requisito seja liberado. Embora um determinado pacote incremental possa necessitar de ser adaptado às necessidades do cliente e necessitar de ser alterado, desde que o pacote incremental seja suficientemente pequeno, o seu impacto em todo o projecto será suportável.

A vantagem de usar o modelo incremental é que a alocação de pessoal é flexível e não há necessidade de investir muitos recursos humanos no início. Se o produto principal for muito popular, a mão de obra pode ser adicionada para realizar o próximo incremento; quando o a equipe não consegue concluir o produto dentro do prazo estabelecido, o que fornece uma maneira de lançar primeiro o produto principal, para que alguns recursos possam ser liberados primeiro para os clientes, agindo como um tranquilizador para os clientes. Além disso, os incrementos permitem o gerenciamento planejado de riscos técnicos. A desvantagem do modelo incremental é que se houver intersecção entre pacotes incrementais e isso não puder ser bem tratado, uma análise abrangente do sistema deverá ser feita e os módulos não poderão ser bem divididos . O modelo incremental aplica o método de refinamento funcional e desenvolvimento separado ao processo de desenvolvimento de software onde os requisitos mudam frequentemente.

3.4 Modelo espiral

O modelo espiral combina o modelo em cascata e o modelo de prototipagem (evolução) , combinando as vantagens de ambos e adicionando análise de risco . Baseia-se no protótipo e gira de dentro para fora ao longo da espiral.Cada rotação requer planejamento, análise de risco, engenharia de implementação, avaliação do cliente e outras atividades, e uma nova versão do protótipo é desenvolvida .

O modelo espiral enfatiza a análise de risco e é especialmente adequado para sistemas grandes, complexos e de alto risco . Após vários processos em espiral, o sistema final é obtido, conforme mostrado na figura: (Os requisitos muitas vezes são vagos no início do projeto, mas gradualmente se tornarão claros à medida que o projeto avança, ou seja, os requisitos são gradualmente detalhados. )

Modelo 3,5V

No modelo de desenvolvimento, o teste é frequentemente usado como uma reflexão tardia para remediar a situação, mas também existe um modelo de desenvolvimento centrado no teste , que é o modelo V. O modelo V recebeu apenas um reconhecimento vago na indústria de software. O modelo V afirma que o teste não é um ato de compensação posterior, mas um processo que é tão importante quanto o processo de desenvolvimento, conforme mostrado na figura:

O modelo V é o modelo de teste mais representativo, é uma variante do modelo em cascata , fortalece os testes baseados no modelo em cascata e reflete a relação entre as atividades de teste e a análise e design. No modelo V, as partes descendentes à esquerda são as etapas do processo de desenvolvimento e as partes ascendentes à direita são as etapas do processo de teste. A estratégia de teste de software do modelo V inclui testes de baixo nível e testes de alto nível.O teste de baixo nível é para a correção do código-fonte e o teste de alto nível é para todo o sistema atender às necessidades do usuário. O modelo V tem certas limitações: considera o processo de teste apenas como uma etapa após a análise de requisitos, projeto de esboço, projeto detalhado e codificação. Faça com que os testes funcionem do começo ao fim .

O modelo V enfatiza a colaboração e a velocidade de desenvolvimento de software, combina organicamente a implementação e verificação de software e encurta o ciclo de desenvolvimento, garantindo ao mesmo tempo alta qualidade de software. O modelo V é adequado para desenvolvimento de software de nível empresarial e revela mais claramente as características e a essência do processo de desenvolvimento de software.

O valor do modelo V é que ele indica claramente os diferentes níveis que existem no processo de teste e descreve claramente a correspondência entre essas fases de teste e os estágios durante o processo de desenvolvimento:

• O principal objetivo do teste unitário é identificar vários erros que podem existir durante o processo de codificação. Por exemplo: erros nos valores limite durante a validação da entrada do usuário.
• O principal objetivo dos testes de integração é direcionar possíveis problemas no projeto detalhado, principalmente para verificar possíveis erros na interface entre cada unidade e outras partes do programa.
• O teste do sistema concentra-se no design geral e verifica se o sistema como um todo está operando de maneira eficaz. Por exemplo: se o alto desempenho esperado é alcançado nas configurações do produto.
• Os testes de aceitação geralmente são conduzidos por especialistas de negócios ou usuários para confirmar se o produto pode realmente atender às necessidades comerciais do usuário.

O conceito de iteração e incremento

3.6 Modelo de fonte

O modelo fonte fornece suporte para reutilização de software e integração de múltiplas atividades de desenvolvimento no ciclo de vida . Ele suporta principalmente métodos de desenvolvimento orientados a objetos . É um modelo orientado pelas necessidades do usuário e orientado por objetos . A própria palavra "fonte" incorpora a natureza iterativa e contínua. Uma determinada parte do sistema é frequentemente retrabalhada diversas vezes, com funcionalidades relacionadas adicionadas ao sistema em evolução em cada iteração . A chamada ausência de lacuna significa que nas atividades de desenvolvimento não existe uma fronteira óbvia entre análise, design e codificação, conforme mostrado na figura:

3.7 Modelo baseado em componentes CBSD (modelo de montagem de componentes/desenvolvimento de software baseado em componentes)

Um componente (Component) é uma unidade de software com valor reutilizável e funções relativamente independentes. O modelo de Desenvolvimento de Software Baseado em Componentes (CBSD) utiliza métodos de modularização para modularizar todo o sistema e, com o suporte de um determinado modelo de componente, reutiliza um ou mais componentes de software na biblioteca de componentes por meio de combinação. com alta eficiência e alta qualidade.

O modelo de desenvolvimento baseado em componentes incorpora muitas características do modelo espiral, é de natureza evolutiva e o processo de desenvolvimento é iterativo. O modelo de desenvolvimento baseado em componentes consiste em cinco etapas: análise e definição de requisitos de software, projeto de arquitetura, estabelecimento de biblioteca de componentes (a biblioteca de componentes inclui aquisição e gerenciamento de componentes), construção, teste e lançamento de software aplicativo . Como mostrado na imagem:

Os componentes do CBSE devem ter as seguintes características:

• Montabilidade: Todas as interações externas devem ocorrer através de interfaces definidas publicamente.
• Implementabilidade: Os componentes estão sempre em formato binário e podem ser executados na plataforma como uma entidade independente.
• Documentação: Os usuários julgam se o componente atende aos requisitos com base na documentação.
• Independência: Pode ser montado e implantado sem outros componentes especiais.
• Padronização: Um modelo de componente que está em conformidade com um determinado padrão.

Sequência de montagem dos componentes CBSE:

• Montagem sequencial: chame os componentes existentes em sequência. Você pode usar dois componentes existentes para criar um novo componente.
• Montagem hierárquica: A interface “fornecida” do componente chamado deve ser compatível com a interface “solicitada” do componente chamador.
• Montagem de sobreposição: Vários componentes são mesclados para formar um novo componente. O novo componente integra as funções dos componentes originais e fornece novas interfaces para o mundo exterior.

Como uma importante tecnologia e ferramenta de software, os componentes foram bastante desenvolvidos.Esses novos padrões e ferramentas de tecnologia incluem DCOM/COM da Microsoft, EJB da Sun, CORBA da OMG, etc. As atividades de desenvolvimento baseadas em componentes começam com a identificação de componentes candidatos . Ao pesquisar a biblioteca de componentes existente , confirme se o componente necessário já existe. Se já existir , extraia-o da biblioteca de componentes para reutilização ; se não existir , use o objeto- método orientado. Desenvolva-o. Depois que os componentes extraídos passam pelas verificações de sintaxe e semântica, esses componentes são montados por meio de código cola para implementar o sistema. Esse processo é iterativo.

O método de desenvolvimento baseado em componentes faz com que o desenvolvimento de software não comece mais do zero. O processo de desenvolvimento é o processo de montagem de componentes, e o processo de manutenção é o processo de atualização, substituição e expansão de componentes. Sua vantagem é que o modelo de montagem de componentes leva a reutilização e melhorias de software Melhora a eficiência do desenvolvimento de software ; os componentes podem ser definidos por uma parte, implementados por outra parte e depois fornecidos a terceiros para uso; o modelo de montagem de componentes permite que vários projetos sejam desenvolvidos ao mesmo tempo, reduzindo custos, melhorando a capacidade de manutenção e permitindo o envio passo a passo de Produtos de Software.
A desvantagem é que, devido ao uso de padrões de estrutura de montagem personalizados, há uma falta de padrões de estrutura de montagem universal e a introdução é arriscada; a reutilização e a eficiência do software não são fáceis de coordenar, exigindo analistas e desenvolvedores capazes e experientes. Geralmente, Se os desenvolvedores não puderem se envolver, a satisfação do cliente será baixa; muita confiança será colocada nos componentes e a qualidade da biblioteca de componentes afetará a qualidade do produto .

3.8 Modelo ágil

Manifesto de Desenvolvimento: Indivíduos e interações acima de processos e ferramentas, software funcional acima de documentação exaustiva, colaboração com o cliente acima da negociação de contratos, respondendo às mudanças acima de seguir um plano .

Métodos de desenvolvimento ágil

Duas características distinguem os métodos ágeis de outros métodos:
(1) É “adaptativo” e não “predefinido”.
(2) É “orientado para as pessoas” e não “orientado para os processos”.
Ideias centrais do desenvolvimento ágil:
(1) O desenvolvimento ágil é adaptativo , não previsível. Abrace a mudança e adapte-se a ela.
(2) O desenvolvimento ágil é orientado para as pessoas e não para os processos. Destaque as características humanas.
(3) Processo de desenvolvimento iterativo e incremental . Com base na ideia de desenvolvimento de protótipo, o método é utilizado para substituir o desenvolvimento incremental e a versão de lançamento é miniaturizada.

Programação XP Extrema

XP é um método de desenvolvimento de software leve (ágil), eficiente, de baixo risco, flexível, previsível, científico e divertido. Em comparação com outras metodologias, suas maiores diferenças são:

(1) Para regras baseadas em código, o documento importante é o código-fonte.
(2) Fornecer informações de feedback específicas e contínuas mais cedo e em um ciclo mais curto.
(3) Planejar iterativamente, primeiro gerando rapidamente um plano mestre no início e depois evoluindo-o ao longo do processo de desenvolvimento do projeto.
(4) Confiar em programas de testes automatizados para monitorar o progresso do desenvolvimento e detectar defeitos antecipadamente.
(5) Confiar na comunicação verbal, testes e programas fonte para comunicação.
(6) Defender o design evolutivo contínuo.
(7) Depende de estreita colaboração dentro da equipe de desenvolvimento.
(8) Tentar, tanto quanto possível, alcançar um equilíbrio entre os interesses de curto prazo dos programadores e os interesses de longo prazo do projeto.

Quatro valores:

• comunicação, fortalecer a comunicação face a face
• Simples, não excessivamente projetado
• feedback, feedback oportuno
• Coragem, a coragem de aceitar a mudança

XP é um método de desenvolvimento quase em espiral que divide o complexo processo de desenvolvimento em ciclos relativamente simples: por meio de comunicação ativa, feedback e uma série de outros métodos, desenvolvedores e clientes podem ter clareza sobre o progresso do desenvolvimento. ser resolvido e dificuldades potenciais, etc., e ajustar o processo de desenvolvimento em tempo hábil de acordo com a situação real.

A XP defende testar primeiro para minimizar a chance de bugs no futuro.

O XP é usado de forma muito eficaz em algumas empresas que possuem um controle rígido de custos .

método de cristal

O método Crystal Series, assim como o método XP, tem uma filosofia centrada nas pessoas, mas é diferente na prática. O objectivo é desenvolver uma abordagem que promova a “mobilidade” e contenha elementos centrais comuns, cada um com funções, modelos de processos, produtos de trabalho e práticas únicos.

O Método Crystal explora maneiras de alcançar o sucesso com o mínimo de disciplina , alcançando assim um equilíbrio entre produtividade e facilidade de operação.

Código aberto

Código aberto: Os desenvolvedores de programas estão amplamente distribuídos geograficamente [outros métodos enfatizam escritórios centralizados] .

Argumentando pela lei em paralelo

SCRUM é um processo iterativo e incremental. Uma iteração por período (como 30 dias) é chamada de "Sprint", e os produtos são implementados de acordo com o nível de prioridade dos requisitos. Equipes auto-organizadas e autônomas implementam incrementalmente o produto em paralelo.

SCRUM: Um processo metodológico claramente definido e repetível, focado no gerenciamento de projetos. .

Desenvolvimento Orientado a Recursos (FDD)

O desenvolvimento orientado a recursos (FDD) é um modelo de desenvolvimento iterativo. Acredita-se que o desenvolvimento eficaz de software requer 3 elementos: pessoas, processos e tecnologia. Existem 5 processos principais: desenvolvimento do modelo geral de objetos, construção da lista de recursos, planejamento do desenvolvimento de recursos, design de recursos e construção de recursos. São definidas seis funções principais do projeto: gerente de projeto, arquiteto-chefe, gerente de desenvolvimento, programador líder, programador e especialista de domínio.

Desenvolvimento Orientado a Funções (FDD): Os desenvolvedores de programação são divididos em duas categorias: programadores líderes e programadores de "classe" .

Método TEA

Método ASD : Em sua essência estão três fases de desenvolvimento não lineares e sobrepostas: adivinhação, colaboração e aprendizagem .

Métodos de desenvolvimento de sistemas dinâmicos

Método de Desenvolvimento de Sistema Dinâmico (DSDM) : defende tomar __ negócios como núcleo.

3.9 Modelo RAD (modelo de desenvolvimento rápido de aplicativos)

O modelo Rapid Application Development (RAD) é um modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto . O modelo RAD é uma variante de "alta velocidade" do modelo em cascata , que usa um método de construção baseado em componentes para alcançar um desenvolvimento rápido através do uso extensivo de componentes reutilizáveis . Se os requisitos forem bem compreendidos e o escopo do projeto for limitado, um “sistema de informação” totalmente funcional poderá ser criado rapidamente usando este modelo. O processo começa com a modelagem de negócios, seguida pela modelagem de dados, modelagem de processos, geração de aplicativos, testes e iteração. O modelo de desenvolvimento abrangente do modelo cascata e CBSD (Desenvolvimento de Software Baseado em Componentes) , conforme mostrado na figura:

As tarefas a serem concluídas em cada período de atividade do modelo RAD são as seguintes:

• Modelagem de negócios : quais informações orientam os processos de negócios? Que informações devem ser geradas? Quem o gera? Para onde vai o fluxo de informações? Por quem? Isso pode ser complementado por diagramas de fluxo de dados.
• Modelagem de dados : para apoiar o fluxo de dados dos processos de negócios, encontre uma coleção de objetos de dados, defina atributos de objetos de dados e forme um modelo de dados em relacionamento com outros objetos de dados, que pode ser complementado por diagramas ER.
• Modelagem de processos : permite que objetos de dados completem diversas funções de negócios no fluxo de informações. Crie um processo para descrever a adição, modificação, exclusão e pesquisa de objetos de dados, ou seja, refine as caixas de processamento no diagrama de fluxo de dados.
• Geração de aplicativos : Use a linguagem de quarta geração (4GL) para escrever programas de processamento, reutilizar componentes existentes ou criar novos componentes reutilizáveis ​​e usar as ferramentas fornecidas pelo ambiente para gerar e construir automaticamente todo o sistema de aplicativos.
• Teste e entrega , devido à grande quantidade de reutilização, geralmente apenas o teste geral é feito, mas os componentes recém-criados ainda precisam ser testados.

Comparado ao modelo em cascata, o modelo RAD não usa linguagens de programação tradicionais de terceira geração para criar software, mas adota um método de desenvolvimento baseado em componentes, reutilizando estruturas de programa existentes (se possível) ou usando componentes reutilizáveis. se necessário. Em todos os casos, foram utilizadas ferramentas automatizadas para auxiliar na criação de software. Claramente, as restrições de tempo impostas a um projeto de modelo RAD exigem “um escopo escalável”. Se uma empresa puder ser modularizada de modo que cada função principal possa ser concluída em menos de três meses, então ela será candidata ao RAD. Cada função principal pode ser implementada por um grupo RAD separado e finalmente integrada para formar um todo.

O modelo RAD acelera o desenvolvimento através do uso extensivo de componentes reutilizáveis ​​e é particularmente eficaz no desenvolvimento de sistemas de informação. Mas como todos os outros modelos de processos de software, a abordagem RAD tem suas falhas:

• Nem todos os aplicativos são adequados para RAD. O modelo RAD tem requisitos relativamente altos de modularidade . Se alguma função não puder ser modularizada, haverá problemas com os componentes necessários para construir o RAD; se o alto desempenho for um indicador, o indicador deverá ser adaptado ao sistema ajustando a interface. Os componentes podem vencer e a abordagem RAD pode não funcionar.
• Os desenvolvedores e clientes devem concluir uma série de análises de demanda em um período de tempo muito curto. A cooperação inadequada por parte de qualquer uma das partes levará ao fracasso do projeto RAD.
• O RAD só pode ser utilizado para desenvolvimento de sistemas de informação e não é adequado para situações onde os riscos técnicos são elevados . Isso acontece quando um novo aplicativo utiliza muitas tecnologias novas ou quando o novo software exige um alto nível de interoperabilidade com programas de computador existentes.

3.10 Modelo de Processo Unificado (RUP/UP)

Recursos do RUP

(1) Orientado a casos de uso : Atividades como análise de requisitos, design, implementação e testes são todas orientadas por casos de uso.
(2) Centrado na arquitetura : incluindo a organização geral e o controle global do sistema, protocolos de comunicação, etc. É uma estrutura multidimensional e será descrita usando múltiplas visualizações (4 + 1 visualizações) .
(3) Iteração e incremento : Divida todo o desenvolvimento do projeto em vários processos iterativos. Em cada iteração, apenas parte dos requisitos do sistema são considerados, e processos como análise, design, implementação, testes e implantação são realizados; cada iteração é realizada com base nas partes concluídas, e algumas novas implementações funcionais são adicionadas cada vez. Isso continua até que o projeto final seja concluído.

Existem 4 fases no RUP

O processo unificado de desenvolvimento de software define quatro etapas de desenvolvimento, que são a etapa inicial, etapa de refinamento, etapa de construção e etapa de entrega de acordo com a sequência do processo, entre elas os principais documentos gerados na etapa de construção são os modelos de projeto.

• Estágio inicial : documento do plano do projeto (requisitos principais, recursos principais, restrições principais), modelo de caso de uso, plano do projeto

• Etapa de refinamento : completar o projeto arquitetônico e eliminar elementos de alto risco

• Fase de construção : modelo UML, casos de teste

• Fase de entrega : produto de software executável, manual do usuário, plano de suporte ao usuário.

Existem 9 fluxos de trabalho principais no RUP

O fluxo de trabalho do RUP é dividido em duas partes: fluxo de trabalho principal e fluxo de trabalho de suporte principal. Os fluxos de trabalho principais (processos em projetos) incluem modelagem, análise e design, implementação, teste e implantação de requisitos de negócios; os fluxos de trabalho de suporte principais (processos em organizações) incluem ambiente, gerenciamento de projetos, configuração e gerenciamento de mudanças.

O ciclo de vida de desenvolvimento de software RUP é um modelo bidimensional de desenvolvimento de software.Existem 9 fluxos de trabalho principais no RUP , como segue:

• Modelagem de negócios : Compreender a organização onde o sistema a ser desenvolvido está localizado e suas operações de negócios, garantir que todos os participantes tenham um entendimento comum da organização onde o sistema a ser desenvolvido está localizado e avaliar o impacto do sistema a ser desenvolvido sobre a organização.
• Requisitos : Definir as funções do sistema e a interface do usuário, permitir que os clientes conheçam as funções do sistema, permitir que os desenvolvedores entendam os requisitos do sistema e fornecer uma base para o orçamento e planejamento do projeto.
• Análise e design : Converta os resultados da análise de demanda em modelos de análise e design.
• Implementação : Converta o modelo de design em resultados de implementação, execute testes unitários no código desenvolvido e integre módulos desenvolvidos por diferentes implementadores em sistemas executáveis.
• Teste : Verifique a interação e integração entre os subsistemas, verifique se todos os requisitos estão implementados corretamente, arquive os defeitos descobertos na qualidade do software e faça sugestões para melhorar a qualidade do software.
• Implantação : empacotar, distribuir, instalar software, atualizar sistemas antigos; treinar usuários e equipe de vendas e fornecer suporte técnico.
• Gerenciamento de configuração e mudança : rastreie e mantenha a integridade e consistência de todos os artefatos produzidos durante o desenvolvimento do sistema.
• Gerenciamento de projetos : Fornece orientação sobre planejamento, alocação de pessoal, execução, monitoramento, etc. para projetos de desenvolvimento de software e fornece uma estrutura para gerenciamento de riscos.
• Ambiente : Fornece ambiente de desenvolvimento de software para organizações de desenvolvimento de software, ou seja, fornece gerenciamento de processos e suporte a ferramentas.

4. Engenharia reversa

A engenharia reversa é caracterizada pela extração de estrutura de dados, arquitetura e informações de programação de programas existentes.

Seu processo é: sistema existente → engenharia reversa → considerar novos requisitos → engenharia avançada → novo sistema.

A engenharia reversa de software é um processo de recuperação de um projeto, extraindo dados, arquitetura e informações de projeto de processo de um programa existente. A completude da engenharia reversa pode ser descrita pelo nível de detalhe fornecido em um determinado nível de abstração. Na maioria dos casos, quanto maior o nível de abstração, menor será a completude.

O nível de abstração em nível de domínio é o mais alto e o mais baixo de completude, e o nível de abstração em nível de implementação é o mais baixo e o mais alto de completude.

Os conceitos relacionados à engenharia reversa incluem refatoração, recuperação de projeto, reengenharia e engenharia direta:

• A reestruturação refere-se à transformação da forma de descrição do sistema no mesmo nível de abstração .
• A recuperação de design refere-se ao uso de ferramentas para abstrair informações sobre design de dados, design de estrutura geral e design de processos de programas existentes.
• A engenharia reversa é o processo de analisar um programa e tentar estabelecer uma representação do programa em um nível de abstração superior ao do código-fonte. A engenharia reversa é o processo de recuperação do design.
• Engenharia avançada refere-se não apenas à recuperação de informações de projeto de sistemas existentes, mas também ao uso dessas informações para alterar ou reconstruir sistemas existentes para melhorar sua qualidade geral .
• A reengenharia é um processo de redesenvolvimento de sistemas existentes, incluindo três etapas: engenharia reversa, consideração de novos requisitos e engenharia avançada .

Métodos de engenharia reversa para recuperar informações:

método	Exportar informações
Métodos de pesquisa e transformação guiados pelo usuário	Nível de implementação, nível de estrutura
método transformador	Nível de implementação, nível de estrutura, nível de função
Métodos baseados em conhecimento de domínio	Nível funcional, nível de domínio
Métodos de pesquisa e transformação guiados pelo usuário	Nível de implementação do método de recuperação de placa de chumbo, nível de estrutura

5. Engenharia de Requisitos

2.1 Hierarquia de requisitos de software

2.2 Engenharia de Requisitos

Os requisitos de software referem-se às expectativas dos usuários em relação ao sistema em termos de funções, comportamento, desempenho, restrições de design, etc.

Engenharia de Requisitos (ER) refere-se à aplicação de princípios e métodos comprovados e eficazes para descrever sistematicamente o sistema a ser desenvolvido, suas características comportamentais e restrições relacionadas por meio de ferramentas e notações apropriadas.

A engenharia de requisitos consiste em cinco etapas: aquisição de demanda, análise de demanda, formação de especificação de demanda (ou documentação de demanda), confirmação e verificação de demanda e gerenciamento de demanda, conforme mostrado na figura:

Especificação de Requisitos de Software (SRS)
SRS inclui especificamente requisitos funcionais , requisitos não funcionais e restrições . As restrições incluem restrições de projeto e restrições de processo. Um SRS aprovado éa ponte entre o desenvolvimento e o gerenciamento de requisitos .

Gerenciamento de Requisitos
O gerenciamento de requisitos é um processo de alteração, compreensão e controle de requisitos do sistema, incluindo controle de alterações, controle de versão, rastreamento de requisitos e outras atividades.

2.5 Desenvolvimento de requisitos (linha principal, objetivos)

2.5.1 Classificação de requisitos

• Classificação de requisitos

(1) Necessidades de negócios : As necessidades de negócios refletem os requisitos-alvo de alto nível da empresa ou do cliente para o sistema. Geralmente vêm de investidores de projetos, clientes que compram produtos, gerentes de unidades de clientes, departamentos de marketing ou departamentos de planejamento de produtos, etc. Os requisitos de negócios determinam a visão e o escopo do projeto.

(2) Requisitos do usuário : Os requisitos do usuário descrevem os objetivos específicos do usuário ou as tarefas que o usuário exige que o sistema conclua. Ou seja, os requisitos do usuário descrevem o que os usuários podem fazer com o sistema. Entrevistas e questionários com usuários geralmente são usados ​​para organizar cenários de uso do usuário (cenários) para estabelecer as necessidades do usuário.

(3) Requisitos do sistema : Os requisitos do sistema descrevem os requisitos de software de uma perspectiva do sistema, incluindo requisitos funcionais, requisitos não funcionais e restrições de design.

• QFD de Implantação da Função de Qualidade

É uma tecnologia que converte requisitos do usuário em requisitos de software, com o objetivo de maximizar a satisfação do usuário durante o processo de engenharia de software. Para atingir este objetivo, o QFD divide os requisitos de software em três categorias, nomeadamente requisitos regulares, requisitos esperados e requisitos inesperados.

(1) Necessidades básicas : também chamadas de necessidades regulares, as funções ou desempenho que os usuários acham que o sistema deve alcançar. Quanto mais funções ou desempenho forem implementados, mais satisfeitos os usuários ficarão.

(2) Requisitos esperados : Os usuários tomam como certas as funções ou o desempenho que o sistema deveria ter, mas não conseguem descrever corretamente as funções ou os requisitos de desempenho que desejam. Se as expectativas não forem atendidas, os usuários ficarão insatisfeitos.

(3) Requisitos inesperados : Requisitos inesperados, também conhecidos como requisitos interessantes, são funções ou desempenho fora do escopo dos requisitos do usuário (mas geralmente recursos técnicos que os desenvolvedores de software ficam felizes em fornecer ao sistema). Os usuários ficarão mais felizes se esses requisitos forem atendidos. realizados, mas não o são, nem afecta as suas decisões de compra.

2.5.2 Aquisição de requisitos

método	Características
juntar informação	Colete informações relacionadas ao sistema que sejam úteis para o desenvolvimento do sistema.
Leia documentos históricos	Útil para coletar informações baseadas em dados.
Entrevistas com usuários	1 a 1-3, usuários representativos, compreensão de pensamentos subjetivos, boa interação. O custo é alto e requer suporte de conhecimento de domínio.
Questionário	São muitos usuários , é impossível realizar uma entrevista e o custo é baixo .
Observação no local	Para processos e operações mais complexas.
Participe da prática empresarial	Descubra efetivamente a natureza dos problemas e encontre soluções para eles.
Planejamento de Requisitos Conjuntos (JRP)	Reuniões em grupo altamente organizadas, envolvendo todas as partes, entendendo ideias, eliminando diferenças, boa interação e alto custo.
Storyboard ( método de prototipagem)	Uma série de imagens através das quais uma história é contada.
Pesquisa/amostragem por amostragem	Com base em estatísticas matemáticas, reduza custos e obtenha rapidamente. Tamanho da amostra = a*(coeficiente de credibilidade/erro aceitável)2 Nota: a é geralmente 0,25

• Entrevistas com usuários
  As entrevistas com usuários são o meio mais básico de obtenção de requisitos e seus formulários incluem estruturados e não estruturados . Estruturado significa preparar antecipadamente uma série de perguntas e conduzi-las de forma direcionada; não estruturado significa apenas elencar uma ideia aproximada e desenvolvê-la de acordo com a situação específica da entrevista . As entrevistas mais eficazes são realizadas combinando estes dois métodos, afinal é impossível planear tudo com clareza e deve ser mantida uma boa flexibilidade.
  As entrevistas com usuários têm boa flexibilidade e uma ampla gama de aplicações . No entanto, também existem muitas dificuldades. Por exemplo, os usuários estão frequentemente ocupados e têm dificuldade em organizar o tempo; a quantidade de informações durante as entrevistas é grande e a gravação é difícil ; a comunicação requer muitas habilidades eos analistas de sistemas devem ter conhecimento de domínio suficiente , etc. Além disso, durante a entrevista, você também poderá se deparar com alguns temas confidenciais e delicados para a empresa. Portanto, esta tecnologia aparentemente simples também exige que os analistas de sistemas tenham vasta experiência e fortes habilidades de comunicação.

• 
  Pesquisa por questionário Em comparação com entrevistas com usuários, a pesquisa por questionário pode coletar dados de um grande número de respostas em um curto espaço de tempo e com baixo custo; a pesquisa por questionário permite que os entrevistados preencham anonimamente, e a maioria dos usuários pode fornecer informações reais ; pesquisa por questionário Os resultados são mais fáceis organizar e contar . No entanto, a maior deficiência da pesquisa por questionário é a falta de flexibilidade. Outras deficiências incluem:
  ① As duas partes não se encontraram. O analista do sistema não pode obter mais algumas informações implícitas da expressão do usuário e de outras ações, e o usuário não tem oportunidade esclarecer imediatamente sua opinião sobre a questão. Respostas vagas ou incorretas.
  ② Os usuários podem psicologicamente não prestar atenção a um formulário pequeno e não levá-lo a sério, resultando em informações de feedback incompletas.
  ③ O questionário não permite responder às perguntas e não consegue compreender alguns detalhes.
  ④ O número de respondentes costuma ser menor do que o esperado e não há garantia de que os usuários responderão às perguntas ou explicarão melhor todas as perguntas.

• Pesquisa/amostragem por amostragem A pesquisa
  /amostragem por amostragem refere-se ao processo de seleção sistemática de um conjunto de amostra representativo de uma população . Através de um estudo cuidadoso do conjunto de amostra selecionado, informações úteis sobre a população como um todo podem ser reveladas. Para o desenvolvimento de sistemas de informação, a documentação (arquivos) do sistema existente é a população amostral. Ao começar a fazer uma análise de requisitos de um sistema, revisar a documentação do sistema existente é a melhor maneira de obter uma compreensão preliminar do sistema. No entanto, que tipos de documentos os analistas de sistemas devem examinar?Quando os dados nos documentos são muito grandes para serem estudados um por um, técnicas de amostragem precisam ser usadas para selecionar dados representativos . A tecnologia de amostragem não só pode ser usada para coletar dados, mas também para coletar entrevistas com usuários ou coletar e observar usuários. As mesmas técnicas de amostragem descritas acima se aplicam à amostragem de pessoas. Através da tecnologia de amostragem, a selecção de partes em vez de toda a população não só acelera o processo de recolha de dados, mas também aumenta a eficiência, reduzindo assim os custos de desenvolvimento. Além disso, a tecnologia de amostragem utiliza os princípios da estatística matemática para reduzir distorções na recolha de dados.
  No entanto, como a tecnologia de amostragem é baseada em princípios estatísticos, a determinação do tamanho da amostra depende da credibilidade esperada e do conhecimento prévio existente, e depende em grande parte dos fatores subjetivos do analista de sistema, da experiência pessoal e da experiência do analista de sistema. altamente dependente e exige que os analistas de sistema tenham um alto nível e uma experiência rica.

• Planejamento Conjunto de Requisitos (JRP)
  O JRP é um método relativamente caro de obtenção de requisitos, mas também é muito eficaz. Ele discute os requisitospor meio de reuniões organizadas . Normalmente o número de participantes nesta reunião é de 6 a 18 pessoas, e a duração é de 1 a 5 horas .
  A principal intenção do JRP é coletar requisitos em vez de analisar e verificar os requisitos . Os seguintes princípios principais devem ser compreendidos ao implementar o JRP:
  ① Antes da implementação do JRP, uma agenda detalhada deve ser formulada e rigorosamente seguida.
  ② Realizar de acordo com o cronograma estabelecido.
  ③ Tente registrar o conteúdo da reunião da forma mais completa possível.
  ④ Tente evitar o uso de termos profissionais durante a discussão.
  ⑤ Faça pleno uso das habilidades de resolução de conflitos.
  ⑥ Deve ser definido tempo de intervalo suficiente durante a reunião.
  ⑦Incentive a equipe a chegar a um consenso.
  ⑧ Garantir que todo o pessoal participante do JRP possa cumprir as regras previamente acordadas.

2.5.2 Análise de requisitos

Análise de requisitos : um bom requisito deve ter características como inequívoco, integridade, consistência, testabilidade, certeza, rastreabilidade, correção e necessidade.Portanto, os analistas precisam combinar requisitos confusos do usuário com Converter em necessidades do usuário é o trabalho da análise de requisitos.

Tarefas de análise de requisitos :
(1) Desenhar o diagrama de escopo do contexto do sistema
(2) Criar um protótipo de interface do usuário
(3) Analisar a viabilidade dos requisitos
( 4) Determinar a prioridade dos requisitos
(5) Estabelecer um modelo para os requisitos
(6) Criar um conjunto de dados dicionário
(7) Use QFD (Desdobramento da Função de Qualidade)

2.5.2.1 Método de Análise Estruturada - SA

O núcleo do método de análise estruturada SA é o dicionário de dados . Existem três níveis de modelos em torno deste núcleo, nomeadamente modelo de dados, modelo funcional e modelo comportamental (modelo de estado) .

As etapas da análise estruturada são as seguintes:
(1) Analisar a situação do negócio e fazer um diagrama de fluxo de dados (Data Flow DiagramDFD) que reflita o modelo físico atual.
(2) Derive o DFD do modelo logístico equivalente.
(3) Projetar um novo sistema lógico e gerar dicionário de dados e descrição primitiva.
(3) Estabelecer uma interface homem-máquina e propor um DFD alternativo do modelo físico do sistema alvo.
(5) Determinar os custos e níveis de risco de várias opções e analisar várias opções em conformidade.
(6) Escolha um plano.
(7) Estabeleça uma especificação completa de requisitos.

O método de análise estruturada SA é fluxo de dados e fluxo de controle.Os métodos comumente usados ​​são diagrama de fluxo de dados (DFD) e dicionário de dados.

2.5.2.1.1 SA - Dicionário de Dados DD

O dicionário de dados é o núcleo do modelo de análise de requisitos. É uma descrição de cada fluxo de dados, arquivo, processo e item de dados que compõe o fluxo de dados ou arquivo no diagrama de fluxo de dados.

O dicionário de dados possui quatro categorias de entradas: fluxo de dados, itens de dados, armazenamento de dados e processamento básico. Incluindo elementos de dados, estruturas de dados, fluxos de dados, lógica de processamento e entidades externas. Como mostrado abaixo:

2.5.2.1.2 SA - Diagrama de Fluxo de Dados DFD

O diagrama de fluxo de dados (DFD) usa um diagrama de fluxo de dados para representar um modelo funcional. O DFD descreve as funções concluídas pelo sistema. Do ponto de vista da transmissão e processamento de dados, símbolos gráficos são usados ​​para descrever as funções de cada componente do sistema e a transferência de dados entre eles através da subdivisão camada por camada. situação para ilustrar as funções concluídas pelo sistema. Como mostrado abaixo:

Entre eles, o DFD também terá “mapa DFD de nível superior” e “mapa DFD de camada 0”.

Conforme mostrado na figura acima, existem as seguintes descrições de "elementos de imagem":

Em anexo está um diagrama DFD incorreto, como segue:

Erro conforme mostrado acima:

O processamento 3.1.2 tem entrada, mas não tem saída, o que é chamado de "buraco negro".
O processamento 3.1.3 tem saída, mas não tem entrada. Chame isso de "milagre".
No processamento 3.1.1, a entrada não é suficiente para produzir a saída, que chamamos de “buraco cinza”.

2.5.2.1.3 SA - Diagrama de Transição de Estado STD

Um diagrama de transição de estado é usado para representar um modelo comportamental.STD representa o comportamento do sistema descrevendo o estado do sistema e os eventos que causam a transição de estado do sistema, indicando quais ações serão executadas como resultado de eventos específicos. Como mostrado abaixo:

2.5.2.1.4 SA - diagrama ER/diagrama entidade-relacionamento

O diagrama ER descreve principalmente os atributos da entidade e os relacionamentos entre as entidades. Além disso, o modelo ER é um modelo e produto da era estruturada e não existe na orientação a objetos e na UML. Como mostrado abaixo:

O que é uma entidade fraca?
Por exemplo: No sistema de gestão de pessoal, a informação sobre os filhos dos empregados baseia-se na existência de empregados.A entidade infantil é uma entidade fraca, e a relação entre filhos e empregados é uma relação de dependência. Portanto, os colaboradores são entidades e também podem se tornar entidades fortes.
A relação entre entidades fortes e entidades fracas só pode ser 1:1 ou 1:N.

2.5.2.2 Método de análise orientada a objetos - OOA

Vários conceitos relacionados

objeto	Atributo [dados] + método [operação] + ID do objeto/ID de identificação
Aula [ver detalhes abaixo]	Classe de entidade/classe de controle/classe de limite Classe de entidade: geralmente tem um relacionamento correspondente com o banco de dados, seja um tipo de dados Classe de controle: uma classe que conecta classes de entidade e classes de limite Classe de limite: uma classe que se comunica com o exterior no limite de um sistema A relação entre três modelos MVC semelhantes, suas ideias são as mesmas
Herança e generalização	Mecanismo de reutilização, é uma espécie de acoplamento apertado. Porque quando a classe pai muda, a subclasse tem que mudar. A herança é baseada em instâncias existentes
encapsulamento	Oculte as propriedades e detalhes de implementação do objeto e exponha apenas a interface ao mundo externo
Polimorfismo	Objetos diferentes recebem as mesmas informações e produzem resultados diferentes.
interface	Uma classe especial que possui apenas definições de métodos, mas nenhuma implementação de métodos
Sobrecarga	Uma classe pode ter vários métodos com o mesmo nome e diferentes tipos de parâmetros. A característica de uma função com o mesmo nome, mas com parâmetros diferentes, é que
comunicação de notícias	As mensagens são comunicadas de forma assíncrona
Substituir e reescrever	O método com o mesmo nome da subclasse substitui o método com o mesmo nome da classe pai
Combinação e agregação	Relação de agregação: a relação entre as peças do automóvel e todo o veículo (o ciclo de vida do todo e da peça é diferente) Relação de combinação: a relação entre departamentos e empresas. Se a empresa falir, os departamentos serão extintos (todo o ciclo de vida é igual ao ciclo de vida da peça)

OOA segue aproximadamente as 5 etapas básicas a seguir:

（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

2.5.2.2.1 OOA - UML

OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。

UML基本构造块之事物【重要组成部分】

事务	描述
结构事物	最静态的部分，包括类，接口，协作用例，活动类，构件和节点
行为事物	代表时间和空间上的动作，包括消息，动作次序，连接
分组事物	看成是个盒子，如包和构件
注释事物	UML模型的解释部分。描述，说明，和标注模型的元素

UML基本构造块之关系【把事物紧密联系在一起】

关系	描述
依赖关系	一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖
泛化关系	特殊一般关系，特殊元素的对象可替换一般元素的对象
关联关系	描述了一个链，链是对象之间的连接
实现关系	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系。
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.5.2.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.5.2.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.5.2.2.4 需求分析工具

2.5.2.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.5.2.2.4.1 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.5.2.2.4.1 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.5.2.2.4.1 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.5.3 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5.4 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

2.6 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

2.6.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

2.6.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

2.6.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

2.6.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

(1) Todas as alterações de requisitos devem seguir o processo de controle de alterações.
(2) O trabalho de concepção e implementação não deve ser realizado para alterações que não tenham sido aprovadas.
(3) As mudanças devem ser decididas pelo Conselho de Controle de Mudanças do Projeto e quais mudanças devem ser implementadas.
(4) Os detentores dos riscos do projeto devem ser capazes de compreender o conteúdo das alterações.
(5) O documento original da solicitação de mudança não deve ser excluído ou modificado da biblioteca de configuração do projeto.
(6) Cada mudança de requisito integrada deve ser rastreável até uma solicitação de mudança aprovada para manter a rastreabilidade horizontal.

2.6.5 Risco de demanda

As práticas arriscadas incluem: ① Não há usuários suficientes para participar. ②A classificação do usuário é ignorada. ③As demandas dos usuários continuam a aumentar. ④ Necessidades ambíguas. ⑤Recursos desnecessários. ⑥SRS excessivamente simplificado. ⑦Estimativa imprecisa.

Razões para mudanças: ① Mudanças no ambiente externo. ②Os requisitos e o design não estão suficientemente completos. ③O surgimento de novas tecnologias. ④ A reorganização da organização da empresa resulta em mudanças nos processos de negócios.

2.6.6 Acompanhamento de requisitos

Os requisitos de cada item de configuração de software no SRS devem ser rastreáveis ​​bidirecionalmente aos requisitos dos sistemas (ou subsistemas) envolvidos. O chamado rastreamento bidirecional inclui rastreamento direto e rastreamento reverso. O rastreamento direto refere-se à verificação se cada requisito no SRS pode encontrar um ponto correspondente nos resultados de trabalho subsequentes; o rastreamento reverso, também chamado de rastreamento reverso, refere-se à verificação do projeto • Se documentos, códigos, casos de teste e outros resultados de trabalho podem ser encontrados no SRS.