Ciclo de vida de desenvolvimento de sistemas

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

Modelo do ciclo de vida de desenvolvimento de software, com destaque para a fase de manutenção

Em engenharia de sistemas , sistemas de informação e engenharia de software , o ciclo de vida de desenvolvimento de sistemas ( SDLC ), também conhecido como ciclo de vida de desenvolvimento de aplicativos , é um processo para planejar, criar, testar e implantar um sistema de informação . [1] O conceito de ciclo de vida de desenvolvimento de sistemas se aplica a uma variedade de configurações de hardware e software, pois um sistema pode ser composto apenas de hardware, apenas de software ou uma combinação de ambos. [2] Geralmente há seis estágios neste ciclo: análise de requisitos, design, desenvolvimento e teste, implementação, documentação e avaliação.

Visão geral

Um ciclo de vida de desenvolvimento de sistemas é composto de várias fases de trabalho claramente definidas e distintas que são usadas por engenheiros de sistemas e desenvolvedores de sistemas para planejar, projetar, construir, testar e entregar sistemas de informação . Como tudo o que é fabricado em uma linha de montagem, um SDLC visa produzir sistemas de alta qualidade que atendam ou superem as expectativas do cliente, com base nos requisitos do cliente, fornecendo sistemas que se movem através de cada fase claramente definida, dentro de prazos programados e estimativas de custo. [3] Os sistemas de computador são complexos e muitas vezes (especialmente com o recente aumento da arquitetura orientada a serviços) ligam vários sistemas tradicionais potencialmente fornecidos por diferentes fornecedores de software. Para gerenciar esse nível de complexidade, vários modelos ou metodologias SDLC foram criados, como cascata , espiral , desenvolvimento de software ágil , prototipagem rápida , incremental e sincronizar e estabilizar. [4]

SDLC pode ser descrito ao longo de um espectro de metodologias ágeis para iterativas e sequenciais. Metodologias ágeis, como XP e Scrum , focam em processos leves que permitem mudanças rápidas (sem necessariamente seguir o padrão de abordagem SDLC) ao longo do ciclo de desenvolvimento. [5] Metodologias iterativas , como o Rational Unified Process e o método de desenvolvimento de sistemas dinâmicos , focam no escopo limitado do projeto e na expansão ou melhoria de produtos por várias iterações. Modelos sequenciais ou big-design-up-front (BDUF), como cascata, focam no planejamento completo e correto para guiar grandes projetos e riscos a resultados bem-sucedidos e previsíveis. [ citação necessária] Outros modelos, como desenvolvimento anamórfico , tendem a se concentrar em uma forma de desenvolvimento que é guiada pelo escopo do projeto e iterações adaptativas de desenvolvimento de recursos.

No gerenciamento de projetos, um projeto pode ser definido tanto com um ciclo de vida do projeto (PLC) quanto com um SDLC, durante o qual ocorrem atividades ligeiramente diferentes. De acordo com Taylor (2004), “o ciclo de vida do projeto engloba todas as atividades do projeto , enquanto o ciclo de vida do desenvolvimento de sistemas concentra-se na realização dos requisitos do produto ”. [6]

O SDLC não é uma metodologia em si, mas sim uma descrição das fases do ciclo de vida de uma aplicação de software. Em um sentido amplo, essas fases são: investigação, análise, projeto, construção, teste, implementação e manutenção e suporte. Todas as metodologias de desenvolvimento de software seguem as fases do SDLC, mas o método de fazer isso varia muito entre as metodologias. No framework Scrum, [7] por exemplo, pode-se dizer que uma única história de usuário passa por todas as fases do SDLC em um único sprint de duas semanas. Compare isso com a metodologia em cascata, como outro exemplo, onde todos os requisitos de negócios (registrados na fase de análise do SDLC em um documento chamado Especificação de Requisitos de Negócios) [ citação necessária ]é traduzido em descrições de recursos/funcionais (registradas na fase de design em um documento chamado de Especificação Funcional) que são, então, todas construídas de uma só vez como uma coleção de recursos da solução normalmente durante um período de três a nove meses ou mais. [ citação necessário ] Essas metodologias são abordagens diferentes, mas ambas contêm as fases do SDLC nas quais um requisito nasce, então percorre as fases do ciclo de vida terminando na fase final de manutenção e suporte, após a qual todo o ciclo de vida normalmente começa novamente para uma versão subsequente do aplicativo de software. [ citação necessária ]

História e detalhes

O ciclo de vida do produto descreve o processo de construção de sistemas de informação de forma muito deliberada, estruturada e metódica, reiterando cada etapa da vida do produto. O ciclo de vida de desenvolvimento de sistemas, de acordo com Elliott & Strachan & Radford (2004), "se originou na década de 1960, para desenvolver sistemas de negócios funcionais em larga escala em uma era de conglomerados empresariais de grande escala . As atividades de sistemas de informação giravam em torno de processamento pesado de dados e processamento de números rotinas". [8]

Várias estruturas de desenvolvimento de sistemas foram parcialmente baseadas em SDLC, como o método de análise e projeto de sistemas estruturados (SSADM) produzido para o Office of Government Commerce do governo do Reino Unido na década de 1980. Desde então, de acordo com Elliott (2004), "as abordagens tradicionais do ciclo de vida para o desenvolvimento de sistemas foram cada vez mais substituídas por abordagens e estruturas alternativas, que tentaram superar algumas das deficiências inerentes ao SDLC tradicional". [8]

Fases

A estrutura do ciclo de vida de desenvolvimento do sistema fornece uma sequência de atividades para os projetistas e desenvolvedores do sistema seguirem. Consiste em um conjunto de etapas ou fases em que cada fase do SDLC utiliza os resultados da anterior. [9] [10]

O SDLC adere a fases importantes que são essenciais para desenvolvedores—como planejamento , análise , design e implementação — e são explicadas na seção abaixo. Isso inclui avaliação do sistema atualmente usado, coleta de informações, estudos de viabilidade e aprovação de solicitação. Vários modelos SDLC foram criados, incluindo cascata, fonte, espiral, construção e correção, prototipagem rápida, incremental, sincronizar e estabilizar. [11] [12] O mais antigo deles, e o mais conhecido, é o modelo em cascata , uma sequência de estágios em que a saída de cada estágio se torna a entrada para o próximo. [10]Esses estágios podem ser caracterizados e divididos de diferentes maneiras, incluindo o seguinte: [9] [10] [13] [14]

Uma versão de dez fases do ciclo de vida de desenvolvimento de sistemas [9]
  • Análise preliminar : Comece com uma análise preliminar, proponha soluções alternativas, descreva custos e benefícios e apresente um plano preliminar com recomendações.
  1. Realizar a análise preliminar: Descobrir os objetivos da organização e a natureza e abrangência do problema em estudo. Mesmo que um problema se refira apenas a um pequeno segmento da própria organização, descubra quais são os objetivos da própria organização. Então veja como o problema que está sendo estudado se encaixa com eles.
  2. Propor soluções alternativas: Depois de investigar os objetivos da organização e problemas específicos, várias soluções podem ter sido descobertas. No entanto, propostas alternativas ainda podem vir de entrevistas com funcionários, clientes, fornecedores e/ou consultores. O insight também pode ser obtido pesquisando o que os concorrentes estão fazendo.
  3. Análise custo-benefício: Analisar e descrever os custos e benefícios da implementação das mudanças propostas. No final, a decisão final sobre deixar o sistema como está, melhorá-lo ou desenvolver um novo sistema será guiada por isso e pelo restante dos dados da análise preliminar.
  • Análise de sistemas, definição de requisitos : Defina os objetivos do projeto em funções e operações definidas da aplicação pretendida. Isso envolve o processo de coleta e interpretação de fatos, diagnóstico de problemas e recomendação de melhorias no sistema. Os objetivos do projeto serão ainda auxiliados pela análise das necessidades de informações do usuário final e pela remoção de quaisquer inconsistências e incompletudes nesses requisitos.
Uma série de etapas seguidas pelo desenvolvedor incluem: [15]
  1. Coleta de fatos: Obtenha os requisitos do usuário final por meio de documentação, entrevistas com clientes, observação e questionários.
  2. Escrutínio do sistema existente: Identificar prós e contras do sistema atual em vigor, de modo a levar adiante os prós e evitar os contras no novo sistema.
  3. Análise do sistema proposto: Encontre soluções para as deficiências descritas na etapa dois e prepare as especificações usando quaisquer propostas específicas do usuário.
  • Projeto de sistemas : Nesta etapa, os recursos e operações desejados são descritos em detalhes, incluindo layouts de tela, regras de negócios , diagramas de processo , pseudocódigo e outras documentações.
  • Desenvolvimento : O código real está escrito aqui.
  • Integração e teste : Todos os módulos são reunidos em um ambiente de teste especial e, em seguida, verificados quanto a erros, bugs e interoperabilidade.
  • Aceitação, instalação, implantação : Este é o estágio final do desenvolvimento inicial, onde o software é colocado em produção e executa os negócios reais.
  • Manutenção : Durante a fase de manutenção do SDLC, o sistema é avaliado/avaliado para garantir que não se torne obsoleto. É também aqui que as alterações são feitas no software inicial.
  • Avaliação : Algumas empresas não veem isso como uma etapa oficial do SDLC, enquanto outras consideram como uma extensão da etapa de manutenção e podem ser chamadas em alguns círculos como revisão pós-implementação. É aqui que se avalia o sistema desenvolvido, bem como todo o processo. Algumas das perguntas que precisam ser respondidas incluem se o sistema recém-implementado atende aos requisitos e objetivos iniciais de negócios, se o sistema é confiável e tolerante a falhas e se funciona de acordo com os requisitos funcionais aprovados. Além de avaliar o software que foi lançado, é importante avaliar a eficácia do processo de desenvolvimento. Se houver algum aspecto de todo o processo (ou certas etapas) com o qual a administração não esteja satisfeita, este é o momento de melhorar.
  • Descarte: Nesta fase, são desenvolvidos planos para descontinuar o uso de informações do sistema, hardware e software e fazer a transição para um novo sistema. O objetivo aqui é mover, arquivar, descartar ou destruir adequadamente informações, hardware e software que estão sendo substituídos, de forma a evitar qualquer possibilidade de divulgação não autorizada de dados confidenciais. As atividades de descarte garantem a migração adequada para um novo sistema. É dada especial ênfase à preservação e arquivamento adequados dos dados processados ​​pelo sistema anterior. Tudo isso deve ser feito de acordo com os requisitos de segurança da organização. [16]

No diagrama a seguir, esses estágios do ciclo de vida de desenvolvimento de sistemas são divididos em dez etapas, desde a definição até a criação e modificação dos produtos de trabalho de TI:

Nem todo projeto exigirá que as fases sejam executadas sequencialmente; no entanto, as fases são interdependentes. Dependendo do tamanho e complexidade do projeto, as fases podem ser combinadas ou podem se sobrepor. [9]

Investigação do sistema

Primeiro, a proposta do sistema de TI é investigada. Durante esta etapa, considere todas as prioridades atuais que seriam afetadas e como elas devem ser tratadas. Antes que qualquer planejamento do sistema seja feito, um estudo de viabilidade deve ser realizado para determinar se a criação de um sistema novo ou melhorado é uma solução viável. Isso ajudará a determinar os custos, benefícios, requisitos de recursos e necessidades específicas do usuário necessárias para a conclusão. O processo de desenvolvimento só pode continuar depois que a administração aprovar as recomendações do estudo de viabilidade. [17]

A seguir, representam diferentes componentes do estudo de viabilidade:

Análise

O objetivo da análise é determinar onde está o problema, na tentativa de consertar o sistema. Esta etapa envolve dividir o sistema em diferentes partes para analisar a situação, analisar os objetivos do projeto, dividir o que precisa ser criado e tentar engajar os usuários para que os requisitos definidos possam ser definidos.

Projeto

No projeto de sistemas , as funções e operações do projeto são descritas em detalhes, incluindo layouts de tela, regras de negócios, diagramas de processo e outras documentações. A saída deste estágio descreverá o novo sistema como uma coleção de módulos ou subsistemas.

A fase de projeto toma como entrada inicial os requisitos identificados no documento de requisitos aprovado. Para cada requisito, um conjunto de um ou mais elementos de design será produzido como resultado de entrevistas, workshops e/ou esforços de protótipo.

Os elementos de design descrevem os recursos desejados do sistema em detalhes e geralmente incluem diagramas de hierarquia funcional, diagramas de layout de tela, tabelas de regras de negócios, diagramas de processos de negócios, pseudocódigo e um diagrama de entidade-relacionamento completo com um dicionário de dados completo. Esses elementos de design destinam-se a descrever o sistema com detalhes suficientes, de modo que desenvolvedores e engenheiros qualificados possam desenvolver e entregar o sistema com o mínimo de design de entrada adicional.

Ambientes

Ambientes são áreas controladas onde os desenvolvedores de sistemas podem construir, distribuir, instalar, configurar, testar e executar sistemas que se movem pelo SDLC. Cada ambiente está alinhado com diferentes áreas do SDLC e tem finalidades específicas. Exemplos de tais ambientes incluem:

  • ambiente de desenvolvimento , onde os desenvolvedores podem trabalhar independentemente uns dos outros antes de tentar mesclar seu trabalho com o trabalho de outros;
  • ambiente de construção comum , onde o trabalho mesclado pode ser construído, em conjunto, como um sistema combinado;
  • ambiente de teste de integração de sistemas , onde testes básicos dos pontos de integração de um sistema para outros sistemas upstream ou downstream podem ser testados;
  • ambiente de teste de aceitação do usuário , onde as partes interessadas do negócio podem testar em relação aos seus requisitos de negócios originais; e
  • ambiente de produção , onde os sistemas finalmente são implantados para uso final por seus usuários finais pretendidos.

Testando

O código é testado em vários níveis de teste de software . Testes de aceitação de unidade, sistema e usuário são frequentemente realizados. Esta é uma área cinzenta, pois existem muitas opiniões diferentes sobre quais são os estágios de teste e quanto, se ocorrer alguma iteração. A iteração geralmente não faz parte do modelo em cascata, mas os meios para corrigir defeitos e validar correções antes da implantação são incorporados a essa fase.

A seguir estão os tipos de testes que podem ser relevantes, dependendo do tipo de sistema em desenvolvimento:

Treinamento e transição

Depois que um sistema é estabilizado por meio de testes adequados, o SDLC garante que o treinamento adequado no sistema seja realizado ou documentado antes de fazer a transição do sistema para sua equipe de suporte e usuários finais. O treinamento geralmente abrange o treinamento operacional para as pessoas que serão responsáveis ​​pelo suporte do sistema, bem como o treinamento para os usuários finais que usarão o sistema após sua entrega em um ambiente operacional de produção.

Após a conclusão bem-sucedida do treinamento, os engenheiros e desenvolvedores de sistemas fazem a transição do sistema para seu ambiente de produção final, onde ele deve ser usado por seus usuários finais e apoiado por sua equipe de suporte e operações.

Operações e manutenção

A implantação do sistema inclui várias alterações e aprimoramentos antes da desativação ou encerramento do sistema. A manutenção do sistema é um aspecto muito importante do SDLC. À medida que o pessoal-chave muda de posição na organização, novas mudanças serão implementadas. Existem duas abordagens para o desenvolvimento de sistemas: a abordagem tradicional (estruturada) e a orientada a objetos . A engenharia da informação inclui a abordagem de sistema tradicional, que também é chamada de análise estruturada e técnica de projeto. A abordagem orientada a objetos vê um sistema de informação como uma coleção de objetos que são integrados entre si para formar um sistema de informação completo e completo.

Avaliação

A fase final do SDLC é medir a eficácia do sistema e avaliar possíveis melhorias.

Análise e projeto de sistemas

Análise e projeto de sistemas (SAD)é o processo de desenvolvimento de sistemas de tecnologia da informação (ITS) que efetivamente usam hardware, software, dados, processos e pessoas para apoiar os objetivos de negócios da empresa. É um processo de planejamento de um novo sistema de negócios ou substituição de um sistema existente, definindo seus componentes ou módulos para satisfazer requisitos específicos. A análise e o projeto do sistema podem ser considerados a atividade de metadesenvolvimento, que serve para definir o cenário e delimitar o problema. O SAD pode ser aproveitado para definir o equilíbrio correto entre os requisitos de alto nível concorrentes nos domínios de análise funcional e não funcional. A análise e o design do sistema interagem fortemente com a arquitetura corporativa distribuída, a arquitetura corporativa de TI e a arquitetura de negócios, e depende muito de conceitos como particionamento, interfaces, personagens e funções, e implantação/modelagem operacional para chegar a uma descrição de sistema de alto nível. Essa descrição de alto nível é então dividida em componentes e módulos que podem ser analisados, projetados e construídos separadamente e integrados para atingir a meta de negócios. SDLC e SAD são os pilares do planejamento de produtos e sistemas de ciclo de vida completo.

Análise orientada a objetos

A análise orientada a objetos (OOA) é o processo de análise de uma tarefa (também conhecido como domínio do problema ), para desenvolver um modelo conceitual que pode ser usado para concluir a tarefa. Um modelo OOA típico descreveria um software de computador que poderia ser usado para satisfazer um conjunto de requisitos definidos pelo cliente. Durante a fase de análise de resolução de problemas, um programador pode considerar uma declaração de requisitos escrita, um documento de visão formal ou entrevistas com partes interessadas ou outras partes interessadas. A tarefa a ser abordada pode ser dividida em várias subtarefas (ou domínios), cada uma representando um negócio diferente, tecnológico ou outras áreas de interesse. Cada subtarefa seria analisada separadamente. Restrições de implementação (por exemplo, simultaneidade , distribuição ,persistência , ou como o sistema deve ser construído) não são considerados durante a fase de análise; em vez disso, eles são abordados durante o projeto orientado a objetos (OOD).

O modelo conceitual resultante do OOA normalmente consiste em um conjunto de casos de uso , um ou mais diagramas de classe UML e vários diagramas de interação . Também pode incluir algum tipo de maquete da interface do usuário .

A entrada para o projeto orientado a objetos é fornecida pela saída da análise orientada a objetos . Perceba que um artefato de saída não precisa ser completamente desenvolvido para servir como entrada de projeto orientado a objetos; análise e projeto podem ocorrer em paralelo e, na prática, os resultados de uma atividade podem alimentar a outra em um curto ciclo de feedback por meio de um processo iterativo. Tanto a análise quanto o design podem ser realizados de forma incremental, e os artefatos podem ser continuamente aumentados em vez de completamente desenvolvidos de uma só vez.

Alguns artefatos de entrada típicos (mas comuns a todos os tipos de análise de design) para orientação a objetos:

  • Modelo conceitual : O modelo conceitual é o resultado da análise orientada a objetos, ele captura conceitos no domínio do problema. O modelo conceitual é explicitamente escolhido para ser independente de detalhes de implementação, como concorrência ou armazenamento de dados.
  • Caso de uso : caso de uso é uma descrição de sequências de eventos que, juntos, levam um sistema a fazer algo útil. Cada caso de uso fornece um ou mais cenários que transmitem como o sistema deve interagir com os usuários chamados atores para atingir um objetivo ou função de negócios específica. Os atores do caso de uso podem ser usuários finais ou outros sistemas. Em muitas circunstâncias, os casos de uso são elaborados em diagramas de casos de uso. Os diagramas de caso de uso são usados ​​para identificar o ator (usuários ou outros sistemas) e os processos que eles executam.
  • Diagrama de Sequência do Sistema: O diagrama de Sequência do Sistema (SSD) é uma figura que mostra, para um determinado cenário de um caso de uso, os eventos que os atores externos geram, sua ordem e possíveis eventos entre sistemas.
  • Documentações da interface do usuário (se aplicável): Documento que mostra e descreve a aparência da interface do usuário do produto final. Não é obrigatório ter isso, mas ajuda a visualizar o produto final e, portanto, ajuda o designer.
  • Modelo de dados relacional (se aplicável): Um modelo de dados é um modelo abstrato que descreve como os dados são representados e usados. Se um banco de dados de objetos não for usado, o modelo de dados relacional geralmente deve ser criado antes do design, uma vez que a estratégia escolhida para o mapeamento objeto-relacional é uma saída do processo de design OO. No entanto, é possível desenvolver o modelo de dados relacional e os artefatos de design orientado a objetos em paralelo, e o crescimento de um artefato pode estimular o refinamento de outros artefatos.

Ciclo de vida

Gestão e controle

Fases da SPIU relacionadas aos controles de gestão [18]

As fases SDLC servem como um guia programático para a atividade do projeto e fornecem uma maneira flexível, mas consistente, de conduzir projetos com uma profundidade que corresponda ao escopo do projeto. Cada um dos objetivos da fase SDLC é descrito nesta seção com os principais resultados, uma descrição das tarefas recomendadas e um resumo dos objetivos de controle relacionados para um gerenciamento eficaz. É fundamental que o gerente de projeto estabeleça e monitore os objetivos de controle durante cada fase do SDLC durante a execução dos projetos. Os objetivos de controle ajudam a fornecer uma declaração clara do resultado ou propósito desejado e devem ser usados ​​em todo o processo SDLC. Os objetivos de controle podem ser agrupados em categorias principais (domínios) e relacionados às fases do SDLC, conforme mostrado na figura. [18]

Para gerenciar e controlar qualquer iniciativa SDLC, cada projeto deverá estabelecer algum grau de estrutura analítica do projeto (WBS) para capturar e agendar o trabalho necessário para concluir o projeto. A EAP e todo o material programático devem ser mantidos na seção "descrição do projeto" do caderno do projeto. O formato WBS é deixado para o gerente de projeto estabelecer de uma maneira que melhor descreva o trabalho do projeto.

Existem algumas áreas-chave que devem ser definidas na WBS como parte da política SDLC. O diagrama a seguir descreve três áreas-chave que serão abordadas na EAP de uma maneira estabelecida pelo gerente de projeto. [18] O diagrama mostra a cobertura abrange várias fases do SDLC, mas o MCD associado tem um subconjunto de mapeamentos primários para as fases do SDLC. Por exemplo, Análise e Design são executados principalmente como parte do Domínio de Aquisição e Implementação e Construção e Protótipo do Sistema são executados principalmente como parte de entrega e suporte.

Organização estruturada de divisão de trabalho

Estrutura analítica do projeto [18]

A seção superior da estrutura analítica do projeto (WBS) deve identificar as principais fases e marcos do projeto de forma resumida. Além disso, a seção superior deve fornecer uma visão geral de todo o escopo e cronograma do projeto e fará parte do esforço inicial de descrição do projeto que leva à aprovação do projeto. A seção intermediária da WBS é baseada nas sete fases do ciclo de vida de desenvolvimento de sistemas como um guia para o desenvolvimento de tarefas da WBS. Os elementos da EAP devem consistir em marcos e "tarefas" em oposição a "atividades" e ter um período definitivo (geralmente duas semanas ou mais). Cada tarefa deve ter uma saída mensurável (ex: documento, decisão ou análise). Uma tarefa WBS pode depender de uma ou mais atividades (por exemplo, engenharia de software, engenharia de sistemas) e pode exigir coordenação estreita com outras tarefas, internos ou externos ao projeto. Qualquer parte do projeto que necessite de apoio de empreiteiros deve ter umdeclaração de trabalho (SOW) escrita para incluir as tarefas apropriadas das fases SDLC. O desenvolvimento de uma SOW não ocorre durante uma fase específica do SDLC, mas é desenvolvido para incluir o trabalho do processo SDLC que pode ser conduzido por recursos externos, como contratados. [18]

Linhas de base

As linhas de base são uma parte importante do ciclo de vida de desenvolvimento de sistemas. Essas linhas de base são estabelecidas após quatro das cinco fases do SDLC e são críticas para a natureza iterativa do modelo. [19] Cada linha de base é considerada um marco no SDLC.

  • linha de base funcional: estabelecida após a fase de projeto conceitual.
  • linha de base alocada: estabelecida após a fase de projeto preliminar.
  • linha de base do produto: estabelecida após a fase de detalhamento e desenvolvimento.
  • linha de base do produto atualizada: estabelecida após a fase de construção da produção.

Metodologias complementares

Os métodos de desenvolvimento de software complementares ao ciclo de vida de desenvolvimento de sistemas são:

Comparação de Abordagens Metodológicas (Post, & Anderson 2006) [20]
SDLC RAD Código aberto Objetos JAD Prototipagem Usuário final
Ao controle Formal SIM Fraco Padrões Articulação Do utilizador Do utilizador
Prazo Grandes Curto Médio Algum Médio Curto Curto

Comercial Vários Alguns Alguns Varia Alguns Um ou dois Um
Pessoal do MIS Vários Alguns Centenas Dividir Alguns Um ou dois Nenhum
Transação/ DSS Transação Ambos Ambos Ambos DSS DSS DSS
Interface Mínimo Mínimo Fraco janelas Crucial Crucial Crucial
Documentação e treinamento Vital Limitado interno Em objetos Limitado Fraco Nenhum
Integridade e segurança Vital Vital Desconhecido Em objetos Limitado Fraco Fraco
Reutilização Limitado Algum Pode ser Vital Limitado Fraco Nenhum

Pontos fortes e fracos

Poucas pessoas no mundo moderno da computação usariam um modelo estrito em cascata para seu SDLC, pois muitas metodologias modernas substituíram esse pensamento. Alguns argumentarão que o SDLC não se aplica mais a modelos como computação ágil, mas ainda é um termo amplamente utilizado nos círculos de tecnologia. A prática SDLC tem vantagens em modelos tradicionais de desenvolvimento de sistemas que se prestam mais a um ambiente estruturado. As desvantagens de usar a metodologia SDLC são quando há necessidade de desenvolvimento iterativo ou (ou seja, desenvolvimento web ou e-commerce) onde as partes interessadas precisam revisar regularmente o software que está sendo projetado.

Uma comparação dos pontos fortes e fracos do SDLC:

Força e fraquezas do SDLC [20]
Forças Fraquezas
Ao controle Maior tempo de desenvolvimento
Monitore grandes projetos Maior custo de desenvolvimento
Etapas detalhadas Os sistemas devem ser definidos antecipadamente
Avaliar custos e metas de conclusão Rigidez
Documentação Custos difíceis de estimar, estouro do projeto
Entrada do usuário bem definida A entrada do usuário às vezes é limitada
Facilidade de manutenção Pouco paralelismo
Padrões de desenvolvimento e design A automação de documentação e padrões é limitada
Tolera mudanças no MIS de pessoal Não tolera mudanças nos requisitos
Projetos enlatados logo no início resultam em pouco ou nenhum valor

Uma alternativa ao SDLC é o desenvolvimento rápido de aplicativos, que combina prototipagem, desenvolvimento conjunto de aplicativos e implementação de ferramentas CASE. As vantagens do RAD são velocidade, custo de desenvolvimento reduzido e envolvimento ativo do usuário no processo de desenvolvimento.

Ciclo de vida do sistema

O ciclo de vida do sistema em engenharia de sistemas é uma visão de um sistema ou sistema proposto que aborda todas as fases de sua existência para incluir concepção, projeto e desenvolvimento do sistema, produção e/ou construção, distribuição, operação, manutenção e suporte, aposentadoria, eliminação progressiva e descarte. [21]

Projeto conceitual

O estágio de projeto conceitual é o estágio em que uma necessidade identificada é examinada, os requisitos para soluções potenciais são definidos, as soluções potenciais são avaliadas e uma especificação do sistema é desenvolvida. A especificação do sistema representa os requisitos técnicos que fornecerão orientação geral para o projeto do sistema. Como este documento determina todo o desenvolvimento futuro, o estágio não pode ser concluído até que uma revisão do projeto conceitual determine que a especificação do sistema atende adequadamente à necessidade motivadora.

Os principais passos dentro do estágio de projeto conceitual incluem:

  • Precisa de identificação
  • Análise de viabilidade
  • Análise de requisitos do sistema
  • Especificação do sistema
  • Revisão do projeto conceitual

Projeto preliminar do sistema

Durante este estágio do ciclo de vida do sistema, os subsistemas que executam as funções desejadas do sistema são projetados e especificados de acordo com a especificação do sistema. As interfaces entre os subsistemas são definidas, bem como os requisitos gerais de teste e avaliação. [22] Ao final desta etapa, é produzida uma especificação de desenvolvimento que é suficiente para realizar o projeto e o desenvolvimento detalhados.

As principais etapas da fase de projeto preliminar incluem:

  • Análise funcional
  • Alocação de requisitos
  • Estudos detalhados de trade-off
  • Síntese de opções do sistema
  • Projeto preliminar de modelos de engenharia
  • Especificação de desenvolvimento
  • Revisão preliminar do projeto

Por exemplo, como analista de sistema do Viti Bank, você foi encarregado de examinar o sistema de informações atual. O Viti Bank é um banco de rápido crescimento em Fiji. Clientes em áreas rurais remotas estão encontrando dificuldades para acessar os serviços bancários. Eles levam dias ou até semanas para viajar até um local para acessar os serviços bancários. Com a visão de atender às necessidades dos clientes, o banco solicitou seus serviços para examinar o sistema atual e apresentar soluções ou recomendações de como o sistema atual pode ser fornecido para atender às suas necessidades.

Projeto e desenvolvimento de detalhes

Esta fase inclui o desenvolvimento de projetos detalhados que trazem o trabalho de projeto inicial em uma forma completa de especificações. Este trabalho inclui a especificação de interfaces entre o sistema e seu ambiente pretendido e uma avaliação abrangente dos requisitos logísticos, de manutenção e suporte do sistema. O detalhamento do projeto e desenvolvimento é responsável por produzir as especificações do produto, processo e material e pode resultar em mudanças substanciais na especificação de desenvolvimento.

As etapas-chave dentro da fase de projeto e desenvolvimento de detalhes incluem:

  • Projeto detalhado
  • Síntese detalhada
  • Desenvolvimento de modelos de engenharia e protótipos
  • Revisão da especificação de desenvolvimento
  • Especificação do produto, processo e material
  • Revisão crítica do projeto

Produção e construção

Durante a fase de produção e/ou construção, o produto é construído ou montado de acordo com os requisitos especificados nas especificações do produto, processo e material e é implantado e testado dentro do ambiente operacional alvo. As avaliações do sistema são realizadas para corrigir deficiências e adaptar o sistema para melhoria contínua.

As principais etapas da fase de construção do produto incluem:

  • Produção e/ou construção de componentes do sistema
  • Teste de aceitação
  • Distribuição e operação do sistema
  • Teste e avaliação operacional
  • Avaliação do sistema

Utilização e suporte

Uma vez totalmente implantado, o sistema é usado para a função operacional pretendida e mantido em seu ambiente operacional.

Os principais passos dentro do estágio de utilização e suporte incluem:

  • Operação do sistema no ambiente do usuário
  • Mudar a gestão
  • Modificações do sistema para melhoria
  • Avaliação do sistema

Eliminação e eliminação

A eficácia e a eficiência do sistema devem ser avaliadas continuamente para determinar quando o produto atingiu seu ciclo de vida efetivo máximo. [23] As considerações incluem: Existência contínua de necessidade operacional, correspondência entre requisitos operacionais e desempenho do sistema, viabilidade de eliminação do sistema versus manutenção e disponibilidade de sistemas alternativos.

Veja também

Referências

  1. ^ SELECIONANDO UMA ABORDAGEM DE DESENVOLVIMENTO . Recuperado em 17 de julho de 2014.
  2. ^ Parágrafo C. Pendharkara; James A. Rodgerb; Girish H. Subramanian (novembro de 2008). "Um estudo empírico das propriedades da função de produção Cobb-Douglas do esforço de desenvolvimento de software". Tecnologia da Informação e Software . 50 (12): 1181-1188. doi : 10.1016/j.infsof.2007.10.019 .
  3. ^ "Ciclo de vida do desenvolvimento de sistemas de" . FOLDOC . Recuperado 2013-06-14 .
  4. ^ "Ciclo de Vida de Desenvolvimento de Software (SDLC)" .
  5. ^ "Visão geral do SDLC: Modelos e metodologias" . Recuperado 2021-12-12 .
  6. ^ Taylor, James (2004). Gerenciando Projetos de Tecnologia da Informação . pág. 39.
  7. ^ "O que é Scrum?" . 24 de dezembro de 2019.
  8. ^ a b Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology . p.87.
  9. ^ a b c d US Departamento de Justiça (2003). GESTÃO DE RECURSOS DE INFORMAÇÃO Capítulo 1. Introdução.
  10. ^ a b c Everatt, GD; McLeod Jr., R. (2007). "Capítulo 2: O Ciclo de Vida do Desenvolvimento de Software" . Teste de software: teste em todo o ciclo de vida de desenvolvimento de software . John Wiley & Filhos. págs. 29-58. ISBN 9780470146347.{{cite book}}: CS1 maint: multiple names: authors list (link)
  11. ^ Unhelkar, B. (2016). A arte da prática ágil: uma abordagem composta para projetos e organizações . Imprensa CRC. págs. 56–59. ISBN 9781439851197.
  12. ^ Terra, SK; Smith, DB; Walz, JW (2012). Suporte prático para definição de processo de software Lean Six Sigma: usando padrões de engenharia de software IEEE . John Wiley & Filhos. págs. 341–3. ISBN 9780470289952.{{cite book}}: CS1 maint: multiple names: authors list (link)
  13. ^ Kay, Russell (14 de maio de 2002). "QuickStudy: Ciclo de Vida do Desenvolvimento do Sistema" . ComputerWorld .
  14. ^ Taylor, GD (2008). Introdução à Engenharia Logística . Imprensa CRC. págs. 12.6–12.18. ISBN 9781420088571.
  15. ^ Controle e Auditoria, Sistemas de Informação. SDLC (ed. de agosto de 2013). Capítulo 5: Institute of Chartered Accountants of India. pág. 5.28.{{cite book}}: CS1 maint: location (link)
  16. ^ Radack, S. (sd). "O ciclo de vida de desenvolvimento do sistema (SDLC)" (PDF) . Instituto Nacional de Padrões e Tecnologia.
  17. ^ Marakas, James A. O'Brien, George M. (2010). Sistemas de informação de gestão (10ª ed.). Nova York: McGraw-Hill/Irwin. págs. 485-489. ISBN 978-0073376813.
  18. ^ a b c d e Câmara dos Representantes dos EUA (1999). Política de Ciclo de Vida de Desenvolvimento de Sistemas . p.13. [ link morto ]
  19. ^ Blanchard, BS , & Fabrycky, WJ (2006) Engenharia de sistemas e análise (4ª ed.) New Jersey: Prentice Hall. p.31
  20. ^ a b Post, G., & Anderson, D., (2006). Sistemas de informação gerencial: Resolvendo problemas de negócios com tecnologia da informação . (4ª edição). Nova York: McGraw-Hill Irwin.
  21. ^ Blanchard e Fabrycky (2006). Engenharia e Análise de Sistemas, Quarta Edição . Prentice Hall. pág. 19.
  22. ^ Dr. John Gouws (2007). Introdução à Engenharia, Engenharia de Sistemas . Melikon Pty Ltd.
  23. ^ Cunningham, James. "Manutenção HERC" . Fargo . XXI (Avenida Norte): 49 . Recuperado em 13 de maio de 2009 .[ link morto ]

Leitura adicional

  • Cummings, Haag (2006). Sistemas de Informação Gerencial para a Era da Informação . Toronto, McGraw-Hill Ryerson
  • Beynon-Davies P. (2009). Sistemas de Informação Empresarial . Palgrave, Basingstoke. ISBN 978-0-230-20368-6 
  • Computer World, 2002 , Recuperado em 22 de junho de 2006 da World Wide Web:
  • Management Information Systems, 2005 , Recuperado em 22 de junho de 2006 da World Wide Web:

Links externos