Método de Concepção de

Sistemas de Informação
(MCSI-1)

1
MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Esta cadeira Método de Concepção de Sistemas de Informação, pertence

ao grupo de disciplinas do curso de Engenharia Informática da Universidade
Kimpa Vita, IP/Uíge.

1. OBJECTIVOS
Gerais :
 Iniciar os estudantes nas metodologias usadas para o desenvolvimento de
projectos informáticos no contexto empresarial ;
 Estudar os procedimentos e técnicas que permitirão a automatização de
uma aplicação informática.

Especícos :
 Identicar e documentar os requisitos especícos do sistema de informa-
ção, incluindo funcionalidades desejadas, restrições e metas de desem-
penho.
 Desenvolver nos estudantes a capacidade de analisar e desenhar o es-
quema de sistemas.

Método de Concepção do sistema de informação

informatizado (MCSI I)
 Capítulo 1. Introdução
 Capítulo 2. Sistema de Informação
 Capítulo 3. Ciclo de vida de Software
 Capítulo 4. Técnica Estruturada

Método de Concepção do sistema de informação

informatizado (MCSI II)
 Capítulo 1. Introdução
 Capítulo 2. Modelo Conceptual
 Capítulo 3. Modelo Organizacional
 Capítulo 4. Modelo Lógico
 Capítulo 5. Modelo Físico
 Capítulo 6. Analogia Merise/UML
 Capítulo 7. Aplicação com Windev/HFSQL

 Não existe vitória sem sacrifício!  2

 Sumário

1 Sistema de informação 4
1.1 Noção de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 As características de um sistema . . . . . . . . . . . . . . 4
1.1.2 A representação esquemática dos sistemas da empresa . . 5
1.2 A separação de dados e processamento . . . . . . . . . . . . . . . 6
1.2.1 Dados (ou informações) . . . . . . . . . . . . . . . . . . . 6
1.2.2 Entrevista . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Estudo de documentos internos . . . . . . . . . . . . . . . 11
1.2.4 Estudo de documentos externos . . . . . . . . . . . . . . . 11
1.2.5 Os diferentes tipos de informações . . . . . . . . . . . . . 12

2 Ciclo de vida de software 13

2.1 O ciclo de vida de um projeto de software com a metodologia
Merise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 ciclo de vida usando o RAD (rapid aplication developper) . . . . 15

3 TÉCNICA ESTRUTURADA 17
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Análise Estruturada . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Diagrama de Contexto . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Diagrama de uxo de dados . . . . . . . . . . . . . . . . . 18
3.2.3 Dicionário de dados . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Diagrama de Entidade-Relacionamento (DER) . . . . . . 20
3.2.5 Diagrama de Transição de Estado (DTE) . . . . . . . . . 21
3.2.6 Especicação de Processos . . . . . . . . . . . . . . . . . . 22
3.3 Projeto Estruturado . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Programação Estruturada . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Desenvolvimento Top-down . . . . . . . . . . . . . . . . . . . . . 24
3.6 Equipes de Programação . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Revisões Estruturadas . . . . . . . . . . . . . . . . . . . . . . . . 25

3
 CAPÍTULO 1

Sistema de informação

A concepção de um sistema informático é uma etapa crucial no ciclo de de-

senvolvimento de software, na qual os engenheiros de software e analistas de
sistemas denem os principais aspectos do sistema a ser construído. Essa fase
envolve a transformação dos requisitos do sistema em um plano de projeto de-
talhado que servirá como base para o desenvolvimento. A concepção de sistema
é essencial para garantir que o software atenda às necessidades dos usuários e
da organização de maneira eciente e ecaz.

1.1 Noção de sistema

Em anatomia, um sistema se refere a um conjunto de partes similares que
participam de uma atividade comum (sistema cardíaco, sistema digestivo, sis-
tema respiratório, etc.). Em ciência, o sistema pode ser usado para denir uni-
dades, como o sistema métrico.

Segundo o Robert, um sistema é um dispositivo formado pela reunião de

elementos análogos. A denição do Larousse parece mais explícita : "Combina-
ção de partes que se coordenam para concorrer a um resultado, de maneira a
formar um conjunto". Todo sistema funciona transformando uxos de entrada
em uxos de saída de acordo com processos mais ou menos complexos.

1.1.1 As características de um sistema

Um sistema é um elemento nito cujo perímetro é uma fronteira que o separa
do seu ambiente. Ele interage com o seu ambiente através de uxos de infor-
mações de entrada, que ele irá processar e restituir ao ambiente sob a forma de
uxos de informações de saída.

4
MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

O sistema vai gerar informações que dão conta do seu comportamento tanto
dentro do ambiente, mas também para si próprio. Um sistema comunica.

Um sistema precisa armazenar e processar informações para tomar decisões.

1.1.2 A representação esquemática dos sistemas da em-

presa
Se retomarmos a analogia anatômica e compararmos a empresa a um corpo
humano, podemos reduzir a empresa a um cérebro que pilota, um músculo
que opera e nervos que fazem transitar as informações. Aqui está um esquema
simplicado que resulta disso :

Figure 1.1 

1.1.2.1 O sistema de pilotagem

O sistema de pilotagem dene as missões e os objetivos, organiza o emprego
dos meios, controla a execução dos trabalhos. Ele atribui objetivos à organização,
analisa o ambiente e o funcionamento interno da organização, controla o sistema
operante. Ele está ligado aos outros sistemas por uxos de informações internas.

1.1.2.2 O sistema de informação

O sistema de informação é o conjunto dos recursos humanos, técnicos e nan-
ceiros que fornecem, utilizam, compilam, processam e distribuem a informação

 Não existe vitória sem sacrifício!  5

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

da organização. Ele alimenta a organização com informações de várias origens

(internas ou externas). Ele é a passagem obrigatória para todas as informações
da empresa.

1.1.2.3 O sistema operante

O sistema operante é o conjunto de meios humanos, materiais e organizacio-
nais que executam as ordens do sistema de pilotagem. Ele assegura o funciona-
mento do sistema global, sua atividade é controlada pelo sistema de pilotagem.

1.2 A separação de dados e processamento

1.2.1 Dados (ou informações)
A informação é a emissão ou recepção de sinais orais ou escritos, sonoros,
visuais ou multimídia, cujo objetivo é desencadear os processos que alimentam
a troca, base natural e indispensável da animação da organização.

As informações são coletadas dentro do domínio a ser estudado. A lista de

informações é constituída de várias maneiras :
 entrevista ;
 estudo de documentos internos ;
 estudo de documentos externos.

1.2.2 Entrevista
Entrevistas são interações diretas entre duas ou mais pessoas, onde uma pes-
soa, conhecida como entrevistador, faz perguntas ou conduz uma conversa com
o objetivo de obter informações, opiniões, insights ou respostas de outra pessoa,
chamada de entrevistado. As entrevistas são uma forma comum de comunicação
e coleta de informações em diversos contextos, incluindo pesquisa, jornalismo,
recrutamento, investigação, entre outros. Elas podem variar em termos de for-
mato, estrutura e propósito. Aqui estão alguns aspectos-chave relacionados às
entrevistas :

1. Objetivo : O propósito de uma entrevista pode ser variado. Pode ser

usado para obter informações sobre um tópico especíco, para conhecer
a opinião de alguém sobre um assunto, para obter histórias pessoais, para
avaliar candidatos a empregos e muito mais.

2. Formato : As entrevistas podem ser estruturadas, semiestruturadas ou

não estruturadas. Em entrevistas estruturadas, o entrevistador segue um
conjunto predenido de perguntas. Em entrevistas semiestruturadas, há
um roteiro de tópicos, mas o entrevistador tem exibilidade para explorar
tópicos em mais profundidade. Entrevistas não estruturadas não seguem
um roteiro predenido.

3. Condução : O processo de condução de uma entrevista envolve fazer

perguntas, ouvir atentamente as respostas, fazer perguntas de acompan-
hamento quando necessário e manter a conversa uindo.

 Não existe vitória sem sacrifício!  6

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

4. Registro de Dados : As respostas e informações obtidas durante a

entrevista são geralmente registradas de alguma forma. Isso pode envolver
anotações escritas, gravação de áudio ou vídeo.

5. Análise : Após a entrevista, as informações coletadas podem ser ana-

lisadas para obter insights ou dados relevantes, dependendo do objetivo
da entrevista.

6. Entrevistadores e Entrevistados : O entrevistador é a pessoa que

faz as perguntas ou conduz a entrevista. O entrevistado é a pessoa que
fornece as respostas.

7. Contexto : Entrevistas podem ocorrer em diversos contextos, como

pesquisa acadêmica, jornalismo, recrutamento de pessoal, investigação
criminal, avaliação de desempenho, entre outros.

8. Técnicas de Entrevista : Existem técnicas especícas para conduzir

entrevistas de maneira ecaz, incluindo a formulação de perguntas aber-
tas, ouvir atentamente, criar um ambiente confortável para o entrevistado
e evitar viés ou inuência.

9.

As entrevistas são uma ferramenta valiosa para coletar informações e pers-

pectivas diretamente das pessoas. A escolha do tipo de entrevista e a maneira
como ela é conduzida dependem dos objetivos e do contexto especíco em que
está sendo realizada. Elas desempenham um papel importante em muitos cam-
pos, desde a pesquisa cientíca até o jornalismo investigativo e a seleção de
pessoal.

1.2.2.1 Técnicas de Entrevista

Entrevistar ecazmente requer o domínio de técnicas que podem ajudar a
obter informações precisas, completas e relevantes. Aqui estão algumas técnicas
de entrevista que podem ser úteis em diferentes contextos :

1. Formulação de Perguntas Abertas :

 Use perguntas abertas que incentivem o entrevistado a fornecer re-
spostas detalhadas e expansivas em vez de respostas simples de "sim"
ou "não".
 Exemplo de pergunta fechada : "Você gostou do produto X ?"
 Exemplo de pergunta aberta : "Pode me contar sobre sua experiência
com o produto X ?"

2. Escuta Ativa :
 Preste atenção cuidadosa ao que o entrevistado está dizendo. Isso en-
volve não apenas ouvir as palavras, mas também observar a linguagem
corporal e as emoções.
 Faça perguntas de acompanhamento com base no que foi dito para
esclarecer ou aprofundar informações.

3. Empatia :
 Demonstre empatia e compreensão em relação às experiências e sen-
timentos do entrevistado. Isso pode encorajá-los a se abrir e compar-
tilhar mais informações.

4. Neutralidade e Não Tendenciosidade :

 Não existe vitória sem sacrifício!  7

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

 Evite fazer perguntas tendenciosas que possam inuenciar as respo-

stas do entrevistado. Em vez disso, faça perguntas neutras e impar-
ciais.
 Por exemplo, em vez de perguntar "Você acha que o novo sistema é
mais eciente ?", pergunte "Como você avaliaria a eciência do novo
sistema ?".

5. Questionamento de Exploração :
 Use questionamentos de exploração para aprofundar o entendimento
dos tópicos abordados pelo entrevistado. Pergunte "por quê", "como"
e "pode me dar um exemplo" para obter mais detalhes.

6. Rapport :
 Crie um relacionamento de conança com o entrevistado. Isso pode
ser alcançado por meio de uma comunicação amigável, respeitosa e
aberta.

7. Estrutura da Entrevista :
 Tenha um plano ou estrutura para a entrevista, com uma sequência
lógica de tópicos a serem abordados. Isso ajuda a garantir que todos
os pontos relevantes sejam discutidos.

8. Flexibilidade :
 Esteja preparado para se adaptar durante a entrevista. Às vezes, as
respostas do entrevistado podem levar a áreas inesperadas, e a exi-
bilidade é essencial para explorar essas oportunidades.

9. Controle da Entrevista :
 Mantenha o controle da entrevista, garantindo que ela permaneça
focada nos tópicos relevantes e que o tempo seja gerenciado adequa-
damente.

10. Encerramento da Entrevista :

 No nal da entrevista, permita que o entrevistado faça perguntas ou
forneça informações adicionais que possam ter sido esquecidas.

11. Agradecimento e Acompanhamento :

 Agradeça ao entrevistado pela participação e, se apropriado, forneça
informações sobre o próximo passo ou o acompanhamento.

Essas técnicas são valiosas para qualquer pessoa que realize entrevistas em
contextos como pesquisa, jornalismo, recrutamento, avaliação ou qualquer outra
situação em que a coleta de informações diretas seja necessária. Dominar essas
técnicas pode ajudar a tornar as entrevistas mais ecazes e produtivas.

1.2.2.2 Exemplo de entrevista

Uma entrevista na área de informatização pode ser conduzida para coletar
informações sobre a implementação de sistemas de informação em uma organi-
zação, entender as necessidades dos usuários ou avaliar a ecácia de um sistema
existente. Abaixo está um exemplo ctício de uma entrevista com um gerente
de TI em uma empresa que está buscando informatizar seus processos de geren-
ciamento de estoque :
 Entrevistador : Olá, obrigado por concordar em se encontrar
conosco hoje. Nosso objetivo é entender melhor como a infor-
matização pode melhorar o gerenciamento de estoque em sua

 Não existe vitória sem sacrifício!  8

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

empresa. Para começar, você pode nos dar uma visão geral dos
processos de gerenciamento de estoque atualmente em vigor ?
 Gerente de TI : Claro. Atualmente, usamos principalmente planilhas
para rastrear nosso estoque. Cada vez que recebemos ou enviamos produ-
tos, atualizamos manualmente as planilhas. Também fazemos contagens
físicas periódicas para reconciliar as informações nas planilhas com o es-
toque real.

 Entrevistador : Entendi. Quais são os principais desaos que

você enfrenta com o sistema atual ?
 Gerente de TI : Bem, há alguns problemas. Primeiro, as atualizações
manuais nas planilhas consomem muito tempo e às vezes resultam em
erros de entrada. Isso nos levou a enfrentar problemas de estoque desa-
tualizado. Além disso, não temos uma maneira ecaz de rastrear o histó-
rico de movimentação de produtos, o que diculta a detecção de perdas
ou a análise de tendências.

 Entrevistador : Compreendo. Agora, estamos explorando op-

ções de informatização. O que você gostaria de alcançar com
um novo sistema ?
 Gerente de TI : Gostaríamos de ter um sistema que automatize o ras-
treamento de estoque, para que as atualizações sejam feitas em tempo
real. Isso reduzirá erros e nos permitirá tomar decisões mais informadas
sobre reabastecimento e otimização de estoque. Também queremos um
histórico detalhado de movimentação de produtos para ns de auditoria
e relatórios.

 Entrevistador : Excelente. Quais recursos ou funcionalidades es-

pecícas você acha mais importantes em um novo sistema de
gerenciamento de estoque ?
 Gerente de TI : Em primeiro lugar, um mecanismo de rastreamento
em tempo real. Também precisamos de um sistema que possa lidar com
variações de estoque, como produtos perecíveis ou sazonais. Relatórios
personalizáveis e a capacidade de integração com nossos outros sistemas
empresariais também são cruciais.

 Entrevistador : Muito obrigado por compartilhar essas infor-

mações. Vamos levar essas considerações em conta ao avaliar
nossas opções de informatização. Haverá mais algum comentá-
rio ou preocupação que gostaria de destacar ?
 Gerente de TI : Não no momento, a não ser que a segurança de da-
dos seja uma prioridade. Dado que estaremos lidando com informações
críticas de estoque, a segurança deve ser robusta.

Neste exemplo, a entrevista tem o objetivo de coletar informações sobre as neces-

 Não existe vitória sem sacrifício!  9

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

sidades e desaos do gerenciamento de estoque da empresa antes de considerar a

implementação de um sistema informatizado. As respostas do entrevistado aju-
darão a orientar o processo de informatização e a denição de requisitos para o
novo sistema.

1.2.2.3 Desenvolva um Plano Geral de Entrevistas

Um plano geral de entrevistas é uma estratégia que você pode criar antes de
conduzir uma série de entrevistas para garantir que elas sejam ecazes e atinjam
seus objetivos. Abaixo está um exemplo de um plano geral de entrevistas que
pode ser adaptado para diversos contextos :

 Título do Plano : Plano de Entrevistas para Avaliação de Satisfação

dos Clientes.
 Objetivo das Entrevistas : Coletar feedback dos clientes para avaliar
seu nível de satisfação com os produtos e serviços da empresa.

Fase de Planejamento :
1. Identicação dos Entrevistados : Determine quem são os clientes que
serão entrevistados. Isso pode incluir clientes ativos, clientes antigos ou
clientes que tiveram experiências recentes com a empresa.

2. Seleção dos Entrevistadores : Escolha os entrevistadores com base em sua

capacidade de conduzir entrevistas de forma imparcial e objetiva.

3. Desenvolvimento do Roteiro de Entrevista : Crie um roteiro que inclua

perguntas abertas e fechadas relacionadas à satisfação do cliente, expe-
riência de compra, qualidade do produto, atendimento ao cliente, entre
outros.

Fase de Execução :
1. Agendamento de Entrevistas : Entre em contato com os entrevistados
para agendar as entrevistas. Explique o propósito das entrevistas e o
tempo estimado necessário.

2. Condução das Entrevistas : Realize as entrevistas conforme agendado,

seguindo o roteiro estabelecido. Certique-se de registrar as respostas de
forma precisa.

3. Manutenção do Controle : Mantenha o controle da entrevista, garantindo

que ela permaneça focada nos tópicos relevantes. Evite interrupções ou
distrações.

Fase de Análise :
1. Transcrição e Codicação : Transcreva as respostas das entrevistas, se
necessário. Em seguida, codique as respostas para análise..

2. Análise de Dados : Analise as respostas para identicar padrões, tendên-

cias e insights relacionados à satisfação do cliente.

3. Preparação de Relatórios : Compile os resultados em relatórios que des-

taquem os principais achados das entrevistas. Isso pode incluir grácos e
resumos.

 Não existe vitória sem sacrifício!  10

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Fase de Comunicação :
1. Compartilhamento de Resultados : Compartilhe os relatórios e resultados
com as partes interessadas relevantes, como a equipe de gerenciamento
ou departamentos responsáveis pela melhoria dos serviços.

Ações de Acompanhamento :
1. Plano de Ação : Com base nos resultados das entrevistas, desenvolva um
plano de ação para abordar áreas de insatisfação e melhorar a satisfação
do cliente.

2. Feedback para Entrevistados : Forneça feedback aos entrevistados sobre

como suas opiniões estão sendo usadas para melhorar os produtos e ser-
viços.

Cronograma :
Dena um cronograma para cada fase do plano, incluindo datas para a
condução das entrevistas, análise de dados e comunicação de resultados.

1.2.2.4 questionário de pesquisa

A criação de um questionário de pesquisa é um passo crucial na coleta de
informações e na obtenção de dados relevantes para sua pesquisa. Lembre-se de
que a formulação de perguntas deve ser precisa e especíca em relação ao seu
tópico de pesquisa.

Para criar questionários de pesquisa de forma automatizada, você pode usar

Google Forms e
ferramentas de pesquisa online. Duas opções populares são o
o SurveyMonkey. Ambas as ferramentas permitem criar questionários perso-
nalizados de maneira rápida e fácil.

1.2.3 Estudo de documentos internos

Os documentos internos (faturas, notas de entrega, ordens de fabricação)
contêm informações que muitas vezes são omitidas durante as entrevistas. Essas
omissões se devem ao caráter automático e recorrente dessas informações. As
pessoas que as manipulam no dia a dia frequentemente esquecem de citá-las,
pois elas lhes parecem óbvias.

1.2.4 Estudo de documentos externos

O estudo de documentos externos (faturas de fornecedores, notas de entrega
de fornecedores, etc.) assim como o estudo de documentos internos permite
descobrir informações esquecidas durante as entrevistas e também descobrir al-
gumas regras de gerenciamento.

Para esta coleta de informações, é necessário respeitar certas regras para

evitar erros futuros. Antes de adicionar uma informação, é imperativo vericar
se ela já não está presente.

 Não existe vitória sem sacrifício!  11

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Por exemplo, um número de cliente pode aparecer em uma nota de entrega

e em um a fatura. Não é necessário listá-lo duas vezes. Da mesma forma, uma
informação pode ser sinônimo de outra.
Por exemplo, na nota de entrega aparece "Código do cliente" e na fatura "Nú-
mero do cliente". É imperativo manter apenas uma das duas informações.

1.2.5 Os diferentes tipos de informações

1.2.5.1 Informações elementares e memorizáveis
As informações elementares são informações cujos valores não podem ser
inventados, elas não são dedutíveis de outras informações.
Por exemplo, um nome de cliente ou sua razão social não podem ser inventados.
Uma quantidade encomendada também não pode ser inventada.

Uma informação deve ser atômica, ou seja, não decomponível.

Por exemplo, se a informação Endereço deve conter "36, rua de la Paix 75000
Paris", ela pode ser decomposta em várias informações elementares :
 Endereço ;
 Código postal.
 Cidade.
Cada valor tomado por uma informação é chamado de ocorrência.
Por exemplo, a informação Nome pode ter as seguintes ocorrências : Baptista ;
Durand.

1.2.5.2 As informações calculadas

As informações calculadas são dedutíveis das informações elementares. Por
exemplo, o total de uma linha de pedido é o resultado da multiplicação do preço
de venda sem impostos pela quantidade encomendada.

1.2.5.3 Os processamentos
Eles são coletados como informações através de um processo de entrevista e
estudo de documentos. Eles podem ser de dois tipos :
 automáticos ;
 manuais.
Eles são acionados pela chegada de eventos. A gestão dos processamentos serve
para identicar as funcionalidades de acordo com uma abordagem que vai do
geral ao particular e que dene sua divisão e sequenciamento.

 Não existe vitória sem sacrifício!  12

 CAPÍTULO 2

Ciclo de vida de software

O ciclo de vida de software é uma abordagem sistemática para o desenvolvi-

mento, manutenção e gestão de software, desde a concepção até a aposentadoria.
Ele descreve as fases pelas quais um projeto de software passa, desde a ideia in-
icial até a entrega e o suporte contínuo. Existem várias metodologias e modelos
para o ciclo de vida de software, mas uma estrutura comum inclui as seguintes
fases :

1. Concepção (Iniciação) :
Nesta fase, a ideia para o software é concebida. Os requisitos iniciais são
identicados, e a viabilidade do projeto é avaliada.

2. Denição de Requisitos :
Os requisitos detalhados do software são coletados e documentados. Isso
inclui requisitos funcionais e não funcionais, bem como as expectativas
dos usuários.

3. Design :
Os engenheiros de software criam uma arquitetura de alto nível do sis-
tema, identicando os componentes e suas interações. O design de soft-
ware detalhado também é realizado, incluindo a criação de diagramas e
especicações técnicas.

4. Desenvolvimento (Implementação) :
Durante esta fase, o código-fonte real do software é escrito com base no
design. Os programadores implementam os algoritmos e funcionalidades
necessárias.

5. Testes :
O software é submetido a testes rigorosos para identicar erros e garantir
que ele atenda aos requisitos. Isso inclui testes de unidade, testes de
integração e testes de aceitação.

6. Implantação : O software é implantado no ambiente de produção e

disponibilizado aos usuários nais. Isso pode incluir a instalação em ser-
vidores, distribuição de aplicativos ou disponibilização online.

13
MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

7. Operação e Manutenção :
Após o lançamento, o software requer operação contínua e manutenção.
Isso envolve correção de erros, atualizações de segurança e implementação
de novos recursos.

8. Aposentadoria :
Eventualmente, o software pode ser aposentado se não for mais viável ou
útil. Nesse ponto, os dados são arquivados e os sistemas são desativados.

Além do modelo em cascata, que segue uma sequência linear de fases, há meto-
dologias ágeis, como Scrum e Kanban, que enfatizam o desenvolvimento iterativo
e colaborativo, permitindo mudanças mais exíveis durante o ciclo de vida do
software. Cada fase pode ser dividida em iterações curtas, onde novos recursos
são implementados e testados continuamente.

O ciclo de vida de software é fundamental para o desenvolvimento de software

ecaz, garantindo que os requisitos sejam atendidos, o software seja testado e
seguro, e que as mudanças e melhorias possam ser gerenciadas de forma eciente
ao longo do tempo.

2.1 O ciclo de vida de um projeto de software

com a metodologia Merise
O ciclo de vida de um projeto de software com a metodologia Merise envolve
várias etapas que guiam o desenvolvimento de sistemas de informação. Merise
é uma metodologia francesa de desenvolvimento de sistemas de informação que
se concentra na modelagem de dados, processos e interfaces. Abaixo estão as
principais etapas do ciclo de vida do projeto de software com Merise :

1. Estudo Preliminar :
Nesta fase, são identicados e analisados os problemas e necessidades que
o sistema de informação deve resolver. A ênfase está na compreensão dos
requisitos gerais do sistema.

2. Estudo Detalhado :
Na fase de estudo detalhado, os requisitos são analisados em maior pro-
fundidade. Isso envolve a modelagem de dados para denir as estruturas
de dados necessárias e a modelagem de processos para descrever como as
informações uirão pelo sistema.

3. Projeto Conceitual :
Nesta etapa, é criado um modelo conceitual do sistema de informação.
Isso envolve a criação de diagramas de entidade-relacionamento (DER)
para representar as entidades de dados e suas relações.

4. Projeto Lógico :
O projeto lógico se concentra na denição de estruturas de dados mais de-
talhadas, como tabelas de banco de dados, e na modelagem de processos
detalhados.

5. Projeto Físico :
Na fase de projeto físico, são denidos os detalhes técnicos de implemen-
tação do sistema, incluindo a escolha de tecnologias e plataformas.

 Não existe vitória sem sacrifício!  14

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

6. Desenvolvimento :
Nesta etapa, o software real é desenvolvido com base nas especicações
denidas nas fases anteriores.

7. Testes :
Após o desenvolvimento, o sistema é testado para garantir que ele atenda
aos requisitos e funcione conforme o esperado.

8. Implementação :
O sistema é implantado em ambiente de produção, permitindo que os
usuários nais o utilizem.

9. Manutenção :
A fase de manutenção envolve a correção de erros, atualizações e melho-
rias contínuas no sistema ao longo do tempo.

10. Documentação :
A documentação é criada em todas as fases do ciclo de vida do projeto,
incluindo documentação de requisitos, modelagem de processos, docu-
mentação técnica e manuais de usuário.

Merise enfatiza a importância da modelagem de dados e processos como base

para o desenvolvimento de sistemas de informação. A metodologia promove a
clareza na denição dos requisitos, o que ajuda a evitar problemas comuns de
ambiguidade e má compreensão dos requisitos.

É importante ressaltar que o ciclo de vida do projeto de software com Merise

pode variar em complexidade dependendo do tamanho e da natureza do projeto.
Projetos maiores podem envolver várias iterações e ciclos de desenvolvimento
para aprimorar o sistema ao longo do tempo. Além disso, a metodologia Merise
pode ser adaptada para atender às necessidades especícas de um projeto ou
organização.

2.2 ciclo de vida usando o RAD (rapid aplication

developper)
O ciclo de vida de um projeto usando o Rapid Application Development
(RAD), ou Desenvolvimento Rápido de Aplicativos em português, é uma abor-
dagem de desenvolvimento de software que se concentra na entrega rápida de
sistemas e protótipos funcionais. O RAD é conhecido por sua ênfase na cola-
boração próxima com os usuários e na construção de sistemas iterativos. Aqui
estão as principais etapas do ciclo de vida de um projeto usando o RAD :

1. Planejamento Inicial : Nesta fase, os objetivos do projeto são denidos,

e os requisitos iniciais são identicados de maneira geral. É importante
criar um plano de projeto que descreva o escopo, as metas e os recursos
necessários.

2. Modelagem de Dados :
O RAD frequentemente começa com a modelagem de dados para entender
a estrutura de informações que será manipulada pelo sistema. Os modelos
de dados, como diagramas de entidade-relacionamento, são criados para
representar as relações entre os dados.

 Não existe vitória sem sacrifício!  15

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

3. Prototipagem Rápida :
Uma característica central do RAD é a criação rápida de protótipos.
Protótipos interativos e funcionais do sistema são desenvolvidos em co-
laboração com os usuários. Isso permite que os usuários visualizem e
experimentem o sistema em um estágio inicial do projeto.

4. Design de Interface do Usuário :

Durante o desenvolvimento de protótipos, o design da interface do usuá-
rio (UI) é considerado e desenvolvido. O foco está na usabilidade e na
experiência do usuário.

5. Desenvolvimento Iterativo :
O RAD envolve ciclos de desenvolvimento iterativos e incrementais. Os
desenvolvedores criam partes funcionais do sistema, que são revisadas e
aprimoradas pelos usuários e partes interessadas.

6. Revisão e Feedback :
Após cada iteração de desenvolvimento, os usuários e partes interessadas
revisam o protótipo e fornecem feedback. Esse feedback é usado para
renar e melhorar o sistema.

7. Integração de Componentes :
À medida que o sistema cresce, os diferentes componentes e módulos
desenvolvidos em iterações anteriores são integrados para formar uma
aplicação coesa.

8. Testes Contínuos :
Testes são conduzidos em cada iteração para garantir que o sistema
atenda aos requisitos e funcione corretamente. Erros e problemas são
identicados e corrigidos prontamente.

9. Implantação Gradual :
À medida que o sistema se torna mais completo e robusto, as versões apro-
vadas são implantadas para uso real. A implantação pode ser gradual,
permitindo que os usuários experimentem o sistema em um ambiente de
produção.

10. Manutenção Contínua :

Após a implantação, o sistema é mantido e aprimorado continuamente
com base no feedback dos usuários e nas mudanças nos requisitos.

O RAD é adequado para projetos em que os requisitos não são completamente

conhecidos ou podem mudar durante o desenvolvimento. Ele é altamente cola-
borativo e permite a entrega rápida de software funcional. No entanto, é impor-
tante ter um controle rigoroso de mudanças e feedback contínuo dos usuários
para garantir que o sistema atenda às necessidades em evolução.

 Não existe vitória sem sacrifício!  16

 CAPÍTULO 3

TÉCNICA ESTRUTURADA

3.1 Introdução
Neste capitulo serão apresentadas as técnicas estruturadas utilizadas no de-
senvolvimento de sistemas, e que podem também ser chamadas de : técnicas de
melhoria de produtividade, técnicas de produtividade na programação ou ainda
técnicas de engenharia de software. Elas incluem os seguintes tópicos :

ˆ Análise estruturada ;

ˆ Projeto estruturado ;

ˆ Programação estruturada ;

ˆ Desenvolvimento top-down ;

ˆ Equipes de programação ;

ˆ Revisões estruturadas.

3.2 Análise Estruturada

Como o próprio nome sugere, ela refere-se ao extremo inicial de um projeto
de desenvolvimento de sistemas, durante o tempo em que os requisitos do usuá-
rio são denidos e documentados.

Por que a análise estruturada é tão importante ? Simplesmente porque a

análise clássica é não atendeu as necessidades. O problema é muito simples de
ser expressado : em qualquer coisa diferente de um projeto de desenvolvimento
de sistemas trivial, o usuário não tem um bom entendimento do que está sendo
feito para ele. Os problemas da análise clássica podem ser resumidos como :

ˆ As especicações funcionais clássicas são monolíticas ;

ˆ As especicações funcionais clássicas são redundantes ;

17
MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

ˆ As especicações funcionais clássicas são difíceis de se modicar ou man-

ter ;

ˆ As especicações funcionais clássicas fazem muitas suposições sobre os

detalhes de implementação.

Todos esses fatores contribuem para tornar a fase de análise dos sistemas
convencionais, na maioria dos grandes projetos, uma atividade dolorosa e de-
morada. Em muitos casos, todos estão desesperados para passar para pela apro-
vação. Tendo acabado a fase de análise de sistemas, poucos pensam em voltar
atrás e reexaminar ou revisar as especicações formais.

O que então a análise estruturada pode oferecer ? A análise estruturada

introduz o uso de ferramentas de documentação gráca para produzir um tipo
diferente de especicação funcional, uma especicação estruturada, em contraste
à novela vitoriana clássica e monolítica. As ferramentas de documentação da
análise estruturada são :

ˆ Lista de Eventos ;

ˆ Diagrama de Contexto ;

ˆ Diagrama de uxo de dados (DFD) ;

ˆ Dicionário de dados (DD) ;

ˆ Diagrama de entidade relacionamento ;

ˆ Diagramas de transição de estado (DTE) ;

ˆ Especicação de processo.

3.2.1 Diagrama de Contexto

Documenta o âmbito do estudo, apresentando os uxos de dados que entram
e saem do sistema e sua interação com as entidades externas. Tem como função
delinear a área de observação.

3.2.2 Diagrama de uxo de dados

Fornece um meio fácil e gráco de modelar o uxo de dados pelo sistema.
É uma representação em rede dos processos (funções) do sistema e dos dados
que ligam esses processos. Ele mostra o que o sistema faz e não como é feito. A
gura mostra os elementos básicos de um DFD : os terminadores ou Entidades
(fontes ou destinos), Fluxos de dados, processos e Depósitos ou armazenagem
de dados.

ˆ Entidade  é na maioria das vezes uma categoria de coisas ou pessoas

que representam uma origem ou destino das transações.

ˆ Fluxo de dados  podemos associar cada uxo de dados com um tubo

por onde passam pacotes de dados. É identicado por uma descrição do
seu conteúdo.

ˆ Processo  É a descrição da função a ser executada, o seu nome é sempre

no imperativo e o mais objetivo possível.

ˆ Depósito de Dados  é o local onde serão armazenadas as informações

(dados) processadas e de onde serão recuperadas quando necessárias.

 Não existe vitória sem sacrifício!  18

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Figure 3.1 

3.2.3 Dicionário de dados

O dicionário de dados é um repositório de dados sobre os dados do software.
Ele deverá conter a denição dos elementos que tornam o Modelo de Dados e o
Diagrama de Fluxo de Dados precisos, quais sejam :

ˆ Fluxos de dados ;

ˆ Depósitos de Dados/Entidades ;

ˆ Atributos.

Por exemplo, o elemento de dados pedido-cliente mostrado no DFD da gura

acima poderia ser denido da seguinte forma :

ˆ PEDIDO-CLIENTE = NOME-CLIENTE + NRO-CONTA + ENDEREÇO

+ 1ITEM-PEDIDO6

ˆ ITEM-PEDIDO = COD-PRODUTO + DESC-PRODUTO + QTD-PROD

+ PRECO

ˆ ENDERECO = TIPO-LOGRADO + LOGRADOURO + NRO-LOGRADO

+ (COMPLEMENTO) +BAIRRO + CIDADE + UF + CEP + (TELE-
FONE)

ˆ TIPO-LOGRADO = [ RUA | AVENIDA | PRACA | TRAVESSA ]

Regras para a formação de nomes dos uxos de dados :

 O nome deve ser formado por palavras separadas por sublinha com até
32 caracteres.
 Preferencialmente os nomes devem ser efetuados de acordo com o usuário.
 Devem ser eliminados as proposições e conjunções.
 Quando houver a necessidade de abreviar uma palavra, que seja uma
abreviatura clara.

 Não existe vitória sem sacrifício!  19

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Simbologia utilizada no Dicionário de Dados :

Símbolo Signicado
= É composto de

+ E

[ ] Escolha uma das opções alternativas

Interações de

( ) Opcional (pode estar presente ou ausente)

| Separa as opções alternativas na construção [ ]

* * Comentário

@ Identicador (campo chave) de um depósito de dados

3.2.4 Diagrama de Entidade-Relacionamento (DER)

Também conhecido como Modelo de Dados. Ele enfatiza os principais obje-
tos, ou entidades com o que o sistema lida, bem como a relação entre os objetos.
Os objetos normalmente correspondem, um a um, aos locais de armazenagem
de dados mostrados no DFD, mas o DFD não informa sobre as relações entre
os objetos. Mostra uma visão estática das informações (entidades) de interesse
e dos vínculos (relacionamentos) existentes entre elas.

Os componentes do DER são : Entidade, Atributo, Chave de identicação,

Lista de entidades, Domínio e Ocorrência.

1. Entidade é algo real ou abstrato, percebido no ambiente e sobre o qual

nos interessa armazenar dados.

2. Atributo é um dos itens de dados que armazenamos sobre uma entidade,

caracteriza ou qualica uma determinada propriedade de uma entidade.

3. Chave de Identicação de uma entidade é denida por um atributo, ou

conjunto de atributos, cujos valores individualizam uma única ocorrência
dessa entidade.
Tipos de chaves :
ˆ chaves candidatas  são as possíveis chaves de identicação de uma
única ocorrência na entidade.

ˆ Chave primária  é uma das chaves candidatas, selecionada por

melhor conveniência (facilidade de uso, menor possibilidade de erro,
etc...).

Exemplo
ˆ EMPREGADO(MATRICULA, NOME-EMPR, CPF-EMPR, COD-DEPTO)

ˆ DEPARTAMENTO(COD-DEPTO, NOME-DEPTO)

Lista de Entidades é uma relação de entidades com seus respectivos atri-

butos, utilizada para documentar os trabalhos de análise de dados. É formada
pelo nome da entidade seguida da relação de atributos que compõem entre pa-
rêntesis e seguindo a seguinte convenção :

 Não existe vitória sem sacrifício!  20

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

ˆ Cada atributo é separado do outro pelo sinal de adição (+).

ˆ O(s) atributo(s) que identicam a entidade devem estar no início da rela-

ção e sublinhados.

ˆ O(s) atributo(s) que ocorrem mais de uma vez (repetitivos) são identi-
cados por uma inclusão entre parêntesis.

Exemplo
ˆ CLIENTE(COD-CLIENTE + NOME-CLIENTE + END-CLIENTE +
(FONE-CLIENTE) + CPF-CLIENTE )
Domínio são os possíveis valores que um atributo pode assumir.

Exemplo
ˆ SEXO = [ M | F ]

Ocorrência representa o número de vezes que um determinado atributo apa-

rece em outra entidade.
Símbolos especiais colocados nas extremidades de uma linha que representa
o relacionamento.Exemplo :

Figure 3.2  O diagrama DER também enfatiza três relações

ˆ Empregados pertencem a departamentos ;

ˆ Empregados são atribuídos a projetos ;

ˆ Departamentos iniciam projetos.

3.2.5 Diagrama de Transição de Estado (DTE)

É usado para modelar o comportamento de transição de estado, é uma fer-
ramenta de modelagem para descrever o comportamento de sistemas de tempo

 Não existe vitória sem sacrifício!  21

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Figure 3.3 

real e a parte de interface humana de muitos sistemas online. Cada estado repre-
senta o período de tempo durante o qual o sistema tem algum comportamento
observável ; as setas conectando cada quadro retangular mostra a mudança de
estado, ou transições de um estado para outro. Associadas a cada mudança de
estado estão uma ou mais condições (os eventos ou circunstancias que causam
a mudança de estado), e zero ou mais ações (a resposta, ou saída, ou atividade
que ocupa parte da mudança de estado).

As etapas de construção de um DTE, podem ser seguidas dos seguintes

modos :

ˆ Começar pela identicação de todos os estados possíveis do sistema, re-

presentando

ˆ cada um deles como um retângulo. Em seguida, achar todas as conexões

signicativas (mudança de estado) entre os retângulos.

ˆ Começar pelo estado inicial, continuando metodicamente seu caminho

para o(s) estado(s) seguinte(s). depois do(s) estado(s) secundário(s) para
o(s) terciário(s).

ˆ Após ter elaborado o DTE, devemos vericar a consistência do mesmo,

respondendo :

ˆ Foram denidos todos os estados ?

ˆ Todos os estados foram atingidos ? Algum estado foi denido sem que haja
caminhos que levem a ele ?

ˆ Todos os estados tem saída ?

ˆ Em cada estado, o sistema reage adequadamente a todas as condições

possíveis ? Este é o erro mais comum, é esquecido de especicar o com-
portamento do sistema em condições inesperadas.

3.2.6 Especicação de Processos

Sua nalidade é permitir que o analista de sistemas descreva, rigorosa e pre-
cisamente, a política representada por cada um dos processos atômicos de baixo
nível nos diagramas de uxo de dados de baixo-nível.

 Não existe vitória sem sacrifício!  22

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

Uma das maneiras de descrever a especicação de processos é utilizar o

português estruturado, mas existem outras como Tabela de decisão e Árvore
de decisão. O português estruturado, utilizado na especicação de processos
consiste apenas no seguinte :

ˆ Um grupo limitado de verbos de ação, como calcular e validar  um grupo

de mais ou menos 40 verbos ;

ˆ Estruturas de controle tiradas da programação estruturada para descrever

ações alternativas e repetitivas, como : Se-então-caso contrario , Faça-
enquanto e Repitaenquanto ;

ˆ Nomes que foram denidos no dicionário de dados ou que estão denidos

dentro da própria especicação de processo.

Exemplo, especicação para um processo :

Executa Cobrança
1. Se o valor da fatura vezes o número de semana em atraso for maior que
1000,00 u.m Faça :

a) Chamar o Cliente ;
b) Examinar o Cliente em duas semanas ;
c) Incrementar Contador de notas em atraso em um ;
2. Caso contrário Se menos de quatro notas de atraso foram enviadas, Faça :

a) Chamar o Cliente ;
b) Examinar a fatura em uma semana ;
c) Incrementar Contador de notas em atraso em um ;
3. Caso contrário :

a) Enviar ao Cliente uma cópia da fatura contendo o número de semanas

e atraso ;

b) Examinar a fatura em uma semana ;

Para desenvolver, pode-se seguir :

ˆ Escolha uma ou mais implementações lingüísticas para cada uma das

construções básicas. Voce deveria car com a fraseologia usada nesta
seção ou desenvolver uma própria.

ˆ Use as palavras e frases-chave de suas implementações para compor uma

lista de palavras reservadas.

ˆ Acrescente à sua lista palavras novas que são necessárias à descrição de

condições, relacionamentos, etc..., quando for detectada a necessidade
delas.

ˆ Ao escrever descrições de programas de ação, restrinja-se ao uso das pala-

vras em sua lista reservada, termos do Dicionário de dados, e verbos no
imperativo.

Utilizando estes recursos para a descrição do programa de ação, o processo será

escrito em português estruturado.

 Não existe vitória sem sacrifício!  23

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

3.3 Projeto Estruturado

Talvez o ponto mais importante a entender seja que o projeto estruturado
não é apenas programação modular, ou projeto modular, como foi chamado
inicialmente, e nem apenas um projeto top-down. O projeto estruturado pode
ser denido como a determinação de quais módulos, interconectados de que
forma, melhor solucionarão algum problema bem denido. O projeto estruturado
insiste numa denição de módulo simples, como sendo um grupo de comandos
de programa contíguos e ligados, possuindo um único identicador (nome) pelo
qual ele pode ser referenciado como uma unidade. Os componentes do projeto
estruturado são :

ˆ Técnicas de documentação ;

ˆ Critérios de avaliação de projeto ;

ˆ Heurísticas de projeto ;

ˆ Estratégias de projeto.

3.4 Programação Estruturada

A programação estruturada foi a primeira das técnicas estruturadas a ser
discutida e praticada amplamente. Para muitas pessoas, o termo programação
estruturada é genérico e inclui losoas de projeto, estratégias de implementa-
ção, conceitos de organização de programas, e as virtudes básicas de prospe-
ridade, lealdade e bravura. Para as nalidades desta discussão, no entanto, a
programação estruturada deve ser pensada como uma técnica de codicação e
só deve ser discutida no contexto da programação.

A teoria por trás da programação estruturada é relativamente simples : ela

diz que qualquer lógica de programa pode ser construída pelas combinações das
três estruturas : seqüência, decisão e repetição. Na maioria das linguagens de
programação de alto nível isto signica que os programas de computador podem
ser construídos com as seguintes combinações :

ˆ Comandos imperativos simples, como : leia, calcule, escreva e comandos

algébricos ;

ˆ Comandos para a tomada de decisão, como : se e caso ;

ˆ Comandos de repetição ou iteração, como : repita até que ou faça en-

quanto.

O ponto principal é que este conjunto de construções é suciente para formar

todo e qualquer tipo de lógica de programa ; e em particular, não é necessário
usar os comandos de desvio em programação estruturada.

3.5 Desenvolvimento Top-down

Em muitos casos, por motivos históricos, o desenvolvimento top-down é
confundido com projeto top-down, mas estamos pensando em implementação
top-down. Três aspectos topdown estão relacionados, mas distintos, da seguinte
forma :

 Não existe vitória sem sacrifício!  24

MCSI 1/UnikiviIP Uige II° Ano EI/23-24 Docente Dk Mavambu

ˆ Projeto top-down é uma estratégia de projeto que divide problemas grandes

e complexos em problemas menores e mais simples, facilmente solucioná-
veis ;

ˆ Codicação top-down é uma estratégia para se codicar módulos de alto-

nível, antes que os módulos detalhados de nível mais baixo ;

ˆ Implementação top-down é uma estratégia para testar os módulos de alto-

nível de um sistema antes que os módulos de baixo nível tenham sido
codicados e possivelmente, até antes que tenham sido projetados.

O desenvolvimento top-down consiste em desenvolver inicialmente uma versão

inicial com todos os módulos de alto-nível do sistema. As versões subsequentes
simplesmente envolvem o acréscimo de módulos de nível mais baixo ao esqueleto
já existente dos módulos de alto-nível, até que uma versão nal produz a saída
satisfatória ao usuário.

3.6 Equipes de Programação

Outro aspecto do método de desenvolvimento de sistemas estruturados é o
conceito de equipes de programação, em particular, as equipes de programador-
chefe e equipes abertas. O conceito de equipe de programador-chefe é baseada
na liderança, na capacidade técnica e na experiência de uma pessoa para co-
mandar o desenvolvimento de um sistema por uma equipe.

O conceito de equipe aberta é baseada na teoria da participação de toda a

equipe na solução dos problemas sem a supervisão direta de qualquer um.

3.7 Revisões Estruturadas

Uma revisão estruturada é um procedimento organizado para que um grupo
de examinadores (analistas de sistemas, programadores, etc) revisem um pro-
duto técnico para ns de correção e garantia de qualidade.

As revisões podem ocorrer em uma série de estágios num projeto típico de

desenvolvimento de sistemas. A ênfase tem sido na revisão do código, mas o
conceito se aplica também às revisões de projetos e especicações.

O método de revisões estruturadas é conduzida por membros de uma equipe,

são quase sempre caracterizadas por um ambiente informal e aberto ; permite
revisões rápidas e ecientes da precisão técnica da especicação, projeto e có-
digo para o sistema.

 Não existe vitória sem sacrifício!  25

 REFERÊNCIAS BIBLIOGRÂFICAS

1. A. Heuser, Carlos , Projeto de Banco de Dados.

https ://www.cin.ufpe.br/ jrsl/Books/Projeto %20de%20Banco%20de%20Dados%20−
%20C.%20A.%20Heuser.pdf.
2. Jean Luc Baptiste, MERISE Guide Pratique, Modelisation des données
et des traitements, langage SQL, edição ENI.

3. PRESMANN, R. Engenharia de Software : uma abordagem prossional.

7. ed. Rio de Janeiro : Mc Graw Hill, 2011.

4. SOMMERVILLE, I. Engenharia de Software. 8. ed. Rio de Janeiro : Pear-

son, 2007.

5. Dankatu, Mavambu. Notas de Aula. ISP/Mb-Ng. Inédito, 2009.

26