| Data de elaboração | 19/09/2022 |
| Responsável pelo estudo | Rafael Passos dos Santos (Assessor) Lucas de Souza e Sousa (Assessor) |
| Equipe do estudo | Gustavo Felix Gomes (Desenvolvedor Full-Stack)
Alef Carvalho da Silva (Analista) André Honório de Andrade Silva (Tecnico) Gezinéia Paula da Costa (Product Owner) Emanuel Rufino Alcantara de Lima (Analista) Lucas de Souza e Souza (Assessor) Rafael Passos dos Santos (Assessor) |
| Alvo | Portal do Cidadão |
| Origem | Objetivo estratégico: Permite a exibição e solicitações de serviços no Portal do Cidadão que não sejam cadastrados diretamente no Alpha. |
| Objetivo | Verifica a possibilidade de gerenciar os serviços do portal do cidadão por outra aplicação, para usuário de entidades externas. |
| Documentação correlata | -/- |
| Observações | O presente estudo pretende também levantar as Historias dos Cards para futuras Sprint |
Atualmente só é possível cadastrar, listar, editar um serviço por meio do alpha.
Com esse cenário, vindo de uma entidade externa, será necessário consumir aplicações externas para obter dados dos departamentos, ou criar de uma forma genérica uma estrutura para guardar os dados dos departamentos externos. Esses dados são essenciais, pois com eles, o serviço tem um ou vários endereços onde pode ser atendido, qual ou quais departamentos podem atender aquele serviço, etc.
Deverá ser criado a documentação de como consumir a API, para que entidades externas que precisem cadastrar seus serviços para o portal do cidadão, possam consultar.
A entidade externa deverá solicitar o acesso a api, por meio de chamado, para que seja liberado o acesso ao sistema. Com acesso ao sistema, a entidade externa irá implementar e consumir a API
Carta de Serviço:
Para se cadastrar uma carta de serviços é necessário informar qual a Unidade gestora do departamento, nesse caso, a aplicação salva o ID da unidade gestora do departamento. Minha sugestão é que seja criado um novo campo, por exemplo: Origem.
Assim a carta de serviços teria o departamento e a origem
Assim teríamos o controle do departamento e de qual entidade seria essa carta de serviço.
Dessa forma, quando um usuário do banco do brasil acessar a carta de serviço, poderiam ser filtradas somente as cartas de serviços do banco do brasil.
Serviço:
Nos serviços, para um melhor controle, seria necessário criar um outro campo (Tipo de Serviço), com os seguintes valores: EXTERNO/INTERNO.
Para preencher o campo origem do serviço, usaremos a sigla da nova aplicação por exemplo: EGCS (externo gerenciamento da carta de serviço).
No campo cadastradoPor, usaremos uma sigla com a junção da entidade + o departamento. exemplo: BBDepartamento, CXDeparamento, etc.
No campo AreaResponsavel, usaremos a mesma sigla anterior: BBDepartamento.
Possíveis histórias
| História | Pontos |
|---|---|
| Criar a aplicação e toda estrutura da aplicação, entidades, interfaces e toda configuração. | 8 pts |
| Adicionar o ELK na aplicação. | 3 pts |
| Criar autenticação para a API, ou usar uma existente. exemplo: central do desenvolvedor. | 5 pts |
| Serviço | |
| Criar uma action método POST, para cadastrar um serviço | 8 pts |
| Criar uma action método PUT, para atualizar os dados do serviço de meio externo. | 5pts |
| Criar uma action método GET, para buscar os serviços. | 5 pts |
| Criar uma action método GET, para buscar um serviço especifico. | 3 pts |
| Carta de Serviços | |
| Criar uma action método POST, para cadastrar a carta de serviço. | 8 pts |
| Criar uma action método PUT, para atualizar a carta de serviço. | 5 pts |
| Criar uma action método GET, para obter as cartas de serviços. | 5 pts |
| Criar uma action método GET, para obter uma carta de serviço especifico. | 3 pts |
| Total: | 58 pts |