10.2: Modelo do ciclo de vida de desenvolvimento de sistemas (SDLC)

Modelo de ciclo de vida de desenvolvimento de sistemas (SDLC)

O SDLC foi desenvolvido pela primeira vez na década de 1960 para gerenciar os grandes projetos associados aos sistemas corporativos executados em mainframes. É um processo muito estruturado projetado para gerenciar grandes projetos com o esforço de muitas pessoas, incluindo profissionais técnicos, comerciais e de suporte. Esses projetos geralmente são caros de construir e têm um grande impacto na organização. Um projeto fracassado ou uma decisão comercial incorreta de escolher um projeto errado para financiar pode ser uma catástrofe comercial ou financeira para uma organização.

O SDLC é um modelo que define um processo de um conjunto de fases para planejamento, análise, projeto, implementação e manutenção. O capítulo 1 discute que um sistema de informação (SI) inclui hardware, software, banco de dados, redes, processos e pessoas. O SDLC tem sido usado com frequência para gerenciar um projeto de IS que pode incluir um, alguns ou todos os elementos de um IS. Vamos analisar cada uma das cinco fases de um SDLC, conforme ilustrado na Figura 10.1:

Fig. 10.1 - Modelo de ciclo de vida de desenvolvimento de software. A imagem de Ly-Huong Pham, Ph.D. é licenciada sob CC BY NC

1. Planejamento. Nessa fase, uma solicitação é iniciada por alguém que atua como patrocinador dessa ideia. Uma pequena equipe é montada para realizar uma avaliação preliminar do mérito e da viabilidade da solicitação. Os objetivos desta fase são:

• Para determinar como a solicitação se encaixa na estratégia ou nas metas de negócios da empresa.
• Realizar uma análise de viabilidade, que inclui uma análise da viabilidade técnica (é possível criar isso?) , a viabilidade econômica (podemos nos dar ao luxo de fazer isso?) e a viabilidade legal (podemos fazer isso?).
• Para recomendar a opção “sim” ou “não” para atender à solicitação. Se for aprovado, uma proposta de conceito também será produzida para aprovação da gerência.

2. Análise. Depois que a proposta de conceito é aprovada, o projeto é formalizado com uma nova equipe de projeto (incluindo a fase anterior). Usando a proposta de conceito como ponto de partida, os membros do projeto trabalham com diferentes grupos de partes interessadas para determinar os requisitos específicos do novo sistema. Nenhuma programação ou desenvolvimento é feito nesta etapa. Os objetivos desta fase são:

• Identifique e entreviste os principais interessados.
• Documente os principais procedimentos
• Desenvolva os requisitos de dados
• Produzir um documento de requisitos do sistema como resultado dessa fase. Isso tem os detalhes para iniciar o design do sistema.

3. Design. Depois que os requisitos do sistema forem aprovados, a equipe poderá ser reconfigurada para trazer mais membros. Esta fase visa que a equipe do projeto pegue o documento de requisitos do sistema criado na fase anterior e desenvolva os detalhes técnicos específicos necessários para o sistema. Os objetivos são:

• Transforme os requisitos de negócios em requisitos técnicos específicos
• Projete a interface do usuário, o banco de dados, as entradas e saídas de dados e os relatórios
• Produza um documento de design do sistema como resultado dessa fase. Este documento terá tudo o que um programador precisará para criar o sistema.

4. Implementação Depois que o design do sistema é aprovado, o código do software finalmente é escrito na fase de programação, e o esforço de desenvolvimento de outros elementos, como hardware, também acontece. O objetivo é criar um sistema de trabalho inicial. Os objetivos são:

• Desenvolva o código do software e outros componentes do IS. Usando o documento de design do sistema como guia, os desenvolvedores começam a codificar ou desenvolver todos os componentes do projeto IS.
• Teste o sistema de trabalho por meio de uma série de testes estruturados, como:
  • O primeiro é um teste unitário, que testa partes individuais do código em busca de erros ou bugs.
  • Em seguida, há um teste do sistema, em que os diferentes componentes do sistema são testados para garantir que funcionem juntos corretamente.
  • Finalmente, o teste de aceitação do usuário permite que aqueles que usarão o software testem o sistema para garantir que ele atenda aos seus padrões.
  • Teste iterativamente todas as correções novamente para resolver quaisquer bugs, erros ou problemas encontrados durante o teste.
  • Treine os usuários
  • Forneça documentação
  • Execute as conversões necessárias de qualquer sistema anterior para o novo sistema.
  • Produza, como resultado, o sistema de trabalho inicial que atenda aos requisitos estabelecidos na fase de análise e o projeto desenvolvido na fase de projeto.

5. Manutenção. Essa fase ocorre quando a fase de implementação é concluída. Nessa fase, o sistema deve ter um processo de suporte estruturado para:

• Reportar bugs
• Implante correções de bugs
• Aceite solicitações de novos recursos
• Avalie as prioridades dos bugs relatados ou dos recursos solicitados a serem implementados
• Identifique um cronograma previsível e regular para lançar atualizações do sistema e realizar backups.
• Elimine dados e qualquer outra coisa que não seja mais necessária

As organizações podem combinar ou subdividir essas fases para atender às suas necessidades. Por exemplo, em vez de uma fase, Planejamento, uma organização pode optar por ter duas fases: Iniciação, Conceito ou dividir a implementação em duas fases: implementação e teste.

Modelo em cascata

Um modelo específico baseado em SDLC é o modelo Waterfall, e o nome geralmente é considerado o mesmo de SDLC. Ele é usado para gerenciar projetos de software, conforme descrito na Fig. 10.2, com cinco fases: Requisitos, Projeto, Implementação, Verificação e Manutenção. Esse modelo enfatiza que cada fase deve ser concluída antes que a próxima possa começar (daí o nome cachoeira). Por exemplo, mudanças nos requisitos não são permitidas após o início da fase de implementação, ou mudanças devem ser buscadas e aprovadas em um processo de mudança. Eles podem exigir que o projeto seja reiniciado a partir da fase de requisitos, pois novos requisitos precisam ser aprovados, o que pode fazer com que o projeto seja revisado antes que a fase de implementação possa começar.

Fig. 10.2 Modelo em cascata de desenvolvimento do sistema. Imagem de Peter Kemp/Paul Smit é licenciada CC BY 3.0

A estrutura rígida do modelo em cascata foi criticada por ser bastante rígida e fazer com que as equipes sejam avessas ao risco para evitar voltar às fases anteriores. No entanto, essa estrutura também traz benefícios. Algumas vantagens e desvantagens do SDLC e do Waterfall são:

Vantagens e desvantagens do SDLC e do Waterfall

Vantagens	Desvantagens
O processo robusto para controlar e rastrear mudanças para minimizar o número de riscos pode inviabilizar o projeto sem saber.	Reserve um tempo para registrar tudo, o que gera custos e prazos adicionais no cronograma.
Processos padronizados e transparentes ajudam no gerenciamento de grandes equipes.	Muito tempo gasto participando de reuniões, buscando aprovação, etc., o que resulta em custos e tempo adicionais no cronograma.
A documentação reduz os riscos de perda de pessoal, facilitando a adição de pessoas ao projeto.	Alguns membros não gostam de gastar tempo escrevendo, o que gera o tempo adicional necessário para concluir um projeto.
É mais fácil rastrear um problema no sistema até a raiz sempre que erros são encontrados, mesmo após a conclusão do projeto.	É difícil incorporar mudanças ou o feedback dos clientes, pois o projeto precisa voltar a uma ou mais fases anteriores, levando as equipes a se tornarem avessas ao risco.

Outros modelos são desenvolvidos ao longo do tempo para responder a essas críticas. Discutiremos dois outros modelos: Rapid Application Development e Agile, como diferentes abordagens para o SDLC.

Desenvolvimento rápido de aplicativos (RAD)

O desenvolvimento rápido de aplicativos (RAD) é uma metodologia de desenvolvimento de software (ou desenvolvimento de sistemas) que se concentra menos no planejamento e na incorporação contínua de mudanças. O RAD se concentra em criar rapidamente um modelo funcional do software ou sistema, obter feedback dos usuários e atualizar o modelo de trabalho. Após várias iterações de desenvolvimento, uma versão final é desenvolvida e implementada. Vamos percorrer as quatro fases do modelo RAD, conforme ilustrado na Fig. 10.3.

Fig 10.3 O modelo de desenvolvimento rápido de aplicativos de imagem é de domínio público licenciado.

1. Planejamento de requisitos. Essa fase é semelhante às fases de planejamento, análise e design do SDLC.
2. Design do usuário. Nessa fase, os representantes dos usuários trabalham com os analistas, designers e programadores do sistema para criar interativamente o design do sistema. Uma técnica para trabalhar com todas essas várias partes interessadas é a sessão de Desenvolvimento Conjunto de Aplicativos (JAD). Uma sessão do JAD faz com que todos os usuários relevantes que interagem com os sistemas de diferentes perspectivas e outras partes interessadas importantes, incluindo desenvolvedores, tenham uma discussão estruturada sobre o design do sistema. Os objetivos são que os usuários entendam e adotem o modelo de trabalho e que os desenvolvedores entendam como o sistema precisa funcionar da perspectiva do usuário para proporcionar uma experiência positiva ao usuário.
3. Construção. Na fase de construção, as tarefas são semelhantes à fase de implementação do SDLC. Os desenvolvedores continuam trabalhando interativamente com os usuários para incorporar seus comentários à medida que interagem com o modelo de trabalho que está sendo desenvolvido. Esse é um processo interativo, e mudanças podem ser feitas à medida que os desenvolvedores trabalham no programa. Essa etapa é executada paralelamente à etapa de Design do Usuário de forma iterativa até que uma versão aceitável do produto seja desenvolvida.
4. Transição. Essa etapa é semelhante a algumas das tarefas da fase de implementação do SDLC. O sistema entra em operação ou está totalmente implantado. Todas as etapas necessárias para passar do estado anterior para o uso do novo sistema são concluídas aqui.

Em comparação com o modelo SDLC ou Waterfall, a metodologia RAD é muito mais comprimida. Muitas das etapas do SDLC são combinadas e o foco está na participação e iteração do usuário. Essa metodologia é mais adequada para projetos menores e tem a vantagem adicional de oferecer aos usuários a capacidade de fornecer feedback durante todo o processo. O SDLC requer mais documentação e atenção aos detalhes e é adequado para projetos grandes e que consomem muitos recursos. O RAD é mais adequado para projetos que consomem menos recursos e precisam ser desenvolvidos rapidamente. Aqui estão algumas das vantagens e desvantagens do RAD:

Vantagens e desvantagens do RAD

Vantagens	Desvantagens
Aumente a qualidade devido à frequência de interação com os usuários	Riscos da implementação fraca de recursos que não são visíveis para os usuários, como segurança
Reduzir os riscos de recusa dos usuários em aceitar o produto acabado	A falta de controle sobre o sistema muda devido à rápida execução de uma versão funcional para resolver os problemas dos usuários.
Aumente as chances de conclusão dentro do prazo e do orçamento à medida que os usuários atualizam em tempo real, evitando surpresas durante o desenvolvimento.	A falta de design, pois as mudanças estão sendo feitas no sistema, pode, sem saber, afetar outras partes do sistema.
Aumente o tempo de interação entre desenvolvedores/especialistas e usuários	Recursos escassos à medida que os desenvolvedores estão vinculados, o que pode atrasar outros projetos.
Mais adequado para equipes de projeto de pequeno a médio porte	É difícil escalar para equipes grandes

Metodologias de desenvolvimento ágil

As metodologias ágeis são um grupo de metodologias que utilizam mudanças incrementais com foco na qualidade e atenção aos detalhes. Cada incremento é lançado em um período de tempo especificado (chamado de caixa de tempo), criando um cronograma de lançamento regular com objetivos específicos. Embora sejam consideradas uma metodologia separada da RAD, elas compartilham alguns dos mesmos princípios: desenvolvimento iterativo, interação com o usuário e mutabilidade. As metodologias ágeis são baseadas no “Manifesto Ágil”, lançado pela primeira vez em 2001.

As características dos métodos ágeis incluem:

• pequenas equipes multifuncionais que incluem membros e usuários da equipe de desenvolvimento;
• reuniões diárias de status para discutir o estado atual do projeto;
• incrementos curtos de prazo (de dias para uma ou duas semanas) para que cada alteração seja concluída; e
• No final de cada iteração, um projeto de trabalho é concluído para demonstrar às partes interessadas.

Em essência, a abordagem ágil valoriza mais as tarefas que promovem a interação, criam versões de trabalho frequentes, colaboração entre clientes e usuários, resposta rápida às mudanças e menos ênfase nos processos e na documentação. O objetivo das metodologias ágeis é fornecer flexibilidade de uma abordagem iterativa e, ao mesmo tempo, garantir um produto de qualidade.

Há uma variedade de modelos que são criados usando metodologias ágeis. Um exemplo é o modelo de desenvolvimento Scrum.

Modelo de desenvolvimento Scrum

Esse modelo é adequado para equipes pequenas que trabalham para produzir um conjunto de recursos em interações de tempo fixo, como duas a quatro semanas, chamadas de sprints. Vamos examinar os quatro elementos principais de um modelo Scrum, conforme mostrado na Fig. 10.4.

Fig. 10.4. O método de gerenciamento de projetos Scrum. A imagem da Lakeworks é licenciada CC BY-SA 4.0

1. Lista de pendências de produtos. Esta é uma lista detalhada do trabalho a ser feito. Todo o trabalho é priorizado com base em critérios como riscos, dependências, missões críticas, etc. Os desenvolvedores selecionam suas próprias tarefas e se auto-organizam para realizar o trabalho.
2. Lista de pendências de sprint. Esta é uma lista do trabalho a ser feito no próximo sprint.
3. Arrancada. Esse é um tempo fixo, como 1 dia, 2 semanas ou 4 semanas, conforme acordado pela equipe. Uma reunião diária de progresso é chamada de scrum diário, normalmente uma reunião curta de 10 a 15 minutos facilitada por um mestre de scrum cuja função é remover obstáculos para a equipe.
4. Incremento de trabalho do software e. Essa é uma versão funcional criada de forma incremental com as listas de detalhamento no final dos sprints.

A metodologia Lean

Uma última metodologia que discutiremos é um conceito relativamente novo retirado do best-seller de negócios The Lean Startup, de Eric Reis.

Fig. 10.5. A metodologia Lean. David T. Bourgeois, Ph.D. é licenciado CC BY-SA 2.0

Essa metodologia se concentra em tomar uma ideia inicial e desenvolver um produto mínimo viável (MVP). O MVP é um aplicativo de software funcional com funcionalidade suficiente para demonstrar a ideia por trás do projeto. Depois que o MVP é desenvolvido, ele é entregue a usuários em potencial para análise. O feedback sobre o MVP é gerado de duas formas: (1) observação direta e discussão com os usuários e (2) estatísticas de uso coletadas do próprio software. Usando essas duas formas de feedback, a equipe determina se deve continuar na mesma direção ou repensar a ideia central do projeto, mudar as funções ou criar um novo MVP. Essa mudança na estratégia é chamada de pivô. Várias iterações do MVP são desenvolvidas, com novas funções adicionadas a cada vez com base no feedback, até que um produto final seja concluído.

A maior diferença entre a metodologia enxuta e as outras metodologias é que o conjunto completo de requisitos do sistema é desconhecido quando o projeto é lançado. À medida que cada iteração do projeto é lançada, as estatísticas e o feedback coletados são usados para determinar os requisitos. A metodologia lean funciona melhor em um ambiente empreendedor em que uma empresa está interessada em determinar se vale a pena desenvolver sua ideia para um aplicativo de software.

Referências:

Manifesto para o desenvolvimento ágil de software (2001). Recuperado em 10 de dezembro de 2020, de http://agilemanifesto.org/

A startup enxuta. Obtido em 9 de dezembro de 2020, de http://theleanstartup.com/