# Termos e Definições Termos e definições relacionadas ao processo de software. # Backlog do Produto **DEFINIÇÃO:** É uma lista de todas as funcionalidades, requisitos, melhorias e correções que devem ser implementadas no produto. O **BACKLOG DE PRODUTO** possui as tarefas de **SUPORTE E SUSTENTAÇÃO.** **RESPONSÁVEL:** O Product Owner (PO)/Analista de Negócios é responsável por manter e priorizar o **BACKLOG DO PRODUTO**. **OBJETIVO:** Organizar tudo o que precisa ser feito para o produto, de forma que as equipes possam trabalhar nas prioridades mais importantes. **REGRAS:** 1. Só devem estar no **BACKLOG DO PRODUTO** as tarefas com **SITUAÇÃO** definida como **NOVA** 2. Só devem estar no **BACKLOG DO PRODUTO** as tarefas de **SUPORTE E SUSTENTAÇÃO** 3. Somente o **ANALISTA DE NEGÓCIO** poderá definir quais tarefas devem estar no **BACKLOG DO PRODUTO** 4. A **EQUIPE DE DESENVOLVIMENTO** não poderá iniciar a implementação de tarefas que estão no **BACKLOG DO PRODUTO** **ACESSO AO** [BACKLOG DO PRODUTO](https://gp.ufla.br/projects/suporte-e-sustentacao/issues?query_id=169) # Backlog da Sprint **DEFINIÇÃO:** É uma lista de tarefas selecionadas do **BACKLOG DO PRODUTO** para serem trabalhadas durante uma **SPRINT**. Cada **SPRINT** tem um **BACKLOD DA SPRINT** distinto, que contém as metas e os itens que a equipe se compromete a entregar ao final da **SPRINT**. **RESPONSÁVEL:** Toda a a equipe é responsável por planejar e gerenciar o **BACKLOD DA SPRINT**. As alterações de prioridade ou inserção de novas tarefas no **BACKLOD DA SPRINT** deve ser definida pelo **ANALISTA DE NEGÓCIO** ou **CHEFIA**. **OBJETIVO:** Garantir que a equipe se concentre nas tarefas prioritárias e que consiga cumprir os objetivos da **SPRINT** de maneira eficiente. **REGRAS:** 1. No **BACKLOG DA SPRINT** só podem existir tarefas com: 1. PGD = referente ao mês corrente do planejamento 2. SITUAÇÃO = PARA FAZER 3. As tarefas podem ou não estar atribuídas a determinado membro da equipe 4. Só podem existir tarefas classificadas como SUPORTE E SUSTENTAÇÃO. # Quadro Ágil O Quadro Ágil é uma ferramenta visual usada em metodologias ágeis para organizar e acompanhar tarefas dentro de um time de desenvolvimento, gestão de projetos ou qualquer equipe que trabalhe com fluxos de trabalho iterativos. Ele ajuda a visualizar o progresso, melhorar a colaboração e aumentar a produtividade. **ESTRUTURA DO QUADRO ÁGIL:** O quadro geralmente é dividido em colunas que representam os diferentes estágios do fluxo de trabalho. No **QUADRO ÁGIL** da CSI são exibidas todas as tarefas de **PROJETOS** e **SUPORTE E SUSTENTAÇÃO** que foram planejadas para serem realizadas em determinado mês. O campo **PDG** indica o mês em que a tarefa deve ser realizada. Cada coluna do **QUADRO ÁGIL** da CSI possui uma situação. O significado de cada situação pode ser consultado [AQUI](https://kb.ufla.br/books/instrucoes-sobre-redmine/page/situacoes-das-tarefas). **BENEFÍCIOS DO QUADRO ÁGIL:** - Transparência – Todos conseguem ver o status das tarefas. - Melhoria da produtividade – Facilita a identificação de gargalos. - Colaboração eficiente – Times sincronizados com o fluxo de trabalho. - Flexibilidade – Pode ser adaptado para diferentes tipos de projetos. **ACESSO AO [QUADRO ÁGIL ](https://shre.ink/quadroagil)** # Característica-chave do produto É o serviço ou macro-funcionalidade que agrega valor ao negócio do cliente, dispensando uma descrição mais detalhada. As características-chaves, ou macrofunções, são atributos de valor ou serviços providos pela solução, derivados dos objetivos de negócio, para satisfazer necessidades de negócio dos clientes, em outros termos, são os aspectos mais relevantes do produto de *software* que o cliente valorizará com mais facilidade. Podem ser funcionalidades de negócio, performance, segurança, escalabilidade, etc.. As necessidades e expectativas do cliente, relacionadas aos objetivos de negócio, deverão ser utilizadas para definir o conjunto de características-chaves do produto final e deverão estar fortemente alinhadas. # Categorias dos projetos ##### **Categorias dos projetos, de acordo com sugestões da Metodologia de Gerenciamento de Portfólio de Projetos do SISP.** - **Mandatório** Projetos que não possuem alternativas à sua execução. Podendo ser motivados por exemplo devido a questões legais, ou mesmo questões técnicas. - **Melhoria de Serviço:** Projetos cujos objetivos sejam a melhoria de um serviço existente, que já encontra-se informatizado. Trazem ganhos incrementais em eficiência e/ou eficácia. Como por exemplo, podemos citar um projeto para melhorias em sistemas corporativos existentes, cuja necessidade foi gerada devido a mudanças promovidas no processo de negócio. - **Novo produto:** Projetos cujos objetivos sejam a informatização de processos parcialmente/não informatizados, ou a construção de um novo produto para o atendimento a uma demanda não relacionada necessariamente à informatização de processos. Exemplos: desenvolvimento ou implantação de novos sistemas, desenvolvimento de novos módulos em sistemas existentes, etc.. - **Exploratório:** Projetos que envolvem novas tecnologias em relação ao conhecimento apropriado pela organização, novas estratégias de negócio ou novas estruturas ou processos organizacionais. São projetos de grande incerteza intrínseca. Contudo, se bem sucedidos, podem trazer grandes ganhos de eficiência ou eficácia para a organização. Exemplos: Desenvolvimento de aplicativos para dispositivos móveis, desenvolvimento de novas soluções para apoio a tomada de decisão. # Desenvolvimento de Software Conjunto de atividades a serem executadas pela Área de TIC (unidade organizacional responsável por desempenhar as atividades relativas à Gestão de TIC no âmbito da UFLA) com a finalidade de atender às necessidades organizacionais que requeiram a alteração de um software institucional preexistente ou implementação de um novo software. Tem como resultado final a alteração ou criação de um software, incluídos seus artefatos vinculados (por exemplo, a documentação de software). O Desenvolvimento de Software deve estar em conformidade com a metodologia de desenvolvimento a ser estabelecida pela Área de TIC, sendo aplicados em especial os procedimentos necessários à garantia da qualidade do artefato de software. # Desenvolvimento Incremental Em um contexto ágil, o desenvolvimento incremental significa que cada versão sucessiva do produto é utilizável, e cada nova versão baseia-se na versão anterior, adicionando funcionalidades visíveis ao usuário. Este tipo de desenvolvimento resulta nos chamados incrementos "verticais", em oposição à estratégia tradicional que entrega componentes técnicos completos, sucessivamente: por exemplo, criar um esquema de banco de dados e, em seguida, construir regras de negócios em cima disso e, apenas em seguida, implementar os componentes de interface do usuário. Veja mais detalhes em: [https://www.agilealliance.org/glossary/incremental-development/](https://www.agilealliance.org/glossary/incremental-development/). # Desenvolvimento Iterativo O desenvolvimento iterativo é uma abordagem de desenvolvimento de *software* que divide o processo de desenvolvimento de um produto em partes menores. Cada parte, denominada iteração, representa todo o processo de desenvolvimento, contendo as etapas de planejamento, design, desenvolvimento, teste e validação. Veja mais detalhes em: [https://www.agilealliance.org/glossary/iterative-development](https://www.agilealliance.org/glossary/iterative-development). # Documento de Visão do Produto O documento de visão define o escopo de alto nível e o propósito de um projeto. Uma definição clara do problema, solução proposta e os recursos de alto nível do produto ajudam a estabelecer expectativas e a reduzir riscos. Este documento deve conter as informações identificadas durante o entendimento da demanda, tais como [objetivos de negócio](https://kb.ufla.br/books/termos-e-definicoes/page/objetivos-do-negocio "Objetivos do negócio"), [características-chaves do produto](https://kb.ufla.br/books/termos-e-definicoes/page/caracteristica-chave-do-produto "Característica-chave do produto"), aspectos tecnológicos e riscos, utilizados para orientar o desenvolvimento do produto de *software*. O modelo para elaboração da visão do produto, contendo as instruções para a sua elaboração, pode ser acessado a partir do seguinte endereço: [https://docs.google.com/document/d/1V6NJvMBTzAyTswA2xc8xtXGu\_g5yryewVAm7GtzL2rw/edit?usp=sharing](https://docs.google.com/document/d/1V6NJvMBTzAyTswA2xc8xtXGu_g5yryewVAm7GtzL2rw/edit?usp=sharing) # Implantação de Software Conjunto de atividades a serem executadas com a finalidade de atender às necessidades organizacionais que requeiram a implantação de um software de terceiro (cedido ou repassado à instituição, adquirido por meio de contratação ou obtido por outros meios). # Incidente Qualquer evento que não seja parte da operação programada para um serviço de TIC e que cause, ou possa causar, uma interrupção não planejada ou redução na qualidade do serviço. São exemplos de incidentes: sistema indisponível; sistema disponível mas com erro de funcionamento; exclusão indevida de dados pelo usuário; etc. # Integração Contínua Integração Contínua é uma prática de desenvolvimento de *software* que visa tornar a integração de código mais eficiente, através de *builds* e testes automatizados. É responsável pela coleta e empacotamento dos diversos componentes integrantes da aplicação, assim como a sua disponibilização em ambiente previamente determinado. As equipes utilizam-na para integrar rapidamente as suas implementações em uma versão ou incremento de *software*. # Objetivos do negócio São os objetivos que o cliente almeja alcançar em um determinado período de tempo. Os objetivos do negócio devem estar sempre no foco do projeto (agregação de valor para o cliente), pois são a chave para tomar boas decisões sobre custo, escopo e prazos. Os objetivos de negócio devem atender simultaneamente a seis critérios: - Focado em um resultado e não em um uma atividade; - Consistente, ou seja, alinhado coerentemente a outros objetivos e demais metas da organização; - Específico, ou seja, bem definido; - Mensurável, ou seja, quantificável e objetivo; - Alcançável. # Processo de Desenvolvimento de Software Fluxo de atividades pertencentes ao conceito de [Desenvolvimento de Software](https://kb.ufla.br/books/termos-e-definicoes/page/desenvolvimento-de-software "Desenvolvimento de Software"), instaurado após a elaboração e aprovação de um [Projeto de Desenvolvimento de Software](https://kb.ufla.br/books/termos-e-definicoes/page/projeto-de-software "Projeto de Software"). # Processo de Implantação de Software Fluxo de atividades pertencentes ao conceito de I[mplantação de Software](https://kb.ufla.br/books/termos-e-definicoes/page/implantacao-de-software "Implantação de Software"), instaurado após a elaboração e aprovação de um [Projeto de Implantação de Software](https://kb.ufla.br/books/termos-e-definicoes/page/projeto-de-software "Projeto de Software"). # Processo de Sustentação de Software Fluxo contínuo de atividades pertencentes ao conceito de [Sustentação de Software](https://kb.ufla.br/books/termos-e-definicoes/page/sustentacao-de-software "Sustentação de Software"), sem a necessidade de um [Projeto de Software](https://kb.ufla.br/books/termos-e-definicoes/page/projeto-de-software "Projeto de Software"). # Projeto de Software Esforço temporário de Desenvolvimento ou Implantação de Software, correspondendo a um Projeto de Desenvolvimento de Software ou um Projeto de Implantação de Software, respectivamente. Um Projeto de Software tem prazo de término definido e deve resultar em um produto final. Envolve o planejamento dos recursos necessários para que o software tenha o ambiente necessário para o seu funcionamento. # Requisição Solicitação formal de um serviço de Desenvolvimento, Sustentação ou Implantação de Software, como, por exemplo: criação de nova funcionalidade em sistema existente; alteração do cabeçalho de um relatório; fornecimento de dados; solicitar apoio técnico para implantação de novo software de terceiro, etc. # Suporte e Sustentação Entende-se por Suporte e Sustentação atividades de manutenções evolutivas e corretivas, não relacionadas a [Projetos de Software](https://kb.ufla.br/books/termos-e-definicoes/page/projeto-de-software "Projeto de Software"). Entram nessa categoria a realização de qualquer tipo de suporte técnico, execução de *scripts* para correção de erros operacionais, extração pontual de dados, análise de logs, etc, bem como a execução de atividades de [Sustentação de Software](https://kb.ufla.br/books/termos-e-definicoes/page/sustentacao-de-software "Sustentação de Software"). # Sustentação de Software Conjunto de atividades de [Desenvolvimento de Software](https://kb.ufla.br/books/termos-e-definicoes/page/desenvolvimento-de-software "Desenvolvimento de Software") necessárias para a manutenção da disponibilidade, integridade, estabilidade e desempenho do software em produção, dentro de um nível de acordo de serviço estabelecido pelo órgão. São ainda categorizadas como Sustentação de Software as atividades de Desenvolvimento de Software necessárias para a realização de manutenções evolutivas pontuais (cosméticas, adaptativas e perfectivas) de pequeno porte e baixo impacto, que não justifiquem o atendimento por meio de um novo [Projeto de Software](https://kb.ufla.br/books/termos-e-definicoes/page/projeto-de-software "Projeto de Software"). # Termo de Abertura do Projeto O Termo de Abertura do Projeto é o documento que formaliza o inicio do projeto, ou seja, que formaliza a aprovação para o início das atividades necessárias para o seu atendimento. O modelo para elaboração do Termo de Abertura do Projeto pode ser acessado a partir do seguinte endereço: [https://docs.google.com/document/d/1VBr-utvcdM7Q\_6l67\_pbKBrP6sD\_3Phdv9CtmvnNtY4/edit?usp=sharing](https://docs.google.com/document/d/1VBr-utvcdM7Q_6l67_pbKBrP6sD_3Phdv9CtmvnNtY4/edit?usp=sharing) # Estágios do Projeto Durante a Fase de Execução ##### Durante a fase de execução, um projeto poderá estar em um dos seguintes estágios: - **Inicial:** Estágio de planejamento inicial e coleta de informações. Nesta fase é feita a elaboração do [Termo de Abertura do Projeto](https://kb.ufla.br/books/termos-e-definicoes/page/termo-de-abertura-do-projeto "Termo de Abertura do Projeto"), do [Documento de Visão do Produto](https://kb.ufla.br/books/termos-e-definicoes/page/documento-de-visao-do-produto "Documento de Visão do Produto") e do [*Roadmap* de entregas](https://kb.ufla.br/books/termos-e-definicoes/page/roadmap "Roadmap"). Estarão nesta fase também os projetos cujo o início do desenvolvimento dependa de informações e/ou atuação de órgãos externos, como por exemplo, a liberação de acesso a APIs de integrações por parte do Governo Federal. - **Desenvolvimento:** Estágio posterior ao estágio inicial. Neste momento o projeto encontra-se em pleno desenvolvimento pela equipe alocada para o mesmo. # Roadmap O *roadmap* consiste em um registro cronológico com o planejamento de liberação de versões (*Releases*) do produto de *software*. Deve prover uma visão global das necessidades do produto ([objetivos de negócio](https://docs.google.com/document/d/15d7P5ue1jNlrERkF1n1nPQk8cNztdM0TZj6Xg6uQZZc/edit#bookmark=id.m7foydbk0z1x) e [características-chaves](https://docs.google.com/document/d/15d7P5ue1jNlrERkF1n1nPQk8cNztdM0TZj6Xg6uQZZc/edit#bookmark=id.pyr6ziuexmq3) associadas), sendo uma ferramenta valiosa para o planejamento, acompanhamento e organização da jornada de desenvolvimento do produto.