Poder Judiciário. Justiça do Trabalho. Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO

Poder Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 24ª Região SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO DIVISÃO DE SISTEMAS E INTERNET METODOLOGIA DE PRODUÇÃO DE SOFTWARE Versão 1.0

APROVAÇÃO APROVADO DATA ASSINATURA João Carlos Ferreira Filho Diretor da STI 24/06/2013 REVISÕES Data Versão Descrição Autor 24/06/2013 1.0 Criação do Documento EQUIPE RESPONSÁVEL Nome Função Telefone E-mail Aise Maria Longhi Canéppele Chefe da DSI 3316-1728 aise@trt24.jus.br Chefe da Divisão de Sistemas e Internet Waldeci Leitun de Almeida Chefe da SENET 3316-1707 walmeida@trt24.jus.br Chefe da Seção de Internet Marco Antonio Ribeiro Molento Chefe da SEDS 3316-1762 mmolento@trt24.jus.br Chefe da Seção de Desenvolvimento

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 ÍNDICE DE ASSUNTOS 1. INTRODUÇÃO...4 2. HISTÓRICO...4 3. FINALIDADE...5 4. OBJETIVOS...5 5. POLÍTICAS GERAIS...5 6. MODELO DE DESENVOLVIMENTO DE SOFTWARE...6 7. PAPÉIS E RESPONSABILIDADES...7 8. PRODUTOS DE TRABALHO...10 8.1. DOCUMENTO DE VISÃO...11 8.2. PLANO DE GERENCIAMENTO DE PROJETO...11 8.3. PLANO DE GERENCIAMENTO DE ITERAÇÃO...11 8.4. RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO...11 8.5. DOCUMENTO DE CASOS DE USO...11 8.6. LISTA DE REGRAS DE NEGÓCIO...12 8.7. LISTA DE REQUISITOS FUNCIONAIS...12 8.8. LISTA DE REQUISITOS NÃO FUNCIONAIS...12 8.9. DOCUMENTO DE ARQUITETURA...12 8.10. CÓDIGO FONTE...12 8.11. BUILD (CONSTRUÇÃO)...12 8.12. MODELO DE DADOS...12 8.13. CASOS DE TESTE...13 8.14. REGISTRO DE TESTE...13 9. DIAGRAMAS DA UML ADOTADOS NESTA METODOLOGIA...13 10. UTILIZAÇÃO DE OUTROS ARTEFATOS...13 11. ARTEFATOS GERADOS DURANTE O PROCESSO...14 12. CONCLUSÃO...15 13. LISTA DE ANEXOS...16 14. GLOSSÁRIO...16 15. REFERÊNCIAS...18 Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 3/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 1. INTRODUÇÃO A visão que a Divisão de Sistemas e Internet (DSI) tem do processo de produção de software como uma cadeia produtiva, contempla todas as atividades desde o momento em que o cliente abre uma demanda para a Secretaria de Tecnologia da Informação (STI) até o momento em que recebe o produto solicitado. Apenas quando o software entregue modifica as rotinas de trabalho do nosso cliente, agregando-lhes valor, é que a STI pode considerar concluído o processo de solução de demanda de software. O processo de desenvolvimento de software é composto por uma série de atividades executadas por uma equipe multidisciplinar e que planeja a execução do projeto, realiza a análise de requisitos, a codificação, a integração, e os testes de aceitação do software. Essas atividades estão definidas de forma a compor o processo de demanda de software apresentado neste documento. A existência de processos definidos é necessária para a maturidade de toda organização que produz software. Com a padronização dos seus processos de trabalho, a DSI busca a o fácil acompanhamento dos seus projetos, além de tornar a organização menos dependente da atuação individual de seu quadro técnico. Porém, não basta que os processos estejam definidos; é preciso que eles sejam aderentes à realidade da nossa organização. A metodologia de produção de software da DSI, descrita neste documento, define um roteiro para a execução dos projetos e das ações de manutenção dos produtos já existentes. Nosso objetivo é que esta metodologia padronize os processos de desenvolvimento e manutenção de software e que seja utilizada por toda a equipe da DSI. A metodologia está baseada no OPEN UP (Processo Unificado Aberto), uma metodologia ágil de desenvolvimento de software, baseada nas principais características do RUP (Rational Unified Process), mas que aplica a abordagem iterativa e incremental em um ciclo de vida estruturado. Portanto encontramos uma série de similaridades entre RUP e Open UP, porém este último apresenta uma quantidade bem menor de produtos de trabalho, papéis e tarefas. 2. HISTÓRICO A DSI possui uma larga produção de software, porém, apesar de várias boas práticas serem utilizadas, estas não estão compiladas e formalizadas numa metodologia de desenvolvimento. A metodologia existente atualmente refere-se apenas à gerência do projeto de desenvolvimento, mas não abrange o processo de desenvolvimento em si. Além da metodologia de gerenciamento do projeto adotada na DSI, também já obtivemos bastante sucesso aplicando o SCRUM em nossos projetos. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 4/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 A nossa experiência com o Scrum nos mostrou que, apesar de a implementação ser realmente rápida e com uma dinâmica bastante positiva, ao final do projeto, verificamos que a documentação gerada não é completa. 3. FINALIDADE Esta metodologia de produção de software visa descrever e padronizar os processos para o desenvolvimento de sistemas no âmbito da Divisão de Sistemas e Internet, da Secretaria de Tecnologia da Informação e servir como guia de todo o processo de construção e manutenção de software, a partir da sua publicação. 4. OBJETIVOS O objetivo geral desta metodologia é orientar e organizar a realização de projetos de desenvolvimento e de manutenção de software, desde a chegada da requisição até o término de sua implementação, visando: Aumentar a produtividade das atividades realizadas pela DSI, através da redução do retrabalho e da organização das tarefas do projeto. Padronizar a forma de trabalho das equipes técnicas, melhorando a comunicação entre seus membros. Melhorar a qualidade do software produzido, facilitando a sua compreensão por técnicos e usuários. Definir os papéis e responsabilidades dentro do processo de desenvolvimento de sistemas; Descrever o fluxo das atividades a serem desenvolvidas para o desenvolvimento de sistemas; Definir os produtos de trabalho gerados durante o processo de desenvolvimento de sistemas; Padronizar os documentos gerados durante o processo de desenvolvimento de sistemas. 5. POLÍTICAS GERAIS a) As equipes que participam dos processos de produção de software devem ser escolhidas de acordo com as competências exigidas para cada atividade. b) As equipes de desenvolvimento devem estar adequadamente capacitadas para as atividades que executarão. Caso sejam necessários treinamentos específicos para a execução do projeto, estes devem ser identificados e solicitados com antecedência. c) Os recursos materiais deverão ser programados de acordo com as necessidades especificadas nos projetos. Cabe ao gerente do projeto providenciar previamente as aquisições e recursos necessários (equipamentos, hardware, software). Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 5/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 d) As políticas e os processos deverão ser revisados nas reuniões anuais de planejamento estratégico da STI. e) Esta metodologia deve ser publicada no site do TRT da 24ª Região, na página da STI. f) Todo projeto deve ter um único responsável pelo seu planejamento e execução. g) Todo projeto deve alocar a equipe com os seguintes papéis: Um gerente do projeto, dois analistas de sistemas, dois desenvolvedores, um projetista da arquitetura do sistema, um analista de métricas. h) Deve ser possível auditar a execução dos processos citados nesta metodologia, provendo, assim, a transparência com relação aos mesmos. 6. MODELO DE DESENVOLVIMENTO DE SOFTWARE O processo de produção de software descreve o fluxo de atividades a serem executadas para transformar requisitos de usuários em produto final de software. O modelo proposto apresenta todos os processos da DSI, que estão descritos nos anexos I a IV deste documento, a saber: Processo Nº STI-2.001 - Solução de demanda de software Objetivo O objetivo deste processo é descrever toda a cadeia de atividades executas desde o pedido inicial do cliente até a implantação do software. Este é o principal processo da DSI e resume a sua própria identidade que é produzir e entregar software e deve abranger toda a alteração ou a criação de sistemas e serviços web mantidos pela DSI. Trata-se do macro processo que apresenta as atividades de solicitação, autorização e entrega. A partir deste processo, podemos verificar como as demandas serão analisadas e encaminhadas. Processo Nº STI-2.003 Atendimento por operação continuada Objetivo Trata-se de um processo executado quando existe demanda de desenvolvimento para um sistema já existente e que necessita de manutenção evolutiva. O produto deste processo será sempre um software alterado por procedimentos evolutivos. Seu fluxo é mais simples que o processo de desenvolvimento de novas soluções. Processo Nº STI-2.004 Execução Objetivo O objetivo deste processo é descrever as atividades executadas para analisar a melhor solução a ser proposta ao cliente, planejar e executar o projeto cuja conclusão entregará o novo software pronto. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 6/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 Este processo abrange os subprocessos de gerenciamento do projeto e de desenvolvimento do software. O subprocesso de gerenciamento de projeto está descrito na metodologia de gerenciamento de projetos (MGP-TRT24). Processo Nº STI-2.004.5 Desenvolvimento de software Objetivo O objetivo deste processo é descrever as atividades executadas para o desenvolvimento de um novo sistema. Trata-se do processo mais complexo e que esta metodologia trata com maior profundidade. Os processos STI-2.003 Atendimento por operação continuada e STI-2.004.5 Desenvolvimento de software representam as atividades do desenvolvimento, propriamente ditos. Estes dois processos apresentam várias fases de desenvolvimento. Em cada fase o trabalho a ser realizado pode ser composto por ciclos completos de atividades que, uma vez realizadas, levam a um conjunto de produtos de trabalho que atingem o escopo da fase. 7. PAPÉIS E RESPONSABILIDADES Um papel define o comportamento e as responsabilidades dos profissionais que participam de um projeto de desenvolvimento de software. O seu comportamento é representado pelas das atividades que ele deve desempenhar ao longo do projeto e por suas responsabilidades. Os papéis associados a esta metodologia que não são parte da equipe do DSI são: Papel Patrocinador Cliente Responsabilidades Papel responsável por fornecer os recursos para que os projetos sejam executados na organização. É a autoridade que garante a consecução do projeto Define as pessoas que conhecem ou utilizam o processo para o qual o sistema será desenvolvido. É responsável por fornecer as informações que permitam o levantamento dos requisitos do sistema, validar os produtos gerados no processo, bem como receber o sistema desenvolvido. São suas atribuições: Informar as regras de negócio que nortearão o sistema; Informar os requisitos funcionais do sistema; Homologar os produtos do projeto; Dar o aceite final à solução entregue. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 7/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 Os demais papéis, apresentados a seguir, estão associados a esta metodologia e fazem parte da equipe do DSI. Papel Gerente do Projeto Responsabilidades Representa o responsável pelo planejamento e controle do projeto, coordenando as interações com os clientes e mantendo a equipe de projeto focada nos objetivos do projeto. É responsável pelo resultado do projeto e pela aceitação do produto pelo cliente. Este papel atua em todas as fases do projeto. Sua atividade inicia a partir da sua designação no Termo de Abertura do Projeto e só vai terminar quando o projeto for encerrado. São suas atribuições: Planejar, coordenar e controlar todas as atividades do projeto; Planejar e gerenciar as iterações do processo de desenvolvimento; Gerenciar a equipe de desenvolvimento; Gerenciar os planos de comunicação, de qualidade, de riscos, conforme descrito na metodologia MGP-TRT24. Analista de sistemas É o responsável pelos levantamentos iniciais das necessidades do cliente e também pela captura dos requisitos do sistema a ser desenvolvido e a sua especificação por meio de uma linguagem de modelagem apropriada. Inicialmente, a sua atuação permitirá que o cliente e o gerente do projeto possam trabalhar uma mesma visão do projeto. Na verdade, a sua atuação se aproxima da função de um analista de negócio e seu trabalho será maior quando o ambiente para o qual o software será construído, não tiver suas próprias regras documentadas e seus processos de trabalho mapeados. Sua atividade inicia logo após a autorização do projeto e os seus levantamentos irão subsidiar não só o seu planejamento do projeto, mas os levantamentos dos requisitos do sistema. São suas atribuições: Capturar as regras de negócio no âmbito da solução que será construída; Especificar as necessidades e recursos mais importantes do cliente; Resumir os principais processos de trabalho do cliente e que devem ser levados em conta para a construção da solução (caso este processos ainda não tenham sido mapeados); Traduzir as necessidades do cliente e dos usuários, delimitando o sistema; Elaborar o documento de visão; Validar, junto ao cliente, os documentos de requisitos gerados sob sua responsabilidade; Durante o processo de desenvolvimento, suas atribuições são: Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Conduzir a elicitação dos requisitos e a modelagem do sistema em modelos conceituais Página 8/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 relacionados aos requisitos funcionais da aplicação; Elaborar e manter os documentos que descrevem os requisitos a serem atendidos pelo sistema, considerando ainda, os requisitos não funcionais do sistema; Validar, junto ao cliente os documentos de requisitos gerados sob sua responsabilidade. Analista de Métricas É o responsável pela mensuração do projeto de desenvolvimento de software. São suas atribuições: Estabelecer o método de estimativa a ser aplicado ao projeto; Estimar o software na sua fase de elaboração; Medir o software entregue. Arquiteto É o responsável pela definição da arquitetura do software. São suas atribuições: Realizar o desenho técnico do projeto; Identificar e documentar os aspectos arquiteturais significativos do sistema, tais como visões que descrevem requisitos, design, implementação e distribuição; Reduzir os riscos técnicos e assegurar que as decisões sejam eficazmente comunicadas, validadas e seguidas; Estabelecer a estrutura geral da arquitetura do sistema, liderando e coordenando as atividades e os artefatos técnicos durante o projeto. Desenvolvedor É o responsável pela implementação e integração dos componentes que são parte da solução. São suas atribuições: Implementar a solução a partir das definições recebidas. Transformar o design em código, implementar a estrutura do sistema na linguagem fonte escolhida; Implementar o comportamento do sistema definido nos requisitos funcionais; Escrever o código que permita às diferentes partes da aplicação (classes ou componentes) colaborar para a realização do comportamento do sistema; Construir os testes de desenvolvedor que verificam o comportamento dos componentes técnicos; Integrar e construir o incremento da solução na qual esteja trabalhando; Implementar e integrar os componentes que são parte da solução e, também, executar testes de unidade. Administrador do banco de É o responsável pela definição de tabelas, índices, visões, restrições, triggers, procedimentos armazenados, parâmetros de armazenamento e outras construções específicas de um banco Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 9/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 dados de dados necessárias para armazenar, recuperar e excluir objetos persistentes. Identificar possibilidades de reuso de dados; Integrar os modelos de dados do projeto com o modelo de dados corporativo; Implementar o modelo físico de dados. 8. PRODUTOS DE TRABALHO Cada uma das atividades executadas no processo de desenvolvimento do software gera produtos de trabalho tangíveis. Estes produtos são resultado da realização das atividades pelos papéis. E alguns produtos são insumos para as atividades seguintes. Dentre os produtos de trabalho, podemos encontrar: Produtos que documentam o processo são gerados com o objetivo de possibilitar o controle das atividades do processo, sendo, pois, produtos específicos da metodologia de gerenciamento de projetos MGP-TRT24. Produtos que documentam o sistema documentam o sistema e permitem a comunicação entre os membros da equipe do projeto ou destes como os seus clientes. Além disso, possibilitam um melhor entendimento do sistema para as futuras operações de manutenção. Artefatos que documentam o projeto Termo de abertura do projeto Documento de visão Plano de projeto Plano de iteração Relatório de Avaliação da Iteração Atas de reunião Termo de Encerramento do Projeto Artefatos de suporte ao produto Documento de visão Casos de Uso Lista de regras de negócio Lista de Requisitos Funcionais Lista de Requisitos Não Funcionais Glossário Documento de arquitetura Modelo de dados Casos de teste e registro de teste Os produtos de trabalho apresentados a seguir, são obrigatórios nesta metodologia. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 10/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 8.1. DOCUMENTO DE VISÃO Apresenta claramente a visão do cliente em relação ao negócio e ao sistema de informação que será desenvolvido para suportá-lo; Este artefato deve apresentar, além da visão dos envolvidos com o produto a ser desenvolvido, também a especificação das necessidades e recursos mais importantes; Os requisitos centrais pretendidos devem estar descritos, constituindo-se em uma base contratual para o desenvolvimento do produto; 8.2. PLANO DE GERENCIAMENTO DE PROJETO Esse artefato reúne todas as informações necessárias ao gerenciamento do projeto de desenvolvimento de software; Ele consolida vários documentos que detalham como as atividades do projeto serão desenvolvidas; É mantido e atualizado durante todo o processo pelo gerente do projeto; Deve ser elaborado de acordo com a conforme metodologia de gerenciamento de projetos MGP- TRT24, aprovado pela PORTARIA TRT/GP/DGCA Nº 704/2011. 8.3. PLANO DE GERENCIAMENTO DE ITERAÇÃO Detalha as iterações que serão realizadas dentro de cada fase considerada, onde o sistema é decomposto em funcionalidades que serão disponibilizadas; Ao final de cada iteração, um produto de valor significativo é gerado. Ao final de cada fase, planeja-se a iteração da próxima fase. 8.4. RELATÓRIO DE AVALIAÇÃO DA ITERAÇÃO Relatório utilizado para demonstrar se o que foi previsto no plano de iteração foi, efetivamente, realizado; A partir desta avaliação, pode-se planejar o prosseguimento do projeto. 8.5. DOCUMENTO DE CASOS DE USO Artefato que especifica as funções que devem ser contempladas pelo sistema; Serve como um contrato estabelecido entre clientes e equipe do projeto de desenvolvimento e deve ser utilizado como fonte de informações essencial para atividades de análise, design e teste; Detalha as atividades a serem executadas em cada caso de uso, por meio de fluxos principais, alternativos e de exceção, além da descrição completa dos atores que interagem com o sistema. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 11/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 8.6. LISTA DE REGRAS DE NEGÓCIO Esse artefato detalha as regras do negócio do cliente que possuem influência sobre o software a ser desenvolvido; As suas sentenças devem possuir uma abordagem restritiva, pois elas restringem os processos operacionais da organização; A lista de regras de negócio não descreve como cada regra será verificada ou como as operações deverão ser realizadas. Descreve apenas o que o processo irá executar; Deve ser percebida pela organização; Não deve possuir elementos de soluções de tecnologia e pode ser atendida sem uso de sistema; Pertence ao domínio do negócio e não do sistema. 8.7. LISTA DE REQUISITOS FUNCIONAIS Esse artefato discrimina as funcionalidades que o sistema deverá atender. Essas funcionalidades expressam o que o sistema fará, para atender seus objetivos. 8.8. LISTA DE REQUISITOS NÃO FUNCIONAIS Este artefato documenta a análise relacionada à infraestrutura de produção do sistema e ao comportamento e restrições que ele deve atender. 8.9. DOCUMENTO DE ARQUITETURA O documento de arquitetura de software fornece uma visão geral de arquitetura abrangente do sistema de software; Serve como um meio de comunicação entre o arquiteto de software e outros membros de equipe de projeto, com relação a decisões arquiteturalmente significativas tomadas sobre o projeto; 8.10. CÓDIGO FONTE É o resultado da implementação das realizações dos casos de uso; 8.11. BUILD (CONSTRUÇÃO) Esse artefato produz uma versão operacional como parte de um sistema que demonstra um subconjunto de recursos a serem fornecidos no produto final. Uma versão é constituída por um ou mais elementos de implementação (geralmente executáveis), cada construído a partir de outros elementos, normalmente por um processo de compilação e link de código fonte. 8.12. MODELO DE DADOS Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 12/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 Esse artefato descreve as representações lógicas e físicas dos dados persistentes utilizados pelo aplicativo. Nos casos em que o aplicativo utilizará um RDBMS, o modelo de dados poderá incluir também elementos de modelo para procedimentos armazenados, gatilhos e restrições que definem a interação dos componentes de aplicativo com o RDBMS. 8.13. CASOS DE TESTE Este artefato é usado para especificar um conjunto de testes, condições de execução e resultados esperados, com a finalidade de avaliar aspectos particulares de um cenário. 8.14. REGISTRO DE TESTE Neste artefato devem ser registrados todos os resultados dos testes realizados sobre o produto em desenvolvimento. 9. DIAGRAMAS DA UML ADOTADOS NESTA METODOLOGIA Diagrama de Classes; Modelo de Dados (caso seja utilizada uma base de dados relacional); Além dos diagramas obrigatórios, outros podem ser definidos e criados, de acordo com as características de cada projeto. 10. UTILIZAÇÃO DE OUTROS ARTEFATOS As equipes dos projetos poderão, ainda, adotar outros artefatos opcionais, além dos obrigatórios. De qualquer forma, é imprescindível a produção e atualização da documentação do sistema durante todo o seu ciclo de desenvolvimento, de forma a permitir futuras manutenções. Diagrama de Sequência; Diagrama de Atividades, para auxiliar o entendimento de Casos de Uso mais Complexos; Diagrama de Componentes; Diagrama de Implantação; Diagrama de Pacotes; Diagrama de casos de uso. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 13/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 11. ARTEFATOS GERADOS DURANTE O PROCESSO Os produtos de trabalho gerados durante a execução dos processos e fases do ciclo de vida de desenvolvimento são apresentados abaixo, com a indicação de quando acontecem e quem é o responsável. A lista contempla, também, alguns artefatos da MGP-TRT24 que aparecem nos nossos processos. Estes artefatos são descritos mais detalhadamente na MGP-TRT24: Artefato Quando Responsável Documento de oficialização da demanda (DOD) Estudo de viabilidade do projeto (VAP) Termo de abertura do projeto Documento de visão Lista de regras de negócio Plano de gerenciamento de projeto Gerado no processo STI-2.001 - Solução de demanda de software na fase de Autorização, subprocesso de Gestão de Demandas. Gerado no processo STI-2.001 - Solução de demanda de software na fase de Autorização, atividade de para realizar a análise de viabilidade do projeto. Gerado no processo STI-2.001 - Solução de demanda de software na fase de Autorização, atividade de elaboração do TAP. Gerado no processo STI-2.004 Execução na atividade de definição da visão do negócio e revisado no subprocesso STI-2.004.5 Desenvolvimento de software. Gerado no processo STI-2.004 Execução na atividade de definição da visão do negócio. Gerado no processo STI-2.004 Execução no subprocesso de planejamento e revisado no subprocesso STI-2.004.5 Desenvolvimento de software. Chefe da DGTI Chefe da DSI Chefe da DSI Analista de sistemas Analista de sistemas Gerente do projeto Documentos gerados no subprocesso STI-2.004.5 Desenvolvimento de software Plano de gerenciamento de Iteração Relatório de avaliação da iteração Lista de requisitos funcionais Documento de casos de uso Gerado na fase de Concepção; Revisado nas fases de Elaboração, de Construção e Transição. Gerado em todas as fases. Gerado na fase de Concepção e revisado nas fases de Elaboração e Construção. Gerado na fase de Concepção e revisado nas fases de Elaboração e Construção. Gerente do projeto Gerente do projeto Analista de sistemas Analista de sistemas Lista de requisitos não Gerado na fase de Concepção e revisado na fase de Arquiteto Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 14/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 funcionais Documento de arquitetura Elaboração. Gerado na fase de Concepção e revisado na fase de Elaboração. Arquiteto Código fonte Gerado nas fases de Elaboração e Construção Desenvolvedor Build Modelo de dados Casos de teste Registro de teste Gerado nas fases de Elaboração e Construção e revisado na fase de Transição. Gerado na fase de Elaboração e revisado na fase de Construção. Gerado nas fases de Elaboração e Construção e revisado na fase de Transição. Gerado nas fases de Elaboração e Construção e Transição. Desenvolvedor Analista de sistemas Analista de sistemas Testador 12. CONCLUSÃO Muitas das atividades descritas nesta metodologia já são realizadas atualmente, sem que a metodologia esteja formalmente publicada. Muitas vezes, ocorre que a equipe de desenvolvimento, premida pela exiguidade do tempo determinado para a entrega do software, não documenta todas as atividades e vários artefatos acabam ficando incompletos. Isto tem penalizado, sobretudo, a documentação do produto. A partir da publicação desta metodologia, a DSI passa a atuar de forma mais organizada e orientada pelos processos de trabalho definidos e produzindo, não somente o software de qualidade, mas também a sua completa documentação. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 15/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 13. LISTA DE ANEXOS 13.1. Processo Nº STI-2.001 - Solução de demanda de software 13.2. Processo Nº STI-2.003 Atendimento por operação continuada 13.3. Processo Nº STI-2.004 Execução 13.4. Processo Nº STI-2.004.5 Desenvolvimento de software 13.5. Do armazenamento das informações 13.6. Modelos de documentos 14. GLOSSÁRIO 14.1. ABREVIATURAS E SIGLAS TERMO DESCRIÇÃO RUP OPEN UP DBA UML RDBMS DSI DGTI STI MGP-TRT24 Processo Unificado da Rational Processo Unificado Aberto Administrador de Banco de Dados Linguagem de Modelagem Unificada Sistema Gerenciador de Banco de Dados Relacional Divisão de Sistemas e Internet Divisão de Governança em TI Secretaria de Tecnologia da Informação Metodologia de Gerenciamento de Projetos do TRT24 14.2. TERMOS E DEFINIÇÕES TERMO Build (construção) Base line DESCRIÇÃO Versão compilada de um software ou parte dele que contém um conjunto de recursos que poderão integrar o produto final. Linha de base que estabelece nos projetos os pontos de referências para futuras comparações. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 16/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 Caso de uso Descrição de comportamento do sistema em termos de sequências de ações. Um caso de uso deve produzir um resultado de valor observável para um ator (alguém ou algo fora do sistema que interage com ele). Ele contém todos os fluxos alternativos de eventos referentes à produção do "resultado de valor observável". Um caso de uso define um conjunto de cenários, especificação de uma sequência de ações (incluindo variantes) que um sistema (ou outra entidade) pode executar, interagindo com atores do sistema. É uma unidade de um trabalho significante, como, por exemplo: "autenticação no sistema", "autorizar solicitação de servidor". Cada caso de uso tem uma descrição o qual descreve a funcionalidade que irá 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. Cada caso de uso deve descrever somente uma funcionalidade ou objetivo do sistema. Em sistemas complexos pode ser necessário um grande número de casos de uso para uma correta e completa descrição de todas as funcionalidades requeridas pelo sistema. Ciclo de vida do projeto É o conjunto das fases ou atividades que compõem um projeto de software. Gerência de requisitos de software Integração Contínua Marco de projeto Refatoração Regra de negócio Processo que tem como objetivo principal gerenciar os requisitos dos produtos e dos componentes do produto, e identificar inconsistências entre esses requisitos e os produtos de trabalho do projeto. A integração contínua é uma prática de implementação onde membros de equipe integram seu trabalho com conjunto de mudanças realizadas por outros desenvolvedores e testam a aplicação antes de tornar seu trabalho disponível para os demais. Isto permite a detecção de erros de integração mais prematuramente possível, tais como erros de compilação, notificações do sistema de gerenciamento de configuração e erros relatados pela ferramenta de teste. Um ponto de revisão geral do progresso do projeto, e que serve de momento ideal para reavaliar sua viabilidade. Deve ser planejado no cronograma e deveria envolver todos os participantes do projeto. Técnica de melhorar o desenho interno de um código ou produto de trabalho sem afetar as suas interfaces externas. Declaração que controla ou define alguns aspectos de um negócio. O RUP define Regra de Negócio como declarações sobre políticas ou condições que devem ser satisfeitas. Trata-se de uma restrição imposta pelo negócio e que regulamenta o comportamento de um procedimento operacional do negócio. É criada por políticas definidas pela organização. Podem ser originárias de leis, portarias e outros regulamentos. Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 17/18

TRT da 24ª Região Metodologia de produção de software Data: 25/06/2013 Regras de negócio têm vida totalmente independente de sistemas. Podem ser criadas e obedecidas sem uso de sistemas, pois pertence somente ao domínio do negócio. Entretanto, nada impede que regras de negócio venham a ser automatizadas, isto é, seja realizada por um sistema. Requisito funcional de software Condição ou capacidade que deve ser atendida pelo software, de forma que permita a um usuário solucionar um problema ou atender a um objetivo. Os requisitos funcionais especificam ações que um sistema deve ser capaz de executar, sem levar em consideração restrições físicas. Especificam, portanto, o comportamento de entrada e saída de um sistema. Requisito não funcional Requisitos que descrevem as qualidades do sistema, mas não as suas funcionalidades. Os requisitos não funcionais, ao contrário dos funcionais, não expressam as funções a serem realizadas pelo software, e sim os comportamentos e restrições que este software deve satisfazer. 15. REFERÊNCIAS MGP-TRT24 - Metodologia de Gerenciamento de Projetos do Sistema de Administração de Recursos de Informação e Informática (MGP-SISP) do Ministério do Planejamento, Orçamento e Gestão The Agile Unified Process (AUP) OpenUP / Basic Manual técnico para metodologia de desenvolvimento de software do exército Artigo: Open Up um processo ágil PORTARIA TRT/GP/DGCA Nº 704/2011 http://www.ambysoft.com/unifiedprocess/agileup.html http://epf.eclipse.org/wikis/openuppt/ B80-MT-78.001. MINISTÉRIO DA DEFESA. EXÉRCITO BRASILEIRO. DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA. MANUAL TÉCNICO Sandra Sergi Santos, Especialista em Engenharia de Software para Rational, IBM http://www.ibm.com/developerworks/br/local/rational/open_up/ Artigo: OpenUp the best of two worlds http://www.methodsandtools.com/archive/archive.php?id=69 Conceitos do Bizagi mapeamento de processos http://wiki.bizagi.com/en/index.php?title=main_page http://bizagibrasil.wordpress.com/2012/10/24/bizagi-brasil/ Secretaria de Tecnologia da Informação Divisão de Sistemas e Internet Página 18/18

SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO DIVISÃO DE SISTEMAS E INTERNET METODOLOGIA DE PRODUÇÃO DE SOFTWARE ANEXOS I a IV DOS PROCESSOS DE TRABALHO

TRIBUNAL REGIONAL DO TRABALHO DA 24ª REGIÃO Processos de Gerenciamento de Serviços de TI Processo STI-2.001 - Solução de demanda de software STI Secretaria de Tecnologia de Informação Divisão de Sistemas e Internet

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 APROVAÇÃO ELABORADO REVISADO APROVADO Aise Maria Longhi Canéppele João Carlos Ferreira Filho REVISÕES Revisão Data Descrição EQUIPE Nome Função Telefone E-mail Aise Maria Longhi Canéppele Chefe da DSI 3316-1728 aise@trt24.jus.br Waldeci Leitun de Almeida Chefe da SENET 3316-1707 walmeida@trt24.jus.br Marco Antonio Ribeiro Molento Chefe da SEDS 3316-1762 mmolento@trt24.jus.br Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 2/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 ÍNDICE 1 OBJETIVO...4 2 ABRANGÊNCIA...4 3 DEFINIÇÕES...4 4 PROCESSO...5 4.1 PAPÉIS E RESPONSABILIDADES...5 4.2 FLUXO DO PROCESSO STI-2.001 - SOLUÇÃO DE DEMANDA DE SOFTWARE...5 4.3 DESCRIÇÃO DO PROCESSO STI-2.001 - SOLUÇÃO DE DEMANDA DE SOFTWARE...7 5 MODELO RACI...11 5.1 DESCRIÇÃO...11 5.2 TABELA RACI...11 6 INDICADORES...11 7 REFERÊNCIAS...13 Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 3/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 1 OBJETIVO O objetivo do processo de desenvolvimento/manutenção de software da Secretaria de Tecnologia da Informação - STI-2.001 - Solução de demanda de software - é descrever toda a cadeia de atividades executas desde o pedido inicial do cliente até a implantação do software. Este é o principal processo da DSI e resume a sua própria identidade, que é produzir e entregar software especialista para todas as áreas do E. TRT e deve abranger toda a alteração ou criação de todos os sistemas e serviços web mantidos pela Divisão de Sistemas e Internet. 2 ABRANGÊNCIA Deve abranger toda a Secretaria de Tecnologia da Informação e, eventualmente, o SMP, quando envolver aquisições de software. 3 DEFINIÇÕES Termo Descrição STI Secretaria de Tecnologia da Informação DGTI Divisão de Governança de TI DSI Divisão de Sistemas e Internet Comitê Gestor de TIC Comitê formado pela alta gerência, responsável pela adoção da metodologia MGP-SISP como modelo de referência para a implantação da gerência de projetos de TI da Secretaria de Tecnologia da Informação do TRT. Gestão de demandas Processo responsável por gerenciar e coordenar as demandas dos usuários Gestão de portfólio de TIC Processo responsável por gerenciar os projetos do portfólio da STI RDM - Requisição de Mudanças Solicitação para formalizar uma requisição de mudança SIATE Sistema responsável pelo recebiento das solicitações dos clientes TAP Termo de abertura de processo Gestão de demandas Subprocesso de propriedade da DGTI, cujo propósito é avaliar a solicitação do cliente. Gestão de portfólio Subprocesso de propriedade da STI, cujo propósito é gerenciar o portfólio de serviços da TI. HelpDesk Setor da DGTI encarregada do primeiro nível de atendimento aos clientes. Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 4/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 4 PROCESSO 4.1 PAPÉIS E RESPONSABILIDADES Papel Responsabilidades Proprietário do Processo Responsável pela qualidade e eficiência do processo; Responsável por assegurar que todos os envolvidos na execução do processo sejam informados das mudanças efetuadas. Gerente do Processo Responsável pela execução do processo; Responsável pela avaliação do processo. Gerente do Projeto Responsável pelo planejamento, execução e controle do projeto até a sua conclusão; Responsável por manter a equipe focada nos objetivos do projeto e gerenciar conflitos com as partes interessadas; HelpDesk Responsável pelo recebimento da solicitação do cliente e o seu encaminhamento para análise da solução. Central de Serviços Responsável pelo gerenciamento da liberação do novo software. Comitê Gestor de TI Responsável por autorizar e entrada da nova demanda no portfólio de TI. Diretor da STI Responsável pela autorização do início do projeto. Analista de negócio Profissional da DSI responsável por entender a necessidade do cliente e o seu negócio e analisar a requisição para verificar a sua viabilidade. 4.2 FLUXO DO PROCESSO STI-2.001 - Solução de demanda de software Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 5/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 6/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 4.3 DESCRIÇÃO DO PROCESSO STI-2.001 - Solução de demanda de software Os subprocessos que não pertencem à DSI estão marcados com um asterisco (**) e a sua descrição é meramente explicativa para o contexto na qual se insere neste processo avaliado. Os subprocessos que compõem o PROCESSO Nº STI-2.001 estão marcados com um asterisco (*). Atividade Objetivo 1. Abrir solicitação no SIATE Receber as informações iniciais para o novo produto ou mudança. Tarefas Cadastrar a nova RDM no SIATE Relacionamentos Papéis Entradas Saídas Cliente e HelpDesk (primeiro nível de atendimento Formulário preenchido pelo solicitante via sistema SIATE (RDM) Nova RDM para análise Subprocesso ** Objetivo Observação Entradas Saídas 2.1. Gestão de Demandas Realizar avaliação inicial da solicitação do cliente Processo descrito em documento da DGTI - Analisar as informações da RDM, observando se as informações constantes nos são suficientes para a análise da demanda e verificar com a DSI se é um pedido de alteração de software ou se a complexidade/tamanho do produto solicitado indica que é um novo projeto Nova RDM para análise Documento de oficialização da demanda (DOD) Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 7/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Atividade Objetivo 2.2. Realizar análise de viabilidade do projeto Analisar a nova demanda e avaliar a sua viabilidade de modo a embasar a decisão para a abertura do novo projeto Tarefas Realizar os estudos requeridos para verificação da viabilidade técnica e financeira do projeto Avaliar viabilidade do ambiente institucional para a realização do projeto, a partir do clima político e organizacional, identificando possíveis entraves e oportunidades, assim como o impacto dos resultados do projeto sobre as rotinas da organização Identificar os patrocinadores do projeto Identificar as principais partes interessadas no projeto, internas e externas, favoráveis ou não Analisar a demanda, buscando entendimento inicial da necessidade a partir dos dados fornecidos, o que pode envolver a área requisitante para esclarecer requisitos básicos. Caso aplicável, avaliar o alinhamento da solicitação com o planejamento estratégico e tático da instituição Avaliar a possibilidade de atendimento da necessidade, incluindo análise das vantagens e desvantagens de cada opção Levantar as informações básicas sobre a capacidade técnica para realizar o projeto (comparar a tecnologia e a capacitação necessária para o projeto e os recursos disponíveis na organização, o que inclui estrutura física e de pessoal) Avaliar a relação custo x benefício das soluções identificadas A partir da análise do resultado, validar o projeto e emitir parecer recomendando a continuidade ou não da demanda Relacionamentos Papéis Entradas Saídas Responsável: Analista de sistemas Participantes: Cliente, projetista, administrador do banco de dados Documento de oficialização da demanda (DOD) Estudo de viabilidade (AVP) e, opcionalmente Observação Conforme metodologia de gerenciamento de projetos MGP-TRT24, aprovado pela PORTARIA TRT/GP/DGCA Nº 704/2011 Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 8/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Subprocesso ** Objetivo Observação Entradas Saídas 2.3. Gestão de Portfólio Analisar o impacto do novo projeto, autorizá-lo e priorizá-lo, conforme publicado em Modelo de Gestão de Portfólio da STI Subprocesso da STI Estudo de viabilidade, documento de oficialização da demanda e a planilha de mensuração do projeto, se houver Ata de reunião que alterou o portfólio, incluindo o projeto com alta prioridade Atividade Objetivo 2.4. Autorizar análise da solução Ordem do diretor da STI para que seja iniciado o procedimento de análise para execução do processo Tarefas Emitir ordem para a elaboração do Termo de Abertura do Projeto Relacionamentos Papéis Entradas Saídas Responsável: Diretor da STI Ata de reunião que alterou o portfólio, incluindo o projeto com alta prioridade Ordem de serviço Atividade Objetivo 2.5. Elaborar termo de abertura do projeto Elaborar e aprovar o TAP Tarefas Descrever a justificativa para o projeto, seus objetivos e o cenário pretendido após a implantação do projeto, de acordo com o documento de visão Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 9/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Definir o escopo (produtos ou serviços) Definir os produtos que não fazem parte do projeto (não escopo) Estimar prazos e custos do projeto, se possível Identificar principais premissas e restrições Identificar riscos de alto nível Definir equipe básica e estrutura para execução do projeto Aprovar e divulgar o Termo de Abertura de Projeto Relacionamentos Papéis Responsável Gerente do projeto Participantes Patrocinador, Diretor da STI, cliente Entradas Saídas Ordem de serviço, documento de visão Termo de Abertura do Projeto (TAP) aprovado Observação Conforme metodologia de gerenciamento de projetos MGP-TRT24, aprovado pela PORTARIA TRT/GP/DGCA Nº 704/2011 Atividade Objetivo 2.6. Encerrar chamado no SIATE Este processo é realizado pela DGTI e seu objetivo é dar um retorno ao cliente sobre a sua solicitação Tarefas Informar o usuário da decisão sobre a sua solicitação Atualização do status do chamado no SIATE Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 10/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Relacionamentos Papéis Entradas Saídas DGTI, HelpDesk Decisão sobre a inviabilidade ou não aprovação do projeto Fechamento da RDM no SIATE Subprocesso * Objetivo Observação Entradas Saídas 3. Atendimento por operação continuada Executar as manutenções necessárias nos sistemas atuais, sem que seja necessária a abertura de um projeto para isso Ver documento do processo STI-2.003 Atendimento por operação continuada RDM com status aceita RDM com prioridade definida e atualização do status da solicitação no SIATE Subprocesso * Objetivo Observação Entradas Saídas 4. Execução Construir o novo software Ver documento do processo STI-2.004 Execução Termo de abertura do projeto, documento de visão Software produzido, pronto para a implantação. Subprocesso ** Objetivo 5. Gerenciamento de liberação Implantar solução de software Observação Subprocesso de propriedade da DGTI e que gerencia a liberação do aplicativo, onde são realizados O testes finais da aplicação, a Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 11/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 Entradas Saídas criação de material de apoio e de apresentação do produto, os scripts de instalação e a revisão pós-implantação, para verificar junto ao cliente se a mudança foi realizada de acordo com o planejado e se atendeu os objetivos. Nova aplicação desenvolvida pela DSI Termo de recebimento do cliente 5 Modelo RACI 5.1 DESCRIÇÃO O modelo RACI é uma matriz de responsabilidades que aponta as atividades principais de cada processo e descreve os papéis e responsabilidades envolvidas nas atividades e atribuições. Para as atribuições é adotada a nomenclatura RACI, que define: R Responsible: Aquele que é responsável pela execução ou tomada de decisão, por fazer o trabalho, podendo ser compartilhado; A Accountable: Aquele que é cobrado pela atividade, pessoa que responde pelo trabalho ou quem presta contas, assim somente pode existir um; C Consulted: Aquele que é são consultado ou fornece entradas para que uma atividade seja feita ou decisão seja tomada; I Informed: Aquele que é informado após uma atividade ser feita ou decisão tomada; Informação será por e-mail. 5.2 TABELA RACI Cliente HelpDesk DSI DGTI STI Gerente do Projeto Abrir solicitação no SIATE R R I A I I Realizar análise de viabilidade do projeto I I R/A I I C Autorizar análise da solução I I C I R/A I Elaborar termo de abertura do projeto I I A I I R/A Encerrar chamado no SIATE I R I A I I 6 INDICADORES Não definidos nesta versão do documento Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 12/13

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.001 - Solução de demanda de software. Versão 1.0 7 REFERÊNCIAS Metodologia de Gerenciamento de Projetos de Tecnologia da Informação do Tribunal Regional do Trabalho da 24ª Região - MGP-TRT24 Processos ITIL descritos pela DGTI Guia para o gerenciamento de processos de negócio ABPMP BPM CBOK Versão 2.0 MANUAL TÉCNICO PARA METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE DO EXÉRCITO 1ª Edição - 2012 Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 13/13

TRIBUNAL REGIONAL DO TRABALHO DA 24ª REGIÃO Processos de Gerenciamento de Serviços de TI Processo STI-2.003 Atendimento por Operação Continuada Secretaria de Tecnologia de Informação Divisão de Sistemas e Internet

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.003 Atendimento por Operação Continuada Versão nº 1 APROVAÇÃO ELABORADO REVISADO APROVADO Marco Antonio Ribeiro Molento Aise Maria Longhi Canéppele João Carlos Ferreira Filho REVISÕES Revisão Data Descrição EQUIPE Nome Função Telefone E-mail Aise Maria Longhi Canéppele Chefe da DSI 3316-1728 aise@trt24.jus.br Waldeci Leitun de Almeida Chefe da SENET 3316-1707 walmeida@trt24.jus.br Marco Antonio Ribeiro Molento Chefe da SEDS 3316-1762 mmolento@trt24.jus.br Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 2/10

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.003 Atendimento por Operação Continuada Versão nº 1 ÍNDICE 1 OBJETIVO DO PROCESSO...4 2 ABRANGÊNCIA...4 3 DEFINIÇÕES...4 4 PROCESSO...5 4.1 FLUXO DO PROCESSO...5 4.2 DESCRIÇÃO DO PROCESSO...5 5 RACI...10 5.1 DESCRIÇÃO...10 5.2 TABELA RACI...10 6 REFERÊNCIAS (DOCUMENTOS)...10 Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 3/10

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.003 Atendimento por Operação Continuada Versão nº 1 1 OBJETIVO DO PROCESSO O objetivo do processo STI-2.003 Atendimento por Operação Continuada é descrever a atividade de manutenção de software, abrangendo manutenções evolutivas. A operação continuada é qualquer atividade realizada sobre um produto após o encerramento do seu projeto de construção, e desde que a atividade não tenha, por si só característica de projeto. 2 ABRANGÊNCIA Secretaria de Tecnologia da Informação e gestores de sistemas. 3 DEFINIÇÕES Termo STI DGTI DSI SEINT SEDS RDM DBA Descrição Secretaria de Tecnologia da Informação Divisão de Governança de TI Divisão de Sistemas e Internet Seção de Internet Seção de desenvolvimento de sistemas Requisição de mudança - Formulário para solicitação de alteração em serviços/produtos de TI Administrador de banco de dados Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 4/10

TRT DA 24ª REGIÃO/STI/DSI DESCRIÇÃO DE PROCESSO DE TRABALHO Processo STI-2.003 Atendimento por Operação Continuada Versão nº 1 4 PROCESSO 4.1 FLUXO DO PROCESSO 4.2 DESCRIÇÃO DO PROCESSO Secretaria de tecnologia da Informação/ Divisão de Sistemas e Internet METODOLOGIA DE PRODUÇÃO DE SOFTWARE Página 5/10