Pim IV - Sistema de teleatendimento médico

Prévia do material em texto

UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia
PROJETO DE UM SISTEMA DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS
	
Polo Universidade Paulista UNIP- Sorocaba-SP
2020
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia
		
Aluno: Renan Yohan de Lara
RA: 1969781
Curso: Análise e desenvolvimento de sistemas
2º Semestre 2020
	
Polo Universidade Paulista UNIP- Sorocaba-SP
2020
RESUMO
Este trabalho tem por objetivo desenvolver um plano de negócios para uma nova startup. Além disso, especificar os requisitos necessários de um sistema de teleatendimento médico, conforme a solicitação do cliente, visando esse momento de pandemia que passamos. Esse projeto visa diminuir aglomerações em hospitais para que não se espalhe a doença do novo Covid-19. Foram utilizadas as técnicas de elaboração de Casos de uso, levantamento de requisitos, Regras de negócio, foram abordados os seguintes diagramas: Casos de uso, Atividades, Classes, Sequência, Componentes e de Implantação. Abordando também técnicas de gerenciamento de projeto de software.
O intuito é que esta documentação seja clara e sucinta provendo condições para o desenvolvimento proposto.
Palavras-chave: Pandemia, Covid-19, Teleatendimento, Aglomeração.
1
ABSTRACT
This work aims to develop a business plan for a new startup. In addition, specify the necessary requirements of a medical teleservice system, as requested by the client, aiming at this pandemic moment we have passed. This project aims to reduce agglomerations in hospitals so that the disease of the new Covid-19 does not spread. We used the techniques of preparation of use cases, requirements gathering, business rules, the following diagrams were addressed: Use cases, Activities, Classes, Sequence, Components and Implementation. Also addressing software project management techniques.
The aim is for this documentation to be clear and succinct, providing conditions for the proposed development.
Keywords: Pandemic, Covid-19, Call Center, Agglomeration.
2
SUMÁRIO
Introdução ......................................................................................................... 3
Empreendedorismo .......................................................................................... 4
 Mercado consumidor em potencial ................................................................... 4
 Benefícios ......................................................................................................... 4	
 Estimativa de receita ......................................................................................... 5
 Estrutura de custos ........................................................................................... 5
 Receitas ............................................................................................................ 9
 Marketing ........................................................................................................ 10
Projeto App Telemedicina .............................................................................. 11
 Os desafios dos aplicativos de telemedicina ................................................... 11
 Benefícios que atraem o paciente ................................................................... 12
 Benefícios que atraem os médicos ................................................................ 13
Planejamento para o desenvolvimento do App ........................................... 14	
Requisitos Funcionais ................................................................................... 14
Requisitos Não Funcionais ............................................................................ 18
Regras de Negócios ....................................................................................... 20
Diagrama de Casos de Uso ............................................................................ 22
 Elaboração dos Casos de Uso ....................................................................... 23
 Especificação dos Casos de Uso ................................................................... 25
Diagrama de Atividades ................................................................................. 28
Diagrama de Classes ...................................................................................... 29
Diagrama de Sequência ................................................................................. 31
Diagrama de Componentes e implantação .................................................. 32
Gestão da qualidade ....................................................................................... 33
 CMMI .............................................................................................................. 33
 Representações do Modelo CMMI ................................................................. 34
 Representação por estágio ............................................................................ 34
 Porque escolhemos CMMI ............................................................................. 36
Gerenciamento do projeto de software ........................................................ 37
 Termos de abertura do projeto de software ................................................... 38
 Cronograma de atividades e custos ............................................................... 39
 Análise de risco .............................................................................................. 40
 Framework CMMI ........................................................................................... 42
 Lições aprendidas .......................................................................................... 45
Conclusões ..................................................................................................... 46
Referências ..................................................................................................... 47
INTRODUÇÃO
Este trabalho apresenta um projeto de software de teleatendimento médico, que tem como propósito diminuir as visitas e agilizar os atendimentos médicos em época de pandemias nos hospitais. Com a nova Covid-19 devemos por segurança evitar qualquer tipo de aglomeração em hospitais para que a doença não continue se espalhando, logo o software de teleatendimento é essencial para este momento que estamos passando, pois os atendimentos remotos podem ajudar a diminuir a pressão nos sistemas de saúde, deixando assim os hospitais livres para quem, realmente, precisa de atendimento presencial.
Apresenta-se um plano de negócio para a startup que realizará o projeto, além de termos extremamente técnicos envolvendo diagramas e todo o processo de gerenciamento do projeto de software. Buscamos analisar as estratégias para o desenvolvimento completo do software. Nessa análise será verificado o comprometimento de todos dentro da equipe na busca de um planejamento sem falhas. 
3
EMPREENDEDORISMO 
Plano de negócio – A startup 
A Match Tech (nome escolhido para nossa startup), é uma empresa que está prestes a começar um negócio no segmento de tecnologia que por objetivo é oferecer serviços à outras empresas que precisam resolver problemas com a improdutividade ou que planejam inovar nos seus negócios através de aplicativos Web/mobile. 
A Match Tech é responsável pelo desenvolvimento desses aplicativos. A equipe será formada por 8 profissionais da área de tecnologia, marketing e pessoal que irão garantir a qualidade para o produto de software definido pela empresa que optar pelos nossos serviços.
Mercado consumidor em potencial
- Empresas de diversos setores;
- Microempreendedores;
- Órgãos públicos;
Benefícios de investir em parceria com a Match Tech
Esses programas são desenvolvidos com o intuito de facilitar as rotinas, evitar erros e permitir maior controle de tudo o que aconteceno negócio. Assim, dados e informações ficam mais organizados, os processos são otimizados e a produtividade aumenta, trazendo impactos positivos para a empresa de um modo geral.
Cada vez mais, ações e tarefas são cumpridas com o auxílio de recursos tecnológicos e da internet. Por isso, essa é uma tendência atual do mercado. Ela já é acompanhada por várias organizações. Assim, fazer uma parceria com a Match Tech, empresa de desenvolvimento de software ajuda a modernizar a gestão e os processos de seus negócios. 
Softwares ajudam a tornar a gestão do negócio mais simplificada e automatizada. Como tudo fica reunido em um só lugar, os dados e informações são registrados de forma mais fácil, contribuindo para aumentar a produtividade da empresa.
Diversas ações, por serem cumpridas pelo programa, não dependem da atuação de um ser humano. Assim, além de reduzir a carga de responsabilidades e tarefas também minimizamos as chances de acontecerem erros. Desse modo, não é necessário refazer trabalhos e os processos e rotinas fluem sem nenhuma complicação.
4
Estimativa das fontes de receita da Startup
 
As principais fontes de renda da Match Tech são vendas de aplicativos que já estão concluído, e que o único trabalho é a implantação e a manutenção. Logo, esse serviço saíra mais barato por não ter tanto trabalho.
Temos também, vendas de softwares mais específicos para clientes que optam por um aplicativo próprio ou que precisam de algo inovador, porém, a estimativa de tempo para a implantação é muito maior porque passa por um longo processo 
de reunião com os envolvidos no projeto para que se possa entender as necessidades do cliente, apresentação do escopo do software, definir quais ferramentas serão utilizadas no desenvolvimento, além de fazer estimativas de prazo de entrega e custos, para enfim desenvolver o aplicativo. Diante disso, o custo será mais elevado, além do custo mensal pela manutenção, assim como no serviço citado anteriormente.
Apresentamos abaixo uma tabela com preços baseado no mercado hoje. Vale ressaltar que é apenas uma demonstração, apenas uma base, pois esses preços podem elevar de acordo com a complexidade do serviço.
Tabela de preços para cada tipo serviço: 
Tabela aplicativo pronto – Imagem 2
 
Tabela aplicativo próprio – Imagem 3
5
Estrutura de custos 
Abertura do negócio 
Para que a empresa possa cumprir todos os requisitos legais para sua abertura, uma série de consultas deverão ser realizadas e vários documentos deverão ser elaborados e entregues em diversos órgãos, Tais como Prefeitura de Sorocaba, a Junta Comercial do Estado e a Receita Federal. Todo esse processo tem um custo, decorrente do pagamento de taxas e afins. 
A tabela seguir, resume os gastos para abertura de uma empresa, segundo dados fornecidos pelos próprios órgãos e pesquisas realizadas. 
Tabela de gastos para abertura da startup – Imagem 4
Recursos físicos necessários para o funcionamento do negócio
Para que a empresa inicie suas atividades alguns recursos físicos deverão ser adquiridos. A tabela abaixo mostra quais são estes recursos e seus respectivos valores:
Tabela de recursos físicos adquiridos – Imagem 5
6
Além dos recursos a serem instalados para que a empresa esteja em funcionamento, deve-se definir o imóvel em que será instalada a empresa e os respectivos gastos decorrentes de sua utilização. Por se tratar de uma empresa muito pequena que ainda está iniciando suas atividades do mercado de trabalho, optou-se por alugar um imóvel ao invés de comprá-lo. O imóvel será locado no Centro de Sorocaba, onde se encontram diversas empresas. A tabela, a seguir, resume as despesas mensais com as instalações.
Tabela de despesas mensais – Imagem 6
Investimentos iniciais 
Os investimentos iniciais são gastos necessários para que a empresa inicie suas atividades. Estes gastos não são corriqueiros, ocorrendo, normalmente, apenas no momento de sua abertura. Além disso, os investimentos iniciais não são apresentados nas demonstrações citadas, mas não são indispensáveis para o cálculo dos indicadores financeiros.
O capital que temos para investimento inicial da startup é no valor de R$ 380.580,00. Com isso, o capital de giro será suficiente para arcar com os custos e despesas da empresa não cobertos pelas receitas em seus primeiros meses de funcionamento mais o custo e despesas do mês subsequente, antes da entrada das receitas previstas para o mês.
Devido à dificuldade em se definir com exatidão os custos relacionados ao desenvolvimento do software, considerou-se o quanto aos funcionários e sócios deixariam de ganhar em um período de 6 meses, dedicados ao desenvolvimento do software e abertura da empresa. Foi estimado um valor de R$ 4.000,00 para cada um, totalizando R$ 32.000,00.
7
A tabela abaixo apresenta o valor do mês para o funcionamento do negócio: 
Investimentos iniciais para funcionamento do negócio – Imagem 
8
Receitas
A receita prevista para o negócio provém de implantações de aplicativos prontos, desenvolvimento de novos e pagamentos mensais da manutenção do software implantado. Como não há uma forma confiável de determinar o valor cobrado pelos serviços, será utilizado como base preços entre R$ 25.000,00 e R$ 50.000,00 pelo software bruto e R$ 5.000,00 de manutenção. 
Com base nesse valor médio estabelecido e na previsão de vendas calculada no plano de Marketing, será prevista a receita mensal para o ano de 2021, conforme na tabela abaixo.
Lembrando que o valor bruto da implantação só se paga uma vez, e o que permanece sendo pago é a mensalidade de manutenção. Vale a pena ressaltar também, que essa previsão é bastante otimista, talvez para obter este lucro será necessário mais tempo e mais investimento.
Tabela de previsão de vendas e serviços – Imagem 7
9
Planejamento de Marketing
Comunicação
Por apresentar um público-alvo bastante específico, a estratégia de comunicação da empresa será direcionada da melhor forma possível para esse público. Além disso, por se tratar de uma empresa em nascimento, com recursos financeiros limitados, serão desenvolvidas estratégias menos custosas à empresa, assim como mostramos na Imagem 7, mensalmente gastaremos R$ 5.000,00 para alcançar esse público.
A estratégia utilizada será baseada nos seus produtos e serviços, destacando-se o desempenho e a utilidade – a chamada comunicação de produto. Com a visibilidade oferecida pela internet, é extremamente importante a utilização deste canal para comunicação com o cliente. Para isso, a empresa irá desenvolver um website, que explicará todos os benefícios de nossos serviços de desenvolvimento de software. No entanto, não basta apenas criar o site sem que o cliente tenha conhecimento dele. Para isso será utilizada a técnica de marketing direto, através de envio de e-mail para as empresas que compõe o público-alvo com vistas a divulgar o lançamento do produto. 
Ainda no âmbito da internet, podemos utilizar as ferramentas do Google que ajudam a posicionar anúncios dentro das redes sociais, focando diretamente com o público-alvo. Espera-se que com essas campanhas, tornar o produto e os serviços conhecido para a grande parte do público desejado. 
Por fim, a força de venda será utilizada para dois objetivos específicos de comunicação. Primeiramente, para divulgação dos produtos diretamente nas empresas do setor, o chamado marketing direto. Para isso, os responsáveis pelo marketing irão apresentar uma página ou folheto de apresentação dos serviços ao cliente. 
	
10
Projeto aplicativo de telemedicina						11
O que são aplicativos de telemedicina?
Os aplicativos de telemedicina permitem basicamente 3 tipos de teleatendimento, o primeiro é a teleorientação, em que o especialista dá informações ao paciente sobre os sintomas e avalia se ele deve ficar em casa ou procurar um pronto atendimento. A segunda opção é o telemonitoramento, ou seja, o médico faz o acompanhamento remoto do paciente que já está sendo tratado.Por fim, existe a teleinterconsulta que é a discussão de um caso entre médicos de diferentes lugares.
Os desafios dos aplicativos de telemedicina
Construir um aplicativo de telemedicina envolve certos desafios, incluindo segurança e conformidade legal. Essa é uma breve visão geral do que você deve ter em mente ao iniciar o desenvolvimento do aplicativo de telemedicina:
1 – Segurança
Informações de saúde particulares são confidenciais. Aplicativos de telemedicina coletam e armazenam informações e, naturalmente, isso faz com que os clientes se perguntem se seus dados estão em um local seguro e quem tem acesso a eles.
Solução: Para proteger os clientes, você deverá implementar alguns fatores de autenticação como identificação biométrica (ou facial) e terá que encriptar os dados. Essas medidas aumentam a segurança do app e protege os dados, resguardando o usuário e colocando o app de acordo com a Lei Geral de Proteção de Dados. 								
2 – Falta de confiança								12
Outra preocupação é sobre a qualificação dos médicos. Pacientes querem ter certeza de que eles estão sendo atendidos por um profissional qualificado, não um recém graduado na universidade.
Solução: Testimoniais dos pacientes e um sistema transparente de avaliação disponibilizados para os clientes e consulta dos CRMs.
Benefícios que atraem os pacientes
· Conveniência: fazer consultas com antecedência, ir a uma clínica e esperar em uma fila longa não é a maneira mais conveniente de obter assistência médica. 
· Poupar tempo e tratamentos mais rápidos: os pacientes, além de poupar o tempo que teriam se locomovendo, podem iniciar o tratamento o quanto antes.
· Histórico médico na palma da mão: mesmo no mundo moderno, é difícil ter acesso ao seu histórico médico. Um aplicativo de telemedicina permite aos pacientes ver seus históricos e enviarem para outros membros da família, ou mesmo para outros médicos com o fim de melhor diagnóstico.
· Isolamento social: em tempos de pandemia, os aplicativos de telemedicina se mostram eficazes, pois os atendimentos à saúde são feitos sem necessidade de contato físico, fortalecendo ainda mais as medidas obrigatórias de isolamento social.
Benefícios que atraem os médicos						13
· Flexibilidade: de acordo uma pesquisa, 20% dos médicos e psiquiatras trabalham 60 a 80 horas semanais. Com um app de telemedicina, os médicos serão capazes de escolher seu próprio horário.
· Menos trabalho administrativo: em um hospital, grande parte do dia de um médico é gasto com documentos e tarefas administrativas. Como resultado, os médicos examinam menos pacientes e precisam ficar depois do trabalho para preencher toda a papelada. Um aplicativo de telemedicina minimiza a papelada e automatiza muitas tarefas.
· Mais pacientes e maior receita: menos papelada significa mais pacientes. E mais pacientes significam maiores receitas.
· Menos contato físico durante o novo coronavírus: num momento em que a recomendação das autoridades sanitárias é se manter isolado, o uso da telemedicina tende a contribuir para a contenção do vírus. Dessa forma, médicos e pacientes conseguirão interagir sem qualquer proximidade física, o que protege ambas as partes. 
Planejamento para o desenvolvimento do App				14
Neste capítulo abordaremos os requisitos pedido pelo cliente que solicitou o aplicativo de telemedicina. Falaremos primeiro sobre os Requisitos Funcionais e em seguida sobre os Requisitos Não funcionais.
Requisitos Funcionais 
Os requisitos de um software, também chamados de requerimento de software ou de requisitos funcionais de um sistema, devem ser elaborados no início de um projeto de sistema de software. Os Requisitos Funcionais são declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer.
Abaixo fica uma lista com todos os Requisitos Funcionas do sistema de telemedicina:
Principais recursos para pacientes:
Cadastro - #RF-01
Para criar um perfil, o paciente digita seu nome, endereço, sexo, idade, histórico médico e outros dados cruciais necessários para iniciar o processo de tratamento.
Agendamento de consultas - #RF-02
Um usuário pode ver uma lista de médicos, ver seus perfis e marcar uma consulta com o médico que escolher. Esse recurso é um dos mais importantes, pois fornece aos pacientes informações sobre a disponibilidade de um profissional e permite a reserva de um horário adequado para eles.
Videoconferência - #RF-03							15
Pacientes usaram esse recurso quando eles precisarem de um médico para examiná-los. Eles irão fazer uma análise inicial via vídeo, por isso a qualidade da chamada é muito importante. O diagnóstico adequado e o tratamento preciso dependem de uma boa conexão e de uma imagem nítida.
Chamadas por voz - #RF-04
Algumas pessoas preferem não serem vistas e por isso optam por comunicação sem vídeo. Para esse propósito, o aplicativo tem que oferecer chamadas por voz. Isso cria um canal seguro para pessoas que se sentem envergonhadas de falar sobre algum problema, ajudando-as a conseguir assistência qualificada. Ou então, para amenizar problemas com velocidades e capacidades da internet do paciente e do médico.
Lembretes e registros de medicamentos - #RF-06
O aplicativo guarda todas a prescrições que um médico escreveu. Além disso, o app envia notificações para lembrar os pacientes de tomar seus remédios.
Chat in-app - #RF-07								16
O paciente poderá usar um chat seguro dentro do app para contactar um médico para uma pergunta urgente ou se ele tiver qualquer questão sobre os medicamentos.
Recursos para médicos:
Cadastro - #RF-08
Um médico precisa fornecer seu nome, endereço, foto, especialização, CRM e disponibilidade. Eles também podem fornecer informações sobre sua experiência e educação.
Agenda - #RF-09
Os médicos podem fazer alterações em seus cronogramas com base em sua disponibilidade.
Gerenciamento de consultas - #RF-10
Os médicos podem ver sua lista completa de compromissos e aceitá-los ou rejeitá-los.
Chamadas de vídeo em tempo real - #RF-11
As vídeo chamada ajudam os médicos a examinar os pacientes com mais precisão. Um médico pode pedir a um paciente para mostrar sua pele ou garganta, por exemplo, para ver uma lesão de perto e fazer um diagnóstico.
Os médicos também podem usar chamadas somente de voz e opções de bate-papo internas para se comunicar com os pacientes. 
Acesso aos históricos médicos eletrônicos - #RF-12			17
Os médicos têm acesso aos registros médicos de todos os seus pacientes sempre que precisarem.
Prescrições digitais - #RF-13
Permite que os médicos prescrevam medicamentos diretamente no aplicativo. Os pacientes podem usar essas prescrições para comprar medicamentos ou para obter outros serviços de saúde em estabelecimentos médicos.
Requisitos Não Funcionais						 18
Os requisitos não funcionais, como o nome sugere, são aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema. Eles podem estar relacionados a propriedades de sistemas emergentes, como confiabilidade, tempo de resposta e espaço em disco. Como alternativa, eles podem definir restrições para o sistema, como a capacidade dos dispositivos de E/S (entrada e saída) e as representações de dados utilizadas nas interfaces do sistema.
Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a características individuais do sistema. Com isso ele se torna na maioria das vezes mais importantes do que os requisitos funcionais individuais. Pois quando falha pode deixar o sistema inútil, enquanto o requisito funcional apenas degrada o sistema. Por exemplo se um sistema de controle falha em cumprir o requisito de desempenho as funções de controle não irão funcionar direito.
Abaixo serão listadas todas os Requisitos Não Funcionais do App de telemedicina:
Disponibilidade do site 
A disponibilidade do site é uma premissa para toda a operação.O sistema deve apresentar práticas em configuração, administração e operação segura de redes conectadas à internet. A implantação destas práticas minimiza as chances de ocorrerem problemas de segurando e facilita a administração das redes e recursos de forma segura.
Segurança do acesso
Aplicação de práticas de segurança no sistema para prevenção de ataques ou acesso à dados do cliente. 
Garantir segurança através de validação com tokens, cross-origins entre outros.
Desempenho da rede
Garantir alto desempenho dos processos para agilidade nos processamentos internos do sistema e processos com Atores externos nos retornos de execução solicitados pelo usuário.
Usabilidade de fácil compreensão 
Os sistemas devem garantir os parâmetros básicos de usabilidade ao usuário e garantir o fácil aprendizado e memorização em sua utilização, provendo eficiência e segurança no acesso.
Responsabilidade do site							19
Garantir adequação de acesso ao site para todos os tipos de dispositivos com acesso mobile e desktops.
Backup
Sistema deverá fazer o backup dos dados de agendamentos dos pacientes de 30 em 30 minutos. 
Regras de negócio								20
Regra de negócio é o que define a forma de fazer o negócio, refletindo a política interna, o processo definido e/ou as regras básicas de conduta. Ou seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições, validações, condições e exceções do processo são exemplos clássicos de regras de negócio. Uma regra de negócio não necessariamente será refletida no sistema como uma funcionalidade, mas ela com certeza determinará o comportamento de uma ou mais funcionalidades do sistema.
O modelo de descrição foi determinado a partir de técnicas de documentação de regras de negócio e visam especificar condições e regras claras, que fogem ao formato de caso de uso que tem o papel relevante para o desenvolvimento.
			Imagem – Tabela Regras de Negócio_1
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Imagem – Tabela Regras de Negócio_2
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Imagem – Tabela Regras de Negócio_3
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Imagem – Tabela Regras de Negócio_4
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Imagem – Tabela Regras de Negócio_1
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
21
Diagrama de Casos de Uso
O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema que será projetado, é uma excelente ferramenta para o levantamento dos requisitos funcionais do sistema. Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo". Um caso de uso representa uma unidade discreta da interação entre um ator (humano, dispositivo ou outro software) e o sistema. Um caso de uso é uma unidade de um trabalho significante. Por exemplo: o "login para o sistema", "registrar no sistema" e "criar pedidos" são todos casos de uso. Cada caso de uso tem uma descrição da funcionalidade que será construída no sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio comportamento.
Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
Ator
O ator especifica um papel executado por um usuário ou outro sistema que interage com o assunto (sistema). O Ator deve ser externo ao sistema. Um ator deve ter associações exclusivamente para casos de uso, componentes ou classes a exceção que um ator possa herdar o papel de outro. Um ator é representado por um boneco palito (Stich man).
Caso de uso
É uma especificação de um conjunto de ações executadas por um sistema, que contém um resultado observável. Caso de uso é representado por uma elipse, com o nome do caso de uso dentro ou abaixo. Se há limites do sistema no diagrama, o caso de uso deve ficar dentro.
22
Elaboração dos Casos de Uso 
Análise do Caso de Uso
Com base no cenário proposto, foi identificado inicialmente os papéis a serem executados no sistema proposto, considerando relacionamentos com sistema sendo ela humanas ou de sistemas/hardware com interações no processo para identificação de atores e funções executadas no sistema que representam objetivos do sistema determinar os casos de uso a serem desenvolvidos nesta especificação.
Atores Identificados
 Paciente;
 Sistema de Agendamento;
 Médico;
Casos de Uso Identificados
 Realizar Cadastro Paciente/Médico;
 Disponibilidade do médico;
 Paciente escolhe Horário;
 Efetua agendamento;
 Médico confirma agendamento;
23
Na representação da Imagem – Diagrama de Caso de Uso – Efetuar agendamento/Consultas médicas, representação Diagrama de Caso de Uso, cujo objetivo é demonstrar relação dos atores com os casos de uso identificados.
Imagem – Diagrama de Caso de Uso – Efetuar Consultas médicas
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
24
Especificação dos Casos de Uso
Foram abordados na especificação os métodos de elaboração, que consistem na apresentação do caso de uso com sua breve-descrição, Pré-Condições, Pós-condições, fluxo principal e fluxos alternativos (nos cenários identificados).
Segue relação dos casos de uso que foram documentados em tabelas, apresentados nas imagens a seguir:
Imagem – Especificação de Caso de Uso – Realizar cadastro
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
25
Imagem – Especificação de Caso de Uso – Realizar cadastro médico
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
26
Imagem – Especificação de Caso de Uso – Realizar agendamento
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
27
Diagrama de Atividades
O modo para descrever os vários aspectos de modelagem pela UML é através da notação definida pelos seus vários tipos de diagramas. Um diagrama é uma apresentação gráfica de uma coleção de elementos de um modelo, frequentemente mostrado como um gráfico conectado de arcos e vértices (FURLAN, 1998).
Os diagramas usados pela UML são Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Objetos, Diagrama de Gráficos de Estados, Dia de Atividades, Diagrama de Implantação. Esses diagramas permitem a modelagem de todas a fases de um projeto de software.
Neste capítulo será utilizado o diagrama de atividades, que é um diagrama de estado especial onde a maioria dos estados é estado de ação e a maioria das transições é ativada por conclusão das ações nos estados precedentes, mostrando o fluxo de uma atividade para outra. Este diagrama é importante quando se pretende descrever um comportamento paralelo, pois nem sempre os procedimentos se caracterizam por uma sequência mecânica de passos. 
Imagem – Fluxo de atividade do médico.
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Imagem – Fluxo de atividade do paciente.
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
28
Diagrama de Classe
A Linguagem de modelagem unificada (UML) ajuda você a modelar sistemas de diversas maneiras. Um dos tipos mais populares na UML é o diagrama de classes. Bastante usado por engenheiros de software para documentar arquiteturas de software, os diagramas de classes são um tipo de diagrama da estrutura porque descrevem o que deve estar presente no sistema a ser modelado. Não importa seu nível de familiaridade com diagramas UML ou de classe, nosso software de UML online foi concebido para ser simples e fácil de usar.
A UML foi criada como um modelo padronizado para descrever uma abordagem de programação orientada ao objeto. Como as classes são os componentes básicos dos objetos, diagramas de classes são os componentes básicos da UML. Os diversos componentes em um diagrama de classes podem representar as classes que serão realmenteprogramadas, os principais objetos ou as interações entre classes e objetos. 
A forma de classe em si consiste em um retângulo com três linhas. A linha superior contém o nome da classe, a linha do meio, os atributos da classe e a linha inferior expressa os métodos ou operações que a classe pode utilizar. Classes e subclasses são agrupadas juntas para mostrar a relação estática entre cada objeto.
29
Imagem – Diagrama de classes.
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
30
Diagrama de Sequência 								31
Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a sequência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a sequência global do comportamento. O diagrama de sequência representa essa informação de uma forma simples e lógica.
Um diagrama de sequência descreve a maneira como os grupos de objectos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objectos e as mensagens passadas entre esses objectos no caso de uso.
Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, define-se qual o papel do sistema (Use Cases), depois, é definido como o software realizará seu papel (Sequência de operações).
O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objecto a outro, e as respostas desenvolvidas para as solicitações.
Usamos o exemplo abaixo de cadastro do paciente:
Imagem – Diagrama de sequência (Cadastro Paciente)
.
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
Diagrama de componentes e implementação
O diagrama de componentes e um dos dois diagramas da UML voltados a modelar software baseado em componentes. Tem por finalidade indicar os componentes do software e seus relacionamentos. (CLAIR 2010) Este diagrama mostra os artefatos de que os componentes são feitos, como arquivos de código fonte, bibliotecas de programação ou tabelas de bancos de dados. As interfaces e que possibilitam as associações entre os componentes. Concluindo, tem por finalidade indicar os componentes de software que o sistema possuirá e seus relacionamentos, onde são determinadas as configurações de hardware e seus relacionamentos, onde são determinadas as configurações de hardware e os componentes de software.
Imagine um sistema grande, onde temos uma aplicação web, que fala com diversos bancos de dados, comunica-se com diferentes serviços web etc. Nesses casos, é bastante importante que toda a equipe entende como os sistema se relacionam. É para isso que usaremos o diagrama de componentes.
Neste caso, apresentaremos como seria a representação do paciente utilizando o site de teleatendimento Médico.
Imagem – Diagrama de componentes (Login do paciente).
Fonte: Renan Yohan de Lara – Aluno UNIP 2020
32
Gestão da Qualidade
CMMI
Organizações de desenvolvimento de software vêm aumentando, ao longo do tempo, suas percepções relativas aos problemas que tipicamente são identificados durante a execução dos projetos, tais como: prazos e orçamentos não cumpridos, insatisfações dos clientes, produtos com erros, entre outros. Há algum tempo, existe um consenso na comunidade de engenharia de software de que estes problemas estão, em grande parte, relacionados ao fato de que o desenvolvimento de software é muitas vezes realizado de forma “artesanal”; isto é, através de métodos improvisados pelos desenvolvedores, os quais, por sua vez, muitas vezes dependem mais de seu talento individual que de uma sólida formação que oriente suas atividades. [SOMMERVILLE 2003]. O CMMI procura nortear a organização no sentido de implementar a melhoria contínua do processo de software, e o faz através de um modelo que contempla duas representações, divididas em níveis, priorizando de forma lógica as ações a serem realizadas. Quanto maior o nível, maior a maturidade da organização, o que pode se traduzir em maior qualidade do produto final com maior previsibilidade em cronogramas e orçamentos. O objetivo do CMMI é servir de guia para a melhoria de processos na organização, assim como para auxiliar a habilidade dos profissionais em gerenciar o desenvolvimento de aquisição e manutenção de produtos ou serviços de software, além de proporcionar a visibilidade apropriada do processo de desenvolvimento para todos os envolvidos no projeto. Isto é particularmente importante em grandes projetos que possuem equipes envolvendo dezenas de pessoas, pois, sem o apoio desses modelos de maturidade de processos de software como o CMMI, torna-se ainda mais difícil manter o controle do projeto. Com a utilização de níveis, o CMMI descreve um caminho evolutivo recomendado para uma organização que deseja melhorar os processos utilizados para construção de seus produtos e serviços. Os níveis também podem resultar de classificações obtidas por meio de avaliações realizadas em organizações compreendendo a empresa toda (normalmente pequenas), ou grupos menores, tais como um grupo de projetos ou uma divisão de uma empresa [SEI 2006]. Quando uma organização atinge um nível de maturidade, considera-se que seus processos alcançaram uma determinada capacidade, ou seja, tem mecanismos que garantem a repetição sucessiva de bons resultados futuros relacionados principalmente à qualidade, custos e prazos. Com isso, compreende-se que o modelo em uma organização pode ser alcançado em etapas consecutivas, representando a ideia de maturidade (avaliada por estágios) da organização, ou de maneira contínua, onde é mensurada a capacidade em processos individuais, conforme ilustrado na Imagem abaixo.
33
Representações do Modelo CMMI 
O CMMI possui duas representações: a estagiada e a contínua. A representação estagiada permite que as organizações melhorem um conjunto de processos interrelacionados e, de forma incremental, tratem sucessivos conjuntos de PAs. A representação contínua, por sua vez, permite que as organizações melhorem de forma incremental os processos correspondentes a uma ou mais PAs. A empresa seleciona em que áreas de processo ela será avaliada.
Representação por Estágios 
Esta representação preocupa-se com os processos da organização como um todo, oferecendo uma abordagem estruturada e sistemática para a melhoria de um estágio por vez. Atingir um estágio significa que uma estrutura de processo adequada foi estabelecida como base para o próximo estágio [SEI 2006]. As áreas de processo (PAs) são organizadas por níveis de maturidade – do nível “inicial” (nível 1) ao nível “em otimização” (nível 5) – que sugerem uma ordem para a implementação das áreas de processo. Cada nível possui várias PAs, e por sua vez, cada PA possui objetivos, práticas genéricas e específicas, assegurando assim uma base de melhoria adequada para o próximo nível de maturidade.
Na representação por estágios, quando uma organização atinge as práticas necessárias para estar em um nível, significa que atinge todos os requisitos necessários dos níveis imediatamente anteriores, conforme ilustrado na Imagem. [KOSCIANKI & SOARES 2007].
34
A partir da avaliação e do atendimento dessas práticas e metas é possível classificar o nível de capacidade de cada área de processo, em uma escala de 0 a 5 [KNEUPER 2009]: 
a) Nível 0 – Incompleto. Um processo é parcialmente realizado ou não, onde um ou mais objetivos específicos do processo não são satisfeitos. 
b) Nível 1 – Realizado. Um processo realizado satisfaz todos os objetivos específicos da área de processo e produz algum trabalho. 
c) Nível 2 – Gerenciado.Um processo de capacidade nível 2 é um processo realizado (nível 1) que também é planejado e executado de acordo com políticas pré-definidas. Emprega pessoas hábeis com os recursos adequados para produzir saídas adequadas, envolve os stakeholders principais e é monitorado, controlado, revisto e avaliado quanto à aderência à sua descrição. A gerência do processo é relacionada com a realização de objetivos específicos estabelecidos para o processo, como custo, cronograma e qualidade. 
d) Nível 3 – Definido: Um processo definido é um processo gerenciado e ajustado para o conjunto padrão de processos da organização de acordo com suas políticas de conduta. Esse conjunto é estabelecido e melhorado com o tempo e descreve os elementos fundamentais de processos que são esperados nos processos definidos. 
e) Nível 4 - Gerenciado quantitativamente: Um processo neste nível é definido e controlado com a ajuda de técnicas quantitativas e estatísticas. A qualidade e o desempenho do processo são compreendidos em termos estatísticos e são geridos durante sua vida. Objetivos quantitativos para qualidade e desempenho de processos são estabelecidos e usados como critério na gerência do processo. Nível 5 – Em otimização: Um processo em otimização é gerenciado quantitativamente, alterado e adaptado para atender aos objetivos de negócio atuais e projetados. Tal processo enfatiza a melhoria contínua através de aprimoramentos tecnológicos inovadores e incrementais, selecionados com base em uma compreensão quantitativa de sua contribuição esperada à obtenção da melhoria de processos.
Método de Avaliação do CMMI (SCAMPI)
A avaliação de uma organização de acordo com o CMMI deve ser realizada de forma objetiva. Portanto, é necessário haver um processo onde a organização possa ser avaliada de forma repetível e não haja discordâncias entre uma mesma avaliação aplicada em organizações distintas. Com esse objetivo, o SEI criou o SCAMPI (Standard CMMI Appraisal Method for Process Improvement), um método utilizado para avaliação do modelo de referência CMMI. Ele foi projetado para atender todas as exigências de uma avaliação, podendo ser também utilizado para o modelo ISO/IEC 15504. O SCAMPI está atento aos seguintes aspectos [SCAMPI 2001]: • Ganho da acuidade de uma organização identificando os pontos positivos e negativos de seus processos atuais; • Grau de relacionamento que estes pontos positivos e negativos têm com o modelo CMMI; • Priorização de planos de melhoria; • Concentração nas melhorias; A consolidação dos resultados das avaliações executadas é mantida pelo SEI. Tais dados são registrados de forma a catalogar os perfis de maturidade das organizações já avaliadas. Este perfil é baseado em avaliações providas por profissionais treinados do SEI, sendo atualizado semestralmente [SCAMPI 2001].
Porque escolhermos CMMI?
O uso do CMMI garante que os prazos e custos que foram acordados com os clientes antes do início do desenvolvimento de um software sejam cumpridos. Isso ocorre porque o CMMI orienta o planejamento bem-estruturado, baseado em dados históricos que possibilitam previsões precisas, sem imprevistos no percurso das ações.
Quando uma empresa opta por CMMI, a distribuição de tarefas fica mais clara, e elas são executadas de forma mais produtiva. Com isso, a empresa experimenta economia de custos, equipe integrada e resultados mais satisfatórios.
Essa produtividade acontece porque toda a equipe trabalha entendendo melhor as etapas que devem ser concluídas, sem sobrecarga de funcionários.
O CMMI também possibilita aos líderes que eles tenham mais controle de gestão de projetos. Isso faz com que o tempo gasto seja menor e que tudo esteja exposto de forma mais transparente.
36
Gerenciamento do Projeto de Software 
A Engenharia de software é uma área que envolve riscos altos, e demanda o uso de uma abordagem diferente para o gerenciamento de projetos. Normalmente os projetos tradicionais são organizados por estruturas top-down, onde o produto é decomposto em componentes menores artefatos (especificações, plantas, subsistemas etc.), seguindo um processo em cascata com fases sequenciais (TAMAKI, 2007). Dessa forma, o planejamento precisa ser desenvolvido com base na estrutura do produto, que precisa ser definido no início do projeto. Entretanto, essa abordagem falha para projetos de desenvolvimento de software, uma vez que no início do projeto pouco se sabe sobre o sistema que será desenvolvido. Normalmente esses projetos sofrem várias mudanças durante seu ciclo de vida, o que dificulta bastante o seu gerenciamento, com a utilização de técnicas tradicionais de gerenciamento de projetos.
Dessa forma, é recomendável que a divisão do projeto em dois níveis de planejamento, Planejamento das Fases e Planejamento das Iterações. O Planejamento de Fases corresponde ao plano do projeto que aborda as fases do projeto, as iterações e seus objetivos, e a estimativa global de recursos e prazo.
Ciclo de vida de um Projeto
O ciclo de vida de um projeto define o início e o fim do projeto, bem como, divide o projeto em fases ou processos para facilitar o seu controle. Para cada fase espera-se um conjunto de resultados, que auxilia a decisão sobre a continuidade e/ou correção de desvios do projeto.
37
Termos de abertura do projeto 						38
Nome do projeto e descrição 
Projeto de implantação da tecnologia de teleatendimento médico
Devido ao crescimento do novo Covid-19, a prática do meio digital está cada vez mais em alta. A telemedicina traz diversas possibilidades não só ao mundo da medicina, mas também ao mundo dos aplicativos.
Os aplicativos de telemedicina permitem basicamente 3 tipos de teleatendimento, o primeiro é a teleorientação, em que o especialista dá informações ao paciente sobre os sintomas e avalia se ele deve ficar em casa ou procurar um pronto atendimento. A segunda opção é o telemonitoramento, ou seja, o médico faz o acompanhamento remoto do paciente que já está sendo tratado. Por fim, existe a teleinterconsulta que é a discussão de um caso entre médicos de diferentes lugares.
Objetivo do projeto
O projeto visa durante essa pandemia, evitar que as pessoas se aglomerem nos hospitais. Isso então, irá prevenir que mais pessoas e profissionais da medicina seja infectado pela Covid-19.
Necessidades do negócio
Este projeto será desenvolvido a fim de reduzir o número de pessoas nos hospitais. Sua autoridade é total dentro das atividades necessárias para o projeto, podendo o paciente marcar sua consulta de acordo com os horários disponibilizado pelos médicos e por fim ter sua teleorientação. 
1- Agilidade no atendimento, conforto para os pacientes e médicos, poupar tempo, tratamentos mais rápidos, histórico médico na palma das mãos e isolamento social.
Nome do gerente do projeto, suas responsabilidades e sua autoridade
O administrador Renan Yohan é gerente do projeto. Sua autoridade é total dentro das atividades necessárias para o projeto, podendo contratar, realizar comprar e gerenciar o pessoal de acordo com seus próprios critérios. Financeiramente a autoridade do gerente do projeto estará definida de acordo com o estabelecido no plano de gerenciamento de custos.
Caso haja necessidade de comunicação ou relacionamento externo a equipe ou cliente sua autoridade será funcional submetendo-se ao responsável interno.
Cronogramas de atividades e custos
Divisão do Trabalho e distribuição do esforço
O perfil de tempo varia para cada projeto, a tabela abaixo mostra um perfil típico para tempo e esforço durante as fazes do projeto, mostra uma boa distribuição.
Controle dos custos 
O controle dos custos da mão de obra utilizado no projeto, na contratação de serviços de terceiros, na fabricação, por um Sistema de Teleatendimento Médico. Os custos relacionados ao trabalho utilizado nos projetos, são decorrentes do lançamento de horas realizado diariamente no sistema de apontamento de horas existente. Para atualização de todos os custos incorridos mensalmente em cada um dos pacotesde trabalho, em uma planilha auxiliar gerada por exemplo, pelo aplicativo Excel. Essas informações são então disponibilizadas para consulta ao gerente de projeto, aos responsáveis pelos pacotes de trabalho e demais áreas envolvidas no projeto, no diretório do projeto, 
localizado no servidor central da empresa.
39
Análise de riscos
O PMBOK (2004) define uma série de processos, ferramentas e técnicas para lidar com o gerenciamento de riscos de projetos. Entretanto, utiliza uma abordagem generalista, que pode ser utilizada para diversos tipos de projetos diferentes, desde construção civil ao desenvolvimento de software. Por outro lado, outras instituições apresentam modelos para o gerenciamento de riscos voltados a áreas específicas de conhecimento. Esse é o caso do desenvolvimento de software, que possui um modelo específico para o gerenciamento de riscos elaborado pela SEI (Software Engineering Institute). O SEI (2006) enfatiza o aspecto contínuo do gerenciamento de riscos durante o ciclo de vida do projeto, bem como a comunicação. O gerenciamento de riscos é uma prática da engenharia de software que envolve processos, métodos e ferramentas para o gerenciamento constante de riscos dos projetos, constituindo uma forma disciplinada para a tomada de decisões de maneira pró-ativa (Carr et al., 1993). Segundo Pinna (2004) os seis passos que compõe o modelo de gerenciamento de riscos de projetos de software proposto pelo SEI são: 
a) Identificação: procura e localização de riscos antes que se tornem problemas. 
b) Análise: transformação dos dados referentes aos riscos em informações para a tomada de decisões. Engloba a análise de impactos, probabilidade e prazos envolvidos, classificação e priorização dos riscos. 
c) Planejamento: transformação das informações referentes aos riscos em decisões e ações de mitigação. 
d) Rastreamento: monitoração dos indicadores de risco e das ações mitigadoras. 
e) Controle: correção dos desvios do plano de mitigação de riscos. 
f) Comunicação: provê informações e feedbacks internos e externos ao projeto dos riscos atuais e potenciais. Essa atividade ocorre ao longo dos demais passos do gerenciamento de riscos.
A elaboração de categorias de riscos tem sido utilizada por diversos modelos de gerenciamento de riscos de projetos. Uma das técnicas utilizadas é a PCA (Principal Component Analysis). Segundo Shaw (2003), PCA é uma ferramenta usada em análise de dados exploratória e para a criação de modelos preditivos. O PCA representa um procedimento de transformação de variáveis que permite identificar as que são responsáveis pela maior parte da variância encontrada na amostra. Leopoldino et al. (2004), desenvolveu uma pesquisa utilizando PCA para a criação de categorias de risco em projetos de software. Nessa pesquisa foram coletados dados de 56 gerentes de projeto e 25 desenvolvedores de software, e foram identificados sete fatores principais: 
a) Gerência de Projetos. Apenas uma gestão de projetos de qualidade vai assegurar o atendimento das metas propostas. Considera-se responsabilidade da gerência de projetos o cuidar dos custos, a estimação de prazos e tempo de execução de tarefas, definição papéis e responsabilidades, controle e planejamento do desenvolvimento de software utilizando uma metodologia efetiva de desenvolvimento.							 40
 b) Equipe de Desenvolvimento. Mais do que bons profissionais, os projetos de software exigem um trabalho em equipe eficaz. Equipes desmotivadas, insuficientes numericamente, sem estrutura ou ferramentas adequadas dificilmente podem ser eficazes. A liderança do projeto é importante para que os membros da equipe atinjam o máximo dos seus potenciais. 
c) Escopo e Requisitos. Perder o controle sobre os requisitos e/ ou o escopo de um sistema é colocar em risco todo o projeto 
d) Conhecimento e Incerteza Tecnológica. A incerteza decorrente da falta de informação/ conhecimento pode ser reduzida através de aprendizado sobre lógicas de negócio, metodologias e/ou tecnologias de implementação. O fato de se utilizar tecnologias de vários fornecedores aumenta a incerteza tecnológica pela necessidade de integração das plataformas. Todo novo assunto, metodologia ou tecnologia deve ser criteriosamente avaliado antes de ser agregado ao projeto por ser um fator de aumento da incerteza tecnológica. 
e) Relacionamento com o Ambiente Externo. Ainda que dificilmente tenha poder para lidar com este tipo de risco sozinho, o gerente deve estar atento ao ambiente externo ao projeto, cuidando do relacionamento com os clientes e com a alta gerência, obtendo o comprometimento necessário ao transcorrer do projeto. Apenas desta forma conseguirá forjar alianças para gerenciar as mudanças necessárias e as inevitáveis. 
f) Relacionamento com o Cliente ou Usuário. É crítico para o sucesso do projeto um relacionamento rico com o cliente ou usuário do software produzido. Ainda que haja obstáculos como conflitos de interesse entre departamentos do usuário e envolvimento de grande número de unidades organizacionais do cliente, o entrosamento e a cooperação deles devem ser conquistados. 
g) Valor e Importância Atribuídos ao Projeto. A expectativa a respeito do projeto não deve ser exagerada ou ficar abaixo do que ele promete o que pode gerar decepção ou a não adoção do produto (seja em parte ou total). A mudança da propriedade do produto ou no comando da alta gerência pode colocar em evidência um projeto ou reduzir sua importância drasticamente, retirando dos mesmos recursos importantes ou até forçando o seu adiamento ou cancelamento. Em ambos os casos há uma mudança em potencial na importância e no valor atribuídos ao projeto. Este componente possui apenas dois itens, o que pode influir na sua consistência interna, assunto de seção posterior.
41
Framework CMMI 
O CMMI (Capability Maturity Model Integration) é uma abordagem de melhoria de processos que promove as organizações o essencial para que elas possuam processos efetivos. Pode ser usado para guiar processos de melhoria no decorrer de um projeto. 
O CMMI auxilia a integração de funções organizacionais tradicionalmente separadas, definindo metas de melhorias de processos e prioridades, provendo um guia para a qualidade de processos, e provendo um ponto de referência e instrução para os processos em uso (SEI, 2006). O CMMI utiliza níveis para descrever um caminho de evolução recomendado para organizações que desejam aprimorar os processos que usam para desenvolver e manter seus produtos e serviços. Trata-se de seis níveis de capacidade
. 
a) Nível 0 (Incompleto). Esse nível representa processos que não são executados ou que são parcialmente executados. Portanto, não há razão para institucionalizar processos que são parcialmente executados. 
b) Nível 1 (Executado). Representa processos que podem ser ditos “processos executados”. Esses processos satisfazem as metas específicas de uma determinada área. Entretanto, nesse nível os processos ainda não foram institucionalizados. 
c) Nível 2 (Gerenciado). Neste nível o processo é chamado gerenciado. Um processo gerenciado é executado (nível 1), e possui a infraestrutura básica para suportá-lo. Ele é planejado e executado de acordo com as políticas; emprega pessoas com as habilidades necessárias e recursos adequados para produzir as saídas esperadas; envolve stakeholders relevantes; é monitorado, controlado e revisado; e é avaliado sobre a aderência da descrição de seu processo.
 d) Nível 3 (Definido). Constitui processos denominados de definido, ou seja, é um processo gerenciado (nível 2) que é adaptado de acordo com as normas organizacionais da empresa. Existem duas diferenças principais entre este nível e o anterior: os processos são mais rigorosos e o gerenciamento dos processos é feito de maneira mais proativa. 
e) Nível 4 (Quantitativamente Gerenciado). Trata-se de processos denominados de quantitativamente gerenciado, ou seja, é um processo definido (nível 3) que é controlado utilizando-se técnicas estatísticas, além de outras técnicasquantitativas. 
f) Nível 5 (Em otimização). Esse processo é caracterizado como “processo em otimização”. Ele é quantitativamente gerenciado (nível 4) e tem sua melhoria baseada no entendimento de causas comuns de variações no processo. O foco para um processo em otimização é a melhoria contínua do desempenho do processo, tanto por melhorias incrementais como inovadoras. 
42
Metodologia da Pesquisa 
Esta seção apresenta os procedimentos metodológicos que foram aplicados nesta pesquisa. O primeiro item classifica o tipo de pesquisa e os demais itens tratam dos aspectos referentes ao objeto, à estratégia e as fases da pesquisa. 
Tipo de Pesquisa 
A pesquisa realizada se caracteriza por ser um estudo exploratório. Segundo Selltiz (1975), os estudos exploratórios ou formuladores têm como objetivo familiarizar o pesquisador com o fenômeno ou conseguir nova compreensão deste. Esta pesquisa se enquadra nas características de um estudo exploratório e tem como objetivo principal analisar a gestão de risco em projetos de desenvolvimento de software.
Modelo de Gerenciamento de Riscos do Projeto
 	Esse projeto utilizou uma metodologia própria da empresa ALFA, adaptado do CMMI, contendo 21 processos referentes ao gerenciamento de projetos. Um desses processos é gerenciamento de riscos. Esse processo adotou um modelo de gerenciamento composto por quatro subprocessos, conforme ilustra o Quadro 1.
Planejamento do gerenciamento de riscos. No modelo utilizado pela empresa ALFA o planejamento do gerenciamento de riscos é feito pelo coordenador do projeto. Este segue um documento chamado Plano de Gerenciamento de Riscos, que representa um padrão para todos os projetos da empresa ALFA. Esse documento padrão contém instruções sobre como realizar todos os subprocessos do gerenciamento de riscos. Entretanto, o coordenador do projeto pode sugerir extensões aos documentos utilizados, como por exemplo: novas categorias de riscos, outras ferramentas ou técnicas a serem utilizadas, entre outros. Isso ocorre somente se o coordenador do projeto julgar que o projeto em questão tem características específicas que não foram abordadas no processo padrão de gerenciamento de riscos. No projeto SIGSJ o coordenador decidiu seguir o processo padrão de gerenciamento de riscos.
Identificar e analisar riscos. Esse subprocesso teve a participação de toda a equipe do projeto. Para realizar a identificação dos riscos foi utilizada a lista de verificação de riscos padrão. Além disso, para garantir que todo o escopo do projeto fosse abordado utilizou-se o documento Estrutura Analítica do Projeto (WBS). As atividades se iniciaram com uma reunião entre o coordenador e a equipe do projeto, onde se utilizou a lista de verificação de riscos padrão. Como resultado, foram destacados os riscos aplicados ao projeto, e em seguida foi feita uma análise qualitativa para cada risco identificado, o que permitiu elaborar estratégias para o planejamento de respostas aos riscos. Alguns dos riscos identificados foram: falta de integração da equipe, prazo demasiadamente curto do projeto e a falta de conhecimento de alguns membros da equipe do modelo de gerenciamento de risco adotado pela empresa ALFA.
43
Planejar respostas aos riscos. Na empresa ALFA o coordenador do projeto é responsável por definir as estratégias e planejar as ações de respostas aos riscos identificados. As causas dos riscos, que foram identificadas no subprocesso anterior, foram úteis na elaboração do planejamento de resposta. Como exemplo, destaca-se a implantação de reuniões semanais da equipe do projeto, para promover uma maior integração entre os membros da equipe, esclarecendo dúvidas e designando os recursos necessários (mão-de-obra, servidores para testes de sistema, entre outros) conforme as necessidades apontadas.
Monitorar Riscos. O projeto foi planejado considerando-se os riscos envolvidos de forma a antecipar ações de resposta e diminuir o impacto deles no sucesso do projeto. O coordenador do projeto definiu um cronograma de reuniões para gerenciamento dos riscos do projeto. Entretanto, as reuniões referentes ao monitoramento dos riscos acabaram sendo substituídas por reuniões de ponto de controle, onde todos os assuntos do projeto eram tratados. Portanto, não houve efetivamente um processo cíclico de identificação, análise e planejamento de respostas, conforme previsto no modelo padrão da empresa ALFA.
44
Lições Aprendidas
A partir da fundamentação teórica e de um estudo de caso, pode-se concluir que são muitas as dificuldades encontradas pelas empresas e áreas de informática em cumprir prazos, custos e qualidade nos projetos de desenvolvimento de software. 
A fundamentação teórica mostrou que as organizações modernas estão inseridas num ambiente onde existe uma evolução tecnológica acelerada e onde os clientes estão cada vez mais exigentes, devido a facilidade de informação. Neste contexto, as organizações necessitam ser rápidas em assimilar novos conhecimentos, transformando-os em vantagem competitiva. Para isto, é preciso que as empresas aprendam a trabalhar com objetivos específicos, a serem alcançados por equipes multidisciplinares, com prazos e recursos definidos e com uma exigência de alta qualidade nas tarefas realizadas, ou seja, trabalhar com projetos. Assim, este trabalho apresenta as técnicas usadas pelas empresas modernas, que estão obtendo êxito na gestão de projetos, bem como dois fatores chaves de sucesso: a gestão do conhecimento e a motivação e liderança.
45
Conclusões
O desenvolvimento do plano negócio ora apresentado se mostrou uma tarefa desafiadora. No entanto, os dados levantados e as análises realizadas possibilitaram um estreitamento dos laços entre o empreendedor e o seu futuro negócio. Com um planejamento um pouco mais detalhado, o empreendedor estará mais bem preparado para agir frente às adversidades que surgirão.
As metodologias aplicadas no desenvolvimento da especificação abordam em suas etapas as técnicas adquiridas para garantir o desenvolvimento de análises que subsidiarão a implementação, porém devemos considerar que na execução foram contempladas mais de uma técnica para formalização dos requisitos e regras do sistema. Partiu-se de um cenário inicial apontado pela necessidade do cliente que, pode ser interpretado como uma primeira entrevista, para posteriores elaborações de casos de uso, regras de negócio e representações em Diagramas de Classe, Sequência, Atividades, componentes e implementação.
As técnicas modernas de gerenciamento de projetos de software, devem passar a fazer parte do desenvolvimento de software, para que as empresas ou áreas de informática construam produtos com a qualidade esperada pelo cliente.
46
Referências
https://www.sebrae.com.br/sites/PortalSebrae/artigos/artigoshome/startup-entenda-o-que-e-modelo-de-negocios,5b3bb2a178c83410VgnVCM1000003b74010aRCRD
https://www.lucidchart.com/pages/pt/modelos-e-exemplos-de-diagramas-uml
https://www.conceitozen.com.br/analise-de-riscos-o-que-e.html#:~:text=An%C3%A1lise%20de%20risco%20%C3%A9%20uma,ocorrerem%20no%20ambiente%20de%20trabalho.
https://www.uniasselvi.com.br/extranet/layout/request/trilha/materiais/livro/livro.php?codigo=23854
47