Técnico em Informática

Projeto de Desenvolvimento
de Software

Maicon Herverton Lino Ferreira da Silva

2015
Presidenta da República Governador do Estado de Pernambuco
Dilma Vana Rousseff Paulo Henrique Saraiva Câmara

Vice-presidente da República Vice-governador

Michel Temer Raul Jean Louis Henry Júnior

Ministro da Educação Secretário de Educação

Cid Ferreira Gomes Frederico da Costa Amancio

Secretário de Educação Profissional e Secretário Executivo de Educação Profissional

Tecnológica Paulo Fernando de Vasconcelos Dutra
Aléssio Trindade de Barros
Gerente Geral de Educação Profissional
Diretor de Integração das Redes Josefa Rita de Cássia Lima Serafim
Marcelo Machado Feres
Coordenador de Educação a Distância
Coordenação Geral de Fortalecimento George Bento Catunda
Carlos Artur de Carvalho Arêas

Coordenador Rede e-Tec Brasil

Cleanto César Gonçalves

Coordenação do Curso
João Ferreira

Coordenação de Design Instrucional

Diogo Galvão

Revisão de Língua Portuguesa

Letícia Garcia

Diagramação
Izabela Cavalcanti
Sumário
INTRODUÇÃO .......................................................................................................................3
1.COMPETÊNCIA 01 | INTRODUÇÃO A PROJETO DE SOFTWARE ...........................................4
1.1 Conceitos envolvidos em um projeto .................................................................. 8
1.2 Levantamento de Requisitos .............................................................................. 9
1.2.1 Estudo de caso .............................................................................................. 12
1.3 Projeto de Arquitetura ..................................................................................... 13
1.3.1 Estudo de caso .............................................................................................. 16
1.4 Atividades de Fixação ....................................................................................... 17
2.COMPETÊNCIA 2 | PROJETO DE FLUXO DE DADOS E QUALIDADE DE SOFTWARE ............18
2.1 Projeto de fluxo de dados ................................................................................. 18
2.1.1 Estudo de caso .............................................................................................. 21
2.2 Introdução a qualidade em um projeto de software ......................................... 23
2.3 Atividades de fixação........................................................................................ 26
CONCLUSÃO .......................................................................................................................27
REFERÊNCIAS .....................................................................................................................28
GABARITO DAS ATIVIDADES COMPLEMENTARES E DE APRENDIZAGEM ............................. 29
MINICURRÍCULO DO PROFESSOR .......................................................................................30
 INTRODUÇÃO

Caros (as) alunos (as),

Nesta disciplina iremos falar um pouco sobre a arte do desenvolvimento de

projetos de software com um mínimo de qualidade garantida. Vocês já devem
estar mais do que experts no desenvolvimento de um sistema, mas será que
estão mesmo preparados para apresentar esse sistema a um cliente ou
mesmo estruturar o desenvolvimento de um sistema maior, com uma equipe
grande? Descobriremos em breve!

Durante esta disciplina vocês terão duas competências: a primeira tratará um

pouco sobre o que é um projeto de software e como organizar o seu projeto,
selecionando as melhores técnicas para levantamento de requisitos (vocês
sabem o que é isso?! Vão saber em breve!) e a melhor forma de organizar seu
projeto. Na segunda serão abordados conceitos de fluxo de dados e qualidade
de software.

Após o fim desta disciplina, vocês serão capazes de garantir o

desenvolvimento de um software com certo grau de qualidade, satisfazendo
você, sua equipe e o seu cliente.

3
Projeto de Desenvolvimento de Software
Competência 01

1.COMPETÊNCIA 01 | INTRODUÇÃO A PROJETO DE SOFTWARE

Olá, tudo bem? Estamos aqui, em mais uma disciplina, falando um pouco
sobre o desenvolvimento de um software. Depois de tudo que vocês
aprenderam, se acham capazes de tentar resolver o problema de uma pessoa
desenvolvendo um software para ela?

Desenvolver um software é muito mais do que simplesmente codificar uma

ideia e apresentá-la ao cliente. Um dos problemas mais comuns, ao se
desenvolver um software seguindo este modelo, é a manutenção.

Imagine que você faça um software hoje, apresente ao cliente e o implante.

Após quatro anos, o cliente vem falar com você que o modelo de negócios
dele mudou completamente e ele precisa atualizar o sistema que você
desenvolveu. Ao abrir o sistema, você percebe que, após quatro anos, não se
lembra de como as coisas funcionam ou foram feitas ali. Você tem que passar
um bom tempo relembrando o código, descobrindo como ele funciona e o
que ele faz ao certo, de forma que possa começar a alterá-lo.

Agora imagine que você desenvolve um sistema inovador, algo que ninguém
nunca tinha pensado antes e você vende essa ideia por um bom dinheiro,
usando esse dinheiro para montar sua própria companhia de
desenvolvimento de software. Você começa a contratar mais funcionários
para trabalhar no seu software e, a cada novo funcionário, você precisa
explicar pessoalmente como o sistema funciona.

Esse tipo de desenvolvimento direto torna-se rápido e prático em curto prazo,

mas é um problema enorme quando se trabalha em longo prazo. Um bom
projeto de software pode ajudar a resolver todos esses problemas. Um
projeto bem realizado também garante que uma sequência de passos seja
seguida, garantindo um mínimo de qualidade no produto final: o software.

Antes de desenvolver um sistema, de codificá-lo, um projeto de software deve

4
Técnico em Informática
 Competência 01

ser criado. Esse projeto deve conter todas as etapas e esclarecer todas as
dúvidas para que a implantação do software seja concisa e sem erros. Nesse
projeto estarão todas as direções a serem seguidas pelos programadores,
auxiliando no processo de desenvolvimento do sistema.

Ao se desenvolver um projeto, deve ser levado em consideração o problema a

ser resolvido, ou seja, o porquê desse projeto estar sendo desenvolvido. Essa
questão deve ser levantada com o cliente, que é a pessoa que mais sabe sobre
o problema, a pessoa que trouxe o problema para você resolver. Às vezes, o
próprio desenvolvedor faz o papel do cliente, quando ele desenvolve um
software de uso próprio ou com ideias próprias. O problema deve ser bem
detalhado e estar descrito de forma clara, para que os desenvolvedores
consigam desenvolver soluções para ele.

O papel do projetista é descrever processos que definam como o

desenvolvimento do sistema se dará. Esses processos precisam ser concisos,
simples e claros, de forma que todos os envolvidos possam compreendê-lo.
Um bom projeto contém todas as etapas do software, de forma que
modificações, manutenções e aprimoramentos possam ser feitos sem maiores
complicações. Ajuda também a entender melhor o motivo do software ter
sido criado, bem como para que ele serve.

Para desenvolver um projeto de software bem estruturado algumas etapas

devem ser seguidas: levantamento de requisitos com o cliente, modelar o
projeto de arquitetura, desenvolver um projeto de dados e criar um projeto
de interfaces (Pressman, 2002). Englobando todos esses processos, um ciclo
de projeto procedimental é utilizado, ou seja, você vai desenvolvendo o
software aos poucos, e a cada nova etapa que você desenvolve, a etapa
anterior é atualizada de alguma maneira. A tabela abaixo detalha um pouco
sobre cada passo:

5
Projeto de Desenvolvimento de Software
Competência 01

Etapas para o desenvolvimento de um projeto de software.

ETAPA DESCRIÇÃO
Nessa etapa o problema levantado pelo cliente deve ser
Levantamento de
compreendido. O problema deve ser descrito de forma que
Requisitos
qualquer pessoa que o leia possa entendê-lo.
Nessa etapa a arquitetura do sistema é elaborada, ou seja, é
Criação do Projeto de
descrito como o problema da etapa anterior vai ser
Arquitetura
solucionado pelo sistema.
Criação do Projeto de Nessa etapa um fluxo de dados do sistema é elaborado,
Dados utilizando a descrição dada na etapa anterior.
Fonte: O Autor.

É preciso muito cuidado com as etapas de desenvolvimento de um software,

desde sua concepção, onde há um acordo entre o cliente e a empresa. Muitas
coisas precisam ser levadas em consideração antes de você sentar e
realmente codificar o software solicitado.
Veja como é fácil
entender os
As etapas de desenvolvimento podem ser executadas em qualquer ordem, e problemas no
desenvolvimento
quantas vezes necessárias até que o problema que se deseja resolver esteja de um software,
assistindo a esse
solucionado. Uma forma de acelerar o processo é dividir o problema geral, ou vídeo que
seja, o software completo, em pequenos pedaços que podem ser selecionamos para
você:
desenvolvidos em paralelo. Lembre-se de que geralmente esse “pedaço” de www.youtube.com/
software deve ser funcional, ou seja, ter alguma funcionalidade instalada e watch?v=QPiR8jTM
LdI
que funcione.

Para isso, pode-se desenvolver um projeto para cada parte do

desenvolvimento, indicando sempre como ele se liga às outras partes
desenvolvidas. Imagine que você tem um software muito grande, contendo
uma área de cadastro de produtos, uma de cadastro de clientes e uma de
cadastro de fornecedores. Para ajudar no processo de criação do projeto,
você poderia dividir cada uma dessas áreas em um novo projeto. A Figura 1
exibe a ilustração das etapas do desenvolvimento de um projeto de software
utilizando UML no Astah Community.

6
Técnico em Informática
 Competência 01

Figura 1-Ilustração das etapas para o desenvolvimento de um projeto de software.

Fonte: O Autor.

Um projeto de software é um processo iterativo, começando com um nível de

abstração alto e diminuindo a cada ciclo, culminando em um produto
finalizado e pronto para ser entregue. Ao final de cada ciclo de
desenvolvimento, você poderia muito bem entregar uma nova área do
software, primeiro a área de controle de estoque, depois a área de controle
de clientes e ao final a área de controle de fornecedores. Ao fim do projeto
deve ser possível:

 Listar e compreender exatamente o que o cliente precisa;

 Ser um guia legível e compreensível do que foi codificado;
 Identificar todos os elementos envolvidos no software: aspectos
funcionais, interface, dados, implantação.

7
Projeto de Desenvolvimento de Software
Competência 01

1.1 Conceitos envolvidos em um projeto

Alguns conceitos vão ser aplicados nessa disciplina e serão listados aqui.
Utilize-os como um guia de referência, caso não entenda algum ponto deste
caderno volte aqui e procure por ele.

Os conceitos estão divididos em Papéis e Conceitos de Projetos. Os papéis

definem qual posição as pessoas podem ter dentro do projeto de software.
Uma mesma pessoa pode exercer vários papéis em um mesmo projeto de
software. Os conceitos de projetos definem alguns conceitos que vão ser
encontrados durante a descrição de um projeto (Rocha et al., 2001).

 Cliente

Pessoa responsável por entender sobre o Problema a

ser tratado. É aquela pessoa que tem um domínio
completo sobre o Problema. Muitas vezes não sabe
expressar esse domínio muito bem, então cabe ao
Projetista extrair as informações necessárias.

 Projetista

Pessoa responsável por descrever as informações

iniciais coletadas com o Cliente e desenvolver um
projeto a ser seguido de como resolver o Problema.
Esse projeto deve conter todas as diretrizes de
desenvolvimento, a serem seguidas pelos
Programadores.

 Programador

Pessoa responsável por codificar o software, seguindo

as diretrizes desenvolvidas pelo Projetista.

8
Técnico em Informática
 Competência 01
 Problema

Processo a ser automatizado ou resolvido através do

sistema proposto. O Problema deve ser descrito de
forma que qualquer pessoa que leia o compreenda.

 Requisitos

Os requisitos são escritos pelo Projetista e definem o

que o sistema deve ser capaz de fazer. Cada Requisito
deve ser parte da solução para o Problema.

1.2 Levantamento de Requisitos

Essa é a primeira etapa a ser realizada pelo Projetista. É a mais importante,

pois todas as outras dependem dela. É nessa etapa que o Projetista deve
entender o Problema, extraindo as informações do Cliente, e descrevendo-as
para o Programador. Ao fim dessa etapa, um documento contendo as
Funcionalidades do sistema deve ser criado. Contudo, o estudo do
levantamento de requisitos é bastante abrangente, assim mostraremos
apenas o que será necessário, no geral, para o seu projeto de software.

Veja um pouco mais sobre o levantamento de requisitos no vídeo que

separamos para você: http://www.youtube.com/watch?v=Qg1ew72GAcYA
Esta etapa começa com o levantamento dos Requisitos do sistema. Um
Requisito é um problema passado pelo Cliente a ser resolvido pelo sistema.
Os Requisitos devem ser descritos pelo Projetista de forma que seja de fácil
entendimento, mas sem perder nenhum detalhe do que o Cliente deseja.

Um dos principais problemas na hora de se levantar os Requisitos é conseguir

fazer com que o Cliente consiga descrever bem o Problema. Em muitos casos,
o Cliente conhece muito do domínio do problema, mas não consegue
repassar essa informação de forma clara e concisa. Para tanto, algumas
técnicas podem ser utilizadas: Entrevista, Brainstorm, Questionário e

9
Projeto de Desenvolvimento de Software
Competência 01

Observação.

Entrevistas: A entrevista é uma das técnicas tradicionais mais simples de

utilizar e que produz bons resultados na fase inicial de obtenção de dados.
Convém que o entrevistador dê espaço ao entrevistado para esclarecer as
suas necessidades. É uma discussão do projeto desejado com diferentes
grupos de pessoas.

PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS

1. É a técnica mais comum, de 1. Pode consumir muito tempo no

conhecimento geral de todos, processo de entrevista.
podendo ser realizada
rapidamente. 2. Podem ocorrer desvios do foco no
decorrer da entrevista.
2. Pode alterar o foco da
entrevista, de acordo com as 3. É necessário ter um plano para a
dúvidas do Projetista. realização da entrevista, o que pode
consumir certo tempo para
3. Podem-se preparar perguntas preparação.
chaves antes da entrevista.
4. Algumas pessoas têm dificuldade de
4. Podem-se incluir perguntas concentração em reuniões muito
que não estavam presentes na longas.
programação planejada.
5. As perguntas podem não ser
respondidas de forma satisfatória.

Tabela 1-Técnica de levantamento de requisitos: Entrevistas

Fonte: O autor.

BrainStorming: Técnica a ser realizada em grupo. Um grupo de Clientes

levanta vários problemas a serem resolvidos, com suas próprias palavras.
Todos os problemas são listados em um único local. O Projetista faz perguntas
sobre os problemas levantados, de forma a descrevê-los e detalhá-los. Os
Clientes, então, aprovam os detalhes descritos pelo Projetista.

10
Técnico em Informática
 Competência 01

PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS

1. Várias pessoas pensando 1. Sem um controle, a reunião pode

podem descrever melhor o fugir totalmente do foco.
projeto.
2. Os problemas levantados podem não
2. Generaliza a participação dos contemplar o problema geral.
membros do grupo.
3. Os participantes podem ficar presos
3. Podem-se coletar em detalhes de pouca importância.
informações mais variadas
sobre o mesmo problema, o
que pode ajudar na sua
descrição.

Tabela 2-Técnica de levantamento de requisitos: Brainstorming.

Fonte: O autor.

Questionário: Essa técnica se torna interessante quando o Projetista possui

certa experiência na área do Problema. Uma coleção de questões deve ser
planejada pelo Projetista e entregue ao Cliente, que deve respondê-las sem a
presença do Projetista. A partir das respostas obtidas, o Projetista elabora os
Requisitos do sistema.

PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS

1. Possui um menor custo de 1. Não há garantia sobre as respostas

tempo, já que o Cliente pode do questionário estarem claras.
responder quando achar 2. As perguntas, às vezes, podem ter
necessário. significados diferentes para cada
2. Questões padronizadas pessoa que as leia.
garantem uniformidade no
processo.

Tabela 3- Técnica de levantamento de requisitos: Questionário.

Fonte: O autor.

Observação: Essa técnica se dá quando o Projetista passa a observar, ele

próprio, o dia a dia e, com isso, visualiza os processos envolvidos no

11
Projeto de Desenvolvimento de Software
Competência 01

Problema. O Projetista extrai todos os detalhes dessa observação.

PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS

1. Capaz de capturar o 1. Visão polarizada pelo observador.

comportamento natural do 2. O problema pode alterar sua
Problema. natureza pelo fato da presença do
2. Não atrapalha os envolvidos no observador.
Problema. 3. O Observador pode não captar todo
3. Confiável, já que o próprio o Problema, observando-o
Projetista extrai os dados parcialmente.
necessários.

Tabela 4- Técnica de levantamento de requisitos: Observação.

Fonte: O autor.

Após fazer o detalhamento do Problema, o Projetista deve realizar a escrita

dos Requisitos do sistema. Cada Requisito deve descrever uma parte do
problema, que deve ser solucionado pelo sistema proposto.

1.2.1 Estudo de caso

Imagine que um dia desses um Cliente apareceu na Agência de

Desenvolvimento de Software – ADS, em busca de uma solução para um
problema em sua empresa. Ao ser atendido, o Projetista começa afazer
algumas perguntas sobre esse problema. Para o Projetista, a técnica de
Entrevista foi escolhida para fazer o levantamento dos requisitos do sistema.

Após a conversa, o Projetista faz um resumo de como o sistema deve se

comportar:

“O sistema requerido é um sistema para controle de estoque. Através desse

sistema, um funcionário poderá controlar todo o estoque de sua empresa,
adicionando, removendo ou alterando qualquer produto. Um usuário poderá
também fazer um relatório dos produtos no sistema.”

12
Técnico em Informática
 Competência 01

Utilizando esse resumo como base, o Projetista detalha todos os requisitos do

sistema:

REQUISITO #1 INSERIR PRODUTOS

Um funcionário terá acesso a um formulário de cadastro de um novo
Descrição:
produto. Ao preenchê-lo, o novo produto será inserido no sistema.
Restrições:

REQUISITO #2 REMOVER PRODUTOS

Um funcionário poderá excluir um produto, passando o código de cadastro
Descrição:
desse produto.

Um usuário só poderá excluir um produto, caso ele esteja cadastrado no

Restrições:
sistema.

REQUISITO #3 LISTAR PRODUTOS

Descrição: Um funcionário poderá listar todos os produtos cadastrados no sistema.

Restrições:

REQUISITO #4 EDITAR PRODUTOS

Um produto pode ser escolhido para ser editado, alterando-se seus dados a
Descrição:
partir de um formulário.

Restrições: Um produto não pode ter seu id alterado.

Ao fim dessa etapa, todo o sistema deverá ser descrito no formato de

requisitos. Esses requisitos devem auxiliar o Projetista a planejar a arquitetura
e o fluxo de dados.

1.3 Projeto de Arquitetura

Nessa etapa, o Projetista deve planejar qual arquitetura o sistema proposto

deve seguir, baseado nos requisitos. A arquitetura de um sistema define como
ele irá se comportar, qual o recurso de hardware e software ele precisará ter
para ser implantado, além de definir suas restrições. Essa etapa deve contar

13
Projeto de Desenvolvimento de Software
Competência 01

com a ajuda da equipe de Programadores, já que está diretamente ligada à

codificação do sistema.

Ao fim dessa etapa, os seguintes tópicos devem ser esclarecidos:

 Determinar qual a linguagem de programação, plataforma e softwares

que serão utilizados para a implantação do sistema;
 Determinar o cronograma para o desenvolvimento;
 Selecionar a melhor arquitetura para o sistema proposto;
 Gerar protótipos de algumas funcionalidades;
 Fazer uma revisão nos requisitos, baseados nas escolhas realizadas nessa
etapa.

De acordo com a equipe de Programadores disponíveis para o

desenvolvimento do sistema, a determinação da linguagem de programação,
da plataforma e dos softwares que serão utilizados poderá ser afetada.
Devem ser levadas em consideração também, além da expertise da equipe, as
restrições do sistema proposto, definidas pelo Projetista na etapa de
Levantamento de Requisitos. Um sistema em tempo real poderá necessitar de
uma plataforma de desenvolvimento diferente, o que acarretará no
treinamento dos Programadores para tal plataforma, por exemplo.

Um cronograma deve ser criado baseado na quantidade de requisitos, o custo

estimado para o desenvolvimento de cada requisito, além do tempo
necessário para treinamento e adaptação da equipe. Um cronograma nunca é
exato, mas quanto mais detalhado, mais preciso ele será.

A arquitetura de desenvolvimento do sistema influencia diretamente em

todas as outras escolhas. De acordo com a necessidade de cada sistema, um
tipo diferente de arquitetura pode ser utilizado. Dentre as mais comuns,
temos:

14
Técnico em Informática
 Competência 01

 Arquitetura Centralizada

Nessa arquitetura, um sistema está completamente armazenado dentro de

um único computador. Esse enorme computador, muitas vezes chamado de
mainframes, possui um poder computacional imenso e funciona dentro de
uma empresa. Essa arquitetura é muito utilizada para sistemas de controle
empresarial enormes e complexos, controlando todos os processos de uma
grande corporação.

 Arquitetura Cliente-Servidor

Nessa arquitetura, um sistema está dividido em duas partes: um cliente e um

servidor. Cabe ao servidor todo o processamento pesado ou armazenamento
de dados e ao cliente acesso e pré-processamento/visualização desses dados.
É uma arquitetura muito utilizada hoje em dia, sendo padrão para websites e
sistemas web.

 Arquitetura baseada em Nuvem

Essa arquitetura pode ser descrita como uma arquitetura Centralizada em

larga escala. A ‘Nuvem’ é um conjunto de mainframes que podem ser
acessados através da internet, e possui um enorme poder de processamento
e armazenamento. Muitas vezes é utilizada em conjunto da arquitetura
Cliente-Servidor, onde a Nuvem faz o papel de Servidor.

Após a escolha da arquitetura, linguagens de programação e plataforma,

alguns protótipos podem ser planejados. Um protótipo tem um papel de ser
um teste da arquitetura, ou plataforma escolhida, verificando se a escolha foi
correta ou não. É uma pequena parte do sistema, de forma independente.

Após a definição de todos os elementos dessa etapa, os Requisitos podem ser

atualizados, para conter as restrições ou funcionalidades inerentes a cada
escolha realizada.

15
Projeto de Desenvolvimento de Software
Competência 01

1.3.1 Estudo de caso

Após o levantamento de requisitos, o Projetista da ASD define, junto com a

equipe de Programadores, o projeto de arquitetura do sistema. Após
conversarem e debaterem sobre o assunto, as seguintes escolhas foram
tomadas:

 O sistema seguirá uma arquitetura Cliente-Servidor. O Servidor ficará

responsável por armazenar os dados do sistema, centralizando-os. Cada
cliente será um ponto de acesso, contendo o sistema de acesso disponível ao
funcionário. É através dele que o funcionário poderá operar o sistema.

 Para o desenvolvimento do sistema a linguagem de programação

escolhida foi o PHP, a plataforma foi o Linux. O Servidor conterá o banco de
dados MySQL. Isso garantirá um custo menor na produção do sistema, e não
necessitará de treinamento extra para a equipe, visto que eles são fluentes
nas linguagens citadas.

 Um cronograma do projeto foi definido, especificando quanto tempo foi

destinado para o desenvolvimento de cada requisito. O cronograma é exibido
abaixo:

REQUISITO DURAÇÃO
Requisito #1 3 Dias
Requisito #2 3 Dias
Requisito #3 1 Dia
Requisito #4 1 Dia
TOTAL: 8 Dias
Tabela 5-Cronograma proposto para o projeto.
Fonte: O autor.

 O desenvolvimento de um protótipo para acesso aos dados no servidor foi

realizado. Esse protótipo auxiliou a equipe a escolher a linguagem e a
plataforma.

16
Técnico em Informática
 Competência 01

 Os requisitos foram atualizados para incluir um sistema de autenticação

do funcionário para cada tarefa. Nas restrições foram colocadas que o
funcionário só poderá realizar as atividades, caso esteja logado no sistema.

1.4 Atividades de Fixação

Você precisa desenvolver um software para uma padaria. A padaria é

pequena, possuindo apenas um funcionário (o dono do negócio). Você
escolhe a técnica de entrevista para conseguir levantar os requisitos do
problema, segue o resumo da entrevista:

“O sistema requerido é um sistema para uma padaria. Através desse sistema

um funcionário poderá controlar todas as vendas de pães e salgados da
padaria, adicionando, removendo ou alterando qualquer preço das
mercadorias vendidas. Um usuário poderá comprar a mercadoria da padaria.
Cabe ao funcionário cadastrar o cliente no sistema a fim de manter um
cadastro de fidelidade. Cada usuário possui um cartão de acesso, que deve ser
utilizado para as compras de mercadorias. Após dez compras com valor
superior a 10 reais, o usuário recebe até dez pães de gratuitos na próxima
compra”.

Levando em consideração o resumo acima responda as seguintes perguntas:

1) Por que a técnica de entrevista foi escolhida? Você consegue justificar a

escolha?

2) Monte um documento de requisitos para o problema descrito.

17
Projeto de Desenvolvimento de Software
Competência 02

2.COMPETÊNCIA 2 | PROJETO DE FLUXO DE DADOS E QUALIDADE

DE SOFTWARE

2.1 Projeto de fluxo de dados

O Projeto de Fluxo de Dados ajuda a entender melhor o funcionamento do

sistema em um nível baixo. Esse projeto utiliza os Requisitos criados no
levantamento de requisitos e as definições de arquitetura definidas no
Projeto de Arquitetura para criar um diagrama de fluxo de dados. Esse
diagrama auxilia a entender como o sistema funciona no nível de dados,
servindo como um guia para os programadores e para o Projetista. Essa é a
última etapa antes da etapa de implantação e deve ser realizada com muito
cuidado, visto que o diagrama de fluxo de dados descreve todo o
funcionamento do sistema.

Um diagrama de fluxo de dados ajuda a visualizar como o sistema receberá e

processará os dados, incluindo todo o caminho, direções e restrições
necessárias. A Figura 2 exibe uma ilustração básica de um diagrama de fluxo
de dados em sequência, através do uso de UML no Astah Community.

18
Técnico em Informática
 Competência 02

Figura 2-Ilustração de um diagrama de fluxo de dados em sequência.

Fonte: Wordpres,2014

19
Projeto de Desenvolvimento de Software
Competência 02

A leitura de um diagrama de fluxo de dados é direcionada por setas,

facilitando o entendimento. Existem alguns elementos presentes no diagrama
que precisam ser explicados:

 Entidade Externa: A entidade externa define uma

ação de um usuário ou fator externo ao sistema,
em inserir ou operar dados gerados pelo sistema.
Uma entidade externa precisa estar detalhada em
um diagrama de fluxo de dados, de forma a indicar
que o autor daquela ação não é contemplado pelo
sistema.

 Fluxo de Dados: A seta indicativa do fluxo de

dados auxilia a compreender a direção que os
dados estão tomando dentro do sistema.

 Processo: Um processo nada mais é do que a

representação de um Requisito em um fluxo de
dados. Cada processo recebe dados que podem vir
de outros processos, entidades externas ou
depósito de dados.

 Depósito de dados: Um depósito de dados

representa uma estrutura de armazenamento de
dados no sistema. Essa estrutura pode ser um
D1 banco de dados ou até mesmo um simples
arquivo de textos. Um sistema pode ter vários
depósitos de dados, independentes ou
dependentes entre si.

 Decisões: As decisões são utilizadas para

Decisões direcionar o fluxo de dados, de acordo com o
resultado de um processo. Na decisão sempre é

20
Técnico em Informática
 Competência 02

feita uma pergunta e deve ter duas respostas:

uma positiva e uma negativa.

Um bom diagrama de fluxo de dados deve ser claro, conciso e direto. Não
pode conter caminhos duplos, ou dúvidas no fluxo de processamento dos
dados. Após a criação do documento de requisitos, o diagrama de fluxo de
dados deve ser implantado pelo Projetista em conjunto com a equipe de
desenvolvimento. Para cada requisito definido pode ser criado um diagrama
de fluxo de dados, porém em alguns casos um só diagrama pode ser criado
para um grupo de requisitos ou mesmo para todo o sistema.

A disposição dos processos, do fluxo, das entidades externas e das bases de

dados deve ser feitas de acordo com o projeto de arquitetura, seguindo as
restrições de software e hardware impostas pela arquitetura escolhida.

Veja mais no site

Hoje em dia, diagrama de fluxo de dados ainda é utilizado, porém através da que separamos
para você:
UML surgiram outros diagramas que também são bastante utilizados em www.infoescola.co
grandes projetos de software, vale a pena conferir. m/engenharia-de-
software/uml/

2.1.1 Estudo de caso

Para o sistema de locadora definido neste estudo de caso, alguns diagramas

foram criados. Os diagramas para o Requisito 1: Controle de Livros são
exibidos a seguir.

Fluxo de dados para o Requisito 1: Cadastro de Produtos

Dados do ADICIONA Novo

OPERADOR D1 PRODUTO
PRODUTO
Produto Produto S

21
Projeto de Desenvolvimento de Software
Competência 02

Fluxo de dados para o Requisito 2: Remover Produto

Nome do
Nome do Produto
OPERADOR Produto D1 PRODUTOS
BUSCAR
Mensagem
de Erro Produto

SIM
NÃO
ENCONTROU REMOVER
PRODUTO ? PRODUTO

Fluxo de dados para o Requisito 3: Listar Produtos

Pedido Todos
Pedido Todos LISTAR
OPERADOR D1 PRODUTO
PRODUTO Produtos
Produtos S

Todos Produtos Todos Produtos

Fluxo de dados para o Requisito 4: Alterar Produto

Dados do Produto
Dados do Produto
OPERADOR BUSCAR D1 PRODUTOS
LIVRO

Produto

SIM
NÃO
ENCONTROU
REMOVER
ALTERAR
PRODUTO ? PRODUTO

22
Técnico em Informática
 Competência 02

2.2 Introdução a qualidade em um projeto de software

Ao desenvolver um projeto de software, uma das preocupações mais comuns

é sobre a qualidade do software projetado. Esse problema vem sendo
estudado e debatido há muito tempo, mas sempre esbarra na mesma
pergunta: “O que é um software de qualidade?”. Se eu perguntasse a você,
caro (a) aluno (a), com certeza você teria uma resposta para isso. Mas essa
resposta estaria correta? Quem garantiria a você, ou a mim, que a sua
resposta é a mais acertada? Ou a mais errada?

Quando se fala sobre qualidade de software uma enorme incógnita aparece.

Até hoje não existe um conceito único que possa definir o que é um software
de qualidade. Cada projetista, cliente ou desenvolvedor define qualidade
como algo diferente. Para uns, um software de qualidade é aquele que possui
tudo que o cliente pediu. Para outro, é aquele que possui tudo que o cliente
precisa. E notem que são duas coisas completamente diferentes. Outros ainda
definem que um software de qualidade é aquele que nunca vai dar um erro.
Esses são considerados sonhadores, por todos os outros.

Para resolver esse problema, uma série de empresas começou a criar e

descrever o que chamaram de modelos e normas de qualidade de software:
“Os modelos e normas de qualidade de software foram criados a fim de
atender plenamente os requisitos de qualidade, auxiliando na melhoria dos
processos internos e promovendo a normatização de produtos e serviços.”
(Maciel, 2011).

Os modelos e normas de qualidade de software definem um conjunto de

regras e normas a serem utilizadas durante o desenvolvimento do software
para tentar garantir a entrega do produto final, ou seja, para que o próprio
software seja entregue como esperado e ditado por essas regras.

Um exemplo claro disso é a Norma ISO/IEC 9126 que define qualidade de

software como: a totalidade de características de um produto de software

23
Projeto de Desenvolvimento de Software
Competência 02

que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas.

A ISO (Organização Internacional para Padronização, em português) é uma
entidade que estipula e organiza padrões de organização de várias naturezas
em 170 países. Dentre esses padrões, a ISO 12207 regula o desenvolvimento
de softwares.

A ISO 12207 direciona os processos e normas para garantir um mínimo de

qualidade durante todo o ciclo de vida do software. Entenda ciclo de vida
como todo o processo de planejamento, criação e utilização dos softwares,
até ele ser descartado. Essa norma foi publicada pela primeira vez em 1995 e
recebeu muitas atualizações em 2001.

A ISO 12207 oferece melhoria em vários processos, e cada processo está

dividido em três categorias: primário, de apoio e organizacional. Cada
processo descrito pela norma é composto por atividades, e cada atividade é
executada em um conjunto de tarefas. A tabela a seguir ilustra essa hierarquia
e define as atividades mais comuns.

TIPO PROCESSO ATIVIDADES

Definição da necessidade de adquirir o
software.
Aquisição Analisar o pedido de proposta.
Selecionar os fornecedores.
Gerenciar a aceitação do software.
Preparar uma proposta para o cliente.
Fornecimento Assinatura do contrato.
Determinar recursos.
Preparar o plano do projeto.
Processo Primário
Projeto de requisitos;
Projeto de fluxo de dados;
Desenvolvimento
Projeto de codificação;
Projeto de testes.
Operação Criação do Manual do Software

Criar canal de comunicação entre o cliente

Manutenção e o projetista.

24
Técnico em Informática
 Competência 02

Criação da documentação de todos os

Documentação
processos.
Processo de aplicação de procedimentos
Geração de administrativos, com a liberação, manipulação,
Configuração distribuição e modificação dos itens que
compõem o software.
Processo de verificação de todos os outros
Garantia de processos.
Apoio qualidade

Verificação Determina se os produtos de software finais

atendem todos os requisitos.
Determina se o produto de software final
Validação
atende ao uso proposto.
Revisão conjunta Define as atividades para avaliar as situações
de cada atividade.
Determina a aquisição dos requisitos,
Auditoria
planos e contratos de auditoria.

Gerência Gerencia cada processo.

Infraestrutura Estabelecer e manter a infraestrutura
necessária para os outros processos.
Estabelece, avalia, mede e controla a
Melhoria melhoria dos outros processos durante o
Processos
ciclo de vida do software.
Organizacionais Processo que prevê o treinamento,
Recursos Humanos recrutamento e manutenção de pessoal para os
outros processos.
Gerencia a vida dos ativos reutilizáveis, ou
Gestão de ativos seja, de todos os bens utilizados durante o
desenvolvimento dos softwares.
Tabela 6-Processos e atividades da ISSO 12207.
Fonte: PRESSMAN, 2002.

Ao seguir cada uma dessas atividades a ISO 12207 entrega uma garantia de
qualidade em todos os processos envolvidos durante o planejamento,
desenvolvimento e utilização do software. Cada atividade pode ser realizada
por uma equipe diferente, e a empresa que utilizá-las deve estar preparada
com profissionais qualificados.

25
Projeto de Desenvolvimento de Software
Competência 02

A utilização de normas como a ISO 12207 pode até garantir uma qualidade no
produto final, mas vários fatores devem ser levados em consideração antes de
aplica-las: a empresa realmente pode gastar com material, treinamento e
mão de obra para obter a ISO 12207? O tamanho do projeto que você está
desenvolvendo comporta uma estrutura de processos desse porte? Às vezes,
a sua própria definição de qualidade acaba sendo a melhor escolha, então,
antes de começar a desenvolver seu software, pense um bocado sobre essa
questão.

2.3 Atividades de fixação

1) Levando em consideração o documento de requisitos realizado no

exercício anterior, crie um diagrama de fluxo de dados para cada requisito.

2) Quais atividades dos processos primários poderão ser utilizadas nesse

projeto? E por quê?

26
Técnico em Informática
 CONCLUSÃO

O que acharam da nossa disciplina?

Bom, o que vimos é apenas o começo do universo da engenharia de software

e das contribuições que ela traz para o desenvolvimento e projeto de
software, sem ela os projetos não teriam a qualidade que hoje já conseguimos
atingir, e não esqueça, as técnicas aprendidas já foram aplicadas por alguém e
validadas academicamente e no mercado de trabalho, então, basta entende-
las e aplica-las ao seu projeto de software para que seu trabalho se torne um
produto de software profissional e de fácil manutenção.

27
Projeto de Desenvolvimento de Software
REFERÊNCIAS

PRESSMAN, Roger S. Engenharia de Software. Tradução da 5a edição, Mc

Graw Hill, 2002.

ROCHA, Ana Regina C., MALDONADO, José Carlos e WEBER, Kival Chaves.
Qualidade de Software: Teoria e Prática, São Paulo: Prentice Hall, 2001.

WIKIPÉDIA. Diagrama de Fluxo de Dados. Disponível em: https://pt.wikipe

dia.org/wiki/Diagrama_de_fluxo_de_dados. Acesso em: 10 out. 2013.

MACIEL, Ana Carla Fernandes., VALLS, Carmen e SAVOINE, Márcia Maria.

Análise Da Qualidade de Software Utilizando as Normas 12207, 15504, ISSO
9000-3 e os Modelos CMM/CMMI e MPS.BR. São Paulo: ITPAC, 2011.

BARROS, Pablo V. Caderno de Projeto de Software. SEEP-EaD. 2011.

WORDPRESS, Diagrama de Sequência. Disponível em: https://engenhariasoft

ware.files.wordpress.com/2013/05/diagrama-de-sequencia1.png. Acesso em:
10 fev. 2015.

28
Técnico em Informática
 GABARITO DAS ATIVIDADES COMPLEMENTARES E DE APRENDIZA-
GEM

Aqui devem constar os gabaritos das atividades de aprendizagem propostas

ao longo do caderno (quando houver), assim como de alguma atividade
complementar proposta pelo professor, caso ele tenha utilizado tal recurso.

Competência 1:

1) Por que a técnica de entrevista foi escolhida? Você consegue justificar a

escolha?

R - Por se tratar de um software de pequeno porte, e a descrição do problema

ser insuficiente para construirmos o software, utilizamos a entrevista para que
possamos levantar as funcionalidades que provavelmente irão compor o
sistema, com a entrevista fica mais fácil decidir e ao mesmo tempo explicar
para o cliente se é possível desenvolver o software do jeito que ele está
definindo, podemos aproveitar esse momento para norteá-lo para o melhor
caminho a ser tomado dentro das expectativas dele sobre o software

2) O documento de requisitos poderia ser da seguinte forma:

Competência 2:

1) Os diagramas de fluxo de dados devem ser feitos para todos os requisitos

nesse modelo:

2) Todos, pois um sistema por menor que seja precisará ter no mínimo o
processo de aquisição completo para que seja considerado um sistema
documentado e com processo bem definido.

29
Projeto de Desenvolvimento de Software
MINICURRÍCULO DO PROFESSOR

Maicon Herverton Lino Ferreira da Silva é formado em Sistemas de

Informação pela Universidade Federal Rural de Pernambuco. Possui mestrado
em Ciências da Computação, com ênfase em qualidade de software pela
Universidade Federal Rural de Pernambuco. Atualmente, é professor na
Faculdade Escritor Osman Lins e Sócio-Diretor da LIFE Soluções em tecnologia.

30
Técnico em Informática