Plano Geral

Nome dos Processos

Processo de Solicitação de Serviço

Prodesi – Processo de Desenvolvimento de Sistemas da DTI-DSI

 

Papéis e Responsabilidades

Papel

Responsabilidades

Analista de Sistemas

É responsável pela identificação, organização e documentação dos requisitos.

Coordenador de Desenvolvimento

É responsável pelo treinamento no padrão de código fonte e pela inspeção do mesmo após o desenvolvimento. Responsável pela inspeção na interface seguindo, também, os padrões existentes na DSI. Pela tomada decisões de implementação, de projeto e de arquitetura sempre que houver necessidade.

Desenvolvedor

Responsável por desenvolver as funcionalidades de acordo com os padrões e procedimentos definidos para o projeto. Estas atividades incluem implementação e testes.

Fornecedor de Requisitos

É a pessoa responsável por informar todos os requisitos necessários para o entendimento do problema para o qual o sistema será desenvolvido.
Busca-se uma pessoa com conhecimento amplo do problema e disponibilidade para participar das reuniões de levantamento de requisitos.

Gerente do Projeto

Responsável pelo projeto como um todo. Deve garantir que as tarefas sejam planejadas, alocadas e executadas de acordo com o cronograma, custos e nível de qualidade definida para o projeto. Deve acompanhar e monitorar o andamento das atividades do projeto e definir ações corretivas quando necessário.

 

Estimativa de Tamanho e Esforço do Projeto

O tamanho dos projetos da DSI é baseado na Análise de Ponto de Função (APF) e o esforço é derivado desta estimativa de tamanho.

Como não há histórico de produtividade da equipe da DSI é assumido uma produtividade inicial de 3 horas por ponto de função, ou seja, cada ponto de função demanda 3 horas para ser implementado.

As proporções de esforço entre as fases do projeto e papéis pode ser encontrada em https://prodesi.ufv.br/ menu “Artefatos”, documento “Esforço&Custo”.

 

Boas Práticas

  1. Informações de sistema devem estar em documentos de sistema e não e documentos de projeto.

  2. Novos requisitos devem ser inseridos em novas iterações.

  3. Para as entidades que requerem gerenciamento através de operações básicas conhecidas como CRUD (Create, Read, Update e Delete) (Inserir, Consultar, Alterar e Excluir) ou um subconjunto delas, apenas um documento de especificação de casos deve ser redigido. A operação C(Create) (Inserir) deve ser escolhida como o fluxo principal e as demais como fluxo alternativo.

  4. Deve-se anexar, na ferramenta RM da IBM, os fontes gerados pelas ferramentas de análise. São elas: Diagrama de Caso de Uso (Astah, .asta); Protótipo (Pencil, .ep); Diagrama de Entidade Relacionamento.
    Vide o “Manual das ferramentas IBM”, seção “Organizando os artefatos em pastas”.
    Gere, exporte e anexe também as figuras resultantes dessas ferramentas (PNG, JPEG e JPG). Assim, mesmo que a versão do fonte não seja mais compatível, ainda teremos uma imagem do artefato em questão.

  5. Para garantir a rastreabilidade vertical durante o desenvolvimento de cada caso de uso, nos arquivos referentes ao código-fonte, deve-se identificar formalmente a quais casos de uso este arquivo está relacionado.

    As anotações nos arquivos de código-fonte devem ser feitas nos elementos essenciais (que existem por causa do caso de uso) para a implementação do caso de uso. Esses elementos podem ser atributos, métodos, classes ou o arquivo como um todo. Arquivos javascript e css também devem ser anotados, uma vez observado que seu uso é primordial para o caso de uso em questão.

    Para decidir se determinado elemento do arquivo deve ou não ser anotado, podemos definir a seguinte regra geral: “Todos os elementos afetados diretamente pela modificação ou remoção do caso de uso devem ser anotados”. Tal regra exclui, por exemplo, configurações gerais de layout, formatadores e validadores de campos como CPF e telefone, etc, ou seja, elementos que podem permanecer independentemente da existência do caso de uso.

 

Padrões

  1. Nome de projeto que segue o PRODESI:
    Padrão: <sistema>-MêsAA
    Exemplo: SisDSI-Set11
  2. Assunto de E-mails:
    Padrão: [<projeto>] <objetivo do e-mail>.
    Exemplo: [SisDSI-Set11] Reunião de Kickoff do Projeto
  3. Nome de Artefatos:
    Padrão: <nome_artefato>_<AAMMDD>.<extensão>.
    Exemplo: DocumentoRequisitos_20190902.odt