Visão geral do ciclo de vida de desenvolvimento de software (SDLC)

Table of Contents hide

1 Modelo cascata

2 Modelo de transformação

2.1 Modelo espiral

2.2 Modelo de fonte

2.3 modelo V

2.4 Modelo incremental

2.5 Modelo baseado em componentes

2.6 Método de protótipo

2.7 método XP

2.8 Método de Processo Unificado (UP)

2.9 Saber mais

O ciclo de vida de desenvolvimento de software fornece às organizações uma abordagem sistemática, passo a passo, para desenvolver software bem-sucedido, coletando os requisitos iniciais para novos produtos. É um processo sistemático de construção de software para garantir a qualidade e correção do software construído e para atender às expectativas do cliente.

Os principais modelos de desenvolvimento incluem modelo cascata, modelo incremental, modelo espiral, modelo fonte, modelo inteligente, modelo V, modelo RAD, modelo CBSD, método protótipo, método XP, método RUP, etc.

Modelo cascata

O modelo cascata, também conhecido como método do ciclo de vida, é o modelo de desenvolvimento mais utilizado no método do ciclo de vida. Ele divide o processo de desenvolvimento de software em seis etapas: planejamento de software, análise de requisitos, projeto de software, codificação de programa, teste de software e operação e manutenção. Para atingir sua ordem fixa de cima para baixo, como uma cachoeira, eles caem passo a passo.

Plano de software : principalmente determinar os objetivos de desenvolvimento e viabilidade do software.
Análise de requisitos : Depois de confirmar que o desenvolvimento do software é viável, faça uma análise detalhada das várias funções que o software precisa alcançar. A fase de análise de requisitos é uma fase muito importante. Um bom trabalho nesta fase estabelecerá uma boa base para o sucesso de todo o projeto de desenvolvimento de software.
Projeto de software : Projete todo o sistema de software, como projeto de estrutura de sistema, projeto de banco de dados, etc., com base nos resultados da análise de demanda. O projeto de software é geralmente dividido em projeto geral (projeto de esboço) e projeto detalhado.
Código do programa : Converte o resultado do projeto do software em código de programa que pode ser executado por um computador. No processo de programação, uma especificação de programação unificada e compatível com o padrão deve ser formulada para garantir a legibilidade do programa, fácil manutenção e melhorar a eficiência operacional do programa.
Teste de software : Após a conclusão do projeto de software, ele deve passar por testes rigorosos para encontrar e corrigir os problemas no software durante todo o processo de projeto. No processo de teste, é necessário estabelecer um plano de teste detalhado e realizar testes em estrita conformidade com o plano de teste para reduzir a arbitrariedade do teste. Manutenção de software:
A manutenção de software é o período mais longo no ciclo de vida do software. Depois que o software é desenvolvido e colocado em uso, devido a vários motivos, o software não pode continuar a atender aos requisitos dos usuários. Para estender a vida útil do software, o software deve ser mantido.

Modelo de transformação

O modelo de transformação (modelo de evolução) baseia-se no desenvolvimento rápido de um protótipo. De acordo com os comentários e sugestões apresentados pelos usuários no processo de chamada do protótipo, o protótipo é aprimorado para obter uma nova versão do protótipo, e esse processo é repetido até evoluir para o produto de software final.

Modelo espiral

O modelo espiral combina o modelo cascata e o modelo de transformação. Ele combina as vantagens dos dois e adiciona análise de risco. Ele é baseado 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. Após várias espirais, o sistema final é obtido.

Modelo de fonte

O modelo de fonte fornece suporte para reutilização de software e integração de várias atividades de desenvolvimento no ciclo de vida e suporta principalmente métodos de desenvolvimento orientados a objetos. O próprio termo “fonte” incorpora as características de iteração e ausência de lacunas. Uma certa parte do sistema geralmente repete o trabalho muitas vezes, e funções relacionadas são adicionadas ao sistema evoluído em cada iteração. O chamado gapless significa que não há um limite óbvio entre análise, design e codificação nas atividades de desenvolvimento.

modelo V

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 em teste, ou seja, o modelo V. O modelo V foi apenas vagamente reconhecido na indústria de software. O modelo V afirma que o teste não é uma reflexão tardia, mas um processo tão importante quanto o processo de desenvolvimento.

O modelo V descreve alguns níveis de teste diferentes e explica as diferentes etapas do ciclo de vida correspondentes a esses níveis. Na figura, a descida à esquerda são as várias etapas do processo de desenvolvimento, e as correspondentes são as partes ascendentes à direita, ou seja, as várias etapas do processo de teste.

Observe que a nomenclatura da fase de teste pode ser diferente em diferentes organizações. O valor do modelo V é que ele mostra claramente os diferentes níveis que existem no processo de teste e descreve claramente a correspondência entre essas fases de teste e as várias fases durante o processo de desenvolvimento:

O principal objetivo do teste de unidade é lidar com vários erros que podem existir no processo de codificação. Por exemplo: o usuário insere um erro no valor limite durante o processo de verificação.
O principal objetivo do teste de integração é abordar os possíveis problemas no projeto detalhado, principalmente para verificar os possíveis erros na interface entre cada unidade e outras partes do programa.
O teste do sistema é principalmente para o projeto do esboço, verificando se o sistema como um todo está operando efetivamente. Por exemplo: Se o alto desempenho esperado é alcançado nas configurações do produto.
O teste de aceitação geralmente é realizado por especialistas em negócios ou usuários para confirmar se o produto pode realmente atender às necessidades de negócios do usuário.

Modelo incremental

Modelos incrementais, como modelos de implementação de protótipos e outros métodos evolutivos, são essencialmente iterativos. Mas, ao contrário da implementação do protótipo, o modelo incremental enfatiza que cada incremento libera um produto operável. Os primeiros incrementos são a versão “destacável” do produto final, mas eles fornecem funções de serviço ao usuário e fornecem uma plataforma para os usuários avaliarem.

A característica do modelo incremental é a introdução do conceito de pacotes incrementais. Você não precisa esperar até que todos os requisitos saiam, desde que os pacotes incrementais de um determinado requisito saiam, você pode iniciar o desenvolvimento. Embora um determinado pacote incremental possa precisar ser adaptado às necessidades dos clientes e precisar ser alterado, desde que o pacote incremental seja pequeno o suficiente, seu impacto pode ser suportável para todo o projeto.

Modelo RAD O modelo RAD (Rapid Application Development) é um modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento muito curto.

O modelo RAD é uma variante de “alta velocidade” do modelo cascata, que ganha rápido desenvolvimento por meio do uso extensivo de componentes reutilizáveis e um método de construção baseado em componentes. Se os requisitos forem bem compreendidos e o escopo do projeto for restrito, esse modelo pode ser usado para criar rapidamente um “sistema de informação” totalmente funcional.

O processo começa com a modelagem de negócios, seguida pela modelagem de dados, modelagem de processos, geração de aplicativos, teste e iteração. O processo de software usando o modelo RAD é mostrado na figura abaixo.

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 impulsionam a operação do processo de negócios? Quais informações devem ser geradas? Quem o gerou? Para onde vai o fluxo de informações? Quem vai lidar com isso? Pode ser complementado por diagramas de fluxo de dados.

Modelagem de dados: Para dar suporte ao fluxo de dados do processo de negócios, encontre a coleção de objetos de dados, defina os atributos dos objetos de dados e forme o modelo de dados com o relacionamento com outros objetos de dados, que podem ser complementados por diagramas ER .

Modelagem de processos: permite que objetos de dados completem várias funções de negócios no fluxo de informações. O processo de criação descreve a adição, modificação, exclusão e busca de objetos de dados, ou seja, o refinamento da caixa de processamento no diagrama de fluxo de dados.

Geração de programa aplicativo: Use a linguagem de quarta geração (4GL) para escrever o programa 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 aplicativo.

Teste e entrega, devido a uma grande quantidade de reutilização, geralmente só fazem testes gerais, mas os componentes recém-criados ainda precisam ser testados.

Modelo baseado em componentes

Componente (Componente) é uma unidade de software com valor reutilizável e funções relativamente independentes. O modelo de Desenvolvimento de Software Baseado em Componentes (CBSD) é usar uma abordagem modular para modularizar todo o sistema e, com o suporte de um determinado modelo de componente, reutilizar um ou mais componentes de software na biblioteca de componentes, por meio da combinação O processo de construção de software aplicativo sistemas com alta eficiência e alta qualidade.

O modelo de desenvolvimento baseado em componentes incorpora muitas características do modelo espiral e é essencialmente evolutivo, 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, construção de software aplicativo, teste e lançamento.

Método de protótipo

O protótipo de software é a realização parcial do novo produto proposto. O principal objetivo de estabelecer o protótipo é resolver o problema de demanda incerta no estágio inicial de desenvolvimento do produto. Seu objetivo é esclarecer e melhorar os requisitos, explorar opções de design e desenvolver o produto final.

Há muitas maneiras de classificar protótipos. Da perspectiva de se o protótipo realiza suas funções, os protótipos de software podem ser divididos em dois tipos: protótipos horizontais e protótipos verticais.

Os protótipos horizontais também são chamados de protótipos de comportamento, que são usados para explorar alguns comportamentos específicos do sistema esperado e atingir o propósito de refinar os requisitos. Os protótipos horizontais geralmente são apenas navegação de funções, mas na verdade não implementam funções. O protótipo horizontal é usado principalmente na interface.

Os protótipos verticais também são chamados de protótipos estruturados, que implementam parte de suas funções. Os protótipos verticais são usados principalmente na realização de algoritmos complexos.

método XP

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, a maior diferença está em:

Fornecer feedback específico e contínuo mais cedo em um período mais curto.
Planejamento iterativo, primeiro gerando um plano mestre rapidamente no início e depois desenvolvendo-o continuamente durante todo o processo de desenvolvimento do projeto.
Confie em procedimentos de teste automatizados para monitorar o progresso do desenvolvimento e detectar defeitos antecipadamente.
Confie na comunicação verbal, teste e comunicação do programa de origem.
Defenda o design evolutivo contínuo.
Confie na estreita colaboração dentro da equipe de desenvolvimento.
Tente equilibrar os interesses de curto prazo do programador e os interesses de longo prazo do projeto, tanto quanto possível.

Método de Processo Unificado (UP)

O Processo Unificado é uma estrutura de processo geral que pode lidar com uma ampla variedade de sistemas de software, diferentes campos de aplicação, diferentes tipos de organização, diferentes níveis de desempenho e diferentes escalas de projeto. O UP é baseado em componentes, o que significa que o sistema de software desenvolvido por ele é composto por componentes, e os componentes são conectados entre si por meio de interfaces bem definidas. Ao preparar todos os blueprints do sistema de software, a UP utiliza a linguagem de modelagem unificada UML.

Comparado com outros processos de software, o UP possui três características notáveis: orientado a casos de uso, centrado na arquitetura básica, iteração e incremento. O processo de software no Rational Unified Process é dividido em quatro fases sequenciais no tempo, ou seja, a fase inicial, a fase de refinamento, a fase de construção e a fase de entrega. Ao final de cada etapa, uma revisão técnica deve ser organizada para determinar se os objetivos desta etapa foram alcançados. Se os resultados da revisão forem satisfatórios, o projeto pode passar para o próximo estágio.