Universidade Metodista de Angola

Faculdade de Engenharia

Curso de Engenharia Informática

Trabalho de Engenharia de Software

Autor:

Diendonne Mauro Contreiras da Silva Pascoal

Professor:

MSC. Henriques Fernando

Luanda, Outubro de 2018

 1. Ciclo de Vida

O modelo de ciclo de vida é a primeira escolha a ser feita no processo de software. A partir
desta escolha definir-se-á desde a maneira mais adequada de obter as necessidades do cliente, até
quando e como o cliente receberá sua primeira versão operacional do sistema.

O ciclo de vida de um software (em inglês, software lifecycle), indica todas as etapas do
desenvolvimento de um software, da sua concepção até o seu desaparecimento. O objetivo de tal
segmentação é definir balizas intermediárias que permitam a validação do desenvolvimento do
software, ou seja, a conformidade do software com as necessidades expressas e a verificação do
processo de desenvolvimento, isto é, a adequação dos métodos aplicados.

A origem desta segmentação provém da constatação de que os erros têm um custo ainda
maior quando são detectados tardiamente no processo de produção. O ciclo de vida permite detectar
os erros o mais depressa possível e, assim, garantir a qualidade do software, os prazos de sua
realização e os custos associados.

Neste trabalho abordaremos sobre alguns modelos de ciclo de vida, tais como: clássico,
incremental, interativo e evolutivo.

O ciclo de vida é a 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.

1.1. Ciclo de Vida Clássico

O modelo Clássico ou em cascata é o modelo mais antigo mas ainda o mais usado; segue
uma sequência linear (como mostra a figura a seguir). Como a água que flui numa cascata, o
desenvolvimento movimenta-se somente num sentido, de modo que as etapas não podem ser
repetidas.
Suas atividades fundamentais são:

• Análise e definição de requisitos;

• Projeto;
• Implementação;
• Teste;
• Integração.

Figura 1. Modelo Clássico ou em Cascata.

Vantagens:

• Oferece uma maneira de tornar o processo mais visível;

• Facilita o planejamento;

Desvantagens:

• A interação é sempre necessária e está presente, criando problemas na aplicação do modelo;

• Projetos reais raramente seguem o fluxo sequencial;

• Os requisitos se alteram durante o projeto;
 1.2. Ciclo de Vida Incremental

Neste modelo, os requisitos do cliente são obtidos, e, de acordo com a funcionalidade, são
agrupados em módulos. Após este agrupamento, a equipe, junto ao cliente, define a prioridade em
que cada módulo será desenvolvido, escolha baseada na importância daquela funcionalidade ao
negócio do cliente.

O desenvolvimento é dividido em etapas, denominadas “incrementos”; Cada etapa produz

um sistema totalmente funcional e em cada incremento é realizado todo o ciclo do
desenvolvimento de software;

Uma atenção especial deve ser dada ao agrupamento dos requisitos e à qualidade no
desenvolvimento das funções comuns a todo o sistema, que inevitavelmente deverão ser entregues
no primeiro incremento.

Figura 2. Modelo incremental.

Vantagens:

• Existe um risco menor de fracasso do software;

 • Reduz a chance de mudança de requisito;
• Participação constante do cliente.
Desvantagens:
• Dificuldade em manter a documentação de cada fase atualizada devido às melhorias no
sistema e aos ajustes de requisitos solicitados pelos clientes.

1.3. Ciclo de Vida Evolutivo

Neste modelo, os requisitos são adquiridos em paralelo à evolução do sistema. O modelo

evolutivo parte do princípio que o cliente não expõe todos os requisitos, ou os requisitos não são
tão bem conhecidos, ou os requisitos ainda estão sofrendo mudanças. Desta forma, a análise é feita
em cima dos requisitos conseguidos até então, e a primeira versão é entregue ao cliente. O cliente
usa o software no seu ambiente operacional, e como feedback, esclarece o que não foi bem
entendido e dá mais informações sobre o que precisa e sobre o que deseja (ou seja, mais requisitos).

A partir deste feedback, nova análise, projeto e desenvolvimento são realizados, e uma
segunda versão do software é entregue ao cliente que, novamente, retorna com mais feedbacks.
Assim, o software vai evoluindo, se tornando mais completo, até atender todas as necessidades do
cliente dentro do escopo estabelecido. Tem-se assim a versão final, pelo menos até novos
requisitos aparecerem (ver Figura 3).

Figura 3. Modelo Evolutivo.

Vantagens:

• A participação constante do cliente;

Desvantagens:

• alta necessidade de gerenciamento nesse tipo de modelo;

1.4. Modelo Espiral

 O modelo espiral, é um dos modelos evolutivos mais difundidos.
Análise

Especificação de
Requisitos Projeto

Implementação
Entrega e
Implantação

Testes

Figura 4. Modelo Espiral.

Usando o modelo espiral, o sistema é desenvolvido em ciclos, sendo que nos primeiros
ciclos nem sempre todas as atividades são realizadas. Por exemplo, o produto resultante do primeiro
ciclo pode ser uma especificação do produto ou um estudo de viabilidade. As passadas subseqüentes
ao longo da espiral podem ser usadas para desenvolver protótipos, chegando progressivamente a
versões operacionais do software, até se obter o produto completo. Até mesmo ciclos de
manutenção podem ser acomodados nesta filosofia, fazendo com que o modelo espiral contemple
todo o ciclo de vida do software.
É importante ressaltar que, a cada ciclo, o planejamento deve ser revisto com base no
feedback do cliente, ajustando, inclusive, o número de iterações planejadas. De fato, este é o maior
problema do ciclo de vida espiral, ou de maneira geral, dos modelos evolucionários: a gerência de
projetos. Pode ser difícil convencer clientes, especialmente em situações envolvendo contrato, que
a abordagem evolutiva é gerenciável.
1.5. Ciclo de vida iterativo e incremental

Os ciclos de vida iterativos e incrementais são aqueles nos quais se repetem as atividades do
projeto em fases ou iterações e em cada uma delas se aumenta o entendimento do produto por parte
da equipe do projeto. As iterações desenvolvem o produto através de uma série de ciclos repetidos
que vão adicionando sucessivamente funcionalidades ao produto.
 No final de cada iteração, se terá completado um entregável ou um conjunto de entregáveis. As
futuras iterações podem melhorar os referidos entregáveis ou criar novos. O produto final será a
acumulação de funcionalidades construída nas iterações.

Se opta por ciclos de vida iterativos e incrementais quando é necessário gerenciar objetivos
pouco definidos ou de uma alta complexidade ou quando a entrega parcial do produto é a chave
para o sucesso. Este tipo de ciclo de vida permite a equipe do projeto incorporar a retroalimentação
e ir incrementando a experiência da equipe durante o projeto.

1.6. RAD

O modelo RAD (Rapid Application Development), ou modelo de desenvolvimento rápido de

aplicações, é um tipo de modelo incremental que prima por um ciclo de desenvolvimento curto.
Assim, como no modelo incremental, o sistema é subdividido em subsistemas e incrementos são
realizados. A diferença marcante é que os incrementos são desenvolvidos em paralelo por equipes
distintas e apenas uma única entrega é feita, como mostra a figura 5.

Figura 5. Modelo RAD

Assim, como o modelo incremental, o modelo RAD permite variações. Em todos os casos, no
entanto, os requisitos têm de ser bem-definidos, o escopo do projeto tem de ser restrito e o sistema
modular. Se o projeto for grande, por exemplo, o número de equipes crescerá demais e a atividade
de integração tornar-se-á por demais complexa. Obviamente, para adotar esse modelo, uma
organização tem de ter recursos humanos suficientes para acomodar as várias equipes.
 2. Análise Essencial

a) Discuta os fundamentos da análise essencial com palavras próprias.

R: A análise essencial foi proposta em 1984 por McMenamim e Palmer e é um avanço da Análise
Estruturada Clássica.

A análise essencial tem como finalidade a especificação de sistemas com base nos requisitos
(verdadeiros e falsos) do mesmo.

Esta análise consiste em repartir o sistema por eventos que constituem as entradas, saídas e
processamentos do mesmo; para que isso seja possível devemos ter em conta os três modelos
recomendados pela análise essencial que são: modelo funciona, modelo de dados e o modelo de
controle.

A análise essencial dispõe de 2 níveis, cada um com o seu modelo que são:

Nível essencial:

- Modelo essencial: neste modelo deve-se saber conhecer a essência do sistema, ou seja, os

requisitos verdadeiros, desprezando todas as restrições tecnológicas, tais como: hardware, Sistema

Operativo, o armazenamento necessário, etc.

Implementação:

-Modelo de implementação: tem a sua origem e é oposto ao modelo essencial.

b) O que entendes por essência do sistema. Requisitos verdadeiros e falsos, dê exemplos claros

R: essência do sistema, são todas as funcionalidades indispensáveis para o funcionamento de um

sistema, ou seja, é o conjunto de todos os requisitos verdadeiros.
Requisitos verdadeiros - formam a essência do sistema. são as características ou capacidade que
o sistema deve ter para cumprir sua finalidade, independentemente de como o sistema será
implementado.

Requisitos falsos – são as carecterísticas ou comportamentos irrelevantes para o cumprimento da

finalidade do sistema.

c) Discuta o modelo essencial com palavras próprias

R:este modelo consiste na apresentação da essência do sistema, ou seja, das funcionalidades

indispensáveis do sistema desprezando todos os aspectos tecnológicos que possam ser
fundamentais para o bom funcionamento do sistema em causa.

O modelo essencial está constituído por dois modelos: Modelo Ambiental e o Modelo
Comportamental.

d) Um sistema de inscrições e candidaturas para bolsa de estudos. Crie uma lista de eventos e
classifica-os.

Nº Nome do evento Tipo Estímulo Acções Respostas Usuário

de
fluxo

1 O funcionário recebe os C Inscrição Registar Registo Funcionário

dados pessoais do do candidato validado
candidato e insere-os no candidato
sistema

2 O funcionario recebe o F Inserção Inserir Inserção Funcionário

boletim de notas dos das notas efectuada
nota
s
 candidatos e as do
respectivas disciplinas e candidato
insere-as no sistema

3 O sistema analisa e C Validação Validar Validação Sistema

valida os dados dos dos dados dados efectuada analisador
candidatos dos
candidatos

3 O funcionário emite a F Emissão da Consultar Lista Administrador

lista de candidatos lista de notas emitida
amdimitidos aprovados com
sucesso

4 O director aprova a lista C Aprovação Aprovar Director

de candidatos da lista de lista
aprovados
amdimitidos
5 A secretária publica a F Publicação Publicar Lista Secretária
lista de candidatos das lista publicada
lista
admitidos s de
aprovados

e) Neste sistema dê exemplos de Actividades Custodiais, Fundamentais e Memória Essencial

R:

Actividades custodiais:

• Manter candidatos;
• Manter subsídios.

Actividades fundamentais:

• Cadstrar candidatos;
• Validar candidatos;
 • Actualizar candidatos.
Memória essencial:

• Identidade dos candidatos;

• Boletim de notas dos candidatos ;
• Tipo de bolsa;
• O seu subsídio;

f-R:

CANDIDATO

Recibos Requisitos

Requisitos SISTEMA DE Aprovações

SECRETÁRIA CANDIDATURA A BOLSAS DIRECTOR
DE ESTUDO
Informações e Resultados
Relatórios
g)R: DFD(0)

3. Modelo de Processo

O ciclo de desenvolvimento se refere ao conjunto de fases que devem ser realizadas para a
construção de um software.

O Modelo Iterativo e Incremntal foi o ciclo de desenvolvimento adoptado para o

desenvolvimento deste projecto.

O modelo iterativo e incremental é aquele no qual repetem-se as atividades do projeto em

fases ou iterações e em cada uma delas se aumenta o entendimento do produto por parte da equipe
do projeto. As iterações desenvolvem o produto através de uma série de ciclos repetidos que vão
adicionando sucessivamente funcionalidades ao produto.

No final de cada iteração, se terá completado um entregável ou um conjunto de entregáveis.

As futuras iterações podem melhorar os referidos entregáveis ou criar novos. O produto final será
a acumulação de funcionalidades construída nas iterações.

Se opta por ciclos de vida iterativos e incrementais quando é necessário gerenciar objetivos
pouco definidos ou de uma alta complexidade ou quando a entrega parcial do produto é a chave
para o sucesso.

Neste modelo foram consideradas as seguintes fases:

• Requisitos: Nesta fase, foram recolhidos os dados por intemédio de pesquisas feitas, que
possibilitaram a definição dos objectivos do sistema, bem como os requisitos necessários
para a modelagem do sistema;
 • Análise e Projecto: Nesta fase, os requisitos recolhidos foram transformados em estruturas
de suporte a implementação.

Para a modelagem do sistema foram utilizadas as seguintes ferramentas : Justinmind

Prototyper, Software Ideias Modeler e o StarUML na criação de interfaces e diagramas
respectivamente, pelo facto de oferecer um bom design dos diagramas e a grelha que
permite alinhar correctamente a posição de cada relacionamento.

Para a modelagem da base de dados do sistema foi utilizada a ferramenta brModelo.

• Implementação: Nesta fase, foi codificado todos os aspectos abstraídos dos modelos. O
desenvolvimento da interface gráfica(front-end) do sistema foi feito utilizando as
linguagens HTML5 e CSS3 com o auxílio do framework Bootstrap.

A parte interativa(back-end) do sitema foi codificada em Javascript e PHP por oferecer uma
fácil e rápida integração com o bancos de dados feitos no MySQL.

A base de dados foi codificada na linguagem SQL, usando o SGBD MySQL a partir do
Wampserver(tendo em conta que é um pacote que alberga o servidor Apache,
PHPMyAdmin e o MySQL).

Para a codificação do projecto foi utlizada inicialmente a ferramenta Sublime Text e

posterirormente a ferramenta Adobe Dreamweaver CC 2017.

• Teste: nesta fase que foi a última, foram realizados vários testes no Website; estes testes
auxiliaram na identificação de algumas falhas no sistema, que foram corrigidos
posteriormente.

Requisitos Funcionais

São declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a
entradas específicas e de como o sistema deve se comportar em determinadas situações.

Tabela 1: Requisitos Funcionais

 ID Descrição Prioridade
RF01 O sistema deve assegurar aos clientes a compra de produtos. Essencial
RF02 O sistema deve permitir aos clientes a criação de contas de acesso. Desejável
RF03 O sistema deve assegurar que os clientes façam Consulta por produtos. Essencial
RF04 O sistema deve permitir que os clientes adicionem produtos ao carrinho Essencial
de compra.

RF05 O sistema deve permitir ao administrador registar, consultar, actualizar Desejável

e eliminar produtos.

RF06 O sistema deve permitir ao administrador listar e consultar todos os Desejável

pedidos feitos.

RF07 O sistema deve permitir ao administrador a gestão de contas de acesso. Desejável

RF08 O sistema deve permitir ao administrador efectuar qualquer operação. Desejável

Requisitos Não Funcionais

São restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de timing,
restrições no processo de desenvolvimento e restrições impostas pelas normas. Ao contrário das
características individuais ou serviços do sistema, os requisitos não funcionais, muitas vezes,
aplicam-se ao sistema como um todo.

Tabela 2: Requisitos Não Funcionais

ID Tipo Descrição
RNF01 Acessibilidade A transação de produtos deve ser assegurada aos usuários que
possuem uma conta no sistema.
RNF02 Usabilidade O sistema terá uma interface amigável, imediata e de simples
manejamento, isto é, suas informações e funcionalidades estarão
bem visíveis e disponíveis para os usuários.

RNF03 Desempenho O sistema terá um tempo de resposta muito curto dependendo da

capacidade do hardware e da qualidade da conexão com a internet.

RNF04 Usabilidade O sistema deverá ter um alto nível de acessibilidade, devendo ser
acessível a partir de qualquer Navegador, mas para a melhor
visualização, o sistema deverá ser executado em navegadores que
suportem o HTML e CSS nas versões 5 e 3, respectivamente.

RNF05 Segurança O acesso ao sistema não será por meio da validação de usuários.
A validação será necessária para poder efectuar compras.
RNF06 Usabilidade O sistema devera possuir dois tipos de usuários com nível de
privilégios diferentes.

RNF07 Funcionalidade O usuário não terá problemas de conflitos de perfis, pelo facto do
uso de sessões e a distribuição dos ficheiros do sistema aos perfis
adequados.

RNF08 Confiabilidade O sistema estará em serviço a tempo inteiro.