Instituto de Informática – UFG

Processo de Software - 2018-2

Atividade Supervisionada - Definição de Trabalho

O objetivo deste trabalho é especificar uma metodologia para desenvolvimento de software adequada para
uso em projetos realizados na Fábrica de Software que envolvem integração com disciplinas dos cursos de
graduação do INF.

O objetivo geral da metodologia a ser especificada é servir de base para o estabelecimento de um processo
padrão para desenvolvimento de software usado na Fábrica de Software do INF em projetos que fazem
integração com uma ou mais disciplinas de cursos de graduação do INF. Para isso a metodologia deve cumprir
os seguintes objetivos específicos:

• Objetivo 1: facilitar a compreensão do processo e demais conceitos envolvidos.

• Objetivo 2: apoiar a instanciação do processo em um projeto específico.
• Objetivo 3: facilitar a consulta de cada aspecto da metodologia pelo leitor.

Conforme a norma ISO/IEC/IEEE 24765:2017 (Systems and Software Engineering – Vocabulary), elementos de
uma metodologia tipicamente definem uma rede de conceitos abstratos e inter-relacionados que incluem a
especificação de tarefas, atividades, modelos, documentos, linguagens, notações e produtos de trabalho que
podem ou devem ser usados ou gerados ao aplicar a metodologia. A metodologia a ser especificada no
presente trabalho deve conter minimamente a especificação de:

1. Um processo de desenvolvimento de software a ser seguido no projeto.

2. Atividades do processo, incluindo responsabilidades, insumos e produtos de cada atividade.
3. Modelos (templates ou padrões) para os produtos de trabalho a serem utilizados e gerados,
considerando pessoas e ferramentas envolvidas na elaboração de cada produto.
4. Modelos (templates ou padrões) para comunicações previstas para serem realizadas no processo.
5. Práticas recomendadas, técnicas aplicáveis, procedimentos e regras usadas pelos participantes do
projeto para realizar o seu trabalho.

O documento a ser entregue neste trabalho deve conter uma definição de metodologia de desenvolvimento
de software com base nos conceitos operacionais da Fábrica de Software definidos no documento “Fábrica de
Software - Conceitos Operacionais - Desenvolvimento de Software - 2018” disponibilizado pelo docente no
diretório compartilhado da disciplina e na Norma ISO/IEC/IEEE 12207:2017, disponível no mesmo diretório.

O Anexo C do presente documento apresenta um modelo para definição de processo que pode ser útil na
elaboração do trabalho. Vale destacar que esse modelo serve apenas para fins ilustrativos, de forma que
outros formatos de definição de processo podem ser adotados.

O trabalho deve ser feito em grupos, conforme define o Anexo A do presente documento.

O trabalho a ser entregue deve ser um hiperdocumento na Web cuja página raiz deve ter o título “Metodologia
para Desenvolvimento de Software na Fábrica de Software do INF” e o subtítulo deve ser “Projetos Integrados
com Disciplinas do INF”. Um exemplo de estrutura para o hiperdocumento, com propósito meramente
ilustrativo, é apresentado no Anexo B do presente documento.

É essencial que todos os documentos sejam versionados, ou seja, deve ser possível observar as mudanças
feitas em cada documento ao longo do tempo e identificar o autor da mudança.
Não há limite para quantidade de documentos ou para tamanho dos documentos que compõem o
hiperdocumento, considerando que a organização do hiperdocumento deve facilitar a consulta e a
compreensão da metodologia por três tipos de leitores:

1) Especialista: conhece bem a metodologia e acessa o hiperdocumento apenas verificar ou confirmar

algo pontual. Para isso quer ver informações sintéticas e concisas, que permitam uma consulta rápida,
para chegar rapidamente ao ponto que deseja confirmar. Por exemplo, apenas um macrofluxo geral
do processo, associado a uma lista dos produtos gerados pelo processo, a partir dos quais ele possa
navegar diretamente para o ponto desejado.
2) Esporádico: conhece a metodologia, mas não a usa frequentemente, e deseja relembrar algum
aspecto. Não deseja ver todos os detalhes, mas precisa de informações adicionais além daquelas
apresentadas ao especialista. Por exemplo, que ver os objetivos de cada atividade do processo, com
templates e padrões usados nessas atividades.
3) Iniciante: deseja ver a documentação completa da metodologia, com a adição do máximo de
informações, inclusive referências bibliográficas complementares. Para o iniciante a documentação
serve para aprender sobre a metodologia. Diferentemente dos outros tipos de leitor, deseja ler a
metodologia completa, do início ao fim.

A entrega do trabalho deve ser feita no dia 17/11/2018. Após esse prazo haverá desconto na nota do trabalho,
conforme regras definidas no Plano da Disciplina.

A aula do dia 17/11/2018 será feita na modalidade não presencial. A presença nessa aula será verificada
mediante a entrega do trabalho. Trabalho entregue após a data da aula não valerá presença.

Em aulas subsequentes à entrega do trabalho poderá haver apresentação do trabalho de cada grupo para a
turma. O objetivo é discutir e avaliar a metodologia proposta, além de avaliar o domínio dos discentes sobre
os conceitos envolvidos.

Os casos omissos devem ser tratados diretamente com o docente.

 Anexo A – Definição de Grupos e Respectivos Elementos da Metodologia

Embora cada grupo tenha responsabilidade sobre uma parte específica da metodologia, é essencial que as
partes sejam consistentes, padronizadas e homogêneas, ou seja, cada parte é um elemento de uma
metodologia única, e não um conjunto de partes heterogêneas e despadronizadas.

A formação inicial dos grupos está definida a seguir. Essa formação pode ser alterada ao longo do tempo em
função de desistências da disciplina ou a critério do docente para equilibrar a composição dos grupos.

• Grupo 1: Integração (todas as fases):

o DJAIR JUNIO MENDES BATISTA
o GABRIEL PACHECO PERES PEREIRA DE MENEZES
o JOSÉ DA COSTA NUNES NETO
o MURILLO GORDO DE ANDRADE
o RAFAEL GONCALVES DOS REIS

• Grupo 2: Concepção
o ANDRÉ MAIKEL SOARES LOPES
o BENEDITO CARDOSO DOS SANTOS NETO
o GABRIEL RODRIGUES DE SOUZA LIMA
o LUCIANO DE SOUZA MENDES
o PEDRO BASILIO DE CAMARGO NETO
o SAYMON DE OLIVEIRA SOUZA
o VALQUER DINIZ NOVAES

• Grupo 3: Elaboração
o AUGUSTO BORGES DE MOURA
o AUGUSTO CESAR DA FONSECA FALCAO
o ERIK RAPHAEL RIBEIRO DA COSTA
o ERIVAN BARBOSA DO NASCIMENTO
o MARCOS MATHIAS PEREIRA
o RAFAEL CAMPOS DE SOUZA REIS
o WESLEY RAMOS DE LIMA

• Grupo 4: Construção
o EDIONAY DE SOUSA AGUIAR
o HENRIQUE CARDOSO DE FARIA
o JHORDAN GABRIEL OLIVEIRA MAGALHAES
o JOERMESSON DOS REIS CONCEIÇÃO
o MARCOS RAFAEL LAPA DE SOUSA
o PEDRO HENRIQUE PIRES DE JESUS
o RAPHAEL DE BRITO SOARES FERREIRA

• Grupo 5: Transição
o ALEXANDRE DE MATOS XAVIER
o CAIO LENTHULLIUS BARROS
o FERNANDO HENRIQUE COIMBRA AFONSO
o LUCAS SAMPAIO DIAS
o MATHEUS CAMPOS DE OLIVEIRA
 Anexo B – Exemplo de Modelo para Estrutura do Hiperdocumento

A Raiz do Hiperdocumento é um documento que apresenta um resumo de alto nível da metodologia de

desenvolvimento de software. O documento também explica o contexto de aplicação da metodologia (projeto
integrado com disciplina) e mostra as fases do processo de desenvolvimento de software, com links para cada
fase. Cada fase é descrita sucintamente em um documento que contém links para suas atividades. Cada
atividade é descrita sucintamente em um documento que contém links para suas tarefas. Cada tarefa é
detalhada em um documento que pode contar notas sobre a forma de execução da tarefa.

• Metodologia de Desenvolvimento de Software

o Subprocessos (Fases) do Desenvolvimento
▪ Integração
• Atividades
o A1
▪ Tarefas
• T1
• T2
• ...
o A2
o ...
▪ Concepção
▪ Elaboração
▪ Construção
▪ Transição
• Exemplo: Atividades de transição
o Implantar nova versão do software.
o Validar versão do software implantada.
o Encerrar projeto junto à Gestão de Portfólio de Projetos da Fábrica.
o Conduzir beta teste para validar as expectativas dos usuários.
o Implantar, configurar e disponibilizar software para a comunidade de
usuários.
o Corrigir defeitos e completar recursos do software que foram adiados
no projeto.
o Obter concordância das partes interessadas de que a implantação
está concluída.
▪ Descrição detalhada das tarefas da atividade
 Anexo C – Exemplo de Modelo para Definição de Processo de Software

Definição de Processo: << Nome do Processo>>

1) Propósito: «Definir o objetivo do processo na organização.»

2) Responsável: «Definir o responsável pelo processo na organização. Pode ser um papel, se houver um
único indivíduo que atua no papel, ou o papel e o indivíduo, caso o papel seja realizado por mais de uma
pessoa.»
3) Glossário: «Definir os conceitos fundamentais para o processo na forma de um Glossário.
Preferencialmente o glossário deve ser um documento a parte, com todos os conceitos da organização
sobre seus processos.»
4) Políticas: «Definir as expectativas organizacionais para o processo, como por exemplo as áreas de
aplicação do processo, tais como unidades organizacionais ou funções de trabalho.»
5) Métricas: « Definir indicadores de desempenho para o processo. Esses indicadores devem mostrar a
eficiência e a eficácia do processo. Deveria ser uma referência para um documento de métricas
organizacionais, inclusive com link para a base histórica de processos da organização. »
6) Qualidade: « Definir critérios e métodos para avaliar a qualidade do processo. Deveria ser uma referência
para ativos de garantia da qualidade organizacionais, tais como checklists e cronogramas organizacionais
de garantia da qualidade, para processos que não executam em projetos.»
7) Diagrama: « Definir o fluxo de atividades do processo. Usar notação BPMN ou UML (diagrama de
atividades).»
8) Definição de Atividades « Descrever cada atividade do diagrama de atividades de acordo com o modelo
a seguir.»

« Identificar o nome da atividade, que deve ser uma frase única, sem conjunções aditivas, iniciando
Atividade
com um verbo no infinitivo. Este nome da atividade deve refletir o objetivo esperado da atividade. »

« Identificar o papel do colaborador que é responsável pela execução da atividade. Toda atividade
Responsável
deve ter um único responsável.»

« 1. Identificar uma sequência numerada de tarefas que realizam o objetivo da atividade.»

« 2. Descrever cada tarefa como uma ação, com verbo no infinitivo. Definir cada comunicação como
uma tarefa especial dentro da atividade, usando a palavra-chave “Comunicar” como a ação da tarefa.
Ex: Comunicar ao Gerente de Projeto a necessidade de aprovar o início da atividade.»

« 3. Identificar cada tarefa por um número sequencial único na atividade.»

Tarefas
« 4. Denotar tarefas opcionais pelo número sequencial seguido de uma expressão entre
colchetes que define uma condição para execução da ação. Exemplo: 2. [Forma de Pagamento não é
em dinheiro] Verificar a situação do crédito do cliente. »

« 5. Denotar tarefas que podem ser executadas em paralelo, ou de forma concorrente, dentro da
atividade pelo mesmo número sequencial, seguido de uma letra. Exemplo: as ações 2.a e 2.b podem
ser executadas em paralelo dentro da atividade logo após a ação 1.»

« Estabelecer as condições para que a atividade possa ser iniciada. Se não houver critérios definidos
Pré-Condições
informar: “Nenhum critério específico”. Exemplo: “Início da atividade aprovado pela Direção.»

« Definir os artefatos de entrada para a atividade. Devem ser definidas todas as entradas, mesmo
Entradas aquelas que não são exigidas em alguma alternativa de execução da atividade. Um artefato que é
definido por um meta-documento (isto é, um template” ou “padrão”), deve ser sublinhado e deve
possuir um hiperlink apontando para o respectivo meta-documento. Os insumos devem ser
 referenciados nas tarefas que os utilizam. Por exemplo: a tarefa “1. Consultar a Lista Negra de Crédito
para aprovar o cadastro do cliente.” referencia o artefato “Lista Negra de Crédito” que deve estar nos
insumos da atividade.»

Critérios de « Estabelecer as condições para que a atividade possa ser encerrada. Se não houver critérios definidos
Saída informar: “Nenhum critério específico”. Exemplo: “Plano de Projeto aprovado pela Direção”.»

« Definir os artefatos de saída, gerados pela atividade. Esses artefatos devem ser referenciados pelas
tarefas da Atividade que os produzem. Um artefato que é definido por um meta-documento (isto é,
Produtos um “template” ou “padrão”), deve ser sublinhado e deve possuir um hiperlink apontando para o
respectivo meta-documento. Exemplo: “3. Criar a EAP do projeto”. Neste exemplo, EAP é um artefato
de saída da atividade, definido por um template.»

« Definir o ambiente de trabalho necessário para executar a atividade. Exemplos: estação de trabalho
(definir a configuração para a atividade), salas, móveis, climatização, etc.
Infraestrutura
Definir as ferramentas de apoio utilizadas na execução da atividade. Exemplos: softwares,
equipamentos específicos (leitor de código de barras, por exemplo). »