PIM V principal

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP 
EDUCAÇÃO A DISTÂNCIA - EAD 
CURSO SUPERIOR TÉCNICO - ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
 
 
 
 
 
 
 
 
 
PROJETO MULTIDISCIPLINAR V 
 
 
 
 
 
 
 
 
SÃO PAULO/2020 
 
 
 
 
 
UNIVERSIDADE PAULISTA - UNIP 
EDUCAÇÃO A DISTÂNCIA - EAD 
CURSO SUPERIOR TÉCNICO - ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
 
 
 
 
 
 
SISTEMA DE RESERVA DE EQUIPAMENTOS 
 
 
 
 
ELIANE BEZERRA DOS SANTOS 
RA: 2049124 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR V 
Apresentado à Universidade Paulista – UNIP, 
Para Avaliação Bimestral no Curso de Análise 
e Desenvolvimento de Sistemas 
Orientador: Prof. PRISCILLA FACIIOLLI 
 
 
 
RESUMO 
 
 Para que um software se torne real e uma verdadeira ferramenta de uso diário para 
facilitar as rotinas empresariais é necessário antes de tudo, que este produto seja idealizado, 
pensado, desenhado de forma minuciosa baseado nas necessidades de seus futuros 
adquirentes. E para que este produto seja considerado de alta qualidade, atendendo os 
padrões normativos do país, é de extrema importância que efetuem-se diversos estudos e 
levantamentos que estimulem métodos de trabalho eficazes, atualmente o uso de 
metodologias ágeis e ideais de execução rápida com os menores índices possíveis de erros 
no software aumentam significativamente as chances de sucesso do produto. Aplicar de forma 
padronizada testes de qualidade, funcionalidade, testes de interação cliente + produto entre 
outros. O Projeto integrado Multidisciplinar V, faz uso das aplicações ministradas pelas 
disciplinas de Engenharia de Software II, Projeto de Interface Com o Usuário e Programação 
Orientada a Objetos I, que disponibilizam todo o embasamento para que este software torne-
se atrativo economicamente para quem o produz, bem como para quem o comprará. 
Desenvolvi documentações importantes que facilitarão sua manutenção e apresentarei toda 
a viabilidade do negócio com uma breve análise de mercado e levantamento de custos em 
geral com o auxilio das informações captadas na Disciplina de Economia e Mercado. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABSTRACT 
 
In order for software to become real and a true tool for daily use to facilitate business 
routines, it is necessary, first of all, that this product be idealized, thought out, meticulously 
designed based on the needs of its future buyers. And for this product to be considered of high 
quality, meeting the normative standards of the country, it is extremely important that several 
studies and surveys are carried out to encourage effective working methods, currently the use 
of agile methodologies, ideal for quick execution with the lower possible rates of errors in the 
software significantly increase the chances of success of the product. Apply standardized tests 
of quality, functionality, tests of customer + product interaction, among others. The Integrated 
Multidisciplinary Project V, makes use of the applications taught by the disciplines of Software 
Engineering II, User Interface Design and Object Oriented Programming I, which provide all 
the basis for this software to become economically attractive to those who produce it , as well 
as who will buy it. I developed important documentation that will facilitate its maintenance and 
I will present all the viability of the business with a brief market analysis and general cost survey 
with the help of the information captured in the Economics and Market Discipline. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURAS 
FIGURA 1 - Escopo do Projeto ______________________________________________________14 
FIGURA 2 - Modelo de Sugestões de Digitação Solicitado Pelo Cliente ______________________16 
FIGURA 3 – As 4 Principais Disciplinas que compõem o IHC _______________________________18 
FIGURA 4 – Processo de Engenharia de Software Modelo Cascata__________________________19 
FIGURA 5 – Ciclo de Software IHC Modelo Estrela_______________________________________20 
FIGURA 6 – Tela Login e Senha e Validação de Dados Corretos____________________________23 
FIGURA 7 – Tela Menu Inicial________________________________________________________23 
FIGURA 8 – Usuário Seleciona Mês___________________________________________________24 
FIGURA 9 – Calendário com Data reservada e Seleção de Nova Data________________________24 
FIGURA 10 – Cadastro de Equipamentos_______________________________________________25 
FIGURA 11 – Ivan Sutherland Manuseando Sketchpad____________________________________26 
FIGURA 12 – Exemplo de Classes, Atributos, Métodos e Abstração__________________________29 
FIGURA 13 – Encapsulamento de Características dos Equipamentos_________________________29 
FIGURA 14 – Herança de Classes____________________________________________________30 
FIGURA 15 - Polimorfismo _________________________________________________________31 
FIGURA 16 – Modelo de Testes Finais em V ____________________________________________33 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE TABELAS 
 
TABELA 1 – Custo do Investimento ____________________________________________12 
TABELA 2 – Histórico de Revisão de Documentos ________________________________15 
TABELA 3 – Identificação e Divisão da Equipe___________________________________15 
TABELA 4 – Papéis dos Usuários _____________________________________________21 
TABELA 5 – Características Principais para Compor o UI___________________________22 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sumário 
1. INTRODUÇÃO_______________________________________________________7 
2. PESQUISAS BIBLIOGRÁFICAS SOBRE ECONOMIA ________________________8 
3. ANÁLISE MERCADOLÓGICA __________________________________________9 
4. VIABILIDADE ECONOMICA___________________________________________10 
5. ESTUDO DE CASO__________________________________________________11 
6. CUSTO TOTAL DO INVESTIMENTO____________________________________12 
7. CUSTO DO SISTEMA E PRAZO DE ENTREGA____________________________12 
8. ENGENHARIA DE SOFTWARE II_______________________________________13 
8.1 NBR ISO 9000-3__________________________________________________14 
8.2 INICIAÇÃO______________________________________________________14 
8.3 FORMULÁRIO DE ANALISES DE REQUISITOS ____________________15 e 16 
9. PROJETO DE INTERFACE COM USUÁRIO_______________________________17 
9.1 IHC (INTEGRAÇÃO HUMANO COMPUTADOR) ________________________17 
9.2 CICLO DE VIDA DE SOFTWARE_________________________________18 e 19 
9.3 COMPLETANDO AS DOCUMENTAÇÕES PARA PROTOTIPAÇÃO_________20 
9.3.1 PAPÉIS DOS USUÁRIOS____________________________________20 
9.3.2 PRINCIPAIS CARACTERISTICAS_____________________________21 
9.4 PROTOTIPAÇÃO DE ALTA FIDELIDADE____________________22, 23, 24 e 25 
10. PROGRAMAÇÃO ORIENTADA A OBJETOS__________________________26 e 27 
10.1 ABSTRAÇÃO_________________________________________________28 
10.2 ENCAPSULAMENTO___________________________________________29 
10.3 HERANÇA___________________________________________________30 
10.4 POLIMORFISMO______________________________________________31 
11. TESTES FINAIS_____________________________________________________32 
11.1 Modelo V ______________________________________________________32 
12. CONCLUSÃO______________________________________________________33 
13. REFERENCIAS _____________________________________________________34 
 
 
 
 
 
 
7 
 
1. INTRODUÇÃO 
 
Segundo Bill Gates “A primeira regra de qualquer tecnologia utilizada nos negócios é 
que a automação aplicada a uma operação eficiente aumentará a eficiência. A segunda é que 
a automação aplicada a uma operação ineficiente aumentará a ineficiência.” Sabemos que o 
setor de Desenvolvimento e Análise de Softwares passa por crescentes mudanças e alta de 
procura ao longo dos últimos anos, os sistemas e programasde todos os tipos tornaram-se 
ferramentas primordiais e indispensáveis. O aumento das empresas de micro e pequeno 
porte responsáveis pela fabricação de software e sistemas elevou a concorrência e 
consequentemente a busca por mais qualidade e prazos adequados, com isto as 
metodologias ágeis ganharam notoriedade e tornaram-se ferramentas de uso obrigatório 
para as empresas que almejam se destacar, Beck (2004), já nos ensinava que o processo de 
desenvolvimento de software de forma rápida, com qualidade e entregas frequentes eram a 
chave para a redução de impactos econômicos e humanos, uma vez que falhas geram 
maiores custos e menores lucros. 
Este projeto tem por finalidade apresentar testes, metodologias e documentações 
necessárias para que o produto final acompanhe o processo de melhoria continua do qual o 
mercado atual exige. 
 Ralph Johnson, (2010) citou que “Antes do software poder ser reutilizável ele primeiro 
tem de ser utilizável.” Com base em informações imprescindíveis oferecidas pela disciplina 
de Programação Para Objetos tornaremos nossa codificação o mais simples, limpa e exata 
possível, apresentando o uso de classes codificadas com os 4 pilares da POO , abstração, 
encapsulamento, heranças e polimorfismo. 
 “O bom projeto adiciona valor mais rápido do que custo” Thomas C. Gale designer de 
automóveis e projetista do famoso Dodge Viper 1992 acreditava que o sucesso econômico de 
um produto já estaria agregado se o projeto inicial fosse realizado com exatidão e sem falhas. 
Para que um software se torne ferramenta cotidiana de solução das rotinas empresariais este 
o caminho é adotar as boas práticas de projeto. 
 
 
 
 
 
8 
 
2. Pesquisas Bibliográficas Sobre Economia 
 
Os estudos e levantamentos econômicos evoluíram conforme as constantes 
mudanças e necessidades de gerir recursos escassos no qual a humanidade enfrenta ao 
longo dos séculos. A forma com que se lida com a gestão de recursos, investimento de capital 
e aplicação de trabalho para obtenção de renda é uma das ciências mais utilizadas pelas 
civilizações. 
“O pai do Capitalismo Adam Smith” em sua obra A Riqueza das Nações (1776) foi o 
pioneiro a abordar conceitos de precificação, produção, distribuição, finanças públicas, 
comércio internacional e crescimento econômico; suas analises serviram para entender o 
funcionamento do mercado, qual o papel do Estado nas macroeconomias e de que maneira 
a economia industrial afetava os trabalhadores. Para alguns estudiosos a riqueza de uma 
empresa , indústria ou país estava relacionada apenas por acumulo de capital, teoria rebatida 
por Robert Solow que desenvolveu a teoria econômica do crescimento, considerada modelo 
neoclássica cuja a explicação principal apontava para um crescimento real do PIB igual ao 
crescimento de sua população, dessa maneira o PIB se mantinha em constante crescimento, 
Solow recebeu o Nobel de economia em 1987 por sua visão simples porém um dos pilares da 
teoria do crescimento, através desta teoria originou-se a contabilidade econômica, anos mais 
tarde outro grande nome da economia, Rebelo; dá início ao que chamamos de crescimento 
endógeno, que rebate a teoria de Solow , esta teoria determina que a produção do país é a 
soma de capital físico com capital humano, nas décadas de 80 e 90 o modelo endógeno foi 
aprimorado de maneira que o estado intervém umas vez que óptimo social torna-se mais 
superior ao privado. 
 
 
 
 
 
 
 
 
 
9 
 
3. Analise Mercadológica 
Para que um produto ingresse no mercado, dentre as diversas preocupações de uma 
pessoa jurídica destacam-se entender o mercado de atuação, suas necessidades, fraquezas, 
quais suas vantagens competitivas, o que a região de atuação oferece e principalmente, quem 
são os seus clientes? 
Segundo o site da ABES – Associação Brasileira das Empresas de Software em 2019 o 
mercado de software cresceu 16% no Brasil, hoje conta com 21.020 empresas dedicadas ao 
desenvolvimento e produção de software, distribuição e prestação de serviços. Considerando 
apenas as 5.519 empresas que atuam no desenvolvimento e produção de software, cerca de 
95,3% são micro e pequenas empresas, ou seja, possuem até 99 funcionários. Ainda 
analisando as empresas, cerca de 50% destas são empresas de T.I voltadas para finanças, 
serviços e Telecom seguidos pela indústria e Comércio, com essas informações levantamos 
que softwares voltados para Escolas ou Empresas que dispõem de equipamentos para 
locação (buffets, empresas de locação de equipamentos etc.), não atinge 1,8% da fatia de 
produtos oferecidos no mercado. 
Para identificarmos a viabilidade desse negócio, mesmo observando o percentual 
inexpressivo de sistemas para este setor, observamos que apenas no estado de SP existem: 
• 4788 Escolas de Ensino Infantil 
• 2997 Escolas de Ensino Fundamental 
• 1383 Escolas de Ensino Médio 
E, mesmo com a queda de 98% no setor de festas, eventos e buffets com a pandemia 
de 2020, devemos voltar os olhos para este setor que com certeza, muito em breve com a 
retomada das atividades alavancará resultados positivos, uma vez que o último censo da 
ABRAFESTA – Associação Brasileira de Eventos Sociais descreveu uma movimentação de 
cerca de 17 bilhões de reais em 2019. Este levantamento permite definir que o mercado 
consumidor para o sistema de locação de equipamentos é bastante promissor. 
 
 
 
 
 
 
10 
 
4. Viabilidade Econômica 
Para identificar a viabilidade de um negócio, fatores relevantes precisam de valiosa, voltamos 
a atenção para: 
• Evitar e/ou diminuir desperdício de recursos 
• Facilitar a Captação de Recursos. 
• Analisar as Vantagens Competitivas do Negócio 
• Maiores chances de assertividade no negócio 
Para este plano de negócio a idéia é iniciar uma microempresa enxuta com um número 
entre 6 a 8 funcionários no máximo, como no Brasil o regime de Microempreendedor ainda 
não disponibiliza CNPJ para programadores, o inicio será como microempresa cadastrada no 
Simples Nacional, ou seja, inicialmente ingressará com uma receita operacional bruta =< 2,4 
milhões e o limite de até 9 funcionários. 
Quem são os futuros clientes? 
Escolas Particulares de Médio e Grande Porte que dispõem de muitos equipamentos 
de áudio e vídeo e que precisam de um controle maior para alocar e dispor conforme datas 
de requerimento. 
Empresas de Eventos e/ou Locações, Festas e Buffets que também utilizam muitos 
maquinários e sofrem com a organização de datas e melhorias logísticas. 
Existem muitos produtos como este no mercado? Qual o diferencial? 
Apesar de haver dezenas de Softwares voltados para gestão e locação de 
equipamentos, não encontramos um produto que mantenha uma rotina interna, com 
informações voltadas ao tipo de produto e notificações de datas de reserva, ou uma 
ferramenta que comunica se o equipamento está ou não em manutenção etc.... 
A empresa trabalhará apenas um produto pronto? Ou será uma empresa que produz 
softwares por encomenda? 
Produção de Software por encomenda, moldados para solucionar os problemas de acordo 
com as necessidades das empresas. 
 
 
 
 
11 
 
5. Estudo de Caso 
O contexto deste projeto é desenvolver um sistema de agendamento e reserva de 
equipamentos para o Colégio Vencer Sempre. 
O Colégio Vencer Sempre dispõe de inúmeros equipamentos de informática, áudio e 
vídeo (tais como: Datashow, TV com VCR, TV com DVD, projetores de Slides, Microfones, 
Caixas Amplificadas, notebooks, Kits Multimídias etc.) 
Atualmente o sistema de reserva é manual e muitos professores não conseguem 
reservar os equipamentos que precisam, pois, o agendamento é ineficiente. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
6. Custo Total Do investimento 
Maquinário: 
5 Computadores de Alta geração R$ 8.300,00 unidade R$ 41.500,00 
2 Impressoras R$ 4.000,00 
MobíliaCompleta (Mesas, Cadeiras, armários etc..) R$ 18.000,00 
Softwares de Gestão, Vendas .... R$ 3.500,00 
Insumos de Papelaria etc.... R$ 2.000,00 
Capital de Giro R$ 180.000,00 
Valor Total do Investimento R$ 249.000,00 
 Tabela 1. Custo do Investimento 
 
 
7. Custo do Sistema e Prazo de Entrega 
De acordo com os levantamentos realizados até aqui, definimos que este software terá 
um custo aproximado de 2 mil reais baseando o custo total operacional da empresa somados 
as horas trabalhadas dos stakeholders dividindo por 30 que é a quantidade de dias do mês, 
por se tratar de um sistema simples e com poucas informações o prazo de 30 dias para a 
entrega do mesmo é suficiente, lembrando que softwares concluídos em prazos menores que 
o estipulado automaticamente diminuem o custo. 
 
 
 
 
 
 
 
 
 
 
 
13 
 
8. Engenharia de Software II 
Engenharia de Software pode não ser uma disciplina muito prazerosa de se desenvolver, 
porém, considerada imprescindível para que um novo produto de software atinja um nível de 
excelência em qualidade. Qualidade de Software sem dúvida é a palavra chave para 
diferenciar e destacar o produto neste mercado tão competitivo. Os processos envolvidos no 
desenvolvimento do software, se bem efetuados, não só permite um produto final que atenda 
100% das necessidades do cliente, mas que também ofereça maior assertividade no decorrer 
da aplicação, ou seja, oferece uma ferramenta que diminui tempo, prazo, custos, facilita a 
visualização geral para a equipe de desenvolvimento, mastiga os métodos para equipe de 
codificação e traduz para o papel tudo o que o cliente espera. 
Considerado o “guru da qualidade” Philip Crosby foi um dos pioneiros a associar a 
qualidade a requisitos pré-estabelecidos, segundo ele, os padrões deveriam ser estipulados 
pela administração/diretoria de acordo com as necessidades do cliente objetivando aumentar 
a satisfação dele. Crosby apontou 5 princípios básicos para qualidade que se seguidos de 
forma correta atingirão os melhores resultados possíveis conforme listados a seguir: livro 1 
(Engenharia de Software II. / André Luiz Ribeiro. – São Paulo: Editora Sol, 2015.) 
1) Fazer certo da primeira vez, economiza tempo e dinheiro 
2) Qualidade é um processo preventivo 
3) Qualidade é incorporada ao produto como resultado da atenção dedicada às necessidades 
do cliente 
4) Qualidade é responsabilidade de todos os envolvidos 
5) Qualidade é um processo de melhoria continua. 
As consequências resultantes no final do produto de software com qualidade são: 
1) Aumento de produtividade 
2) Redução de Defeitos nos Produtos 
3) Aumento da Confiabilidade do Produto 
4) Menos retrabalho 
5) Menos horas Extras de Trabalho 
6) Maior Satisfação do Cliente 
Existem fatores importantes que podem afetar a qualidade final do software, a cultura 
organizacional, custos e prazos mal estabelecidos ou definidos, equipe não envolvida ou 
100% não identificada com o projeto e a cultura de resistência a mudanças. 
No final da década de 80 com o aumento de tecnologia e a alta na produção industrial como 
um todo, a ISO (International Organization for Standardization) órgão internacional 
14 
 
responsável por fixar normas técnicas essenciais de produção, criou a NBR ISO 9000, norma 
de gestão de qualidade que se tornou um guia para auxiliar as empresas na seleção da norma 
mais apropriada para o seu negócio e na sua utilização. Trata‑se de um documento não 
normativo que no Brasil é representada pela Associação Brasileira de Normas Técnicas 
(ABNT, 2000a). A partir desta originam-se as demais em sequência. 
8.1 NBR ISO 9000-3 
A NBR ISSO 9000-3 é a norma destinada às empresas produtoras de softwares, é 
uma extensão da norma NBR ISSO 9001 que normativa sistemas de qualidade em projetos, 
desde e o seu desenvolvimento, produção, instalação e suporte técnico que acrescida a 
norma 9000-3 descreve itens próprios para demonstrar a capacidade da empresa em 
desenvolver, fornecer e realizar manutenções e melhorias futuras. 
Os três pilares que estruturam a norma 9000-3 são: 
• Atividades de Estrutura 
• Atividades de ciclo de Vida 
• Atividades de Suportes 
À partir dessas informações começamos a definir o escopo do projeto e a preencher 
nossos formulários de análises de requisitos. Na figura 1 vemos o fluxograma do escopodo 
projeto. 
Vale ressaltar que definimos que a coleta de informações será realizada por um 
engenheiro de software que lida diretamente com o cliente, coletando as informações, 
necessidades e trazendo o cliente como integrante da equipe, tornando o projeto 100% 
destinado a empresa solicitante. Uma forma de tornar o produto único. 
 
 
 
 
 
Figura 1 Escopo do Projeto 
 
 
 
15 
 
8.2 Iniciação 
Nesta etapa Criamos um Check in/out para datar as alterações do documento 
 Tabela 2 Histórico de Revisões do Documento 
Em seguida definimos quem serão os responsáveis e por quais setores 
FUNÇÃO NOME EMAIL 
ANALISTA DE REQUISITOS Eliane elianeb.santos@yahoo.com.br 
PRODUCT OWNER Raphael raphael.nara@gmail.com 
STAKEHOLDER Luan luan.kevin@hotmail.com.br 
STAKEHOLDER Val Barci val.barci@yahoo.com.br 
CONTRATANTE 
PATROCINADOR 
Colégio Vencer Sempre financeiro@cvsempre.com.br 
diretoria@cvsempre.com.br 
 Tabela 3 Identificação e Divisão da Equipe 
 
8.3 Formulário de Análise de Requisitos 
Nesta etapa identificamos o problema do cliente 
O Colégio Vencer Sempre dispõe de inúmeros equipamentos de informática, áudio e 
/vídeo (tais como: Datashow, TV com VCR, TV com DVD, projetores de Slides, Microfones, 
Caixas Amplificadas, notebooks, Kits Multimídias etc.) 
Atualmente o sistema de reserva é manual e muitos professores não conseguem reservar os 
equipamentos que precisam, pois, o agendamento é ineficiente. 
 
Coleta dos Requisitos: 
Quais as necessidades e solicitações do cliente ? 
Classificamos esta etapa como identificação de requisitos funcionais “R1” 
R1 - O cliente gostaria que tivesse um loggin e senha para acessar 
DATA VERSÃO MODIFICAÇÃO/ ALTERAÇÃO AUTOR 
23/03/21 1 CRIAÇÃO DESTE DOCUMENTO ELIANE 
23/03/21 1.1 DEFINIÇÃO REQUISITOS FUNCIONAIS REQUISITO R1 ELIANE 
23/03/21 1.2 DEFINIÇÃO REQUISITOS NÃO FUNCIONAIS R2 Raphael 
24/03/21 1.3 Preenchimento dos Requisitos R1.1 ao R1.5 Raphael 
mailto:elianeb.santos@yahoo.com.br
mailto:raphael.nara@gmail.com
mailto:luan.kevin@hotmail.com.br
mailto:val.barci@yahoo.com.br
mailto:financeiro@cvsempre.com.br
mailto:diretoria@cvsempre.com.br
16 
 
R1.1 - Um produto que armazene informações de estoque de todos os equipamentos, 
voltagem, tensão , marca modelo 
R1.2 - Uma tela em estilo calendário que permita inserir o agendamento. 
R1.3 - Uma vez criado o estoque no momento de digitar o item uma interface de inteligencia 
sugere a lista de itens: 
Exemplo: 
Cliente começa digitação 
Mi.. 
 
 
 Figura 2. Modelo de Sugestão de digitação solicitado pelo cliente 
 R1.4 - Assim que realizado o agendamento a tela permite a vizualização em vermelho no 
referido dia no calendario , ao clicar no quadrado (dia) um quadro maior se abre mostrando 
as informações de data , horário , qual sala, qual equipamento e quem solicitou o 
agendamento. Se possível informar para qual tipo de atividade o equipamento destina-se. 
Exemplo das informações que devem conter o agendamento, usaremos um para aula de 
Educação Fisica: 
1 Caixa Amplificada WLS 110/220v1 microfone Starphone 110/220v 
Data: 28/05/2021 Horario: 15 hrs 
Docente: Joao Marcos - Educação Fisíca 
R1.5 - Uma segunda tela que mantenha informações de quantos itens ficam em estoque e 
quais estão em manutenção 
Para que a prototipação fique perfeita e o documento de software tome forma, englobaremos 
a seguir a próxima disciplina que nos permitirá desenhar um modelo da tela interativa de alta 
fidelidade da interface, somar na documentação do software e adquirir as aprovações para as 
proximas etapas, que serão as definições de classes que nos possibilitarão a documentação 
final para avaliações, definição dos requisitos não funcionais e testes. 
 
 
Microfone 
Mixer 
 
 
Microfone SmartMidea c/ fio 110v 
Microfone Starphone s/ fio 110/220v 
Microfone/Fone de ouvido BT 
 
 
17 
 
9 PROJETO DE INTERFACE COM O USUÁRIO 
 
Podemos considerar esta disciplina como uma ferramenta extensora da Engenharia 
de Software. O modelo (desenho) interativo apresentado ao usuário no produto final tem a 
tarefa de transformar toda a linguagem computacional de códigos, classes e toda a parte 
formal, até então considerada desconhecida e chata pelos consumidores, para uma interação 
prazerosa, algumas vezes divertida e primordialmente de fácil usabilidade. Ou seja, as 
metodologias aplicadas no desenvolvimento de uma tela interativa de projeto de interface com 
o usuário podem definir o sucesso ou o fracasso de um software mesmo que bem projetado 
e perfeitamente codificado (SOUZA; COSTA; SPINOLA,2006). 
 “Um projeto pobre de interface com o usuário é a razão pela qual tantos sistemas de 
software nunca foram usados” (FRANCISCO GLAUBOS, UFMA). 
 
9.1 IHC (INTEGRAÇÃO HUMANO COMPUTADOR) 
 
 Segundo Brown, (1996) enquanto os engenheiros de software têm o foco voltado para 
o produto e seu processo (centrado ao sistema), os especialistas em Interação Humano-
Computador têm o foco mais voltado para os aspectos de interação do ser humano com a 
máquina (centrado no usuário). Dentre as diversas áreas de estudos da computação a IHC 
foca diretamente em definir e analisar as diversas formas de interação entre as pessoas e os 
sistemas computacionais. 
 De acordo com Nielsen (1993), o termo “amigável” utilizado para caracterizar a 
facilidade de uso das primeiras plataformas computacionais que surgiram no mercado, não 
era apropriado por ser desnecessariamente antropomórfico, ou seja, os usuários não querem 
ser amigos dos computadores, eles apenas precisam que os computadores não os 
atrapalhem. 
 Com as metodologias aplicadas pela área de IHC o desenvolvedor consegue gerar 
interfaces de sistemas que se encaixem ( se adequem) perfeitamente aos seus usuários e ao 
modo com que eles realizam suas tarefas , uma interface que se molde ao aprendizado do 
usuário e ofereça uma melhor interação torna o usuário mais confiante em suas atividades, 
da mesma maneira que uma interface de difícil manuseio desmotiva o usuário e faz com que 
ele procure outras ferramentas ( CIBYS, 2007). 
 Sommerville (2003) grande estudioso da área de Engenharia de Software, mostrou a 
importância da IHC como ferramenta relevante em desenvolvimento de sistema com foco no 
usuário, fator este que cresce a cada dia e caracteriza-se por ser quase impossível de ignorar 
nos dias de hoje. 
18 
 
 De acordo com Preece (1994), 10 disciplinas diferentes compõem um IHC impecável, 
na figura 3 destacamos 4 destas disciplinas como as principais, mas destaco aqui que Design, 
Inteligência Artificial, Linguística, Filosofia, Sociologia e a conhecida Engenharia completam 
esse pacote de disciplinas. 
 
 
 FIGURA 3. As 4 Principais disciplinas que compõe o IHC. 
 
 Todas essas disciplinas e métodos fornecem material para que questionários, 
análises e levantamentos sejam feitos e todos direcionado para o ser humano. 
Algumas das principais perguntas que o IHC responde são: 
• Quais são os hábitos do usuário? 
• Que tipo de ambiente de trabalho? 
• O que pensa? 
• O que espera? 
• Quais suas expectativas diante do novo software? 
• De que maneira o produto de software afeta aspectos culturais, físicos, sociais 
dos seres humanos? 
• De que maneira garantir o bem-estar e segurança dos usuários? Entre outras. 
 
9.2 Ciclo de Vida de um Software 
 De acordo com Sharp, Rogers e Preece (2005), o termo design não deve ser 
confundido com o design comumente traduzido como projeto e utilizado pela comunidade de 
Engenharia de Software para uma fase do modelo de ciclo de vida de software. Do mesmo 
modo, Leite (1998), destaca que a atividade de design da interface do usuário não deve ser 
confundida com a atividade de especificação da maneira proposta na Engenharia de Software, 
nem com o processo de construção do software. (Livro Texto Souza, Luciano Soares de. 
IHC
CIÊNCIAS 
DA
COMPUTAÇÃO
PSICOLOGIA 
COGNITIVA
ERGONOMIA 
E
FATORES HUMANOS
PSICOLOGIA 
ORGANIZACIONAL E 
SOCIAL
19 
 
Projeto de interface com o usuário. / Luciano Soares de Souza. – São Paulo: Editora Sol, 
2015). 
 Os modelos de ciclos de vida de um software são diferentes se comparados com o 
ciclo de vida de um software desenvolvido pela equipe de Engenharia de Software que foca 
o desenvolvimento, a implementação e a funcionalidade comparados a um Ciclo de Vida de 
Software desenvolvido pela equipe de IHC que volta sua atenção para o design e 
desenvolvimento com a interação do usuário, o modelo mais comumente utilizado é o modelo 
estrela. 
 A Engenharia de Software propõe diversos modelos de processos de softwares, nas 
figuras 4 e 5 destaco a diferença entre as áreas de Engenharia e IHC. Na figura 4 vemos um 
modelo de ciclo de software que utilizaremos neste projeto e mais comumente utilizado o 
modelo cascata. E na figura 5 temos o modelo de processos de interface com o usuário em 
formato estrela. 
 
 
 
 
 
 
 
 
 
 Figura 4 Processos de Engenharia de Software Modelo Cascata 
 
 
 
 
 
Requisitos 
Análises 
Projeto 
Implementação 
Implementação 
Testes 
20 
 
. 
 Figura 5. Ciclo de Software IHC Modelo Estrela 
 As figuras por si só já demonstram as relevantes diferenças nas etapas e processos. 
 
9.3 Completando as Documentações Para a Prototipação 
Para que o Escopo do projeto tome forma, alguns requisitos específicos precisam ser 
identificados nesta etapa são analisados o ambiente, de que forma as tarefas são realizadas, 
qual o grau de intimidade com sistemas computacionais dos usuários e etc. O usuário espera, 
normalmente, que o sistema seja rápido, de uso e aprendizagem fáceis e que apoie 
efetivamente a execução de suas tarefas diárias. Entretanto, o contratante do novo sistema 
privilegia, geralmente, o baixo custo, prazos curtos de entrega do produto e uma vida longa 
do sistema (LIESENBERG, 2005) (Livro Texto Unidade III , Souza, Luciano Soares de. Projeto 
de interface com o usuário. / Luciano Soares de Souza. – São Paulo: Editora Sol, 2015). 
Algumas Documentações já apresentadas anteriormente nos requisitos R1 e suas 
sequencias embasam as informações para compor as análises para a área de projeto de 
interface com usuários, a seguir finalizaremos com as informações necessárias para esta 
etapa: 
9.3.1 (Segmentos) Papéis dos Usuários 
Por se tratar de um colégio de grande porte apenas os responsáveis pela secretaria e 
estoque de equipamentos terão acesso com um login e senha. 
21 
 
Identificação Descrição Principais 
Características 
Critérios de 
Sucesso 
Envolvimento 
Diretora Responsáveis Trabalham em Realizar o 
lançamento dos 
equipamentos, 
com descrição 
de voltagem e 
modelo 
Irá realizar o 
agendamento 
de acordo com o 
pedido 
Secretária Pelos 
agendamentos 
Setores de 
diretoria e 
Agendar o dia e 
a hora da 
reserva 
Dos docentes 
Responsável 
pelos 
equipamentos 
E pelos 
equipamentos 
organizacionais Cominformações de 
Disciplina e 
Docente que 
solicitou e 
identificar quais 
equipamentos 
estão em 
manutenção 
Além de 
agendar é o 
responsável por 
enviar os itens 
para 
manutenção 
 Tabela 4 Papéis dos Usuários 
Por se tratar de um ambiente escolar, definiremos o ambiente de trabalho como sendo: 
Computadores da Escola: Sistema em Rede, computadores dispostos respectivamente nas 
salas da diretoria, secretaria e estoque/manutenção de equipamentos. 
9.3.2 Principais Características 
 Nesta etapa descrevemos e definimos o grau de priorização de itens que não podem 
faltar ou falhar no sistema. Nos permite olhar amplamente para dentro da empresa, quais suas 
disponibilidades e reais necessidades para facilitarmos sua rotina. 
22 
 
 Tabela 5. Características Principais Para Compor o UI 
 Vale ressaltar a importância dessas documentações, no momento de descrever esse 
projeto me deparei com informações, necessidades e requisitos que enriquecem o sistema 
voltando assim algumas vezes para acrescentar e/ou corrigir. 
 9.4 Prototipação de Alta Fidelidade 
 Chegamos na Etapa que dá vida a todos os estudos, basicamente é o produto que o 
cliente verá, é a sua tela de interação e manuseio. 
 Não faremos aqui modelos desenhados como um protótipo inicial, mas vale ressaltar 
que se trata de uma prática muito comum em Projetos de Interface com o Usuário. 
 A tela inicial se apresenta com login e senha como vemos na figura 6. 
 
 
Prioridade Característica Beneficio 
Alta Ser de Fácil Acesso e 
Utilização 
Permite que qualquer 
pessoa sem conhecimentos 
computacionais acesse 
Alta Tempo de Resposta 
imediato 
Uma Interação Rápida, e o 
tempo de reposta em 
milésimos de segundo 
facilitará a identificação de 
equipamentos e Datas 
Alta Ter uma Base de Dados 
Robusta/ Volumosa 
Quanto mais dados , mais 
informações e dessa forma o 
usuário encontrará sempre 
tudo que procurar Ex 
histórico de reservas feitas 
no passado. 
Alta Permitir Acesso a 
Deficientes Físicos 
O sistema deve 
obrigatoriamente oferecer 
acessibilidade, pois não 
sabemos se a escola dispõe 
de funcionários com 
necessidades especiais ou 
venha a ter no futuro. 
23 
 
 
 
 
 
 
 
 
 Figura 6. Tela de Login e Senha e Validação de Dados Corretos 
 No exemplo da Figura 6. O usuário digitou corretamente, assim o ícone de correto 
aparece na parte inferior dando o comando para a próxima página. 
 A Figura 7. Ilustra o Menu Inicial, com os comandos de Cadastro de Equipamentos, 
calendário de reservas, manutenção, reserva de item e eventos (para eventos especiais). No 
exemplo o usuário seleciona a opção reserva de item, imediatamente um calendário do ano 
se abre no canto inferior. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 7. Tela Menu Inicial 
24 
 
 Continuando o exemplo, o usuário seleciona o mês de abril para realizar uma reserva 
como vemos na figura 8. 
 
 
 
 
 
 
 
 
 Figura 8. Usuário seleciona o mês. 
 
 A próxima tela é um calendário no qual o usuário clica na data desejada para abrir a 
tela de agendamento em casos de dia já com agendamento, o preenchimento da coloração 
do número estará em vermelho. Exemplo na Figura 9. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Figura 9. Calendário Com Data Reservada e Seleção de Nova Data. 
 
25 
 
 A tela representada na Figura 10. Mostra a Opção de Cadastro de Equipamento. 
 
 
 
 
 
 
 
 Figura 10. Cadastro de Equipamentos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
10 Programação Orientada a Objetos 
 Um dos grandes marcos da informática foi realizado em 1963 por Ivan Sutherland, no 
MIT, em seu doutorado(PHD), o Sketchpad foi considerado o primeiro software 3D, o pioneiro 
nas atividades de edição gráfica orientado a objetos. Não apenas era possível colocar bits 
coloridos no canvas (cavalete), mas criar objetos que poderiam ser manipulados distintamente dos 
outros. E, mais importante ainda, o Sketchpad permitia que fosse definido um "master drawing" 
(desenho mestre), a partir do qual seriam criadas "instance drawing" (desenhos instanciados). 
As ideias do Sketchpad foram os pontos de partida para os conceitos herança em 
orientação a objetos. A programação em si, usando os conceitos de orientação a objetos, 
também teve origem na década de 1960, na Noruega, no Centro Norueguês de Computação, 
pelos pesquisadores Kristen Nygaard e Ole-Johan Dahl. Nessa época, foram criados os 
conceitos sobre classe e herança (que serão apresentados em detalhes) implementados na 
linguagem simula 67 (LINDEN, 2008; SEBESTA, 2011). 
A terceira versão do Sketchpad estendeu seu sistema de duas dimensões para três 
dimensões. Foi o primeiro editor gráfico a implementar as tradicionais vistas ortogonais com vistas 
em perspectiva em escalas diferentes. Na figura 11 vemos uma imagem de Ivan Sutherland 
(1963), manuseando o promissor Sketchpad. 
 
 
 
 
 
 
 
 
 
 Figura 11. Ivan Sutherland manuseando o Sketchpad 
 Alan Curtis Kay (Springfield, 17 de maio de 1940) é um informático estadunidense. É 
conhecido por ter sido um dos inventores da linguagem de programação Smalltalk, e um dos pais 
do conceito de programação orientada a objetos, que lhe valeu o Prêmio Turing em 2003. 
Concebeu o laptop e a arquitetura das modernas interfaces gráficas dos computadores, s, Alan 
Kay estudava maneiras de interpretar os problemas do mundo real de uma maneira que o ser 
https://pt.wikipedia.org/wiki/Springfield_(Massachusetts)
https://pt.wikipedia.org/wiki/17_de_maio
https://pt.wikipedia.org/wiki/1940
https://pt.wikipedia.org/wiki/Inform%C3%A1tica
https://pt.wikipedia.org/wiki/Povo_dos_Estados_Unidos
https://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Smalltalk
https://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_objetos
https://pt.wikipedia.org/wiki/Pr%C3%AAmio_Turing
https://pt.wikipedia.org/wiki/Laptop
27 
 
humano conseguisse abstrair os conceitos fundamentais de tal problema e inferi-los no mundo 
computacional. Dessa forma, Alan Kay percebeu que um substantivo isolado na mente de 
uma pessoa gera uma forma concreta, mas um verbo isolado na mente de uma pessoa não. 
Logo, um verbo faz parte de um substantivo. Partindo dessa premissa, torna-se fácil para nós, 
seres humanos, perceber que “correr”, isoladamente, não gera uma informação real (torna-se 
uma ação sem sentido). No entanto, “crianças correm” gera uma informa real em nossa mente, 
na qual o substantivo é “crianças” e o verbo é “correr”. A partir dessas observações, Alan Kay 
definiu os princípios da POO: 
• qualquer coisa no mundo real é um objeto; 
• objetos realizam tarefas por meio de ações; 
• cada objeto pode ser agrupado em tipos (classes); 
• um tipo de objeto (classe) deve agrupar objetos por similaridade de forma e 
comportamento; 
• cada tipo de objeto (classe) é organizado hierarquicamente. (Livro Texto Unidade I 
Lopes, Helder Frederico. Programação orientada a objetos I. / Helder Frederico Lopes, 
Olavo T. Ito. – São Paulo: Editora Sol, 2015). 
A POO Programação Orientada a Objetos elevou a eficiência, diminuiu tempo e custos e 
enriqueceu grandemente os processos de desenvolvimento de software, sua principal 
característica é a de desmistificar os métodos de programação estrutural/modular na qual 
temos umasequência de instruções com interação com o usuário, chamada a sub-rotinas e 
tomadas de decisão, a POO vai além desse modelo de programação. Nos casos da 
programação estrutural se o programador quiser reutilizar códigos ele só consegue por meio 
de cópias, e caso essas cópias sejam muito utilizadas isso pode gerar um conflito gigantesco 
se o programa por qualquer motivo sofrer alguma alteração em uma dessas cópias, denota 
uma quantidade de tempo muito maior para que a correção seja feita em todos os códigos 
reutilizados. Em resumo a POO diminui a documentação gerada no processo de 
desenvolvimento tornando o foco principal na regra do negócio e nas necessidades e não na 
programação, diminui, mas não isenta o programador de documentar de alguma forma. 
Segundo a Microsoft, a programação orientada a objeto (POO) é apoiada em três pilares: 
encapsulamento, herança e polimorfismo (MICROSOFT, 2014; SINTES, 2002). Explicaremos 
cada um deles nas páginas a seguir dando forma a nosso projeto. No entanto para o nosso 
projeto colocaremos mais um, que é a abstração. A melhor forma de visualizar projetos de 
softwares desenvolvidos por POO se dá a partir da utilização de gráficos, mais 
especificamente a Unified Modeling Language (UML). Portanto, os gráficos utilizados neste 
28 
 
material seguirão as definições da UML, que é um padrão no que diz respeito a projetos de 
softwares em POO. 
 
10.1 Abstração 
Como estamos lidando com uma representação de um objeto real (o que dá nome ao 
paradigma), temos que imaginar o que esse objeto irá realizar dentro de nosso sistema. São 
três pontos que devem ser levados em consideração nessa abstração. Devemos em primeiro 
lugar dar um nome criar uma identificação ao objeto que vamos gerar, essa identificação deve 
ser única dentro do sistema par que não haja conflito, denominamos “classe”, em seguida vale 
pensar que qualquer objeto no mundo real tem suas características próprias, definiremos 
como “atributos ou propriedades”, e por último damos ao sistema a atividade que ele 
executará assim denominados “métodos” 
Quando temos mais de um objeto, é importante observar a relação entre eles. Esses 
objetos podem existir independentemente entre si e se precisarem interagir, o farão por meio 
de mensagens. São as mensagens que fazem com que outro objeto realize alguma operação. 
Um segundo e importante modo de interação ocorre quando os objetos estão profundamente 
ligados entre si, de forma que o comportamento de um objeto depende do comportamento de 
outro. Um objeto pode conter outro dentro de si ou viver em simbiose entre si 
 Com base nas informações do nosso projeto podemos definir as classes, atributos e 
métodos como uma classe para equipamentos exemplo na figura 12, criamos a classe 
equipamentos de áudio que permite agrupar todas as características dos objetos ( atributos) 
e executa as funções de agendar data da reserva ou informar que o equipamento está em 
manutenção , e a classe reserva de equipamentos nos permite as propriedades voltadas para 
data, horário e identificação da disciplina e docente responsável, dando o comando de 
execução agendar data e hora como método. Neste processo abstraímos para dentro de uma 
única classe (classe equipamentos de áudio) todos os equipamentos relacionados. 
29 
 
 Figura 12. Exemplo de Classe, Atributos e Métodos em Abstração 
10.2 Encapsulamento 
Neste pilar tratamos da segurança da aplicação, e criamos uma espécie de caixa preta 
para esconder as propriedades, os atributos do nosso sistema. A maior parte das linguagens 
orientadas a objetos implementam o encapsulamento baseado em propriedades privadas, 
ligadas a métodos especiais chamados getters e setters, que irão retornar e setar o valor da 
propriedade, respectivamente. Essa atitude evita o acesso direto a propriedade do objeto, 
adicionando uma outra camada de segurança à aplicação. Na figura 13 temos um exemplo 
de encapsulamento. 
 
 
 
 
 
 
 
 
 Figura 13. Encapsulamento de características dos Equipamentos 
Equipamentos de Aúdio
Tipo: Caixa Amplificada
Marca: WLS
Modelo: WLS J15
Número de Série: 015236
Voltagem: Bivolt
______________________
Agendar Data
Lançar em Manutenção
Tipo: Micro System
Marca: Samsung 
Modelo: Sw5817N
Série: 00098
Voltagem: 110v
__________________________
Agenda Data
Lançar em Manutenção
Reserva de Equipamentos
Data da Reserva 05/08/21
Horário: 15rhs
Disciplina: Educação Fisica
Docente: Luiz Alberto 06298
___________________________
Armazena Data/Hora no 
Calendário
Equipamentos 
Tipo: 
Marca: 
Modelo: 
Série: 
Voltagem: 
Agenda Data 
Lançar em 
Manutenção 
Equipamentos de 
Áudio 
Tipo: Caixa 
Amplificada 
Marca: Samsung 
Modelo: SW1857A 
Série: 0523789 
Voltagem: 110/220v 
Fiação 
Equipamentos de Vídeo 
Tipo: Projetor de Parede 
Marca: Sony 
Modelo: RPSN 4899 
Série: 000017 
Voltagem: 110/220v 
Fiação 
Fiação 
Com Fio 
Portátil sem fio 
Oferece opção 
30 
 
 No exemplo, utilizamos a classe Fiação para criar as características com fio e portátil 
sem fio, dessa forma sabendo que muitos dos equipamentos possuem essas características 
e no momento da reserva podemos criar uma forma de escolher um objeto apenas pelas 
opções de com ou sem fio. 
10.3 Herança 
Herança é um dos atributos fundamentais da programação orientada a objeto. Ela permite 
que você defina uma classe filha que reutiliza (herda), estende ou modifica o comportamento 
de uma classe pai. A classe cujos membros são herdados é chamada de classe base. A classe 
que herda os membros da classe base é chamada de classe derivada. A herança diz respeito 
à extensibilidade de classes no modelo orientado a objetos. Quando se diz estender 
determinada classe, entende-se que uma nova classe será criada, contendo suas próprias 
propriedades e características e, agregando a esta nova classe as propriedades e 
características de outra já existente a qual é conhecida também como uma classe Genérica 
(ou superclasse). Já a nova classe é conhecida como classe especializada (ou subclasse) 
 
 
 
 
 
 
 
 
 
 
 
 Figura 14. Herança de Classes 
 Na Figura 14. Fizemos uso da Herança para utilizar as informações da reserva dia, 
mês ano e atribuir ao calendário juntamente com as informações de quem reservou. Dessa 
forma o comando gera a reserva no dia e hora e cria um arquivo com as informações do 
docente solicitante. A herança permite que você baseie a definição de uma nova classe em 
uma classe previamente existente. Quando você baseia uma classe em outra, a definição da 
Reserva de Equipamentos 
Dia: 
Mês: 
Ano 
Hora: 
 
Dia Reservado 
Dia: 
Mês: 
Ano 
Hora: 
Marca reserva no Calendário de 
acordo com o dia digitado 
Reservado Para: 
Docente: 
Disciplina: 
Criar Pasta de Dados no dia 
reservado 
Informar quem reservou 
31 
 
Reserva de 
Equipamentos 
Calendário Equipamentos 
nova classe herda automaticamente todos os atributos, comportamentos e implementações 
presentes na classe previamente existente (SINTES, 2002, p. 72) 
 
10.4 Polimorfismo 
Polimorfismo significa muitas formas. Em termos de programação, o polimorfismo 
permite que um único nome de classe ou nome do método represente um código diferente, 
selecionado por algum mecanismo automático. Assim, um nome pode assumir muitas formas 
e como pode representar código diferente, o mesmo nome pode representar muitos 
comportamentos diferentes (SINTES, 2002, p. 122). 
Na natureza, vemos animais que são capazes de alterar sua forma conforme a 
necessidade, e é dessa ideia que vem o polimorfismo na orientação a objetos. Como 
sabemos, os objetos filhos herdam as características e ações de seus “ancestrais”. Entretanto, 
em alguns casos, é necessário que as ações para um mesmo método sejam diferentes. Em 
outraspalavras, o polimorfismo consiste na alteração do funcionamento interno de um método 
herdado de um objeto pai. 
O conceito chave para entendermos o polimorfismo é: 
• Cada objeto sabe fazer a coisa certa em resposta a mesma chamada de 
método! 
A grande vantagem de utilizar o Polimorfismo é que permite que projetos e sistemas 
sejam facilmente extensíveis, ou seja, acrescentar novas classes a qualquer parte do 
programa com pouca ou nenhuma codificação. 
 
 
 
 
 
 
 
 
 Figura 15. Polimorfismo 
32 
 
11 Teste Finais 
A atividade de testar software é o processo de executar o sistema com a intenção de 
descobrir um erro. 
O que é um teste bem-sucedido? 
É aquele que revela um erro ainda não descoberto. 
Cenários comuns no contexto de testes de softwares 
▪ Falta de planejamento do tempo e custo; 
▪ Preparação e execução do teste são feitas superficialmente; 
▪ O teste é a última etapa do processo de desenvolvimento; 
▪ Testes são tratados como causador de aumento dos custos e prazos dos projetos; 
▪ Testes são executados pela equipe de desenvolvimento; 
Esses cenários são vistos com frequência nas empresas de software. Temos que levar 
em consideração que a falta de planejamento e preparação, a execução tardia e pelos 
próprios desenvolvedores influenciam negativamente na qualidade dos produtos. Os 
testes devem ser efetuados de maneira planejada e por profissionais de teste. 
Testar software envolve: 
▪ Processos 
▪ Equipe de Teste 
▪ Versões de softwares 
▪ Releases 
▪ Ferramentas 
11.1 Testes Modelo V 
Nosso Projeto se finda com os testes no modelo V, conforme Figura 15. Planejamos a 
aceitação com a análise de requisitos, em seguida, projetamos o sistema com projeto 
de alto nível do software, utilizamos das ferramenta de IHC, e por fim os testes de 
codificação. 
 
 
33 
 
 
 
 
 
 
 
 
 
 
 Figura 16. Modelo V Testes Finais 
 
12 Conclusão 
 
Este Projeto Multidisciplinar V, teve por objetivo maior explanar contextos das disciplinas 
Economia e Mercado, Engenharia de Software, Projeto de Interface com Usuário e 
Programação Orientada a Objetos, fiz um apanhado geral das metodologias e compus as 
documentações de software necessárias para o Sistema do Colégio Vencer Sempre, ao longo 
do processo me peguei refazendo, revendo informações, dando ênfase ao modelo proposto 
pelo então “cliente”, e percebi como de fato a essas documentações relevantes se fazem 
obrigatórias, imprescindíveis e indispensáveis, sem projeto não tem sistema , sem 
planejamento não tem projeto, não tem produto e sem testes não tem qualidade, sem 
qualidade não há sucesso! 
Para ingressar num mercado tão competitivo como o de Softwares, a qualidade, o 
conhecimento total do que se produz, o domínio sobre as metodologias ágeis e todo o 
ambiente que cerca a atividade de produção de um sistema tornam o programador, amador. 
Percebo o quanto o caminho para a excelência e qualidade em sistemas é longo e árduo, 
mas me sinto privilegiada por me permitir desbravar tão vasto e rico novo mundo. O mundo 
da tecnologia. 
 
 
34 
 
14. Referencias 
Livro Texto Souza, Luciano Soares de. Projeto de interface com o usuário. / Luciano Soares 
de Souza. – São Paulo: Editora Sol, 2015). 
https://cidades.ibge.gov.br/brasil/sp/sao-paulo/pesquisa/13/5908 
https://www.bbc.com/portuguese/geral-46655386 
https://conteudo.movidesk.com/empresa-de-software/ 
 
(Engenharia de Software II. / André Luiz Ribeiro. – São Paulo: Editora Sol, 2015). 
 
http://www.linhadecodigo.com.br/artigo/2622/sobrecarga-heranca-polimorfismo-e-excecao-
em-csharp.aspx#ixzz6rs40UVZa 
https://www.take.net/blog/tecnologia/o-que-e-prototipacao 
https://slideplayer.com.br/slide/3136717/ 
 
 
https://cidades.ibge.gov.br/brasil/sp/sao-paulo/pesquisa/13/5908
https://conteudo.movidesk.com/empresa-de-software/
https://www.take.net/blog/tecnologia/o-que-e-prototipacao