Modelos de Ciclo de Vida de Projetos de Software

Prévia do material em texto

Metodologia de 
Desenvolvimento de 
Sistemas 
Metodologia de 
Desenvolvimento de 
Sistemas 
1ª edição
2019
Autoria
Parecerista Validador
Samira Santos da Silva
Sandra Gavioli Puga / José Leão
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
35
 3Unidade 33. Modelos do Ciclo de Vida de 
Projetos de Desenvolvimento 
de Software
Para iniciar seus estudos
Nesta unidade, você compreenderá os principais conceitos relacionados ao 
ciclo de vida de projetos de software. Conhecer esses conceitos é essencial 
para a tomada correta de decisões relacionadas ao desenvolvimento 
de software em ambientes de desenvolvimento, como empresas, por 
exemplo. 
Objetivos de Aprendizagem
• Compreender os princípios que envolvem o ciclo de vida de 
projetos de software.
• Compreender os conceitos de arquitetura de software e da 
aplicação do conteúdo abordado através de um estudo de caso.
36
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Introdução da unidade
Esta unidade possui como foco apresentar diversos conceitos relacionados ao ciclo de vida de projetos de 
software. Além de detalharmos as etapas típicas de um ciclo de vida, apresentaremos também alguns dos principais 
modelos de ciclo de vida que podem ser utilizados no desenvolvimento de diferentes tipos de software. São eles 
os modelos sequenciais, incrementais e iterativos. Conhecê-los faz com que a decisão sobre quando aplicá-los 
se torne mais fácil. Apresentaremos também o conceito de arquitetura de software, ilustrando o conceito com 
três dos padrões de arquitetura mais utilizados: Arquitetura em Camadas, Cliente-Servidor, MVC, sendo o último 
um dos mais populares em empresas atualmente. Por fim, ilustraremos como é o processo de decisão sobre um 
modelo de ciclo de vida através da apresentação de um estudo de caso. 
3.1 Modelos do ciclo de vida de projetos de desenvolvimento 
de software
Quando pensamos no desenvolvimento de software, queremos ir logo para a parte da codificação em si. 
Entretanto, existem algumas etapas que necessitam ser realizadas antes de colocar, de fato, a mão na massa. 
Decisões relacionadas aos modelos de ciclo de vida de projetos de desenvolvimento de softwares são algumas 
delas. 
Nesta unidade, abordaremos o conceito de Ciclo de Vida de Projetos de Softwares, bem como alguns dos principais 
modelos existentes. Além disso, apresentaremos e discutiremos o conceito de arquitetura de software juntamente 
com alguns dos padrões existentes. Por fim, apresentaremos um estudo de caso que ilustra a aplicação de 
modelos de ciclo de vida no desenvolvimento de softwares.
3.1.1 Ciclo de vida de projetos de software
Para compreender a definição de ciclo de vida de projetos, primeiramente é necessário compreender a definição 
de projeto. De acordo com o PMBOK (Project Management Body of Knowledge), um conjunto de práticas na gestão 
de projetos desenvolvido pelo instituto PMI, a definição de projeto é dada pelo seguinte trecho:
Um projeto é um esforço temporário, empreendido para criar um produto, serviço ou resultado 
exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são 
temporários e exclusivos, enquanto as operações são contínuas e repetitivas.
De forma geral, o objetivo de um projeto é entregar um produto ou serviço. Quando estamos nos referindo ao 
desenvolvimento de software, o produto do projeto não é algo produzido com ferro derretido que sai moldado de 
uma forma, mas sim algo mais complexo. 
O processo de produção de um software deve ser mais elaborado, o que resulta em um processo mais complexo. Ele 
demanda uma série de atividades que devem ser realizadas de acordo com critérios estabelecidos previamente. 
Essas atividades são agrupadas por questão de organização e afinidade entre fases, que são então colocadas em 
sequência, considerando uma ordem lógica, de forma que sejam executadas na linha do tempo, que vai do início 
ao fim do projeto. O sequenciamento das fases do projeto de acordo com os critérios adotados é chamado de 
ciclo de vida do projeto (STAIR, 2016).
37
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Os critérios adotados em um ciclo de vida do projeto são os métodos ou processos escolhidos 
para ele.
Saiba mais
Outra forma de definição de ciclo de vida de um projeto de software é dada pela norma NBR ISO/IEC 12207:1998 
que o define oficialmente como sendo uma:
Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e 
manutenção de um produto de software, abrangendo a vida do sistema, desde a definição de seus 
requisitos até o término de seu uso.
Em outras palavras, os modelos de ciclo de vida são o esqueleto ou as estruturas predefinidas nas quais 
encaixamos as fases do processo. A primeira escolha a ser feita no processo de desenvolvimento de um software é 
sobre o modelo de ciclo de vida. Partindo dessa escolha, a melhor forma de obter as necessidades do cliente será 
definida, além da provável data em que o mesmo receberá uma primeira versão do sistema em funcionamento. 
A duração do ciclo de vida de um software vai do começo da sua produção até o momento em que seu uso é 
extinguido. Em geral, os ciclos de vida envolvem as seguintes fases que serão detalhadas a seguir: Planejamento, 
Análise e Especificação de Requisitos, Projeto, Implementação, Testes, Entrega e Implantação, Operação e 
Manutenção.
3.1.2 Planejamento
Na etapa de planejamento, o escopo do software é determinado. Deve-se também fornecer uma estrutura de 
modo que possibilite ao gerente a realização de estimativas iniciais tanto de recursos quanto de custos e prazos. 
É normal, na fase de planejamento, o gerente de projetos construir cronogramas de atividades considerando 
recursos necessários e custo de horas, assim também como recursos dos clientes. Além disso, deve-se elaborar 
um plano de projeto que deve ser definido a partir do processo a ser utilizado.
3.1.3 Análise e especificação de requisitos
Na etapa de análise e especificação de requisitos, o escopo do software é refinado, sendo necessário, conforme 
as boas práticas do PMI (Project Management Institute), gerar um documento de change management, ou mudança 
de documento, para documentar as possíveis incongruências entre o escopo original e o refinado, considerando 
também as mudanças que podem impactar o prazo e o custo do projeto. O objetivo aqui é analisar o domínio do 
problema e da solução e definir exatamente o que o software deve fazer, ou seja, quais as funcionalidades que 
deverão existir e de que modo o software deve se comportar. Um documento com os requisitos do software deve 
ser gerado de forma que não haja ambiguidades ou inconsistência entre os mesmos.
38
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
3.1.4 Projeto
A etapa de projeto envolve duas grandes etapas: o projeto da arquitetura do software, bem como o projeto 
detalhado. O resultado da etapa anterior é utilizado como insumo. Aqui pode-se definir, por exemplo, tipos 
de dados a serem utilizados e mecanismo de acesso a eles. Além disso, são fornecidos detalhes essenciais à 
implementação.
3.1.5 Implementação
Na etapa de implementação, o projeto que está no papel é traduzido para uma forma que seja passível de 
execução por um computador. Em outras palavras, o código é de fato escrito, implementando funcionalidades 
que foram identificadas no início do processo.
3.1.6 Testes
Nesta etapa, são executadostestes unitários de diversos componentes e anotando os resultados. Além disso, a 
integração de componentes e o sistema como um todo também são testados. O objetivo é encontrar bugs ou 
defeitos.
Alguns modelos de processo já preveem testes nas etapas iniciais do ciclo de vida, assim 
como definem estratégias e roteiro, considerando a participação do usuário e do perfil do 
Analista de Teste.
Fique atento!
3.1.7 Entrega e implantação
Na etapa de entrega e implantação, o software é instalado no ambiente de produção. Portanto, envolve a 
capacitação de usuários, a configuração do ambiente de produção e conversão de bases de dados, caso seja 
necessário. O objetivo maior desta etapa é realizar o Teste de Aceitação com o usuário. Em outras palavras, 
verifica-se se o software satisfaz os requisitos que foram impostos pelos usuários. Alguns métodos de ciclo de 
vida denominam esta fase como Homologação. 
3.1.8 Operação
39
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
A etapa de operação consiste na real utilização do software pelo usuário no seu ambiente de trabalho. Esta etapa 
é executada após o teste de aceitação da etapa anterior ser concluído com sucesso. 
3.1.9 Manutenção
A manutenção consiste em fazer alterações no software por algum motivo específico. As manutenções podem ser 
Adaptativas, Evolutivas e Corretivas. A manutenção adaptativa tem por objetivo a adequação do software a seu 
ambiente. A manutenção evolutiva tem o intuito de melhorar a qualidade do software geralmente acrescentando 
novas funcionalidades. Por fim, a manutenção corretiva visa corrigir erros que não foram detectados na etapa 
de teste. Normalmente, nesta fase do projeto, as empresas optam por capacitar e manter uma equipe específica 
para dar sustentação ao sistema.
3.2 Principais modelos do ciclo de vida
A primeira escolha software a ser feita no processo de software é a decisão em relação a qual modelo de ciclo de 
vida utilizar. Essa escolha será influenciada pela forma mais adequada de atender às necessidades do cliente, 
da cultura da equipe de TI atual, bem como quando ele deseja receber uma versão inicial do mesmo em 
funcionamento. A Figura 16 ilustra o funcionamento de três das principais abordagens para definir o ciclo de 
vida. 
Figura 16 – Diferença entre os modelos de ciclo de vida: sequencial, incremental e iterativo
Software desejado = + + 
Sequencial Versão 1 Versão 2 Versão 3
Incremental
Iterativo
Fonte: Elaborada pelo autor.
40
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Para decidir sobre qual modelo utilizar, é necessário ter em mente que não existe um modelo ideal. Características 
como perfil e complexidade do problema do cliente, tempo e custo máximo, equipe envolvida e ambiente onde 
o software irá executar são fatores que influenciarão diretamente na escolha de um modelo de ciclo de vida a ser 
utilizado. 
Do mesmo modo, é raro que uma empresa utilize um único ciclo de vida. Na maior parte das vezes, o processo 
se dá com mais de um ciclo de vida envolvido. Ciclos de vida podem se comportar de maneira sequencial (uma 
fase segue a outra em ordem), iterativa (fases possuem retroalimentação) ou até mesmo incremental (software 
é aprimorado a cada fase) (PRESSMAN, 2016). A seguir, veremos essas três formas de gerar ciclos de vida no 
desenvolvimento de softwares.
3.2.1 Modelos sequenciais
Modelos sequenciais organizam o processo de desenvolvimento de software em uma sequência linear de fases. 
Este modelo se aplica em situações onde requisitos estão bem definidos visto que cada fase somente acontece 
uma vez, dificultando a descoberta e implementação de requisitos na fase desenvolvimento, por exemplo. 
Softwares mais simples podem ser desenvolvidos utilizando este modelo. Um exemplo deste tipo de modelo é o 
Cascata, exemplificado na Figura 17.
Figura 17 – Modelo de ciclo de vida em cascata
Requisitos
Design
Análise
Desenvolvimento
Testes
Operação
Fonte: Elaborada pela autora.
3.2.2 Modelos incrementais
Modelos sequenciais propõem o desenvolvimento de softwares em incrementos ou módulos. Dessa forma, seu 
desenvolvimento segue o fluxo sequencial sendo, por exemplo, um requisito implementado por vez, passando 
por todas as etapas do desenvolvimento. Dessa forma, o cliente já possui uma versão inicial do sistema bem 
antes que o modelo sequencial. Outra vantagem é que o cliente vai avaliando o avanço do desenvolvimento dos 
incrementos/módulos e checando se o software que está sendo construído é o que ele realmente quer. Em relação 
41
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
a suas desvantagens, podemos citar o fato de que requisitos instáveis ou incompletos geram muitas mudanças nos 
incrementos. Além disso, a gestão do projeto se torna mais complexa utilizando este modelo. Um exemplo disso 
deste modelo é o RAD (Rapid Application Development) que preza pelo ciclo de desenvolvimento curto, mostrado na 
Figura 18.
Figura 18 – Fases do desenvolvimento rápido de aplicação (RAD)
Análise Inicial
Modelagem de negócio
Testes e correções
Entrega
Modelagem de dados
Modelagem de Processo
Geração da aplicação
Fonte: Elaborada pela autora.
3.2.3 Modelos iterativos
Nos modelos iterativos, não se tem a preocupação em entregar versões que o usuário já consiga operar já no 
primeiro ciclo de vida. O que geralmente são produzidos são protótipos ou modelos para checar se o que está 
sendo desenvolvido é o que o usuário precisa. À medida que os requisitos vão ficando mais claros e constantes, 
versões que o usuário já consiga manipular vão surgindo. Esta abordagem permite aos usuários finais refinarem 
cada vez mais o propósito do software, abrangências e funcionalidades.
Modelos iterativos podem ser empregados para solução de problemas mais complexos, bem como quando 
requisitos mudam a todo momento ou quando não se sabe elucidar ao certo todos os requisitos no início do 
processo. Exemplos de modelos iterativos são o RUP (Rational Unified Process) e o Modelo Espiral, que é ilustrado 
na Figura 19.
42
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Figura 19 – Modelo de ciclo de vida espiral
Fonte: Elaborada pela autora.
3.3 Arquitetura de software
A arquitetura de software é uma descrição em alto nível de abstração que mostra uma visão completa da estrutura 
do sistema (PRESSMAN, 2016). Essa descrição deve dar suporte às funcionalidades existentes no sistema, 
portanto seu comportamento dinâmico deve ser levado em consideração. Além disso, também deve estar em 
conformidade com a qualidade, fazendo com que os requisitos não funcionais sejam de fato aplicados. No nível 
da arquitetura, detalhes de implementação devem ser ocultados. 
Não fazem parte da arquitetura de software o design detalhado (ou de baixo nível) que mostra o projeto dos 
componentes internos, modelos de dados e implementação. Além disso, a arquitetura do sistema físico, que 
inclui processador, topologia de rede, arquitetura de elementos de hardwares, entre outros, também não está 
incluída em arquitetura de software.
43
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Figura 20 – O papel da arquitetura de software no desenvolvimento de software
Requisitos
Requisitos
Arquitetura de Software
Código
Código
?
Fonte: Elaborada pela autora.
Ao longo dos anos, softwares passaram a ter grande importância. Se no início eram aplicações mais simples, 
atualmente estão se tornando cada vez mais complexos, chegando ao ponto de controlar decolagem e pouso de 
aeronaves. Suas funcionalidades simples no princípio de sua popularização, como na utilização de planilhas, nãochegam próximas da complexidade dos softwares mais recentes contendo um número enorme de funcionalidades, 
como no controle de usinas, por exemplo. Para que isso pudesse acontecer, houve modificações na arquitetura 
dos softwares daquela época para que pudessem suportar tamanha complexidade.
Softwares que são bem arquitetados possuem diversas vantagens. A primeira delas é o fato de que suportam um 
aumento de carga considerável sem perda de desempenho. Além disso, podem ser facilmente escalados. Por fim, 
a arquitetura de um software pode também servir para gerar uma estimativa de custo e gerência de determinado 
projeto. Normalmente, características de arquitetura e custos são computados durante a análise de viabilidade e 
pré-projeto, pois influenciam escopo, prazo e custo do projeto de software.
Os padrões de arquitetura de software surgiram como formas de apresentar, compartilhar e reutilizar conhecimento 
sobre sistemas de software. Propostos na década de 90, são amplamente utilizados até os dias de hoje. Para 
compreender a definição de um padrão de arquitetura de software, é necessário pensar em uma descrição 
abstrata, estilizada, de boas práticas já experimentadas e testadas em diversas aplicações e ambientes. Portanto, 
um padrão de arquitetura deve conter a descrição de uma organização de um sistema que obteve sucesso 
anteriormente. Além disso, deve informar também sobre quando é melhor sua utilização, bem como seus pontos 
fortes e fracos. A seguir, descreveremos três dos principais tipos de padrões de arquitetura (SOMMERVILLE, 2007): 
em Camadas, MVC e Cliente-Servidor.
44
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
3.3.1 Arquitetura de software em camadas
O padrão de arquitetura em camadas é uma forma de obter separação e independência entre os componentes 
do software. Neste padrão, as diversas funcionalidades do sistema são distribuídas em camadas separadas, onde 
cada camada só depende dos recursos e serviços que são oferecidos pela camada imediatamente inferior. O 
Quadro 1 mostra algumas das características deste padrão.
Quadro 1 – Descrição da arquitetura de software em camadas
Nome Arquitetura em camadas
Descrição Organiza o sistema em camadas com funcionalidades distribuídas entre elas. Uma 
camada fornece serviços à superior.
Exemplo Sistema de compartilhamento de documentos com direitos autorais, em bibliotecas 
diferentes.
Quando é 
usado
Usado na construção de novos recursos em cima de sistemas existentes, quando o 
desenvolvimento está espalhado por várias equipes.
Vantagens Substituição de camadas inteiras (mantendo interface). 
Desvantagens É difícil a separação clara entre camadas. Desempenho pode ser prejudicado. 
Fonte: Elaborado pela autora.
Esta abordagem suporta o desenvolvimento incremental de sistemas. Ao se desenvolver uma camada, alguns dos 
seus serviços já podem ser disponibilizados ao usuário. A arquitetura é passível de mudança e portável. Contanto 
que sua interface não seja alterada, uma camada pode ser trocada por outra equivalente. E, caso uma camada 
seja alterada, somente a camada adjacente é afetada. 
Na Figura 21 a seguir, exemplificamos uma arquitetura em quatro camadas.
Figura 21 – Exemplo de arquitetura em camadas
Interface de usuário
Gerenciamento de interface de usuário
Autenticação e autorização
Lógica de negócio principal/funcionalidade de 
aplicação Recursos de sistema
Apoio de sistema (SO, banco de dados, etc.)
Fonte: Elaborada pela autora.
45
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
No exemplo da figura anterior, a camada mais baixa contém softwares de apoio ao sistema, como banco 
de dados ou sistema operacional. A segunda camada é a camada de aplicação, incluindo componentes que 
estejam relacionados com o funcionamento da aplicação e componentes utilitários que sejam utilizados por 
componentes da aplicação. A terceira camada se preocupa com o gerenciamento de interface de usuário, bem 
como provê autenticação e autorização ao usuário. Por fim, a quarta camada fornece recurso de interface com 
usuário. O número de camadas nesse padrão é arbitrário.
3.3.2 Arquitetura de software MVC
As características de separação e independência em um padrão de arquitetura são essenciais visto que 
possibilitam com que alterações sejam localizadas. O padrão MVC (Modelo-Visão-Controlador ou Model-View-
Controller) separa os componentes de um sistema em camadas Modelo, Visão e Controlador de forma que seja 
possível alterá-los independentemente. Exemplo disso seria trocar a camada de visão sem ter que alterar as 
restantes. 
A Figura 22 a seguir faz uma analogia da atividade “assistir à TV” com o padrão MVC. O usuário utiliza o controle 
para interagir com as funcionalidades do sistema que estão no modelo. O modelo é um DVD que é quem gerencia 
o que vai ser exibido, de acordo com o que for determinado pelo controle. A camada de visualização, nesse caso, 
é a TV que recebe as ordens da camada modelo (DVD) sobre o que exibir.
Figura 22 – Analogia do modelo MVC com um usuário que assiste a uma TV
Usuário Controlador
Fonte: Adaptada de SHUTTERSTOCK, 2018.
46
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Esse padrão geralmente é utilizado no gerenciamento de iteração em sistemas baseados na Web. O Quadro 2 
resume o padrão MVC. 
Quadro 2 – Descrição da arquitetura de software MV
Nome MVC
Descrição
Separa a apresentação e a interação dos dados do sistema. O componente 
modelo gerencia o sistema de dados e as operações associadas a eles. O 
componente visão define como os dados são apresentados ao usuário. O 
componente controlador gerencia a interação do usuário (ex.: mouse) e passa as 
interações para os outros componentes. 
Exemplo Sistema aplicativo baseado na internet.
Quando é usado Quando existem diversas maneiras de visualizar e interagir com dados. 
Vantagens 
Permite que dados sejam alterados independentemente da sua representação 
e vice-versa. 
Desvantagens Em sistemas simples, o código fica complexo. 
Fonte: Elaborado pela autora.
3.3.3 Arquitetura cliente-servidor
O padrão de arquitetura cliente-servidor é bastante utilizado em sistemas distribuídos, mas pode também ser 
implementado em um único computador. Sua descrição é apresentada no Quadro 3. Nesse tipo de padrão, o 
sistema se organiza como um conjunto de serviços e servidores associados e clientes que utilizam esses serviços.
Quadro 3 – Descrição da arquitetura de software cliente-servidor
Nome Cliente-servidor
Descrição
Funcionalidades associadas a serviços que são oferecidos por servidores. Clientes 
podem solicitar serviços. 
Exemplo Biblioteca de vídeos organizados como um sistema cliente-servidor.
Quando é usado
Quando banco de dados compartilhado precisa ser acessado a partir de uma 
série de locais. 
Vantagens Servidores podem ser distribuídos através de uma rede. 
Desvantagens
Cada serviço é um ponto único de falha suscetível a ataques. Desempenho 
depende da rede. 
Fonte: Elaborado pela autora.
47
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
Os principais elementos dessa abordagem são:
1. Um conjunto de servidores oferecendo serviços a outros componentes. Ex.: servidores de impressão que 
oferecem serviços de impressão.
2. Um conjunto de clientes que podem chamar pelos serviços que servidores oferecem.
3. Uma rede que permita aos clientes acessar esses serviços. 
Neste tipo de arquitetura, como nos outros padrões, também se faz presente a separação e a independência. 
Serviços e servidores podem ser alterados sem modificar o restante dos sistemas. Além disso, clientes precisam 
conhecer os servidores e serviços disponíveis, mas servidores não precisam conheceros clientes. Solicitações são 
feitas por clientes a um servidor que deve respondê-las. 
A Figura 23 contém um exemplo de um sistema multiusuário que utiliza internet para fornecer uma biblioteca de 
filmes e fotos e que usa o modelo cliente-servidor. Servidores diferentes gerenciam mídias diferentes devido às 
suas diferenças. O servidor de catálogos deve fornecer consultas rápidas, além de comércio eletrônico. Por fim, 
um servidor para rodar o programa do cliente numa interface rodando em um browser da internet é utilizado.
Figura 23 – Uma arquitetura cliente-servidor para biblioteca de filmes
Cliente 1
Internet
Servidor de
catálagos
Catálogo de
Biblioteca
Servidor
de vídeos
Servidor
de Fotos
Servidor
Web
Informações sobre
vídeos/fotos
Arquivo de
Filmes
Arquivo de
Fotos
Cliente 2 Cliente 3 Cliente 4
Fonte: Elaborada pela autora.
3.4 Estudo de caso
Nesta seção, desenvolveremos um estudo de caso com o objetivo de consolidar os principais conceitos teóricos 
descritos nesta unidade e prover uma visão prática de como decidir em um projeto do mundo real em relação a 
qual modelo de ciclo de vidas utilizar. 
O sistema do estudo de caso descrito a seguir será chamado de Sistema de Controle Acadêmico (SCA). Uma 
universidade necessita de um software para a gestão dos diversos processos acadêmicos, como matrícula 
em disciplina, lançamento de notas, alocação de recursos para professores, entre outras ações. Após um 
levantamento, obteve-se uma lista de requisitos iniciais. A universidade tem urgência em utilizar o sistema, visto 
48
Metodologia de Desenvolvimento de Sistemas | Unidade 3 - Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
que o início do semestre letivo já está próximo e pelo menos as funcionalidades básicas relacionadas à matrícula 
de alunos não podem demorar a ser implementadas. Além disso, não se tem uma ideia total de como deve ser o 
sistema, apenas uma ideia inicial. 
Considerando a descrição do parágrafo acima, qual seria o modelo de ciclo de vida ideal para o processo do 
desenvolvimento do software SCA? Analisando as informações obtidas, podemos verificar que o modelo ideal 
seria um dos modelos do tipo incremental. Assim, o cliente, que no caso seria a universidade, logo ao final do 
primeiro ciclo já teria uma versão inicial do sistema que poderia ir sendo utilizada. Além disso, a universidade não 
tem uma ideia consistente do que deseja no software, apenas uma ideia dos requisitos iniciais. Desenvolvendo-o 
de forma incremental e com a utilização pela universidade de cada versão, provavelmente serão descobertos 
novos requisitos. Um exemplo de modelo que poderia ser aplicado nesta situação seria o RAD (Rapid Application 
Development) que preza pelo ciclo de desenvolvimento curto.
Síntese da unidade
Nesta unidade, abordamos a definição de ciclo de vida de projetos, suas etapas e os principais modelos existentes. 
Além disso, apresentamos a definição de arquitetura de software, citando também alguns dos padrões de 
arquitetura mais utilizados. Por fim, aplicamos alguns dos conceitos abordados durante a unidade através da 
definição de um estudo de caso.
49
Considerações finais
Desenvolver softwares é um processo complexo, pois seu sucesso 
depende tanto de pessoas quanto de processos e ferramentas. Existe uma 
infinidade de modelos de processo. Entretanto, todos possuem pontos 
positivos e negativos. Todos possuem fases que são comuns à maioria dos 
processos. O ideal é procurar pelo o que mais se adéqua à aplicação a ser 
desenvolvida.
	Unidade 1
	1. Histórico do Desenvolvimento de Software 
	Unidade 2
	2. Fundamentos de Desenvolvimento de Software
	Unidade 3
	3. Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
	Unidade 4
	4. Modelos MDS 
	Unidade 5
	5. Processos de MDS
	Unidade 6
	6. Tipos MDS 
	Unidade 7
	7. Qualidade em MDS
	Unidade 8
	8. Estudos de Casos com Uso de Software CASE