Page 1
SISTEMA DE ENSINO PRESENCIAL CONECTADO
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ARIVELTON BRANDÃO CURCINO
CLEBER RAMOS SARDINHA
MARCELO AGUIAR MARTINS
RUY GUIMARÃES DE OLIVEIRA
WANCLEY RIBEIRO DE MORAIS
WELITON SANTOS SOUZA JÚNIOR
PRODUÇÃO TEXTUAL INTERDISCIPLINAR EM GRUPO
Itapetinga
2015
Page 2
ARIVELTON BRANDÃO CURCINO
CLEBER RAMOS SARDINHA
MARCELO AGUIAR MARTINS
RUY GUIMARÃES DE OLIVEIRA
WANCLEY RIBEIRO DE MORAIS
WELITON SANTOS SOUZA JÚNIOR
PRODUÇÃO TEXTUAL INTERDISCIPLINAR EM GRUPO
Trabalho apresentado no Curso Análise de
Desenvolvimento de Sistemas da UNOPAR -
Universidade Norte do Paraná, para a disciplina
Interdisciplinar do 6º Semestre aos professores Prof.
Paulo K. Nishitani (Fundamentos de Redes de
Computadores), Anderson E. M. Gonçalves (Tópicos
Avançados em Desenvolvimento de Sistemas) e Merris
Mozer (Gestão do Conhecimento).
Itapetinga
2015
Page 3
SUMÁRIO
1 INTRODUÇÃO..................................................................................................3
2 OBJETIVO........................................................................................................4
3 ESPECIFICAÇÃO TÉCNICA DE SOFTWARE.................................................5
3.1 O que é um documento de especificação técnica.............................................5
3.2 Descrição das partes de uma especificação técnica........................................6
3.2.1 Capa..............................................................................................................6
3.2.2 Histórico de revisões.....................................................................................6
3.2.3 Índice.............................................................................................................6
3.2.4 Introdução......................................................................................................6
3.2.5 Público-alvo...................................................................................................6
3.2.6 Escopo do sistema........................................................................................7
3.2.7 Definições, Acrônimos e Abreviações...........................................................7
3.2.8 Prototipação..................................................................................................7
3.2.9 Requisitos funcionais.....................................................................................7
3.2.10 Requisitos não funcionais..............................................................................8
3.2.11 Casos de uso.................................................................................................8
3.2.12 Referências da especificação........................................................................8
3.3 Modelo de especificação técnica de software...................................................8
4 Pesquisa estrutural do sistema.......................................................................26
4.1 Custo com pessoal..........................................................................................26
4.2 Custo com equipamento.................................................................................27
5 Gestão do conhecimento pelos membros da equipe......................................28
5.1 Meios utilizados...............................................................................................28
5.1.1 Socialização................................................................................................28
5.1.2 Externalização.............................................................................................28
5.1.3 Combinação................................................................................................28
5.1.4 Internalização..............................................................................................29
5.2 Capital intelectual da equipe...........................................................................29
6 CONCLUSÃO.................................................................................................30
REFERÊNCIAS.........................................................................................................31
Page 4
1 INTRODUÇÃO
No presente trabalho tem-se como contexto para elaboração da
tarefa interdisciplinar o desenvolvimento de um sistema web para automatização de
serviços de entrega de pizza para a empresa fictícia “Meveana”.
A Meveana empresa do Sr. Dorival é uma empresa de entrega de
pizza (delivery) que passa por um momento de expansão e deseja informatizar de
forma prioritária seus processos de entrega de pizza.
A empresa fictícia “Software House Softplus” foi “contratada” para
viabilizar o desenvolvimento do sistema em questão.
3
Page 5
2 OBJETIVO
As metas a serem alcançadas durante a pesquisa e elaboração da
tarefa estão intimamente ligadas à compreensão do trabalho diário de uma equipe
de analistas de sistema e desenvolvedores em uma empresa de softwares. Visamos
como metas principais, atingir com o máximo possível de realismo a reprodução
desse ambiente de trabalho. As tarefas vão desde reuniões em grupo até testes de
software no seu ambiente final.
Utilizaremos como metodologia a elaboração de uma especificação
técnica que englobe todas as tarefas pedidas pelos professores. Tal especificação
aborda os seguintes conteúdos:
1. Especificação Técnica de Softwares;
2. Pesquisa estrutural necessária para viabilizar o sistema:
2.1. Custos;
3. Gestão do conhecimento pelos membros da equipe:
3.1. Meios utilizados e
3.2. Levantamento do capital intelectual da equipe “Sotfplus”.
4
Page 6
3 ESPECIFICAÇÃO TÉCNICA DE SOFTWARE
3.1 O que é um documento de especificação técnica
O documento de especificação técnica é um conjunto de
informações técnicas relacionadas ao produto a ser fabricado. Nele deve conter as
características básicas como interface, desempenho, custos, tecnologias
necessárias, equipe envolvida, etc. Essas informações, apesar de serem descritas
como técnicas precisam ser elaboradas com linguagem equilibrada para os diversos
públicos: Usuários, clientes, desenvolvedores, os quais são denominados de
“steakholds”.
O objetivo principal de uma especificação técnica é nortear e servir
como fonte de conhecimento sobre o produto. O documento de especificação
técnica é comumente utilizado nas mais diversas ciências humanas, no nosso caso,
utilizaremos uma Especificação Técnica de Softwares.
O corpo da especificação técnica, enumerada na lista abaixo, não
tem como objetivo esgotar o conteúdo de uma especificação técnica, mas apenas,
apresentar de forma rápida as principais partes que compõe uma Especificação
Técnica de Software, sendo:
1. Capa;
2. Histórico de revisões;
3. Índice;
4. Introdução:
4.1.Definições, acrônimos e abreviações;
4.2.Público-alvo;
4.3.Escopo do sistema;
5. Prototipação;
6. Requisitos funcionais;
7. Requisitos não funcionais;
8. Casos de uso;
9. Referências da especificação;
5
Page 7
3.2 Descrição das partes de uma especificação técnica
3.2.1 Capa
Contem basicamente: Logotipo da empresa desenvolvedora, título
da especificação, versão e data.
3.2.2 Histórico de revisões
Tabela contendo as principais modificações realizadas na
especificação técnica, com as respectivas datas, autores e descrição sucinta da
mudança.
3.2.3 Índice
Lista enumerada dos tópicos que compõe a especificação técnica.
3.2.4 Introdução
A introdução abrange informações como público-alvo, escopo,
abreviações e outras que se fizerem necessárias. No entanto deve-se observar que
a introdução acercar-se de informações introdutórias e pouco conclusivas. Serve,
sobretudo, para ambientar os leitores. Pode-se ainda iniciar a introdução com um
breve texto descrevendo o objetivo do documento.
3.2.5 Público-alvo
Define o público objeto da especificação, como clientes,
desenvolvedores, usuários finais e partes interessadas.
6
Page 8
3.2.6 Escopo do sistema
Define de forma clara e objetiva o propósito central do produto a ser
desenvolvido. Deve-se descrevê-lo com o mínimo de linhas possíveis.
3.2.7 Definições, Acrônimos e Abreviações.
Use essa seção para informar os leitores leigos os significados de
acrônimos e abreviações (siglas). Como também, as definições de termos
pertinentes à compreensão do produto, metodologias e partes afins.
3.2.8 Prototipação
Essa seção não é obrigatória em todos os modelos de especificação
técnica. Ela é específica para nosso caso em questão por ser de grande importância
para usuários e clientes visualizarem as diferentes telas de operacionalização do
sistema. Deve ser apresentada por meio de imagens das possíveis telas (protótipos)
do sistema.
3.2.9 Requisitos funcionais
Descrever os requisitos funcionais do sistema, ou seja, o que o
sistema deve fazer. Para uma melhor organização do documento, deve-se organizar
os requisitos em tabela. Identificar, descrever de forma técnica e informal, definir
desenvolvedor e tipificar são algumas necessidades da documentação de requisitos.
7
Page 9
3.2.10 Requisitos não funcionais
Requisitos não funcionais seguem a mesma organização dos
funcionais. Porém, enquanto aquele diz o que o sistema deve fazer, esse está ligado
as propriedades do sistema, as exigências para que os requisitos funcionais possam
ser efetivados.
3.2.11 Casos de uso
Apresentar os diagramas de casos de uso do sistema.
3.2.12 Referências da especificação
Nessa seção deve-se especificar os documentos que se fizeram
necessários para a documentação de especificação técnica como também da
engenharia do software.
3.3 Modelo de especificação técnica de software
Nas próximas páginas apresentamos um modelo de Especificação
Técnica com todas as tarefas solicitadas no trabalho do 6º Semestre. Salientamos
que tal modelo é apenas fictício e não contempla todas as possibilidades de uma
especificação técnica. A especificação é uma ferramenta muito particular à cada
produto, sendo de suma importância atentar para o que é necessário para cada
especificação de acordo às necessidades do projeto no todo.
8
Page 10
SoftPlus
ESPECIFICAÇÃO TÉCNICA
Software para delivery de pizza.
Versão 1.0
Data 23 out. 2015.
Itapetinga-BA
9
Page 11
Histórico de versões
Descrição Autor Data Versão
Início do documento de
especificação.Wancley Ribeiro 19 out 2015 1.0
Inclusão dos protótipos Ruy Guimarães 19 out 2015 2.0
Inclusão dos requisitos funcionais e
não funcionais.Cleber Ramos 20 out 2015 1.5
Inclusão dos diagramas de casos de
usos.Marcelo Aguiar 21 out 2015 2.0
Inclusão da pesquisa de arquitetura
10
Page 12
Índice
Introdução................................................................................................................12
Definições, acrônimos e abreviações.......................................................................2
Público-Alvo..............................................................................................................3
Escopo do sistema...................................................................................................4
Prototipação...............................................................................................................6
Requisitos funcionais................................................................................................7
Requisitos não funcionais........................................................................................8
Diagramas de Casos de uso.....................................................................................9
Referências da especificação.................................................................................10
11
Page 13
Introdução
Este documento de especificação técnica de software para delivery
de pizza tem como objetivo nortear e servir de fonte de consulta para elucidar
dúvidas, orientar de forma técnica, coletar requisitos de sistema como apoio ao
processo de engenharia de software. As inclusões e modificações neste documento
são efetuadas pela equipe de gerência e desenvolvimento do projeto, depois de
acurada avaliação.
Definições
Termo Definições
Casos de usoTécnica baseada em cenários para elucidação de
requisitos.
Escopo Finalidade, o alvo que foi estabelecido como meta final.
Dispositivo mobile
É um computador de bolso habitualmente equipado com
uma pequena tela. (smartphones, notebook, netbook,
PDAs etc).
Desktop Micro computador de mesa.
StakeholdersPessoas ou empresas envolvidas no desenvolvimento e
usos de um produto.
Acrônimos e abreviações
Abreviações Significado
RF Requisito funcional
RNF Requisito não funcional
PDA Personal Digital Assistants - Assistente Pessoal Digital
PHP Personal Home Page
CSS Cascading Style Sheets Folhas de estilo
12
Page 14
HTML Linguagem de Marcação de Hipertexto
SQL Linguagem de Consulta Estruturada a banco de dados
Público-Alvo
Este documento tem como público-alvo, de forma prioritária os
stakeholders (partes envolvidas) como sendo os clientes contratantes, usuários
finais, desenvolvedores e gerentes de projetos.
Escopo do sistema
O sistema proposto visa agilizar os processos de controle de
pedidos de pizza, como também sua entrega, que ocorre de forma terceirizada. O
sistema precisa manter os clientes, entregadores, produtos, fornecedores. O sistema
precisa garantir a não redundância de dados, a segurança das informações dos
clientes, entregadores e fornecedores. O software precisa ainda ser desenvolvido de
forma “rodar” em diversas plataformas de hardware, como dispositivos móbile e
desktops, para tanto, os dados deverão ser armazenados em servidor web com
capacidade e disponibilidade suficientes. Os clientes realização os pedidos por
telefone e o usuário do sistema dará entrada no sistema por meio do controle de
pedidos e encaminhar esse pedido para a entrega via entregador terceirizado
podendo acompanhar o status desse pedido.
13
Page 15
Prototipação
Protótipo 1 – Tela manutenção de pedidos
Protótipo 2 – Tela de manutenção de clientes
14
Page 16
Protótipo 3 – Tela de manutenção de entregadores
Protótipo 4 – Tela de manutenção de empresas terceirizadas
15
Page 17
Protótipo 5 – Tela de manutenção de produtos
Protótipo 6 – Tela de pedidos
16
Page 18
Protótipo 7 - Index do web site para pedidos
17
Page 19
Requisitos funcionais
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
001 Manter pedidos Incluir, Excluir e Alterar
pedidos. (CRUD)
Funcional
Desenvolvedor: RUY GUIMARÃES
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
002 Manter clientes Incluir, Excluir e Alterar
dados dos clientes. (CRUD)
Funcional
Desenvolvedor: RUY GUIMARÃES
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
003 Manter entregadores Incluir, Excluir e Alterar
dados dos entregadores.
(CRUD)
Funcional
Desenvolvedor: WELITON SANTOS
18
Page 20
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
004 Manter emp. Terceirizadas Incluir, Excluir e Alterar
dados dos Emp.
terceirizadas. (CRUD)
Funcional
Desenvolvedor: WELITON SANTOS
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
005 Manter produtos Incluir, Excluir e Alterar
dados dos produtos. (CRUD)
Funcional
Desenvolvedor: WANCLEY RIBEIRO
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
006 Visualizar Status dos pedidos Visualizar pedidos. Funcional
Desenvolvedor: WANCLEY RIBEIRO
19
Page 21
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
007 Visualizar Status dos pedidos Visualizar pedidos. Funcional
Desenvolvedor: WANCLEY RIBEIRO
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
008 Enviar pedidos Enviar pedidos para a
entrega.
Funcional
Desenvolvedor: RUY GUIMARÃES
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
009 Cancelar pedidos Cancelar pedidos do sistema
com exclusão em banco de
dados.
Funcional
Desenvolvedor: RUY GUIMARÃES
20
Page 22
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
010 Emitir relatório de entregas
realizadas
Emitir em vídeo e/ou
impressora relatório com
filtro de período de data das
entregas realizadas.
Funcional
Desenvolvedor: RUY GUIMARÃES
Requisitos não funcionais
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
011 Garantir a persistência de dados Persistir dados e garantir a
não redundância de dados
únicos.
Não
Funcional
Desenvolvedor: CLEBER RAMOS
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
012 O sistema deve ser capaz de
“rodas” em smartphones,
tablets, PDAs e desktops
Sistema multi-plataforma de
hardware.
Não
Funcional
Desenvolvedor: CLEBER RAMOS
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
21
Page 23
013 O web site deve adaptar-se aos
diversos tamanhos de telas
Usar tecnologia de
construção em CSS com
design fluido e responsivo.
Não
Funcional
Desenvolvedor: MARCELO AGUIAR
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
014 Usar linguagens de
programação fáceis e livres.
Usar linguagens PHP, CSS,
HTML e SQL.
Não
Funcional
Desenvolvedor: MARCELO AGUIAR
Cliente Meveana
Sigla do sistema proposto PedPizza
Nº do requisito Descrição informal Descrição técnica Tipo
015 Controlar o acesso aos pedidos
por meio de login de clientes.
Controle de acesso com
segurança.
Não
Funcional
Desenvolvedor: MARCELO AGUIAR
22
Page 24
Casos de uso
Atores
Atendente
Definição dos atores
Atendente: Pessoa que realizará a entrada de pedidos no sistema e sua respectiva
manutenção e envio para a entrega.
Gerente: Pessoa que emitirá semanalmente relatório de entrega de pizzas.
Cliente: Acessa o web site para efetuar pedidos online
Identificação de atores e seus casos de uso
Atores Casos de uso
Atendente
Pesquisa cliente;
Mantem cliente;
Mantem pedidos;
Enviar pedidos;
Mantem entregadores;
Mantem Terceirizadas;
Mantem produtos.
Gerente Emiti relatório de entrega de pizza.
Cliente Efetuar pedidos online.
Gerente Cliente
23
Page 25
Diagrama de caso de uso
24
Page 26
Referência da especificação
Tema Referência
Engenharia
Documentos impressos da Meveana, impressos das empresas
terceirizadas.
PrototipaçãoFormulários de vendas, cardápios, recibos de entregas, cadastros de
fornecedores, cadastro de entregadores, cadastro de clientes.
Protótipo do web site
www.pedidosja.com.br
www.delivery.dominos.com.br
www.brazpizzaria.com.br
25
Page 27
4 PESQUISA ESTRUTURAL DO SISTEMA
4.1 Custo com pessoal
No durante a pesquisa baseadas nos requisitos de sistema,
percebemos a necessidade da contratação de alguns profissionais especializados
em diversas áreas como: Gerente de projetos, Analista desenvolvedor e Designer.
Levando em consideração o valor médio salarial para pequena empresa de cada
uma dessas áreas de atuação em TI, foi possível traçar um custo aproximado para
despesa de pessoal. Salientamos, no entanto, que ainda não uma tarefa fácil a
métrica correta de custo total de um projeto de desenvolvimento de sistema, visto
que não existem padrões e metodologias consagradas para tal empreendimento, no
máximo chega-se a um valor estimado.
A metodologia utilizada para calcular o valor de cada profissional foi
encontrar o valor da hora (Valor/Hora), com base no Salário Médio (Sal. Médio) e
multiplicar pelo total de horas de trabalho (Total/Horas) no projeto. A formula para
tanto é descrita abaixo:
Valor/Dia = Sal Médio / 30 dias
Valor/Hora = Valor/Dia / 8 horas dia
Valor/Hora = R$33,33
Profissional Sal. Médio Total/Horas Valor/Hora Total
Gerente de projetos R$ 8.000,00 160 R$33,33 R$ 5.350,00
Analista desenvolvedor R$ 3.500,00 240 R$ 14,60 R$ 3.500,00
Designer R$ 3.000,00 160 R$12,50 R$ 2.000,00
Total com pessoal R$ 10.850,00
Fonte: Exame.com em: <http://exame.abril.com.br/carreira/ferramentas/tabela-de-salarios-rh/?empresa=ti> acesso
26 out. 2015.
26
Page 28
4.2 Custo com equipamento
Com base no pressuposto de que o sistema será um aplicativo web,
o qual “rodará” diretamente em servidor web tanto na parte que atenderá os clientes
como atendente de gerente da Meveana. Tomamos como base o valor médio de
servidores de hospedagem web. No entanto, julgamos necessária a contratação de
um servidor web dedicado com suporte técnico.
Equipamento Descrição Valor médio
Intel Xeon Quad-Core
16 GB de Memória
2x 2 TB SATA ou 2x 600 GB
SAS HW RAID 1 (espelhamento)
1 TB de tráfego mensal
Servidor dedicado para
hospedagem do web site e
aplicativo web. Já incluso
suporte técnico de segurança,
manutenção, backup e restoure
de dados.
R$1.200,00/mês
27
Page 29
5 GESTÃO DO CONHECIMENTO PELOS MEMBROS DA EQUIPE
5.1 Meios utilizados
No processo de gestão do conhecimento entre a equipe,
percebemos na prática os quatro meios de conversão do conhecimento:
Socialização, Externalização, Combinação, e Internalização.
5.1.1 Socialização
O processo de socialização acontecia de forma natural e concreta
durante as reuniões da equipe para traçar metas, dirimir dúvidas, expor experiências
pessoais e demais processo de socialização. Dessa forma notamos que o
aprendizado em equipe é um processo de transmissão do conhecimento de tácito
para tácito. As reuniões em equipe, para discussão em torno do projeto é um
excelente meio de gestão do conhecimento.
5.1.2 Externalização
A externalização deu-se nos momentos diversos de preparação de
manuais, protótipos, designes de telas, diagramas e de mais artigos, que por fim,
formaram o todo documental do projeto. Nesse processo cada membro contribuiu
com seu conhecimento para convergir de conhecimento tácito para explicito.
5.1.3 Combinação
Por meio da leitura e entendimento dos diversos manuais, livros e
demais mídias de conteúdo em TI, foi possível combinar o conhecimento explicito,
externo ao projeto para o conhecimento explicito interno do projeto, o qual resultou
no documento de especificação técnica presente neste trabalho.
28
Page 30
5.1.4 Internalização
A internalização foi percebida individualmente por cada membro da
equipe, visto que cada um absorveu dos diversos manuais, livros, artigos e demais
leituras (conhecimento explicito), para seu aprendizado pessoal, incrementando seu
conhecimento tácito.
5.2 Capital intelectual da equipe
O capital intelectual de uma pessoa é composto por toda informação
que é transformada em conhecimento, a qual foi adquirida por experiências,
estudos, práticas e tudo mais que contribuiu para construir a gama de conhecimento
de cada individuo.
No nosso caso, da equipe de gerência e desenvolvimento, listamos
abaixo as experiências que cada aluno participante.
Componente Experiência
Arivelton Brandão Técnico em informática e programador C#.
Cleber RamosGerente de redes de computadores, Técnico em informática,
conhecedor de servidores Linux.
Marcelo AguiarProgramador C#, Java, PHP, CSS e HTML técnico em
informática.
Ruy Guimarães Técnico em informática e programador C#
Wancley RibeiroDesenvolvedor de sistemas desktop e web, professor de
informática básica e programação, técnico em informática.
Weliton SantosDesign, programador web, domínio em HTML, PHP,
JavaScript, CSS e SQL.
29
Page 31
6 CONCLUSÃO
O trabalho proposto foi de muita utilidade para a concretização do
conhecimento adquirido no 5º e 6º semestres. A prática em equipe nos ajudou a
perceber como uma equipe de desenvolvimento trabalha. Visualizamos de forma
global as diversas tarefas de analistas, gerentes de projetos e desenvolvedores de
uma empresa de TI. Por meio dessa tarefa foi possível adquirir uma noção do ciclo
de vida de um software, desde o seu nascedouro, as entrevistas iniciais com o
cliente e reuniões de equipe até as etapas finais de teste e treinamento dos usuários
finais.
30
Page 32
REFERÊNCIAS
PERINI, Luis Cláudio; HISATOMI, Marco Ikuro; BERTO, Wagner Luiz. Engenharia de softwares: sistemas II. São Paulo: Pearson Education, 2009.
PRESSMAN, Roger S. Engenharia de softwares: uma abordagem profissional. 7. ed. São Paulo: AMGH Editora Ltda, 2011.
SALÁRIOS do setor de TI. In: EXAME.COM, revista exame info. 2015. Disponível em: <http://exame.abril.com.br/carreira/ferramentas/tabela-de-salarios-rh/?empresa=ti>. Acesso em: 25 out. 2015.
SOMMERVILLE, Ian. Engenharia de softwares. 8. ed. São Paulo: Pearson Addison- Wesley, 2007.
31