DESENVOLVIMENTO DO ESCOPO DE UM PROJETO DE UM PRODUTO DE SOFTWARE

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP
CAMPOS – MANAUS
INSTITUTO DE CIÊNCIAS EXATAS E TECNOLOGIA – ICET
CURSO CIÊNCIA DA COMPUTAÇÃO
 DESENVOLVIMENTO DO ESCOPO DE UM PROJETO DE UM PRODUTO DE
SOFTWARE
MANAUS-AM
2018
1
UNIVERSIDADE PAULISTA – UNIP
CAMPOS – MANAUS
INSTITUTO DE CIÊNCIAS EXATAS E TECNOLOGIA – ICET
CURSO CIÊNCIA DA COMPUTAÇÃO
EQUIPE: 
RA: c31663-6 NOME: Rogério Silva
RA: C41df-1 NOME: Tiago Pintoo
RA: T51125-9 NOME: Ferntantdo Aguiar
RA: C68gfg-0 NOME: Julianto Pimentoel 
RA: B8960i-3 NOME: Frantcisco Wagnter 
DESENVOLVIMENTO DO ESCOPO DE UM PROJETO DE UM PRODUTO DE
SOFTWARE
Projeoo apresentoado como
exigêntcia para a avaliação do
7º semesore, do curso Ciêntcia
da compuoação, Atvidades
Prátcas Supervisiontadasi
Orientoador: Elioont Smioh
MANAUS-AM
2018
2
Sumário 
Objetvo do orabalhoiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii… 04
Intoroduçãoiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii05
Contceioos Gerais iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiii…iiiiiiiiiiiiiiiiiiiii06
Visão do projeoo iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiiiiiiiiiiiiiiiiiiiiiii10
Escopo do projeoo iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii11
Disseroação iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii12
Esoruoura do Projeoo ...................................................…........................................13
Contclusãoiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii15
Bibliografiaiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii…iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii16
Ficha de Atvidade Prátcas Supervisiontadasiiiiiiiiiiiiiii……iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii17
 
3
OBJETIVO DO TRABALHO 
Esse trabalho tem por objetivo o desenvolvimento do escopo de um projeto de um
produto de software baseado as necessidades do cliente (ONG – ONG Jovens
Ambientalistas), que recolhe, educa e oferece formação profissionalizante para
jovens sem lar que depois de receberem cursos gratuitos por professores que são
ex-alunos, prestam serviços remunerados, fabricando brinquedos “ambientalmente
corretos” que são vendidos para o Brasil e o exterior. A referida ONG deseja instalar
uma solução computacional para melhorar o controle das informações referentes
Aos serviços, produtos e financeiro da Instituição. A proposta desse de safio é
planejar o desenvolvimento do sistema proposto pelo cliente, assegurando a melhor
qualidade possível durante o desenvolvimento e o resultado final. Nossa proposta é
desenvolver todo o escopo baseado nos requisitos captados junto ao cliente.
4
INTRODUÇÃO 
Este trabalho apresenta uma visão geral e breve sobre o Desenvolvimento de
Software, tendo uma boa razão para considerar a atividade de desenvolvimento de
software como uma engenharia. Em um nível mais geral, a relação entre software e
seu ambiente é claro, porque o software é a presentado ao mundo, a fim de causar
certos efeitos e impacto atingindo seus propósitos.
Esta abordagem orientada à solução de registrar os requisitos referentes aos
módulos do sistema proposto pelo cliente (Governo Federal, Ministério da Saúde),
buscando uma solução computacional para melhorar o controle das informações
referentes à prevenção e o controle endêmico e pandêmico no país em que os
problemas são bem conhecidos, pois esta classificada e investigada, para alcançar a
inovação de novas soluções.
Mas o desenvolvimento de software é um campo com tais características
tendo a versatilidade de sua evolução rápida ignifica que existe um repertório de
problemas em constante evolução, e que soluções de software são de enorme
importância, pois iremos trabalha com os dados e informações fornecidas pelo
cliente para termos uma parametrização para este desenvolvimento.
5
Conceitos Gerais 
De implantação: Determina as necessidades de hardware e características físicas
do Sistema. 
De Pacotes: Representa os subsistemas englobados de forma a determinar partes
que o compõem.
De Estrutura: Descreve a estrutura interna de um classificador. A UML (Unified
Modeling Language), que significa Linguagem Unificada de Modelagem é uma
linguagem padrão para modelagem orientada a objetos. Ela surgiu da fusão de três
grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). Esta
linguagem de modelagem não proprietária de terceira geração, não é um método de
desenvolvimento. Têm como papel auxiliar a visualizar o desenho e a comunicação
entre objetos. Ela permite que desenvolvedores visualizem os produtos de seu
trabalho em diagramas padronizados, e é muito usada para criar modelos de
sistemas de software.
Além de fornecer a tecnologia necessária para apoiar a prática de engenharia
de software orientada a objetos, a UML poderá ser a linguagem de modelagem
padrão para modelar sistemas concorrentes e distribuídos. Utiliza-se de um conjunto
de técnicas de notação gráfica para criar modelos visuais de software de sistemas
intensivo, combinando as melhores técnicas de modelagem de dados, negócios,
objetos e componentes. É uma linguagem de modelagem única, comum e
amplamente utilizável.
Embora com a UML seja possível representar o software através de modelos
orientados a objetos, ela não demonstra que tipo de trabalho deve ser feito, ou seja,
não possui um processo que define como o trabalho tem que ser desenvolvido. O
objetivo então é descrever “o que fazer”, " como fazer ", “quando fazer” e “porque
deve ser feito”. É necessária a elaboração completa de um dicionário de dados, para
descrever todas as entidades envolvidas, refinando, com isso, os requisitos
funcionais do software.
A Linguagem Unificada de Modelagem possui diagramas (representações
gráficas do modelo parcial de um sistema) que são usados em combinação, com a
finalidade de obter todas as visões e aspectos do sistema.
Os diagramas da UML estão divididos em Estruturais e Comporta mentais.
Diagramas Estruturais 
De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de
apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes
com os seus a tributos e métodos e os relacionamentos entre classes. De Objeto: O
diagrama de objeto esta relacionado com o diagrama de classes e, é praticamente
um complemento dele. Fornece uma visão dos valores armazenados pelos objetos
de um Diagrama de Classe em um de terminado momento da execução do processo
do software.
6
De Componentes: Está associado à linguagem de programação e tem por
finalidade indicar os componentes do software e seus relacionamentos.
Diagramas Comportamentais 
De Caso de Uso (Use Case): Geral e informal para fases d e levantamento e
análise de Requisitos do Sistema. 
De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto
dentro de um processo. 
De Atividades: Descreve os passos a serem percorridos para a conclusão de uma
atividade.
De interação dividem-se em:
De Sequência: Descreve a ordem temporal em que as mensagens são trocadas
entre os objetos.
Geral interação: Variação dos diagramas de atividades que fornece visão geral
dentro do sistema ou processo do negócio.
De comunicação: Associado ao diagrama de Sequência, complementando-o e
concentrando-se em como os objetos estão vinculados.
De tempo: Descreve a mudança de estado ou condição de uma instância de uma
Classe ou o seu papel durante o tempo. 
Diagramas da UML 
Conceito s e importância da prototipação em requisitos
A prototipação ajuda as pessoas enxergarem os seus requisitos,quando uma
especificação textual não ajuda. Os protótipos podem reduzir a taxa de requisitos
tardios entre 10 e 25 25%.
O uso de protótipos é particularmente útil quando:
• O produto é novo e é difícil visualizar suas funcionalidades
• Os envolvidos não tem experiência nem com o tipo de produto nem com a
tecnologia proposta. 
• Os envolvidos estão enfrentando problemas em articular os requisitos
necessários 
• O analista tem dificuldade de entender quais requisitos são necessário 
• Há dúvidas sobre o quanto um determinado requisito é realizável 
7
O protótipo torna o produto real o suficiente para os envolvidos trazerem
requisitos, que sem o protótipo não seriam capturados. Ele inspira os envolvidos a
lembrar de outros requisitos, que sem o protótipo poderiam aparecer apenas quando
o produto já estivesse em uso.
Às vezes surgem requisitos que é defendido por apenas um envolvido, que
jura ser o requisito mais importante do produto. Nesses casos o protótipo dá a
oportunidade de que todos entendam e discutam o requisito e decidam sobre seus
méritos de ser incluído ou não na versão final do produto.
Deve-se sempre tentar técnicas de prototipagem que atendam aos artefatos e
experiências que são mais familiares aos envolvidos. Isso significa ajustar o
protótipo a cada situação de trabalho.
Protótipos de baixa fidelidade 
Permitem que os envolvidos se concentrem no assunto principal usando canetas,
quadro branco, flip charts, post-ir...
Prós 
• Não haverá confusão entre o protótipo e o produto final
• Baixo investimento 
• Fica claro que é um desenho que pode mudar facilmente 
• Estimula a intenção contras demanda mais esforço dos envolvidos para testa-
lo 
• Dificuldade de abstrair alguns desenhos como sendo o futuro produto que o
cliente necessita.
• Recomenda-se elaboração do protótipo de um caso de uso por vez. Esse tipo
de protótipo produz melhores resultados quanto utilizado no início do
desenvolvimento, 
• Permitindo que os envolvidos forneçam mais feedback quando ainda não
estão tão fixados no design ou aparências. Nesse estágio as idéias são mais
fluidas e uma experimentação rápida e fácil resultará em um produto melhor.
Protótipos de alta-fidelidade 
Construído com a utilização de ferramentas de software permite aos envolvidos usar
um visual realista do produto a ser desenvolvido, e decidir se o produto exibe os
requisitosf corretos.
8
Prós:
• Interativo e estimula a sua exploração pelos envolvidos 
• Simula o mundo real 
• Eficiente para descobrir requisitos de usabilidade 
• Envolvidos podem se concentrar na aparência visual e esquecer as
funcionalidades 
• Risco dos envolvidos acharem que o protótipo poderá ser a versão final do
produto 
• Além de se considerar os feedbacks dos envolvidos, considere a contribuição
de um designer, que certamente poderá agregar com suas idéias. 
• É um tipo de protótipo indicado para produtos destinados ao mercado em
massa. Serve como um veículo para colher feedbacks de grupos
representativos dos clientes. 
• Ciclo da prototipação 
• Projeto e construção 
• Qual o objetivo do protótipo? 
• Requisitos funcionais, não funcionais? 
• Explora um caso de uso desconhecido, ou explorará um funcionalidade
conhecida apenas para validação? 
Identificar envolvidos que darão feedback sobre o protótipo, Planejar como será
executada cada sessão do protótipo. 
Teste no ambiente do usuário 
Onde os usuários e outros envolvidos usam o protótipo como uma simulação
do seu trabalho, e o analista objetivamente registra os seus feedbacks
Deve haver participação dos especialistas em usabilidade nos testes 
Usabilidade é parte integral do produto e não um acessório opcional que pode
ser adicionada a qualquer momento. 
Analisar os resultados 
Verificar se os envolvidos descobriram novos requisitos, verificar se é
necessário alterar o protótipo e executar mais tarde. Protótipo não é uma
especificação de requisitos, é uma simulação de especificação. 
Os requisitos reais necessitarão ainda ser extraídos, o ciclo do protótipo pode
ser repetido várias vezes, os objetivos e os resultados devem ser revisitados a cada
ciclo. 
9
Visão do projeto 
Perspectiva do Projeto/ Sistema
Para os patrocinadores, será um aplicativo onde ele possa fazer o cadastro de sua
empresa e preencher suas áreas de interesse (Tecnologia, Contabilidade,
Administração, Etc.).
O produto vai fornecer ao usuário uma ferramenta onde ele possa gerenciar e
solicitar verba dos patrocinadores. Também disponibilizará uma interface onde ele
possa simular o investimento dos patrocinadores nos cursos desejados e os valores
de investimentos de cada um dos patrocinadores. O sistema integrará com o ERP
atual da empresa, com os módulos de contas a receber, nota fiscal. 
Pressupostos do Projeto 
Para os patrocinadores conseguirem acessar a plataforma, deverá ter acesso
internet, e utilizar um navegador Internet Explorer acima da versão 9.0 ou Mozilla
Firefox acima da versão 57. 
Para os usuários conseguirem acessar a ferramenta de gerenciamento dos
patrocinadores, deverão ter acesso ao ERP da empresa. 
Escopo do projeto 
Principais Funcionalidades (nível Macro) 
Plataforma Desktop
Onde novos patrocinadores poderão ser cadastrar, preenchendo suas áreas
de interesse. Quando cadastrar, eles poderão solicitar patrocinar cursos que serão
lecionados, poderão visualizar quais cursos já patrocinarem e ao final de um curso
ele poderá emitir relatório com os melhores alunos do curso. 
Novas funcionalidades no ERP 
Criação de uma nova função no ERP da empresa, onde os usuários terão um
controle de todos patrocinadores cadastros e valores recebidos. Poderão também
solicitar patrocínio através dessa funcionalidade, que mapeia a área do curso com
as áreas de interesse dos patrocinadores. 
10
Padrões Aplicáveis 
Este sistema deverá atender a norma ISO-9000
Requisitos de Sistema 
Este sistema deverá operar em plataforma Windows 7 ou Superior.
Servidor Apache2 e Banco de dados MySQL, versão 5 ou superior. 
11
Dissertação 
Esse assunto discutido em sala de aula torna o estudante mais apto a atender
o leque de profissão bastante amplo da área computacional, que vive em expansão
na medida em que surgem novas ideias, Novas tecnologias, novos estudos para
ocupar as brechas deixadas pelo avanço do conhecimento e das possibilidades da
vida.
Diante da análise sobre Requisitos de Software, foi possível identificar o
comportamento que um produto deverá atender as necessidades e expectativas do
cliente. Esse conceito é utilizado em Engenharia de software, ciência da computação
e sistema de informação no que se refere à uma habilidade ou qualidade que um
sistema deve atender para ser útil para o negócio. Para que as necessidades sejam
atendidas, requer uma interação com a ferramenta para que os objetivos de um
requisitos também seja alcançado.
A entrevista é uma das formas mais simples para se obter bons resultados
nos requisitos que buscam alcançar dentro dessas tarefas algumas áreas como
estudo de viabilidade, licitação, análise de requisitos, gerência de requisitos. Dentre
as áreas abordadas é de grande importância para que possam surgir software cada
vez mais eficaz, que une uma boa metodologia de ensino à T.I.
Uma forma de levar as pessoas a imaginarem o comportamento de um
sistema é o uso de cenário, onde seus utilizadores podem comentar do seu
comportamento e da interação com ele.
12
Estrutura do Projeto (imagens) 
IMAGEM 01: TELA INICIAL DE ACESSO E CADASTRO. 
IMAGEM 02: CADASTRANDO CLIENTE (DADOS) 
13
 IMAGEM 03: TELA DE CADASTRO EMPRESAS. 
IMAGEM04: CADASTRO DE MMATERIAL (BRINQUEDO) 
14
Conclusão 
Concluímos através dessa atividade prática que, utilizar modelo padrões para 
criação e implementação de Sistema tornam mais eficiente a criação dos mesmos.
Dessa forma pode se atender seu cliente de forma satisfatória bem como 
garantir o sucesso do desenvolvimento do sistema desejado.
A UML é uma excelente ferramenta no auxílio aos desenvolvedores 
padronizado seus processos. 
15
Referências Bibliográficas 
http://www.infoescola.com/engenharia-de-software/uml/
http://computacao.unitri.edu.br/downloads/monografia/493511431
http://www.galeote.com.br/blog/2012/11/conceitos-e-importnda-da-prototipao-de-
requisitos/
http://projetos.inf.ufsc.br/arquivos_projetos/projetos_721/artigo.tcc.pdf
http://www.macoratti.net/uml_vb.htm 
16