Engenharia de Software I

IFB / Campus Taguatinga

Curso ABI em Computação
AJ - Antonio Justiniano
PPC - Projeto Pedagógico de Curso
Objetivo: apresentar conceitos da engenharia de software, cujo
foco está nos aspectos práticos da produção de sistemas de
software, desde os estágios iniciais de especificação dos
sistemas até a manutenção destes
Ementa:
1. Modelos de ciclo de vida;
2. Técnicas de modelagem de sistemas;
3. Gerenciamento e Técnicas de apoio ao gerenciamento do
Processo de Produção de Software;
4. Apoio automatizado ao desenvolvimento de software;
5. Gerenciamento de configuração de software;
6. Análise de requisitos: requisitos funcionais e requisitos não
funcionais; técnicas para levantamento e representação de
requisitos, incluindo casos de uso;
7. Qualidade de Software: verificação e validação de software;
8. Padrões de Projeto de Qualidade de Software.
Conteúdo Programático
1. Introdução à engenharia de software
2. Processos de software
2.1. Modelos de processo
2.2. Desenvolvimento ágil
3. Modelagem de sistemas
3.1. Engenharia de requisitos
3.1.1. Requisitos funcionais e não funcionais
3.1.2. Especificação de requisitos
3.1.3. Elicitação e análise de requisitos
3.1.4. Desenvolvimento de casos de uso
3.2. Projeto de interação
3.2.1. Prototipação de interface de usuário
3.2.2. Avaliação de interface de usuário
Conteúdo Programático (cont.)
3. Modelagem de sistemas (cont.)
3.3. Validação de requisitos
3.4. Negociação de requisitos
3.5. Gerenciamento de requisitos
3.6. Modelagem baseada em cenários
3.7. Rastreabilidade de requisitos
4. Gerenciamento de projetos de software
4.1. Planejamento de projetos
4.2. Gerenciamento de qualidade
4.2.1. Qualidade de produto e de processo
4.2.2. Qualidade de documentos
4.3. Gerenciamento de configuração
4.4. Melhoria de processos de software
Metodologia de Trabalho
● Aulas participativas, onde o professor é o facilitador
do conhecimento, em laboratório computacional com:
○ Uso de ambiente virtual da disciplina;
○ Apresentação de slides;
○ Explicação dos conteúdos;
○ Exploração dos procedimentos;
○ Análise de situações-problema;
○ Debate acerca de opiniões, podendo ser
convergentes e divergentes; e
○ Realização de atividades individuais e
colaborativas.
● Todos devem preparar-se para os encontros,
buscando o material necessário para atingir as metas
de cada.
Metodologia de Ensino
Avaliações de aprendizagem:
● Nota = N1*0,3+N2*0,4+AC*0,3 (N1*P1+N2*P2+N3*P3),
onde:
○ N1 e N2: avaliações individuais;
○ AC: avaliação colaborativa (resolução de exercícios,
atividades práticas, pesquisas e estudo de caso);
● Poderá haver uma prova substitutiva, ao final, com matéria
acumulativa, para aqueles que desejarem substituir a menor
das notas, considerando o peso daquela que se substituirá.
Recursos necessários:
● Quadro branco e pincéis;
● Projetor de slides;
● Computadores em rede com os seguintes aplicativos:
○ Navegador; Suíte para edição de textos, planilhas e
apresentações; e Pencil.
Bibliografia
● Principal
○ PRESSMAN, Roger S. Engenharia de
Software: uma abordagem profissional. 7ª ed.,
São Paulo, McGrawHill/Bookman, 2011.
○ SOMMERVILLE, Ian. Engenharia de Software.
9ª ed., São Paulo, Pearson Prentice Hall,
2011.
● Complementar
○ PAULA FILHO, Wilson P. Engenharia de
Software: fundamentos, métodos e padrões.
3ª ed., Rio de Janeiro, LTC, 2012.
○ Conteúdos da Web, cujos links estão neste
documento de apresentação.
 2/08 Apresentações; Introdução à Engenharia de Software
ES1 - 4/08 Fechamento do Plano de Ensino; Processos de software

Agenda de 9/08 Processos de software; Exercício 1

2016/2 11/08 Exercício 1: debate

16/08 Modelos de processos de software; Processo Unificado

18/08 Processo Unificado; Desenvolvimento ágil; Exercício 2

25/08 Exercício 2: debate

30/08 Modelagem de sistemas; Engenharia de requisitos

1/09 Classificação de requisitos; Especificação de requisitos; Exercício 3

6/09 Exercício 3 - debate

8/09 Avaliação 1: aplicação

13/09 Elicitação e análise de requisitos

15/09 Desenvolvimento de casos de uso

20/09 Avaliação 1: correção; Avaliação 2: elaboração; Avaliação 3: definição

22/09 Desenvolvimento de casos de uso; Exercício 4

27/09 Exercício 4; Projeto de interação

29/09 Projeto de interação; Prototipação e avaliação de interface de usuário

4/10 Exercício 4; ConectaIF

 6/10 Exercício 4; ConectaIF
ES1 - 11/10 Prototipação e validação de requisitos; Negociação de requisitos; Exercício 5
Agenda de 13/10 Modelagem baseada em cenários

2016/2 18/10 Gerenciamento de requisitos; Rastreabilidade de requisitos

(cont.) 20/10 Exercício 6; Gerenciamento de projetos de software

25/10 Gerenciamento de projetos de software

27/10 Exercício 6: entrega; Avaliação 2: elaboração

1/11 Avaliação 2: entrega

3/11 Planejamento de projetos; Exercício 7; Gerenciamento de qualidade

10/11 Qualidade de produto e de processo; Exercício 8

17/11 Qualidade de documentos; Gerenciamento de configuração; Exercício 9

22/11 Avaliação 2: correção; Avaliação 3: elaboração

24/11 Melhoria de processo de software; Exercício 10: elaboração

29/11 Melhoria de processo de software; Exercício 10: entrega; Avaliação 3: orientação

1/12 Seminários dos grupos

6/12 Seminários dos grupos (Connepi); Avaliação 3: conclusão

13/12 Avaliação 3: correção (resultado até dia 9 no Nead); Avaliação substitutiva

15/12 Avaliação substitutiva: correção; Resultado final

Introdução à Engenharia de Software
1. Engenharia – o que é? Para quê?
2. Software – o que é? Para quê? Quais são?
3. Crise do Software
4. Engenharia de Software – o que é? Para
quê? Como ocorre?
5. Atuação na Engenharia de Software – quais
as áreas correlatas? Quais as
peculiaridades? Quais são os desafios do
engenheiro de software?
6. Questões éticas e profissionais relacionadas
à Engenharia de Software – qual a
responsabilidade? Há um código de ética?
Engenharia
● A arte de resolver problemas
● É a ciência e a profissão de adquirir e de
aplicar os conhecimentos matemáticos,
técnicos e científicos na criação,
aperfeiçoamento e implementação de
utilidades, tais como materiais, estruturas,
máquinas, aparelhos, sistemas ou
processos, que realizem uma determinada
função ou objetivo
● Características distintivas
○ Planejamento
○ Procedimentos padronizados
 Sistema de Software
● Software é o conjunto de procedimentos que
determinam o funcionamento do computador, de
acordo com as tarefas demandadas pelos seus
usuários. É desenvolvido por profissionais de
software, que fazem a manutenção ao longo de
sua vida útil
● Consiste em:
○ programas de computador que, executados, fornecem
características, funções e desempenho desejados
○ estrutura de dados a serem manipulados por estes
○ documentação que descreve a operação e o uso destes
○ documentação do sistema
○ eventualmente, sites com informações e atualizações
dos programas
Tipos de
Software
Como produto,
transforma
informações,
produzindo,
adquirindo,
modificando,
exibindo ou
transmitindo-as.
Podem ser: ● Software para distribuição de produto
● aplicativos; ○ Sistema operacional
● adaptados ou ○ Utilitários
customizados; ○ Elemento de comunicação em
● encomendados. rede
 ES, SI e Computação
● Ciência da Computação
○ Teorias e métodos básicos referentes aos
computadores e sistemas de software
● Sistemas de Informação
○ Administração do fluxo de informações que circulam
por redes de computadores e das áreas envolvidas
● Engenharia de Sistemas
○ Aspectos do desenvolvimento e da evolução de
sistemas complexos, onde o software tem um papel
principal, mas considera o hardware e outros
○ Projeto de políticas e processos organizacionais
○ Implantação e integração de sistemas em produção
● Engenharia de Software
○ Problemas práticos da produção de software
○ Abordagens específicas para desenvolver software
Engenharia de Software
● Disciplina de engenharia que se ocupa dos diversos
aspectos da produção de software, desde os estágios
iniciais de especificação do sistema até a sua
manutenção, quando já está sendo usado
○ Aplicação apropriada de teorias, métodos e
ferramentas, na busca criativa de soluções
adequadas
○ Considera restrições organizacionais e financeiras
● Relevância da produção de software
○ Dependência crescente de software na sociedade
○ Adoção de ES é mais barata que apenas fazer
programas
○ Inclui o gerenciamento de projeto de software e
adoção de teorias, métodos e ferramentas de apoio
 Crise do Software - Origem da ES
Curva de defeitos de software

● É um processo de engenharia, não de fabricação

● Não se desgasta, mas deteriora-se devido às
modificações
● Os métodos de ES tentam reduzir a magnitude das
elevações (picos) e a inclinação da curva real
● Não existem peças de reposição de software, cada
defeito indica erro no projeto ou no processo, implicando
em complexidade maior na manutenção
Desafios da ES
● Software legado
○ Fazer a manutenção e atualização de softwares
antigos, em processo de substituição
● Heterogeneidade
○ Sistemas interoperando de maneira distribuída em
diferentes tipos de computadores, inclusive portáteis,
com diferentes tipos de sistemas operacionais
○ Produzir software confiável que seja flexível
● Atendimento a mudanças de negócio e social
○ Técnicas de desenvolvimento de software tradicionais
são consideradas demoradas para as mudanças atuais
○ Como desenvolver rapidamente e com qualidade?
● Segurança e confiança
○ A forte presença do software no cotidiano exige que
seja confiável e que estejam protegidos de ataques
Responsabilidade Profissional e Ética
● Responsabilidade do Engenheiro de Software
○ Mais amplas do que habilidades técnicas
○ Considerar estruturas legal e social
● Código de Ética (ACM/IEEE)
○ Confidencialidade de empregadores e clientes
○ Competência, negando trabalho que não seja de
sua alçada
○ Direitos de propriedade intelectual, zelando para
garantir a dos clientes e empregadores
○ Mau uso de computadores, desde o mais básico
até o extremamente grave, como disseminar vírus
● Código de ética e práticas profissionais da
engenharia de software
Camadas da ES

1. Foco na qualidade
a. É a pedra fundamental que sustenta a ES
2. Processo
a. Sequência de atividades para o desenvolvimento de software,
de forma racional e dentro do prazo e outras restrições
b. Inclui atividades de apoio, como gerenciamento de projetos
3. Métodos
a. Fornecem informações técnicas para desenvolver o software
b. Inclui comunicação, análise de requisitos, modelagem de
projeto, construção de programa, testes e suporte
4. Ferramentas
a. Suporte para a qualidade, o processo e os métodos
b. Quando integradas, tem-se um sistema de suporte ao
desenvolvimento de software, chamado engenharia de
software com auxílio de computador (Computer-Aided
Software Engineering - CASE)
Processo de Software
Conjunto de atividades, ações e tarefas
realizadas na criação de software, onde:
● atividade é voltada para atingir um objetivo
amplo, usada independentemente do campo
de aplicação, do tamanho do projeto, da
complexidade de esforços ou rigor na
aplicação da ES
● ação é o conjunto de tarefas que resultam
em artefato
● tarefa tem objetivo restrito e bem definido,
produzindo um resultado tangível
Aplicação do Processo de Software
● Deve ter uma abordagem flexível que permite a
escolha de ações e tarefas apropriadas
● Considera o problema, o projeto, a equipe e a
cultura organizacional com a intenção de
entregar o software no prazo e com a qualidade
que satisfaçam àqueles que o patrocinaram e aos
que o usarão
● “Se os modelos prescritivos forem aplicados de
forma dogmática e sem adaptações, poderão
aumentar a burocracia associada ao
desenvolvimento de sistemas e... criarão
dificuldades para todos os envolvidos.”
Metodologia de Processo
Framework é o alicerce para um processo de ES
completo, por meio de:
● identificação de atividades estruturais
aplicáveis aos projetos de software,
independente de tamanho e complexidade
● conjunto de atividades de apoio para todo o
processo de software
● implementação de atividades metodológicas,
em todo processo de software
Atividades Metodológicas
Atividades da metodologia de processo de ES:
1. Comunicação: envolve comunicar-se e colaborar com os
interessados - clientes, usuários, gerentes do sistema e
outros, como reguladores que certificam a aceitabilidade
2. Planejamento: o Plano de Projeto de Software define o
trabalho de ES, descrevendo tarefas técnicas, riscos
prováveis, recursos necessários, produtos a serem
produzidos e cronograma
3. Modelagem: esboço do sistema para melhor entender as
necessidades do software e o projeto que irá atender a tal
demanda
4. Construção: combina geração de código, manual ou
automatizada, e testes para revelar erros na codificação
5. Implantação (emprego): entrega do software ao cliente,
que o avalia e fornece feedback dessa avaliação
Atividades de Apoio
Complemento do processo de ES, as quais são
aplicadas ao longo de um projeto, sendo:
1. Controle e acompanhamento do projeto: possibilita a
avaliação do progresso em relação ao Plano, tomando
medidas para cumprir o cronograma
2. Administração de riscos: avalia o que pode afetar o
resultado ou a qualidade do projeto e do produto
3. Garantia da qualidade de software: atividades que
garantem a qualidade do software
4. Revisões técnicas (testes): avaliação de artefatos da
ES, tentando eliminar a propagação de erros nas demais
atividades
Atividades de Apoio
Atividade de apoio mais adotadas (cont.):
5. Medição: define e coleta medidas do processo, do
projeto e do produto, auxiliando na entrega do software
de acordo com os requisitos;
6. Gerenciamento de configuração de software: trata
dos efeitos das mudanças ao longo do processo;
7. Gerenciamento da reusabilidade: define critérios para
reuso de artefatos, inclusive componentes de software, e
estabelece como ocorre a obtenção destes;
8. Preparo e produção de artefatos de software: criação
de artefatos como modelos, documentos, formulários,
etc.
Atuação na Engenharia de Software
● Atividades da metodologia e de apoio estabelecem
um esquema para a atuação do engenheiro de
software
● A essência da prática para solução de problemas é:
a. Compreender o problema (comunicação e
análise)
b. Planejar uma solução (modelagem e projeto de
software)
c. Executar o plano (geração de código -
construção)
d. Examinar o resultado para ter precisão (testes -
construção - e garantia da qualidade de
software)
ES1: Exercício 1 (fórum no Nead)
1. O que você entendeu por sistema de software?
2. Como definir a ES? Qual a sua importância?
3. Qual a relação entre a crise do software e a origem da ES?
4. Quais características são peculiaridades da ES, considerando
áreas correlatas da informática?
5. Para você que contribuição a ES pode dar às demais áreas
correlatas da informática?
6. Quais são as camadas da ES, explicando qual a relação entre
duas destas?
7. Com relação a atuação do engenheiro de software, que
desafios lhe chamou a atenção?
8. Qual princípio ético cada um pode destacar, explicando
porque é um destaque para você?
9. Que questão cada um pode levantar para o debate sobre:
a. Processo de software?
b. Metodologia de processo?
Modelos de Processo de Software
● Forma como as atividades, ações e tarefas
necessárias para o desenvolvimento de software,
com boa qualidade, são relacionadas com o
processo e umas com as outras, considerando o
prazo estabelecido
● Todos os modelos aplicam as atividades
metodológicas, com diferenças na ênfase e no
fluxo de processo que as invoca
● Fluxo de processo
○ Define como são organizadas as atividades
metodológicas, com as ações e tarefas de
cada uma, em relação à sequência e ao
tempo
Fluxos de Processo de Software
1. Fluxo de processo linear: cada atividade
metodológica é executada em sequência
2. Fluxo de processo iterativo: uma ou mais
atividades são repetidas antes de
prosseguir, sendo então aplicadas repetidas
vezes, em que cada iteração produzirá um
incremento de software, disponibilizando
recursos e funcionalidades
Fluxos de Processo de Software (cont.)
3. Fluxo de processo
evolucionário: executa
as atividades de forma
circular, onde cada volta
produz uma versão
mais completa
4. Fluxo de processo
paralelo: uma ou mais
atividades são
executadas
simultaneamente com
outras atividades
Modelo de Processo Prescritivo
1. Modelo em cascata: sugere uma abordagem sequencial
(linear) para o desenvolvimento do SW, sendo aplicado
em situações de adaptações ou aperfeiçoamentos bem
definidos em sistema existente. Problemas:
a. Projetos raramente seguem o fluxo sequencial
b. É difícil o cliente explicitar todas as suas necessidades
c. O cliente deverá esperar uma versão operacional
próximo do final do projeto
Modelo de Processo Prescritivo (cont.)
2. Desenvolvimento incremental: combina os fluxos de
processos linear e paralelos, de forma escalonada, onde
cada sequência linear gera incrementais do SW. Usado
quando há necessidade de fornecimento de
funcionalidade aos usuários, para somente após isso,
refiná-la e expandi-la em versões posteriores
● O primeiro incremento é
um produto essencial,
atendendo os requisitos
básicos
● Com resultado do seu
uso, é planejado o
incremento seguinte, que
considera a sua melhoria
e a entrega de
funcionalidades adicionais
 Modelo de Processo Prescritivo (cont.)
3. Processo evolucionário: são modelos iterativos,
possibilitando desenvolver versões cada vez mais
completas do SW. Podem ser:
a. Prototipação: pode ser usada como técnica
implementada em qualquer modelo. É usada quando
os requisitos estão obscuros, permitindo aos
interessados compreender melhor a solução
● Na comunicação, define-se os objetivos
gerais do SW, identificando os
requisitos já conhecidos e as áreas
envolvidas na ampliação de suas
definições
● Uma iteração de prototipação é
planejada e ocorre a modelagem, na
forma de projeto rápido, que se
concentra no que é visível aos usuários
 Modelo de Processo Prescritivo (cont.)
3. Processo evolucionário (cont.):
b. Modelo espiral: combina a prototipação (iterativa) com
aspectos do modelo em cascata, fornecendo potencial
para o desenvolvimento rápido de versões cada vez
mais completas do SW. A 1ª versão é um protótipo, mas
nas iterações posteriores são incrementados o grau de
definição e implementação de um sistema, enquanto
diminui o seu grau de risco
● Pontos âncora de controle
são indicados a cada
passagem evolucionária
● O 1º circuito pode resultar na
especificação de produto,
depois no desenvolvimento
de protótipo e de versões
melhores
Processo Unificado
É um exemplo de processo híbrido, reunindo elementos
gerais de modelos de processo, dirigido a casos de uso,
centrado na arquitetura, com apoio na iteração
(prototipação) e na entrega incremental. Tem as seguintes
fases:
1. Concepção: envolve a comunicação e o planejamento,
descrevendo requisitos de negócio demandados por
entidades externas (usuários e sistemas);
2. Elaboração: envolve a comunicação, planejamento e a
modelagem, desenvolvendo uma compreensão do
problema, um modelo de arquitetura para o sistema e o
plano do projeto;
3. Construção: desenvolve ou adquire componentes de
SW, onde as partes do sistema são desenvolvidas em
paralelo e integradas
 Processo Unificado (cont.)
4. Transição: engloba a construção (entrega) e a
implementação (realimentação ou feedback), onde sistema
é usado, em versão beta, no ambiente real, tendo como
objetivo ajustar o seu funcionamento e sua documentação;
5. Produção: é a atividade de implantação (emprego) quanto
à monitoração do uso do SW, disponibilizando suporte para
o ambiente operacional. Também são elaborados e
avaliados relatórios de defeitos e solicitações de mudanças.
 Disciplinas do Processo Unificado
Workflow Descrição

Modelagem de negócios Os processos de negócio são modelados por meio de casos de uso

Atores que interagem com o sistema são identificados e casos de uso

Requisitos
são desenvolvidos para modelar os requisitos do sistema

Um modelo de projeto é criado e documentado com modelos de

Análise e projeto
arquitetura, de componentes, de objetos e de sequência

Os componentes do sistema são implementados e estruturados em

Implementação subsistemas de implementação. A geração automática de código a
partir de modelos de projeto pode ajudar a acelerar esse processo

É um processo iterativo que é feito em conjunto com a implementação,

Teste
onde o teste do sistema segue a conclusão da implementação

Um release do produto é criado, distribuído aos usuários e instalado em

Implantação
seu local de trabalho

Gerenciamento de
Workflow de apoio que gerencia as mudanças do sistema
configuração e mudanças

Gerenciamento de projeto Workflow de apoio que gerencia o desenvolvimento do sistema

Workflow relacionado com a disponibilização de ferramentas

Meio ambiente
apropriadas para a equipe de desenvolvimento de software
 Desenvolvimento Ágil de Software
● Adotado em ambientes de negócio que se
caracterizam por mudanças rápidas, onde o SW
é desenvolvido em uma série de incrementos.
● As atividades metodológicas permanecem,
mas são reduzidas em tarefas mínimas, onde a
equipe de projeto agiliza a comunicação e a
colaboração entre os envolvidos, priorizando o
desenvolvimento e a entrega
 Princípios dos Métodos Ágeis
Princípios Descrição

Devem estar intimamente envolvidos no processo de

Envolvimento do
desenvolvimento, tendo o papel de fornecer e priorizar novos
cliente
requisitos do sistema e avaliar suas iterações

O software é desenvolvido em incrementos, com o cliente

Entrega incremental
especificando os requisitos para serem incluídos em cada um

As habilidades da equipe de desenvolvimento devem ser

Pessoas, não reconhecidas e exploradas, onde seus membros devem
processos desenvolver suas próprias maneiras de trabalhar, sem
processos prescritivos

Deve-se ter em mente que os requisitos do sistema vão

Aceitar as mudanças mudar, de maneira que o projeto do sistema deve ser flexível
para acomodar as mudanças

O foco na simplicidade deve ser mantido tanto no software a

Manter a
ser desenvolvido, quanto no processo de desenvolvimento,
simplicidade
devendo-se trabalhar para eliminar as suas complexidades
 Métodos Ágeis: Características
● Agilidade é mais que uma resposta à mudança,
exigindo estruturação e atitudes em equipe
para tornar a comunicação mais fácil
● Processo Extreme Programming (XP)
Métodos ágeis
enfatizam a entrega
rápida do software
operacional,
diminuindo a
importância dos
artefatos
intermediários e
priorizando a
entrega incremental
ES1: Exercício 2 (responda no Nead)
1. Os objetivos gerais (amplos) e específicos (restritos) de um
processo de software são abordados por quais de seus
elementos?
2. As atividades de apoio são aplicadas de forma homogênea ao
longo de qualquer processo de software? Explique sua
resposta.
3. Destaque diferenças entre os quatro fluxos de processo de
software com relação à atividade de implantação (emprego).
4. Destaque uma característica de cada modelo de processo
prescritivo. Dê ao menos um exemplo de contexto de
desenvolvimento de software que o faria optar por um deles.
5. Que problema pode ocorrer na adoção do desenvolvimento
ágil de software? Explique o porquê.
6. Que questão cada um pode levantar para o debate sobre:
a. Processos de software;
b. Modelos de processos de software;
c. Processo unificado.
Modelagem de Sistemas
● Processo de desenvolvimento de modelos
abstratos que apresentam uma visão ou
perspectiva diferente de um sistema por meio de
gráficos
● Deve representar:
○ as informações que o SW transforma
○ a arquitetura e as funções que as transformam
○ as características indicadas pelos usuários
○ o comportamento do sistema à medida que a
transformação ocorra
● Linguagem de modelagem unificada, Unified
Modeling Language (UML): notação gráfica para
modelagem orientada a objetos (OO)
Tipos de Modelos de Sistemas
● M. de requisito ou de análise: representam os
requisitos dos clientes
● M. de projeto: a fim de ajudar os desenvolvedores a
construir o SW, oferecem uma especificação concreta
deste, quanto a:
○ arquitetura
○ interface com usuário
○ detalhes de componentes
● M. de sistema existente: permitem esclarecer o que já
é feito, podendo ser o ponto de partida para definir os
requisitos do novo sistema
● M. de novo sistema: ajudam explicar os requisitos
propostos para os interessados (stakeholders) do
sistema, a fim de debatê-los e documentar o sistema
para sua implementação
Princípios Gerais de Modelagem
1. O objetivo principal da equipe de desenvolvimento é
construir SW, e não criar modelos: usar apenas aqueles
que ajudam
2. Não crie mais modelos do que o necessário, elaborando
somente modelos que facilitem
3. Esforce-se ao máximo para produzir um modelo mais
simples possível
4. Construa modelos que facilitem alterações, devendo
haver informações para isso
5. Seja capaz de estabelecer um propósito claro para
cada modelo
6. Adapte o modelo desenvolvido ao sistema, sendo talvez
necessário adaptar a notação ou as regras do modelo ao
aplicativo
 Princípios de Modelagem (cont.)
7. Crie modelos úteis. Esqueça a construção de modelos
perfeitos, pois a modelagem deve ser conduzida tendo
em vista as etapas de ES seguintes
8. Não seja dogmático quanto à sintaxe do modelo. Se
transmite o conteúdo com sucesso, a representação é
secundária, o mais importante do modelo é transmitir
informações que possibilitem a próxima tarefa
9. Se o instinto indica que um modelo não está correto,
embora pareça no papel, provavelmente há motivos com
os quais se preocupar. Se for um engenheiro
experiente, confie em seu instinto
10. Obtenha o feedback o quanto antes. Todo modelo deve
ser revisado pela equipe de SW a fim de corrigir erros de
modelagem e de interpretações, além de adicionar
características ou funções omitidas inadvertidamente
Engenharia de Requisitos (ER)
● Requisitos devem refletir as necessidades dos
clientes e assim a sua finalidade, sendo
○ descrições do que o sistema deve fazer
○ os serviços que oferece
○ as restrições a seu funcionamento
● Engenharia de Requisitos é o conjunto de tarefas e
técnicas que levam ao entendimento dos requisitos
● Tem o objetivo de fornecer a todos os envolvidos um
entendimento escrito do problema
● Artefatos são gerados e revisados com os envolvidos
para garantir o entendimento da equipe, sabendo-se que
ainda assim haverá mudanças ao logo de todo o projeto
● No processo de SW é uma ação da ES iniciada na
atividade de comunicação e continua na de modelagem,
construindo uma ponte para o projeto e para a construção
Abrangência da ER
Abrange as sete etapas seguintes, podendo ocorrer em
paralelo:
1. Concepção estabelece
a. um entendimento básico do problema
b. os envolvidos
c. a natureza da solução desejada
d. a eficácia da comunicação
e. a colaboração preliminares entre a equipe de SW
e os interessados
2. Levantamento define
a. os objetivos do sistema
b. como deve atender às necessidades da
organização
c. como será usado no dia-a-dia
Abrangência da Eng. de Requisitos
3. Elaboração: onde são expandidas e refinadas
informações obtidas durante a concepção e
levantamento, definindo um modelo de requisitos
refinado que identifique os aspectos da função, do
comportamento e das informações do SW
a. cenários de usuário (casos de uso) descrevem
como o usuário e outros atores irão interagir com
o sistema
b. classes de análise são definidas a partir da
análise de cada cenário de usuário. São entidades
do domínio de negócio visíveis ao usuário, seus
atributos e os respectivos serviços exigidos por
cada classe, além das relações e colaboração
entre estas
Abrangência da Eng. de Requisitos
4. Negociação é um processo que busca
a. conciliar os conflitos de interesses entre
diferentes clientes ou usuários
b. definir a ordem de prioridade dos requisitos
c. avaliar seus custos e riscos
d. tratar dos conflitos internos da equipe
5. Especificação pode conter
a. um documento por escrito
b. um conjunto de modelos gráficos
c. um modelo matemático formal
d. um conjunto de cenários de uso
e. um protótipo ou a combinação destes
Abrangência da Eng. de Requisitos
6. Validação ocorre por meio da revisão técnica, onde
engenheiros, clientes e outros interessados examinam
a especificação em busca de falhas, avaliando a
qualidade dos artefatos produzidos para garantir que:
a. não haja ambiguidade em cada um dos requisitos
b. as inconsistências, omissões ou erros tenham sido
detectados e corrigidos
c. que os artefatos estejam de acordo com os padrões
estabelecidos para o processo, o projeto e o produto
7. Gestão: sabendo-se que os requisitos mudam, um
conjunto de atividades ajuda a equipe a identificar,
controlar e acompanhar as necessidades e suas
mudanças a qualquer momento do projeto, sendo estas
as mesmas do gerenciamento de configuração de SW
Classificação de Requisitos
● Requisitos funcionais são declarações
○ dos serviços que devem ser fornecidos
○ das reações a entradas específicas
○ dos comportamentos que devem ocorrer em
determinadas situações
○ em alguns casos, também podem representar o que o
sistema não deve fazer
● Requisitos não funcionais são restrições aos serviços
ou funções oferecidos, quanto a tempo, ao processo de
desenvolvimento e aquelas impostas pelas normas,
geralmente referentes ao sistema como um todo, ao
contrário dos requisitos funcionais
● Requisitos de negócio descrevem, em termos de
negócio, quais são os valores organizacionais que o
sistema de software deve atender
Requisitos Funcionais (RF)
● Definem todos os serviços requeridos pelo cliente
de forma consistente, ou seja, sem contradições
entre eles
● Variam de requisitos gerais, definindo o que o
sistema deve fazer, até os específicos, refletindo os
sistemas e as formas de trabalho
● Exemplos de RF para um sistema usado de
manutenção das informações sobre pacientes em
tratamento por problemas de saúde mental:
○ Um usuário pode pesquisar listas de
agendamentos para todas as clínicas
○ Deve ser gerado a cada dia, para cada clínica, a
lista de pacientes para as consultas daquele dia
Requisitos Não Funcionais (RNF)
● Definem as características e restrições do
sistema como um todo, abrangendo, dentre
outros, desempenho, confiabilidade,
disponibilidade
● Surgem por meio de necessidades dos usuários,
devido a restrições de orçamento, políticas
organizacionais, interoperabilidade com outros
sistemas, regulamentos de segurança ou
legislações de privacidade
● Não estão diretamente relacionados com os
serviços específicos oferecidos aos usuários
● Geralmente não estão relacionados a
componentes específicos, mas difundidos em
todo o sistema
 Tipos de Requisitos Não Funcionais
1. De produto: especificam ou restringem o comportamento do SW
2. Organizacionais: definem políticas e procedimentos das
organizações do cliente e da equipe de desenvolvimento
3. Externos: derivam de fatores externos como legislação, normas
reguladoras e princípios éticos
 Métricas para Especificar RNF
Sempre que possível, RNF devem ser descritos em
quantidades, para que sejam objetivamente
testados
Propriedade Medida
Transações processadas/segundo
Velocidade Tempo de resposta de usuário/evento
Tempo de atualização de tela
Tamanho Megabytes; Número de chips de memória ROM
Facilidade de Tempo de treinamento
uso Quantidade de frames de ajuda
Tempo médio para falhas
Confiabilidade
Taxa de ocorrência de falhas; Disponibilidade
Robustez Tempo de reinício após falha
Portabilidade Percentual de declarações dependentes do sistema-alvo
Especificação de Requisitos
● Descrição de requisitos em um documento no qual, dependendo
do contexto, usa-se linguagem natural e modelos gráficos
● Deve especificar somente o comportamento externo do sistema,
não incluindo detalhes da arquitetura ou projeto
● Req. de usuário (necessidade) são declarações, em linguagem
natural e diagramas, de quais serviços o sistema fornecerá aos
usuários e as restrições com as quais deve operar
● Req. de
sistema são
descrições
mais
detalhadas das
funções,
serviços e
restrições do
sistema
Princípios de Modelagem de Requisitos
1. O universo de informações de um problema deve ser
representado e compreendido, englobando
a. dados que constam no sistema (do usuário, de outros
sistemas)
b. dados que fluem para fora deste (interfaces, relatórios)
c. armazenagem de dados (daqueles que são mantidos)
2. As funções que o software desempenha devem ser
definidas, pois transformam dados, exercem controle sobre o
processamento interno e sobre elementos de sistema externo,
podendo ser descritas em diferentes níveis de abstração,
desde afirmação geral até seu detalhamento
3. O comportamento do software, como consequência de
eventos externos, deve ser representado, pois é comandado
por sua interação com o ambiente externo (usuários, sistema
externo, dados de monitoramento coletados em uma rede etc.),
determinando a operação específica do SW
Princípios de Modelagem de Requisitos
4. Os modelos que descrevem informações, funções e
comportamentos devem ser divididos para que revelem
detalhes por camadas (ou hierarquicamente), onde um
problema grande e complexo é dividido em subproblemas
até que cada um seja relativamente fácil de ser
compreendido, sendo por isso uma estratégia da
modelagem de requisitos denominada fracionamento ou
separação por interesse
5. A análise deve partir da informação essencial para o
detalhamento da implementação, que inicia pela descrição
do problema na perspectiva do usuário (modelagem de
requisitos), sem levar em consideração como a solução será
implementada, para então detalhar como será sua
implementação (modelagem de projeto)
Esses cinco princípios permitem abordar problemas de forma
sistemática
 ES1: Exercício 3 (no Nead)
1. Como você diferencia iteração e incremento?
2. Cite ao menos um elemento que a modelagem de software deve
representar e explique qual a utilidade deste modelo neste caso.
3. Dos dez princípios gerais de modelagem, qual você destaca?
Justifique sua escolha.
4. Que etapa da ER pode tratar da distância entre o que o cliente “quer”,
o que ele “precisa” e o que é tecnicamente viável?
5. Por que os requisitos mudam? Uma mudança pode surgir a partir da
revisão dos requisitos?
6. Qual a diferença de requisitos funcionais e não funcionais? Cite ao
menos uma característica de cada um.
7. A especificação é uma das sete etapas da Engenharia de Requisitos.
Como você a relaciona com as demais?
8. Requisitos de sistema são independentes daqueles de usuário?
Explique.
9. Dê um exemplo de especificação de requisito não funcional, com sua
medida, para um software de gestão escolar.
10. Dos princípios da modelagem de requisitos, o que é e como deve ser
feito o fracionamento?
Processo de Engenharia de Requisitos
● É iterativo
● O tempo e o esforço
dedicados a cada
atividade depende
do processo e do tipo
de sistema
● No início o esforço é a
compreensão dos req.
de negócio e os não
funcionais
● O número de iterações
varia, com os requisitos
sendo desenvolvidos
em níveis cada vez
maiores de
detalhamento
Elicitação e Análise de Requisitos
● Acontece após a concepção
● Engenheiros de SW trabalham com clientes e
usuários do sistema para obter informações sobre o
domínio da aplicação, os serviços que deve
oferecer, o desempenho, restrições, etc.
● O seguinte modelo propõe quatro ações para a
elicitação e análise de requisitos
Elicitação e Análise de Requisitos: Ações
● Descoberta é a fase de interação com
interessados para identificar seus requisitos
● Classificação e organização, onde os
requisitos são organizados em grupos
coerentes
● Priorização e negociação, na qual são, por
meio da negociação, encontrados e resolvidos
os conflitos de interesses e priorizados os
requisitos
● Especificação é a fase em que os requisitos
elicitados até o momento são documentados e
inseridos no próximo ciclo da espiral, após a
validação
Descoberta de Requisitos
● Tem o objetivo de reunir informações sobre o sistema
requerido e os sistemas existentes, permitindo registrar
então os requisitos de usuário e de sistema
● Além dos interessados do sistema, os requisitos também
podem advir do domínio da aplicação e de outros sistemas
que interagem com aquele que está sendo especificado
● Fontes de informação para esta tarefa são a
documentação, os interessados do sistema, e
especificações de sistemas similares
● As diferentes fontes podem ser representadas como
pontos de vista do sistema, onde cada um mostra um
subconjunto de requisitos
● A comunicação com os interessados ocorre por meio de
entrevistas e observações, podendo-se usar cenários de
uso e protótipos para ajudar na compreensão do que será
o sistema
Entrevistas
● Podem ser de dois tipos
○ Entrevista fechada, em que os interessados
respondem a um conjunto predefinido de perguntas
○ Entrevista aberta, na qual não existe uma agenda
predefinida
● Geralmente as entrevistas com interessados misturam
ambos os tipos (semiabertas), onde as respostas a
determinadas perguntas levam a outras
● São eficazes para obter uma compreensão global sobre o
que os interessados fazem, como eles podem interagir
com o novo sistema e as dificuldades que enfrentam com
os sistemas atuais
● A entrevista pode deixar escapar informações essenciais,
devendo ser usada em conjunto com outras técnicas de
elicitação, como observação do usuário e demais fontes
de informação
Os Entrevistadores
● Dificuldades durante as entrevistas
○ Costumam não revelar o conhecimento do
domínio, suas terminologias e jargões específicos
○ A maioria das pessoas relutam discutir questões
políticas e organizacionais que podem afetar os
requisitos
● Características de entrevistadores eficazes
○ São abertos a novas ideias, evitando ideias
preconcebidas sobre os requisitos com disposição
para ouvir os interessados, mesmo quando
estes apresentam requisitos-surpresa
○ Estimulam a participação do entrevistado com
uma questão-trampolim, uma proposta de
requisito ou um protótipo de sistema elaborado de
forma conjunta
Perguntas Iniciais do Processo de ER
1. Primeiramente enfocam o cliente e outros
interessados
○ Quem está por trás da solicitação deste
trabalho?
○ Quem irá usar a solução?
○ Qual será o benefício econômico de uma
solução bem-sucedida?
○ Há uma outra fonte de solução desta demanda?
2. Enfocam depois o entendimento do problema e
percepção do cliente sobre uma solução
○ Qual ou quais problema(s) esta solução tratará?
○ Como se caracterizaria uma solução
bem-sucedida para esse(s) problema(s)?
 Perguntas Iniciais do Processo de ER
2. Enfocam depois o entendimento do problema e
percepção do cliente sobre uma solução (cont.)
○ Qual o ambiente de negócios em que esta
solução será usada?
○ Restrições ou problemas de desempenho afetam
a maneira com que a solução será abordada?
3. Finalmente enfocam a eficácia da comunicação
○ Suas respostas podem ser consideradas oficiais?
○ As perguntas foram relevantes para o seu
problema?
○ Foram feitas perguntas demais?
○ O que mais deveria ter sido perguntado?
○ Outra pessoa poderia dar informações
adicionais?
Observação
● Uma técnica de observação, denominada
Etnografia, pode ser usada para compreender os
processos operacionais e ajudar a extrair
requisitos de domínio ou organizacionais, que
apoiam esses processos
● Um engenheiro faz uma imersão no ambiente de
trabalho em que o sistema será usado, fazendo
anotações sobre as tarefas reais em que os
usuários estão envolvidos, ajudando a descobrir
requisitos implícitos, que refletem processos
reais, além dos formais definidos pela organização
● A observação também ajuda a descobrir requisitos
derivados da cooperação e conhecimento das
atividades de outras pessoas com os usuários
Cenários de Uso
● A medida que os requisitos são levantados, tem-se uma
visão geral das funções e características, mas ainda é
preciso definir como essas funções e características são
usadas por diferentes classes de usuários
● Engenheiros de SW e outros interessados criam um
conjunto de cenários para identificar um roteiro de uso
para o sistema a ser construído
● Cenários adicionam detalhes a uma descrição geral de
requisitos, descrevendo sessões de interação, onde cada
um relata algumas interações possíveis
● Podem ser escritos como texto, suplementados por
diagramas e protótipos. Em uma abordagem estruturada
são chamados casos de uso, fornecendo uma descrição
de como será o sistema quanto a sua interação com
usuários e outros sistemas (atores)
Artefatos da Elicitação de Requisitos
Para a maioria dos sistemas estes são os artefatos
produzidos durante a elicitação de requisitos:
1. Declaração da necessidade e viabilidade dos sistema
2. Declaração restrita do escopo para o sistema
3. Lista de clientes, usuários e outros interessados que
participaram do processo
4. Descrição do ambiente técnico do sistema
5. Lista de requisitos, preferencialmente organizada
por serviços, com as restrições de domínio que se
aplicam a cada um
6. Conjunto de cenários de uso
7. Protótipos desenvolvidos para melhor definição dos
requisitos
Esses artefatos podem compor o Documento de
Requisitos
 Estrutura de Documento de Requisitos
Capítulo Descrição

Define os possíveis leitores do documento e descreve seu histórico

Prefácio de versões, incluindo uma justificativa para a criação de uma nova
e um resumo das mudanças feitas em cada versão

Descreve a necessidade para o sistema, com a descrição breve

das funções deste, explicando como vai funcionar com outros
Introdução
sistemas e descrevendo como atenderá aos objetivos globais de
negócio ou estratégicos da organização que encomendou o SW

Glossário Define os termos técnicos usados no documento

Especificação
Descreve os serviços fornecidos ao usuário e os RNF, incluindo as
de requisitos
normas de produto e processos que devem ser seguidas
de usuários

Deve apresentar uma visão geral em alto nível da arquitetura do

Arquitetura do sistema previsto, mostrando a distribuição de funções entre os
Sistema módulos do sistema. Componentes de arquitetura que são
reusados devem ser destacados
 Estrutura de Documento de Req. (cont.)
Capítulo Descrição

Especificação
Descreve em detalhes os requisitos funcionais e não funcionais,
de requisitos
podendo-se, caso necessário, definir interfaces com outros sistemas
de sistema

Inclui modelos gráficos que mostram os relacionamentos entre os

Modelos de
componentes, o sistema e seu ambiente. Exemplos de modelos:
sistema
modelos de objetos, de fluxo de dados, semânticos de dados

Descreve os pressupostos fundamentais em que o sistema se

Evolução do baseia, bem como quaisquer mudanças previstas em decorrência da
sistema evolução de hardware, de mudanças nas necessidades dos
(Conclusão) usuários, etc., sendo útil para evitar decisões que restrinjam
possíveis mudanças futuras no sistema

Fornece informações relacionadas à aplicação em desenvolvimento,

Apêndices além de descrever, por exemplo, requisitos de hardware e de banco
de dados, com a organização lógica dos dados usados

Vários índices podem ser usados, como alfabético, de diagramas, de

Índice
funções
 Desenvolvimento de Casos de Uso
● A modelagem de caso de uso é amplamente usada para
apoiar a elicitação de requisitos, caracterizando uma
representação do sistema do ponto de vista do que o
usuário espera deste
● Cada caso de uso representa uma tarefa que envolve a
interação externa com um ator
● É composto por elipses com seus atores envolvidos,
representados por figuras-palito, ligados por linhas,
formalmente sem setas

● Às vezes todas as possíveis interações de um sistema

são incluídas em um único diagrama composto por casos
de uso. Caso isso não seja possível, deve-se desenvolver
vários diagramas, cada um mostrando casos de uso
relacionados
 Informações de um Caso de Uso
Estas perguntas devem ser respondidas por um caso de uso
1. Quem são os atores primário(s) e secundário(s)?
2. Quais são as metas do ator?
3. Que precondições devem existir antes de uma história
começar?
4. Que tarefas ou funções principais são realizadas pelo ator?
5. Que exceções deveriam ser consideradas à medida que
uma história é descrita?
6. Quais são as variações possíveis na interação do ator?
7. Que informações de sistema o ator adquire, produz ou
modifica?
8. O ator terá de informar ao sistema sobre mudanças no
ambiente externo?
9. Que informações o ator deseja do sistema?
10. O usuário gostaria de ser informado sobre mudanças
inesperadas?
 Atores
● Primeiramente defina um conjunto de atores envolvidos na
história, podendo ser qualquer elemento externo (pessoa,
SW, dispositivo) que se comunica com o sistema no
contexto da função e comportamento a serem descritos
● Um ator representa uma classe de entidade externa que
desempenha apenas um papel no contexto do caso de
uso, e não a pessoa do usuário, que pode desempenhar
uma série de papéis diferentes ao usar um sistema. Assim
é importante notar que ator e usuário não são a mesma
coisa
● Nem todos os atores são identificados durante a 1ª
iteração, na qual é possível identificar atores primários,
que interagem para atingir a função necessária do sistema
● Atores secundários, que dão suporte ao sistema, de
modo que os primários possam realizar seus trabalhos, são
identificados posteriormente
Funções ou Atividades de um Ator
● Para desenvolver um conjunto de casos de uso
enumere as funções ou atividades realizadas por
um ator
● À medida que a comunicação com o interessado for
avançando, a equipe de ER desenvolve casos de
uso para cada uma das funções citadas
● Primeiramente os casos de uso são escritos em
forma narrativa informal e, se for necessária maior
formalidade, são reescritos em formato estruturado
● Exemplo de narrativa informal
○ Nome do caso de uso: acessar vigilância por
câmeras via Internet - exibir visões das câmeras
○ Ator: proprietário do imóvel
Narrativa Informal de Caso de Uso
Se eu estiver em um local distante, posso usar qualquer
navegador para entrar no site Produtos da CasaSegura.
Introduzo meu ID de usuário e dois níveis de senha e, depois de
validado, tenho acesso a toda funcionalidade para o meu
sistema instalado. Para acessar uma visão de câmera
específica, seleciono “vigilância” nas principais funções
mostradas. Em seguida seleciono “escolha uma câmera” e a
planta da casa é mostrada. Seleciono então a câmera que estou
interessado. Como alternativa, posso ver, ao mesmo tempo,
imagens em miniatura de todas as câmeras, selecionando
“todas as câmeras”. Ao escolher uma câmera, seleciono
“visualização” para visualizar um quadro por segundo, em uma
janela identificada pelo ID da câmera. Se quiser trocar de
câmera, seleciono “escolha uma câmera” e a planta da casa é
mostrada novamente. Em seguida, seleciono a câmera em que
estou interessado, surgindo nova janela de visualização
 Sequência Ordenada de Ações
Fluxo principal (caminho feliz)
1. O proprietário do imóvel faz o login no site da CasaSegura
2. O proprietário do imóvel introduz seu ID de usuário
3. O proprietário do imóvel introduz duas senhas, cada uma com
pelo menos 8 caracteres
4. O sistema mostra os botões de todas as principais funções
5. O proprietário do imóvel seleciona a “vigilância” dentre as
funções principais
6. O proprietário do imóvel seleciona “escolher uma câmera”
7. O sistema mostra a planta da casa
8. O proprietário do imóvel seleciona um ícone de câmera na
planta da casa
9. O proprietário do imóvel seleciona o botão “visualização”
10. O sistema mostra uma janela de visualização identificada pelo
ID da câmera
11. O sistema mostra imagens de vídeo a uma velocidade de um
quadro por segundo
Refinamento de um Caso de Uso
● Interações alternativas são essenciais para um completo
entendimento da função a ser descrita no caso de uso
● Cada etapa do cenário primário é avaliada, respondendo as
seguintes perguntas
○ O ator pode fazer algo diferente neste ponto?
○ Existe a possibilidade de o ator encontrar alguma
condição de erro neste ponto? Se sim, qual seria?
○ Existe a possibilidade de o ator encontrar algum outro
tipo de comportamento neste ponto? Se sim, qual seria?
● Exceção descreve um fluxo secundário, seja uma condição
de falha, seja uma alternativa escolhida pelo ator, fazendo
com que o sistema exiba um comportamento diferente
● A lista de exceções deve ser racionalizada com este critério:
deve ser indicada no caso de uso se o SW for capaz de
detectar uma condição descrita e, em seguida, tratá-la assim
que for detectada
Caso de Uso Formal
● Caso de uso: Acessar vigilância por câmeras via
Internet - exibir visões das câmeras
● Iteração: 2, última modificação: 14/01, feita por Fulano
● Ator: proprietário do imóvel
● Precondições: o sistema deve estar configurado; devem
ser obtidos ID de usuário e senhas apropriadas
● Disparador: o proprietário do imóvel decide fazer uma
inspeção na casa enquanto encontra-se fora dela
● Cenário:
○ Itens 1 a 11 descritos na sequência ordenada
● Exceções:
1. O ID ou senhas são incorretas ou não foram
reconhecidos - ver o caso de uso Validar ID e senhas
2. A função de vigilância não está configurada para este
sistema, mostrando uma mensagem de erro - ver caso
de uso Configurar função de vigilância
Caso de Uso Formal
3. O proprietário seleciona “Visualizar as imagens em
miniatura para todas as câmeras” - ver o caso de uso
Visualizar as imagens em miniatura para as câmeras
4. A planta não está disponível ou não foi configurada,
mostrando uma mensagem de erro - ver caso de uso
Configurar planta da casa
5. É encontrada uma condição de alarme - ver caso de
uso Condição de alarme encontrada
● Prioridade: moderada, a ser implementada após funções
básicas
● Quando disponível: terceiro incremento
● Frequência de uso: moderada
● Canal com o ator: navegador instalado em PC
● Atores secundários: administrador do sistema, câmeras
● Canais com atores secundários: administrador - sistema
baseado em PC; câmeras - conectividade sem fio
Diagrama de
Caso de Uso
Diagramas de casos de
uso em UML:
1. Preliminar para o
sistema Casa Segura
2. Para a função de
segurança domiciliar
Atores e Casos de Uso
● Diagramas de casos de uso especificam os
relacionamentos de associação entre casos de uso e
atores, indicando a comunicação esses
● Um caso de uso pode estar associado a mais de um ator,
quando sua execução requer a participação de diferentes
atores
● Pode-se agrupar atores
em atores genéricos, que
representam
características comuns a
estes, de comportamento
semelhante em relação
ao SW. Atores genéricos
e específicos são ligados
por relacionamento de
herança
Relacionamentos entre Casos de Uso
É uma notação usada para facilitar a descrição de
funcionalidade mais complexa, onde funções são
decompostas em casos de uso mais simples,
combinados por meio de relacionamentos
1. Relacionamento de generalização indica que um
caso de uso mais especializado herda
comportamentos de um caso de uso mais genérico,
acrescentando ou redefinindo detalhes
Relacionamentos entre Casos de Uso
2. Relacionamento de extensão de B para A ocorre
quando B representa um comportamento
adicional, como uma situação opcional, que
normalmente não ocorre durante a execução de
A
Relacionamentos entre Casos de Uso
3. Relacionamento de inclusão de A para B é
quando B representa uma atividade complexa,
invocada dentro do fluxo de A, sendo o caso
de uso incluído referenciado explicitamente no
caso de uso base, ao contrário do que
acontece na extensão
ES1: Exercício 4 - ER
1. Considerando a descrição sobre a Avaliação 3, envie um e-mail para
antonio.neto@ifb.edu.br, até dia 29/09, com o assunto Grupo ES1,
informando o nome ou tema do sistema a ser especificado pelo grupo,
seus integrantes e os papéis que estão responsáveis
2. Crie o Documento de Requisitos, a partir do modelo DOC ou ODT,
usando o exemplo para ajudar no preenchimento
3. Preencha o Doc. de Requisitos do grupo, até a Introdução
4. Planeje (1) um Roteiro para descoberta de requisitos, que deve incluir:
a. Diretrizes da reunião para levantamento de requisitos
b. Apresentação do grupo (3) no contexto do curso de ES1
c. Perguntas que o grupo fará aos interessados
d. Outras fontes que podem ajudar na elicitação de requisitos, como
documentos e telas de sistemas existentes
5. Poste o Roteiro, que será um anexo do Doc. de Requisitos, no fórum do
grupo até dia 03/10
6. Agende (1) e realize a elicitação inicial de requisitos junto aos
interessados até o dia 07/10
7. Poste (2), até o dia 10/10, a versão do Doc. de Requisitos com o
resultado da reunião (1ª iteração), tendo preenchido os itens de 1 a 3
Projeto de Interação
● O termo “projeto de interação” é usado em vez de “projeto
de interface de usuário” porque é importante para o
projetista pensar como os usuários interagem com as
aplicações e não se focar no desenvolvimento de
interfaces atraentes
● O foco está no processo do projeto de interação, e não no
SW que implementa as interfaces de usuário
● O projeto cuidadoso de interação é parte essencial para o
processo mais global de projeto de SW, pois é crítico para
a confiança no sistema
● Muitos dos chamados “erros de usuário” originam-se nas
interfaces que não consideram as capacidades de
usuários reais e seu ambiente de trabalho
● Interface mal projetada significa que os usuários
provavelmente não acessarão algumas características de
sistema, cometerão erros e sentirão que o SW atrapalha
Projeto de Interação: Fatores Considerados
1. Pessoas têm memória de curto prazo limitada, podemos
lembrar instantaneamente de apenas sete itens de
informação. Se apresentar aos usuários muita informação
ao mesmo tempo, eles podem não assimilá-las
2. Todos cometemos erros, especialmente quando temos de
lidar com muita informação ou estamos sob pressão.
Quando os SW não funcionam bem e enviam mensagens
de alerta e alarmes, colocam o usuário sob mais pressão
e aumentam as chances de erros
3. Temos uma faixa diversa de capacidades físicas.
Algumas pessoas veem e escutam melhor que outras,
algumas são melhores que outras na manipulação física.
Não se deve apenas projetar para as suas capacidades e
presumir que todos terão as mesmas capacidades
4. Temos diferentes preferências de interação. Alguns
gostam de trabalhar com imagens, outros, com textos
 Princípios de Projeto de Interface
Princípios Descrição
Familiaridade A interação deve ser baseada em termos e conceitos retirados
de usuário da experiência das pessoas que farão maior uso do sistema
A interface deve ser consistente de maneira que, sempre que
Consistência possível, as operações similares sejam ativadas da mesma
maneira
Surpresa Os usuários nunca devem ser surpreendidos pelo
mínima comportamento de um sistema
Facilidade de A interface deve incluir mecanismos para permitir que os
recuperação usuários recuperem-se de erros
A interface deve oferecer feedback significativo quando erros
Guia de
ocorrem e oferecer recursos de ajuda aos usuários sensíveis
usuário
ao contexto, oferecendo diferentes níveis de ajuda e orientação
Deve haver recursos de interação apropriados para tipos
Densidade de
diferentes de usuários de sistema, alguns são casuais e outros
usuário
mais experientes, que precisam de atalhos
Facilidade de Recuperação: Tipos
1. Confirmação de ações destrutivas: se um usuário
especifica uma ação potencialmente destrutiva, o sistema
deve pedir que ele confirme antes de destruir qualquer
informação, caso tenha sido realmente solicitada
2. Disponibilidade de recurso para desfazer: permite
restaurar o sistema a um estado anterior à ocorrência de
uma ação. Níveis múltiplos de “desfazer” são úteis porque
os usuários nem sempre reconhecem imediatamente que
um erro foi cometido
3. Checkpoint: envolve salvar o estado de um sistema em
intervalos periódicos e permitir que se recomece do último
checkpoint. Quando os erros ocorrem os usuários podem
voltar a um estado anterior e começar de novo. Muitos
SW incluem isso para lidar com falhas de sistema, mas
não permitem que seus usuários usem o recurso para
recuperação de erros cometidos por eles
 Estilos de Interação
Vantagens
Estilo Exemplos Desvantagens Principais
Principais

Pode ser difícil de implementar.

Interação rápida
Manipulação Videogames Adequado apenas quando houver
e intuitiva. Fácil de
direta Sistemas CAD uma metáfora visual para tarefas e
aprender
objetivos

Evita erros do Lento para usuários experientes.

Seleção de Maioria dos sistemas
usuário. Pouca Pode fi€car complexo se houver
menu de propósito geral
digitação é requerida muitas opções de menu

Processamento de
Entrada simples de Ocupa mais espaço de tela. Causa
Preenchimento controle
dados. Fácil de problemas onde opções de usuário
de formulário de estoque e
aprender. não se encaixam nos campos do
Empréstimo
Veri€ficável formulário
pessoal

Sistemas operacionais
Linguagem Difícil de aprender. Gerenciamento
e Sistemas de Poderosa e fl€exível
de comando fraco de erros
comando e controle

Sistemas de Acessível a usuários Requer mais digitação. Sistemas

Linguagem
recuperação casuais. Facilmente de compreensão de linguagem
natural
de informações estendido natural são menos con€fiáveis
Apresentação de Informações
● Pode ser uma representação direta da informação de
entrada, por exemplo texto em um editor de texto, ou
pode apresentar as informações graficamente
● Uma boa diretriz de projeto é manter o SW necessário
para apresentação de informações separado da
informação em si
● Separar o sistema de apresentação dos dados permite
que a representação mude na tela do usuário sem que
haja mudança no sistema subjacente
● A abordagem MVC é uma maneira eficiente para apoiar
apresentações múltiplas dos dados
● Para encontrar a melhor apresentação de informações,
precisa-se conhecer a experiência do usuário e como
ele usa o sistema
Considerações para Apresentar Informação
1. O usuário está interessado em informações
precisas ou nos relacionamentos entre os valores
de dados?
2. Quão rapidamente os valores de informação
mudam? A mudança deve ser indicada
imediatamente ao usuário?
3. O usuário deve tomar alguma ação como
resposta à mudança na informação?
4. O usuário precisa interagir com a informação
exibida via interface de manipulação direta?
5. A informação a ser exibida é textual ou
numérica? Os valores relativos dos itens de
informação são importantes?
 Diretrizes para Apresentar Informação
● Não se deve presumir que o uso de gráficos torna sua
exibição mais “interessante”, pois consomem um espaço
importante de tela e podem levar muito tempo para baixar
os gráficos se o usuário tem uma conexão lenta em um
dispositivo móvel, por exemplo
● A informação que não muda durante uma sessão pode ser
apresentada graficamente ou como texto, dependendo da
aplicação. A apresentação textual consome menos espaço
de tela, mas pode não ser lida de relance
● Deve-se distinguir a informação que não muda da dinâmica,
usando um estilo de apresentação diferente para cada
● Deve-se usar texto para apresentar informações quando se
requer informação precisa que muda relativamente devagar
● Se os dados mudarem rapidamente ou se os
relacionamentos entre eles em vez da precisão for
significante, deve-se apresentar a informação graficamente
 Apresentação de Informações: Cores
1. Limite o número de cores e seja conservador sobre como
estas serão usadas: não se deve usar mais de quatro ou
cinco cores em uma janela, e não mais de sete em toda
interface do sistema. Se usar muitas cores ou se elas
forem muito luminosas, a exibição tende a ficar confusa. A
confusão do usuário também é possível se as cores forem
usadas inconsistentemente
2. Use mudança de cor para indicar uma alteração no estado
do sistema. Se uma exibição muda de cor, isso deve
significar um evento importante. Destacar cores é
importante em exibições complexas, nas quais muitas
entidades diferentes podem ser exibidas
3. Use codificação por cores para oferecer apoio a tarefas
que o usuário realiza. Se ele deve identificar instâncias
anômalas, destaque-as; se as similaridades precisam ser
descobertas, destaque-as também com uma cor diferente
Apresentação de Informações: Cores
4. Use codificação por cores de uma maneira pensada e
consciente. Se uma parte de um sistema exibe mensagens
de erro em vermelho, todas as outras partes devem fazer o
mesmo e o vermelho não deve ser usado para outra coisa.
Senão for assim, o usuário pode interpretar toda mensagem
em vermelho como mensagem de erro
5. Tome cuidado com pares de cor. Devido à fisiologia do olho,
as pessoas não conseguem focar vermelho e azul
simultaneamente. A fadiga visual é uma consequência da
exibição em vermelho e azul. Outras combinações podem
ser incômodas visualmente ou difíceis de ler
6. Deve-se usar a cor para destacar, mas não se deve associar
significados a cores específicas. Cerca de 10% dos homens
são daltônicos e podem interpretar mal. Também por causa
das profissões, as percepções humanas de cores são
diferentes
 Palavreado de uma Mensagem
Fator Descrição

Quando possível, as mensagens geradas pelo sistema devem refletir o

Contexto contexto do usuário atual, devendo o SW estar ciente do que o usuário está
fazendo e deve gerar mensagens que sejam relevantes à atividade

Conforme os usuários se tornam mais familiares com o sistema, irritam-se com

mensagens longas e “significativas”. Contudo, os iniciantes acham difícil
Experiência
entender declarações curtas de um problema. Deve-se oferecer os dois tipos
de mensagem e permitir que o usuário controle a brevidade da mensagem

As mensagens devem estar ajustadas para as habilidades de usuário, assim

Nível de como para sua experiência. Mensagem para classes diferentes de usuários
habilidade podem ser expressas de maneiras diferentes dependendo da terminologia que
é familiar ao leitor

As mensagens devem ser positivas e não negativas. Devem usar modo de

Estilo discurso ativo em vez de passivo. Nunca devem insultar ou tentar ser
engraçadas

Quando for o caso, o elaborador de mensagens deve estar familiarizado com a

cultura do local em que o sistema é vendido. Existem diferenças culturais entre
Cultura
Europa, Ásia e América e uma mensagem adequada para uma cultura pode ser
inaceitável para outra
Processo de Projeto de Interação
● O projeto de interação é um processo interativo no qual os
usuários relacionam-se com os projetistas e protótipos de
interface para decidir as características, organização e
aparência da interface de usuário do sistema
● Às vezes a interface é prototipada separadamente em
paralelo com outras atividades de ES. Especialmente
onde ocorre o desenvolvimento iterativo, o projeto de
interação prossegue incrementalmente conforme o SW é
desenvolvido. Em ambos os casos, antes de começar a
programar, deve-se ter desenvolvido e, idealmente,
testado alguns projetos no papel
● A construção do projeto de interação dentro do processo
de desenvolvimento do SW depende de outras atividades.
A prototipação pode ser usada como parte do
processo de ER e, nesse caso, faz sentido começar o
projeto de interação nesse estágio
Processo de Projeto de Interação: Atividades
1. Análise de usuário: desenvolve-se uma compreensão das
tarefas que os usuários realizam, seu ambiente de trabalho
e outros sistemas que usam, como interagem com outras
pessoas em seu trabalho, etc. Quando há uma faixa grande
de usuários, trabalha-se com grupos específicos
2. Prototipação de interface: o projeto e o desenvolvimento
de interação são processos iterativos. Ainda que os
usuários falem sobre suas necessidades em relação a
interface, é difícil serem específicos até que vejam algo
tangível, devendo-se desenvolver protótipos e os expor ao
usuário, que, então, pode guiar a evolução da interface
3. Avaliação de interface: ainda que se discuta com os
usuários durante o processo de prototipação, deve-se ter
também uma atividade de avaliação mais formalizada na
qual coleta-se informações sobre as experiências reais dos
usuários com a interface
Prototipação de Interface de Usuário
● Devido a natureza dinâmica das interfaces de usuários,
descrições textuais e diagramas não são
suficientes para expressar os requisitos de
interface de usuário
● A prototipação evolucionária ou exploratória com
envolvimento do usuário final é a maneira prática de
projetar e desenvolver interfaces gráficas de usuário
● O objetivo da prototipação é permitir que os
usuários ganhem experiência direta com a
interface. A maioria de nós acha difícil pensar de forma
abstrata sobre a interface de usuário para explicar
exatamente o que queremos
● Quando somos apresentados a exemplos, é mais
fácil identificar as características de que gostamos
ou não
Prototipação de Interface: Ações
1. Inicialmente desenvolve-se protótipos de papel –
maquete dos projetos de tela – para verificá-los com os
usuários finais
2. Não precisa desenvolver qualquer SW e os projetistas
não precisam ser elaborados com padrões profissionais,
podendo-se desenhar versões de papel das telas do
sistema com as quais os usuários interagem e
projetar um conjunto de cenários descrevendo como
o sistema pode ser usado
3. Conforme um cenário progride, esboça-se a informação
que seria exibida e as opções disponíveis aos usuários
4. Trabalha-se então nesses cenários com os usuários para
simular como o sistema poderia ser usado. Esta é uma
maneira eficiente de ter as reações iniciais ao projeto de
interface, as informações que eles precisam do sistema e
como eles normalmente iriam interagir com o sistema
 Prototipação de Interface: Ações
5. Depois pode-se refinar o projeto e desenvolver protótipos
cada vez mais sofisticados e automatizados, então
torna-os disponíveis aos usuários para testes e simulação
de atividades
6. O problema é que se precisa ter alguma funcionalidade do
sistema para interagir. Se você estiver prototipando uma
interface de usuário no início do processo de
desenvolvimento do sistema, ela não estará disponível
7. Para implementar um protótipo pode-se usar uma
linguagem convencional de programação como Java, mas
objetivar um desenvolvimento “rápido e sujo”, sem
observar os padrões normais de programação
8. Alternativamente deve-se usar uma caixa de ferramentas
especializada para criar interfaces de usuários ou um
plug-in baseado em web, como o Flash, para fazer um
protótipo de animação
Prototipação de Requisitos
● Protótipo descartável é construído com a finalidade de
demonstrar o que foi entendido ou resolvido em relação a
algum aspecto da modelagem do SW, podendo ajudar
tanto na modelagem do problema, quanto da solução
● Protótipo descartável não deve ser reaproveitado,
devendo-se esclarecer os interessados quanto aos seus
objetivos
● Quando se decide usá-los, é porque o custo de
construí-los e depois descartá-los é compensado pela
maior estabilidade dos requisitos e redução dos
riscos
● Prazos de construção e uso desses protótipos devem ser
curtos, pois geralmente são usados para confirmar ou
refutar hipóteses
 Prototipação de Requisitos: Tipos
Área Características

Feito em ambiente de edição de site ou ferramenta de desenho.

Funções e interfaces Permite visualizar as interfaces, em determinado nível de
de usuário abstração, e a navegação entre elas, sem efetuar
processamento

Feito em processador de textos ou de planilhas ou ferramenta de

Relatórios textuais geração de relatórios, usado para produzir uma amostra do
relatório

Feito em ambiente de programação com biblioteca de desenho

Relatórios gráficos ou ferramenta de desenho, usado para produzir uma amostra do
relatório

Organização e Ferramenta de desenvolvimento rápido integrada ao sistema de

desempenho de banco gerência de BD que se pretende adotar, usada para realizar
de dados consultas e atualizações típicas

Cálculos e algoritmos Planilha ou ferramenta matemática, usada para implementá-los,

complexos mostrando o desenrolar dos passos

Partes de tempo de
Programa de teste no ambiente-alvo, em sistemas de tempo real
resposta crítico
Protótipo de Requisitos
● É um protótipo visual de baixa fidelidade, com o objetivo
de explorar aspectos críticos dos requisitos de um SW,
simulando um subconjunto da sua funcionalidade
● Não representam fielmente as interfaces reais de usuário,
desde que sejam funcionalmente equivalentes
● Na confecção deve ser evitado o uso de ambientes de
desenvolvimento ou mesmo ferramentas avançadas de
desenho, devendo ser rápida, simples e independente da
tecnologia que será adotada na solução
● Os leiautes devem ser descritos em nível de detalhe
suficiente para o cliente possa aprová-los ou não, mas
sem focar nos aspectos de usabilidade
● Os campos e comandos incluídos em cada interface de
usuário devem ser suficientes para representar requisitos
de captura e exibição de informação, podendo depois ser
substituídos por soluções funcionalmente equivalentes
Protótipo de Requisitos: Exemplos
ConectaIF
● Informações
● Credenciamento
● Oficinas do Qualific Express
● Programação
● Incluído como item da 2ª avaliação
Validação de Requisitos
● Cada requisito e o modelo de análise como um todo deve
ser validado em relação às necessidades do cliente
para garantir a construção do sistema mais apropriado
● Validação de requisitos é o processo em que é verificado
se os requisitos definem o sistema que o cliente
realmente necessita
● A medida que cada elemento do modelo de requisito é
criado, deve ser examinado quanto a inconsistência,
omissões e ambiguidades
● Os requisitos são priorizados pelos interessados e
agrupados em pacotes, que poderão ser implementados
como incrementos de SW
● É importante porque erros em um documento de
requisitos geram custos maiores de retrabalho quando
descobertos durante a construção ou implementação do
SW
Validação de Requisitos: Tipos
1. Verificações de validade: um interessado pode pensar em
determinadas funções de sistema, mas uma análise
aprofundada pode indicar funções adicionais ou diferentes
2. Verificações de consistência: requisitos não devem entrar
em conflito, garantindo que não haja restrições contraditórias
ou descrições diferentes da mesma função
3. Verificações de completude: o documento deve incluir
requisitos que definam todas as funções e restrições
pretendidas pelos interessados do sistema
4. Verificações de realismo: assegura que os requisitos podem
ser implementados, considerando o conhecimento das
tecnologias existentes, o orçamento e o cronograma para o
desenvolvimento do sistema
5. Verificabilidade: requisitos devem ser passíveis de
verificação, permitindo escrever um conjunto de testes que o
demonstrem o atendimento de cada um no SW entregue
Validação de Requisitos: Técnicas
1. Revisões de requisitos: os requisitos são analisados
sistematicamente por uma equipe de revisores que
verifica erros e inconsistência
2. Prototipação: um protótipo do sistema em questão é
demonstrado aos usuários finais e clientes, que podem
experimentá-lo para verificar se atende as suas reais
necessidades
3. Geração de casos de testes: se os testes forem
concebidos como parte do processo de validação,
frequentemente revelam problemas de requisitos. Se é
difícil projetar um teste, isso normalmente significa que
os requisitos serão difíceis de serem implementados e
devem ser reconsiderados. O desenvolvimento de
testes a partir dos requisitos antes de qualquer código
ser escrito é parte integrante do Extreme Programming
Validação de Requisitos: Questões
As respostas a estas perguntas servem para garantir que o
modelo de requisitos reflita de maneira precisa as
necessidades dos interessados e forneça base sólida para o
projeto:
1. Para cada um dos requisitos, a validação deve tratar
destas questões:
a. está consistente com os objetivos globais do sistema?
b. é bem delimitado e sem ambiguidades?
c. possui atribuição? Ou seja, uma fonte, em geral um
indivíduo, é indicada para cada um?
d. é atingível no ambiente que irá abrigar o sistema?
e. uma vez implementado, ele pode ser testado?
f. é realmente necessário ou representa um recurso
adicional que pode não ser essencial para o objetivo
do sistema?
Validação de Requisitos: Questões
2. Todos os requisitos foram especificados no nível de
abstração adequado? Ou algum deles fornece um
nível de detalhe inapropriado no atual estágio?
3. Algum dos requisitos conflita com outros?
4. O modelo de requisitos reflete a informação, função e
comportamento do sistema a ser construído?
5. O modelo de requisitos foi dividido para expor
progressivamente informações mais detalhadas
sobre o SW?
6. Os padrões de requisitos foram utilizados para
simplificar o modelo de requisitos? Todos os padrões
foram validados? Todos os padrões são consistentes
com os requisitos do cliente?
Negociação de Requisitos
● É comum haver negociação da ER com um ou mais
interessados, a fim de contrabalançar funcionalidade,
desempenho e outras características do sistema, em
função de custo e prazo de entrega
● À medida que os requisitos são identificados e o modelo de
análise é criado, a equipe de SW e os interessados no
projeto negociam a prioridade, disponibilidade e o
custo relativo de cada requisito
● Com a negociação é desenvolvido um plano de projeto
que, ao mesmo tempo, atenda as necessidades dos
interessados e reflita as restrições impostas à equipe de
SW, como tempo, pessoal, orçamento
● Boas negociações buscam um resultado “ganha-ganha”,
onde os interessados ganham com um sistema que atenda
a maioria das suas necessidades e a equipe de SW ganha
por trabalhar com prazos e orçamentos reais e exequíveis
Negociação de Requisitos: Tarefas
● É uma ação da atividade de comunicação da ES e uma
etapa da ER, desenvolvida em tarefas que permitem
aumentar a estabilidade da equipe de SW
● O êxito nas seguintes tarefas permite um resultado em
que todos saem ganhando, o que é um critério-chave
para o prosseguimento das demais atividades da ES:
1. Identificação dos principais interessados no
sistema
2. Determinação das “condições de ganho” dos
interessados
3. Negociação das condições de ganho para
harmonizá-las em um conjunto de situações
“ganha-ganha” para todos os envolvidos, o que inclui a
equipe de SW
Arte da Negociação: Diretrizes
1. Reconhecer que não se trata de uma competição,
onde todas as partes precisam ceder para que atinjam
algum objetivo e sintam que ganharam
2. Planejar uma estratégia, na qual se define:
a. o que precisa ser atingido por si e pelos demais e
b. como fazer para que isso ocorra
3. Ouvir ativamente, esperando para formular sua opinião
apenas quando estiver ouvido as outras partes
4. Concentrar-se nos interesses das partes, não
assumindo posições rígidas para evitar conflitos
5. Não deixar a negociação ir para o lado pessoal,
devendo-se concentrar no problema a ser resolvido
6. Ser criativo, não tendo medo de inovar em situações de
impasse
7. Estar preparado para comprometer-se, pois uma vez
que o acordo tenha sido feito, deve-se levá-lo a diante
Ferramentas de Apoio à ER
Auxiliam no desenvolvimento de casos de uso:
● Objects by Design: lista de ferramentas UML
● OSRMT: Open Source Requirements Management Tool
● Pencil, Mockingbird e Marvel: elaboração de diagramas e prototipação de
GUI (Graphical User Interface)
● GitHub: plataforma de hospedagem de código-fonte com controle de versão
● Google Colab: plataforma cloud gratuita para desenvolvimento de códigos
Python de forma colaborativa
● Chrome Web Store:
○ draw.io: elaboração de diagramas online, inclusive UML
■ User Manual, Using with G.Drive, Table of Contents
○ ReqView: edição de requisitos, combinando documentos de estrutura
livre com uma tabela de atributos, discussões e links (inglês)
■ Documentation
○ Acunote: apoia a gerência de desenvolvedores, projetos e requisitos
para o processo Scrum (inglês)
○ MindMup: elaboração de mapas mentais online (inglês)
○ Lucidchart Diagramação: para criar fluxogramas, protótipos, UML, mapas
mentais
○ Desenhos Google: documentação e instalação
ES1: Exercício 5 - ER
1. Desenvolva o diagrama preliminar de casos de uso a partir do
Documento de Requisitos elaborado no exercício anterior,
seguindo estes passos:
a. Identifique os atores em cada requisito
b. Descreva as funções ou atividades de cada ator
c. Elabore os casos de uso que representam todos os requisitos
d. Componha o diagrama com os principais casos de uso
2. Classifique e organize os requisitos em grupos coerentes, a partir
do diagrama elaborado, realizando as devidas alterações no
Documento de Requisitos
3. Agende, planeje e realize a validação e nova elicitação de
requisitos junto aos interessados, postando no fórum do grupo
esse planejamento, com as perguntas, até o dia 14/10
4. Realize as correções e a descrição de cada caso de uso,
incluindo: diagrama de casos de uso; narrativa; sequência
ordenada (fluxo principal); e exceções (fluxos secundários) no
Documento de Requisitos, além de anexar o planejamento, com
as perguntas, postando-o no fórum do grupo até o dia 19/10
Modelagem Baseada em Cenários
● A modelagem de requisitos com UML começa com a
criação de cenários na forma de casos de uso, diagramas
de atividades e de raias
● Tais modelos são orientados a procedimentos,
representando a maneira pela qual vários atores
interagem com funções específicas
● UML: a “linguagem de modelagem unificada” é usada para
visualizar, especificar, construir e documentar artefatos de
um sistema de SW
● Casos de uso: preliminar, refinado e formal
● Diagrama de atividades: complementa o caso de uso com
a representação gráfica do fluxo de atividades envolvidas
no processo de interação, em um cenário específico
● Diagrama de raias: variação do diagrama de atividade
que, além de representar o fluxo de atividades, indica qual
ator ou classe de análise é responsável pela ação descrita
 Diagrama de Atividades: Elaboração
Similar ao fluxograma, usa:
● Retângulos com cantos
arredondados para representar
determinada função do sistema
● Setas para indicar o fluxo
através do sistema
● Losango para representar
decisão com ramificação, onde
cada seta que parte do losango
é identificada
● Linhas horizontais cheias
indicam as atividades paralelas
que ocorrem
● Ex. Acessar vigilância por
câmeras via Internet - exibir
visões das câmeras
 Diagrama de Raias: Elaboração
● As
responsabilidades
são representadas
como segmentos
paralelos que
dividem o
diagrama de
atividades
verticalmente,
como em raias de
piscina
● A raia Interface
representa a
interface de
usuário, conforme
vista por ele
 Diagrama de Atividades: Símbolos
Símbolo Descrição
Retângulo ovalado Atividade (passo do fluxo)
Retângulo Objeto (artefato do fluxo)
Relação de precedência entre
Seta cheia
atividades
Consumo ou produção de objeto por
Seta pontilhada
atividade
Ponto de sincronização (onde
Linha horizontal cheia
subfluxos paralelos se juntam)
Pequeno círculo cheio Estado inicial
Círculo cheio dentro
Estado final
de círculo vazio
Diagrama
de
Atividades
: Exemplo
Gerenciamento de Requisitos: Contexto
● Durante o processo de SW o entendimento dos
interessados a respeito do problema está em
mutação, sendo necessário que os requisitos evoluam
para refletir essas novas percepções do problema
● É difícil para os interessados anteciparem os impactos
que o novo sistema terá sobre os processos de
negócio e suas formas de trabalho, o que origina novos
requisitos quando estiver implantado
● Os ambientes técnico e de negócios do sistema
sempre mudam, seja por novo HW ou SW, seja por
novas prioridades de
negócio ou novidades
na legislação, nos
regulamentos
Gerenciamento de Requisitos
● É o processo de compreensão e controle das
mudanças nos requisitos do sistema, no qual é
preciso:
○ Manter-se a par das necessidades individuais e
das ligações entre as necessidades
dependentes para conseguir avaliar o impacto
das mudanças nos requisitos
○ Estabelecer um processo formal para cada
proposta de mudança e sua ligação com as
exigências do SW
● Pode ser planejado durante o processo de
elicitação de requisitos
● Deve iniciar assim que a versão preliminar do
documento de requisitos estiver disponível
Gerenciamento de Requisitos: Planejamento
● Identificação de requisitos, devendo cada requisito ser
identificado unicamente
● Processo de gerenciamento de mudança, com
atividades que avaliam o impacto e o custo das mudanças
● Políticas de rastreabilidade, que definem os
relacionamentos entre cada requisito e entre os requisitos
e o projeto de sistema
● Ferramenta de apoio, que auxilia no controle de
informações sobre requisitos, variando de sistemas
especializados em gerenciamento destes até
processadores de planilhas, de texto e SGBD simples,
permitindo:
○ Armazenamento de requisitos
○ Gerenciamento de mudança
○ Gerenciamento de rastreabilidade: relacionamento
de requisitos
Gerenciamento de Requisitos: Mudança
● É essencial para decidir se os benefícios da
implementação de novos requisitos compensam os
custos envolvidos nessa mudança
● Tem a vantagem de tratar todas as mudanças de
maneira consistente, alterando o documento de
requisitos de forma controlada
● O documento de requisitos deve ser organizado
para permitir sua reformulação, onde as referências
externas devem ser mínimas e as suas seções o mais
modular possível
● Se um novo requisito precisa ser implementado com
urgência, a tentação de fazê-lo antes de modificar o
documento de requisitos deve ser evitada, impedido a
defasagem e a inconsistência entre esse
documento e o sistema
Mudança de Requisitos: Estágios
Estágios do processo de gerenciamento de mudança:
1. Análise de problema e especificação de mudanças,
onde é analisado se o problema impacta em um
determinado requisito ou uma proposta de um novo é
válida, reportando-se ao solicitante, que pode especificar
melhor ou retirar sua solicitação
2. Análise de mudanças e custos, na qual o efeito da
mudança proposta é estimado em termos de modificações
no documento de requisitos e, se apropriado, no projeto e
implantação do sistema, permitindo-se decidir quanto a
realização ou não da mudança de requisitos
3. Implementação de mudanças, em que o documento de
requisitos e, quando necessário, o projeto e a implantação
do sistema são modificados
Rastreabilidade de Requisitos
● Permite controlar a evolução dos requisitos
ao projeto do sistema, ajudando a garantir uma
contínua concordância entre os requisitos do
sistema e os demais artefatos produzidos ao
longo do seu processo de desenvolvimento
● A rastreabilidade de requisitos inicia na
elicitação e vai até a manutenção do SW,
constituindo a principal atividade do
gerenciamento de requisitos
● Um requisito é rastreável se seu enunciado
permite determinar facilmente os antecedentes
e consequências de todos os requisitos
Rastreabilidade de Requisitos: Tipos
● Para trás: possibilidade de localizar a origem de cada requisito,
sabendo-se porque existe e quem ou o quê o originou quando
há uma mudança, sendo necessário para entendê-la a partir
das informações usadas para elicitar o requisito alterado
● Para frente: capacidade de localizar quais os resultados do
desenvolvimento serão afetados por cada requisito, garantindo
que os artefatos de análise, desenho, código e testes cubram
todos os requisitos e permitindo que se possa avaliar o impacto
das mudanças nestes
● Pré-rastreabilidade: refere-se ao contexto a partir do qual
emergem os requisito, antes da sua inclusão na especificação
de requisitos, sendo útil para, por exemplo, obter suas fontes ou
as pessoas que o apoiam para validar a mudança
● Pós-rastreabilidade: refere-se aos aspectos da vida de um
requisito que resultam da sua inclusão na especificação de
requisitos, vinculando-o aos artefatos da modelagem de projeto
e da implementação, como manuais
Rastreabilidade de Requisitos: Visualização
● Visualizações através de hiperlinks: usadas
quando os objetos e as relações devem ser
apresentados no mesmo ponto de vista
● Matriz de rastreabilidade: usada quando uma visão
global das relações de rastreabilidade é necessária
● Explorador em formato de árvore: ajuda a navegar
através de relações específicas
ReqView - Licença
● Licença:
○ Instale em seu G. Drive
○ Cadastre seu usuário para obter a licença Tryal
○ Ative a licença recebida em seu e-mail: Help >
Import License Key
● Controle de Mudanças:
○ Defina seu usuário do Google: Edit > User
Settings
○ Grave, sempre que alterar, o seu arquivo no
GDrive: File > Upload, selecionando as opções
Save View e Save History
○ Para haver colaboração, no G.Drive compartilhe
os arquivos (.reqw) com o colega do grupo e
para 1968190@etfbsb.edu.br
ReqView - Personaliza Atributos
{
● Personalizar atributos: "status": {
Project > Document "type": "enum",
"name": "Status",
Attributes "values": [
{
○ Altere atributos de "key": "Desconhecido"
},
estado do requisito, {
substituindo pelo "key": "Rascunho"
},
código a seguir: {
"key": "Aprovado"
},
{
"key": "Rejeitado"
},
{
"key": "Implementado"
},
{
"key": "Validado"
}
]
}
}
ReqView - Personaliza Atributos
,
● Para adicionar atributo de "priority": {
prioridade, inclua antes "name": "Priority",
"type": "enum",
da última “}” o seguinte "values": [
código: {
"key": "-",
"label": "Indeterminada",
"default": true
},
{
"key": "1",
"label": "Desejável"
},
{
"key": "2",
"label": "Importante"
},
{
"key": "3",
"label": "Essencial"
}
]
}
ReqView - Rastreabilidade
● Pode-se personalizar atributos de rastreabilidade: Project
> Project Traceability
{
"reference": {
"name": "Reference",
"source": "Faz referência a",
"target": "É referenciado por"
}
}
● Visualize outros atributos: View > Attributes Pane para
visualização dos Links (rastreabilidade)
● Alguns atributos para edição: View > Table Columns
○ Selecione Priority para edição das prioridades
○ As colunas podem ser movidas para organização
● Atributos definidos:
○ Start link: defina um link de requisitos a partir do
requisito selecionado
○ Place link: defina um link para um determinado
requisito, cujo link tenha sido iniciado (start link)
ES1: Exercício 6 - ER
1. A partir do refinamento de requisitos realizado no exercício anterior, especifique os
requisitos de fluxo secundário
2. Desenvolva os seguintes diagramas, colocando-os no doc. requisitos:
a. de casos de uso completo
b. de atividades para um cenário que possua fluxo secundário
c. de raias para o caso de uso mais complexo, com mais de um ator e fluxo secundário
3. Realize a prototipação de ao menos um caso de uso, devendo ser anexada ao documento
de requisitos, que deve ser postado
4. Agende, planeje e realize junto ao cliente a validação e priorização dos requisitos a partir
dos diagramas e protótipo, postando no fórum do grupo esse planejamento, com as
perguntas, até o dia 22/10
5. Atualize o Documento de Requisitos, anexando o planejamento, devendo ser postado no
fórum do grupo até o dia 26/10
6. No Reqview faça, até dia 27/10:
a. Identificação de requisitos, com o mesmo nome que está no doc. de requisitos
b. Frequentemente o upload do arquivo de projeto, devendo estar compartilhado com o
grupo e com 1968190@etfbsb.edu.br
c. Personalização dos atributos Status, Priority e Reference
d. Ccnfiguração para incluir na grade as colunas Priority e Links (View > Table Columns)
e. Priorização dos requisitos (desejável, importante, essencial)
f. Especificação dos relacionamentos entre os requisitos, incluindo os links de
rastreabilidade
g. Ao final, além do upload do arquivo de projeto, imprimir como PDF o projeto (File >
Print), postando-o no fórum do grupo ainda no dia 27/10
Gerenciamento de Projetos de Software
Atividades de apoio relevantes que possibilitam planejar,
organizar, monitorar e controlar projetos de desenvolvimento
de SW, considerando aspectos organizacionais, de
orçamento e de cronograma
● Gerenciamento de riscos: identificar o que pode dar
errado e o que pode ser feito a partir da probabilidade de
ocorrerem
● Planejamento de projetos: definir estimativas e realizar o
acompanhamento
● Gerenciamento da qualidade: processos e técnicas para
garantir e melhorar a qualidade do SW
● Gerenciamento de configuração: planejamento de
configurações, gerenciamento de versões e de mudanças
● Melhoria do processo de SW: processos precisam ser
modificados para melhorar os atributos de produto e de
processo
Gerente de Projetos de Software
● Busca garantir que o projeto de SW atenda e supere as
restrições de orçamento e de cronograma
● Metas importantes:
○ Fornecer o SW ao cliente no prazo acordado
○ Manter os custos dentro do orçamento
○ Entregar SW que atenda as expectativas do cliente
○ Zelar pela qualidade e satisfação de trabalho da equipe
de desenvolvimento
● Desafios:
○ Produto intangível: não se pode ver o progresso olhando
para o artefato
○ Projetos de SW são geralmente únicos: são diferentes
dos anteriores, sendo difícil antecipar problemas
○ Processos de SW são variáveis e têm organização
específica: variam entre as organizações, podendo
conduzir a problemas de desenvolvimento
Gerente de Projeto de SW: Atividades
1. Planejamento de projeto: elaboração de
estimativa de custos e de cronograma de
desenvolvimento de SW e atribuição de
tarefas para interessados, acompanhando o
progresso para verificar se está ocorrendo
dentro do planejado
2. Geração de relatórios: sobre o andamento de
projeto para os clientes e gerentes da área de
desenvolvimento de SW, sendo capaz de
comunicar-se em vários níveis, desde
informações técnicas até resumos
gerenciais, abstraindo informações críticas dos
artefatos de projeto
Gerente de Projeto de SW: Atividades
3. Gerenciamento de riscos: avalia e controla
os riscos que podem afetar o projeto
4. Gerenciamento de pessoas: escolhe pessoas
e estabelece formas de trabalhar, buscando
favorecer o bom desempenho da equipe
5. Elaboração de propostas: descreve os
objetivos do projeto, como será realizado,
podendo incluir estimativa de custos e
cronograma, e justificativa que destaque o
porquê do projeto ser confiado à sua equipe
ou organização
Gerenciamento de Riscos
● Envolve antecipar os riscos que podem afetar o
cronograma do projeto ou a qualidade do software
que está sendo desenvolvido, evitando tais riscos
● Categorias de riscos:
○ Riscos de Projeto: afetam o cronograma ou os
recursos de projeto (perda de projetista
experiente)
○ Riscos de Produto: afetam a qualidade ou
desempenho do SW (falha no desempenho de
um componente comprado)
○ Riscos de Negócio: envolvem a organização
que desenvolve ou adquire o SW (concorrente
que introduz um novo produto)
Gerenciamento de Riscos: Etapas
1. Identificação dos riscos: aqueles que ameaçam o
processo de ES, o SW que está sendo desenvolvido ou a
organização do desenvolvimento
2. Análise de riscos: avaliação da probabilidade e das
consequências dos riscos
3. Planejamento de riscos: planejamento para enfrentar os
riscos, evitando ou minimizando seus efeitos sobre o
projeto (mitigação)
4. Monitoramento de riscos: avaliação dos riscos para a
mitigação desses e atualização a partir de outras
informações sobre os riscos
Os resultados desse processo deve ser documentado em um
plano de gerenciamento de riscos, incluindo as suas
descrições, análise e informações para mitigá-los, no caso de
tornarem-se problema
Análise de Riscos
Atividade em que cada risco é identificado e feito o
julgamento sobre a sua probabilidade e gravidade,
elaborando-se uma tabela ordenada de acordo com a
gravidade do risco, que deve ser atualizada a cada iteração
do processo de risco
● Probabilidade, que pode ser avaliada como:
○ Muito baixa: < 10%
○ Baixa: de 10% a 25%
○ Moderada: de 25% a 50%
○ Alta: de 50% a 75%
○ Muito alta: > 75%
● Impacto, onde os efeitos dos riscos podem ser:
○ Catastróficos: ameaçam a sobrevivência do projeto
○ Graves: causariam grandes atrasos
○ Toleráveis: atrasos estão dentro da contingência
○ Insignificantes
 Análise de Riscos: Exemplo
Risco Probabilidade Impacto

Problemas financeiros podem causar reduções

Baixa Catastrófico
no orçamento do projeto

Impossibilidade de recrutar pessoal com

Alta Catastrófico
habilidades necessárias para o projeto

Defeitos em componentes reusáveis de SW,

Moderada Grave
podem precisar ser reparados antes do reuso

Reestruturação da organização pode definir

Alta Grave
gerências diferentes responsáveis pelo projeto

O banco de dados usado não pode processar

Moderada Grave
tantas transações por segundo quanto esperado

Ferramentas de SW não podem ser integradas Alta Tolerável

Treinamento necessário de pessoal indisponível Alta Tolerável

Ferramentas de geração de código são

Moderada Insignificante
ineficientes
Planejamento e Monitoração de Riscos
● Na fase de planejamento considera-se cada um dos riscos
identificados e desenvolve estratégias para gerenciá-los, por
meio de ações para minimizar a interrupção do projeto, caso
ocorra o problema, incluindo as informações que precisará
para a monitoração
○ Estratégias:
■ Prevenção: reduzir a probabilidade do risco ocorrer
■ Minimização: diminuir o impacto do risco
■ Plano de contingência: preparar para lidar com o
pior, caso aconteça
○ O ideal é a prevenção dos riscos. Se não for possível,
reduzir as chances de acontecerem. Finalmente estar
preparado para o caso de ocorrerem
● A monitoração dos riscos ocorre em todas as fases do
projeto. Em cada revisão da gerência, deve-se considerar e
discutir os principais riscos
 Planejamento de Riscos: Estratégias
Risco Estratégia

Documento com informações essenciais para a

Problemas financeiros gerência, mostrando como o projeto está
organizacionais contribuindo para os objetivos de negócio e quais
seriam os impactos dos cortes de orçamento neste

Problema no Alerte o cliente para possíveis dificuldades e a

recrutamento de possibilidade de atrasos, mas investigue se é
pessoal possível comprar componentes

Defeitos em Substitua componentes potencialmente defeituosos,

componentes reusáveis comprando aqueles com maior confiabilidade

Documento com informações essenciais para a

Reestruturação da
gerência, mostrando como o projeto está
organização
contribuindo para os objetivos de negócio

Desempenho de banco Investigue a possibilidade de aquisição de um SGBD

de dados de alto desempenho
Gerenciamento de Pessoas
● É comum os engenheiros de SW terem boas habilidades
técnicas, mas não possuírem habilidades mais flexíveis que
lhes permitam liderar e motivar equipes de desenvolvimento
● Fatores críticos no gerenciamento de pessoas:
a. Consistência: pessoas de uma equipe devem ser
tratadas da mesma forma, evitando que sintam que sua
contribuição é subvalorizada
b. Respeito: pessoas têm habilidades diferentes,
devendo-se respeitar essas diferenças
c. Inclusão: pessoas contribuem quando sentem que são
ouvidas e que suas propostas são consideradas
d. Honestidade: o gerente deve ser sincero quanto ao que
está indo bem e o que vai mal na equipe, e quanto ao
seu nível de conhecimento técnico, submetendo-se
àqueles com mais conhecimento. Se tentar encobrir isso,
provavelmente perderá o respeito do grupo
Trabalho de Equipe
● Montar uma equipe que tenha o equilíbrio entre habilidades
técnicas, a experiência e as personalidades é uma tarefa
crítica de gerenciamento
● Um bom grupo é coeso e tem espírito de equipe. As
pessoas são motivadas pelo sucesso do grupo e por seus
objetivos pessoais
● Benefícios da criação de um grupo coeso:
a. Estabelece seus próprios padrões de qualidade, sendo
definidos por consenso e não impostos ao grupo
b. Pessoas apoiam-se e aprendem umas com as outras,
onde a aprendizagem mútua é encorajada
c. Conhecimento é compartilhado, de forma que se um
membro sair, outros conseguem assumir tarefas críticas
d. Refatoração e melhorias contínuas são incentivadas,
entregando resultado de maior qualidade e corrigindo
problemas independente de quem tenha sido o culpado
Comunicações de Equipe
● É essencial a boa comunicação entre os membros do grupo
e interessados de outros projetos, trocando informações
sobre a situação de seu trabalho e as decisões de projeto
como mudanças no sistema, no grupo e no planejamento
● A boa comunicação é influenciada por:
○ Tamanho de grupo
○ Estrutura de grupo: pessoas em grupos estruturados
informalmente comunicam-se melhor do que aquelas em
grupos com uma estrutura formal, hierárquica
○ Composição de grupo: pessoas com o mesmo perfil
podem colidir e consequentemente inibir a comunicação,
sendo melhor a comunicação em grupos mistos
○ Ambiente físico de trabalho
○ Canais de comunicação disponíveis: como as equipes
de projeto estão cada vez mais distribuídas, é necessário
usar várias tecnologias para viabilizá-la
Planejamento de Projeto
O planejamento ocorre em 3 estágios:
1. Proposta: é elaborada uma proposta (contrato) para
desenvolver um sistema de SW, sendo esboçado um
plano de projeto para estimar os recursos e calcular o
custo (preço) necessários para o seu desenvolvimento
2. Iniciação do projeto: após a proposta ser aceita o plano
de projeto é refeito a partir de melhor conhecimento dos
requisitos, a fim de dar suporte à tomada de decisões
quanto a formação da equipe, divisão por incrementos de
SW, alocação dos recursos, monitoração do projeto, etc.
3. Acompanhamento: o plano é modificado periodicamente
a partir das informações que surgem durante a
monitoração dos trabalhos, na qual acompanha-se os
custos e o progresso real frente ao planejado,
considerando-se mudanças nos requisitos e
características da equipe
Planejamento de Projeto: Processo
● É um processo iterativo que começa quando um plano
de projeto inicial é criado e continua com sua atualização
sempre que houver mais informações sobre o sistema e a
equipe de desenvolvimento, refletindo as mudanças de
requisitos, de cronograma e de riscos, além das
mudanças de negócio que podem afetar diversos projetos
● Inicialmente avalia-se as restrições que afetam o
projeto: data de entrega, pessoal disponível, orçamento
global, ferramentas disponíveis, etc.
● Em seguida elabora-se o cronograma estimado para o
projeto, com os milestones e os entregáveis, ou seja,
pontos em que serão avaliados os progressos e os
momentos em que haverá entrega de artefato ao cliente
● Após um tempo, de 2 a 3 semanas, deve-se avaliar o
progresso e as discrepâncias com o cronograma previsto
● “Seja realista quando estiver criando o plano de projeto”
 Planejamento de Projeto: Custos
Três parâmetros são usados para calcular custos de um projeto
de desenvolvimento de SW:
1. Custo de esforço: geralmente o maior, envolve os
pagamentos de gerentes e engenheiros de SW, devendo-se
estimar o esforço, em pessoa/período (dia, mês), para cada
perfil necessário à conclusão dos trabalhos e adicionar a
contingência de tempo e esforço extras
2. Custos de hardware e SW, incluindo manutenção: orça os
gastos com equipamentos e licenças para uso de Middleware
e de plataforma operacional
3. Custos de viagens e treinamentos: são geralmente a menor
fração dos gastos, mas têm impactos no tempo de
deslocamento, o que aumenta significativamente os custos
de esforço, devendo-se avaliar o uso de sistemas para
Webconferência e outros SW que oferecem suporte à
colaboração (fórum, wiki)
Desenvolvimento Dirigido a Planos
Em situações formais, o Plano de Projeto define os recursos
disponíveis para o projeto, a divisão de trabalho, o cronograma
e a identificação dos riscos, organizado nas seguintes seções:
1. Introdução: objetivos gerais do projeto e suas restrições
2. Organização de projeto: como a equipe de
desenvolvimento é organizada, com as pessoas envolvidas
e seus papéis na equipe
3. Análise de riscos: possíveis riscos ao projeto, suas
probabilidades de ocorrência e estratégias de mitigação
4. Requisitos de hardware e SW: especifica o HW e o suporte
de SW requeridos para o desenvolvimento
5. Divisão de trabalho: partição do projeto em atividades, por
entregas, e os respectivos resultados esperados
6. Cronograma de projeto (a seguir)
7. Mecanismos de monitoração: geração de relatórios para o
gerenciamento, quando devem ser produzidos e outros
Programação de Projeto: Cronograma
● Consiste na decisão de como será organizado o trabalho de
um projeto em tarefas separadas, incluindo quando e como
essas tarefas serão executadas, resultando no Cronograma
● Nos projetos dirigidos a planos, normalmente as tarefas
duram pelo menos 1 semana e não mais que 2 meses.
Se demorar mais que isso, a tarefa deve ser subdividida
● Algumas tarefas são realizadas em paralelo, com
diferentes pessoas trabalhando em diferentes artefatos,
devendo-se coordená-las de forma que não haja
dependências desnecessárias entre tais tarefas
● Ao estimar cronogramas, considere a possibilidade de
falhas (riscos), onde pessoas podem adoecer, o HW pode
falhar, pode haver atraso na entrega do SW de apoio
● Uma boa regra é estimar sem considerar falhas e aumentar
a estimativa para cobrir os problemas previstos, adicionando
de 30 a 50% para o esforço e tempo como contingência
Representação de Cronograma
● São representados em tabela ou planilha que mostra as tarefas,
o esforço, a duração esperada e as dependências entre essas,
havendo 2 tipos de gráficos que facilitam a compreensão:
a. Gráficos de barras: também chamados gráficos de Gantt,
por causa do seu inventor Henry Gantt, são baseados em
calendário e mostram o início e o término das atividades,
quem é o responsável por cada uma, o respectivo tempo
previsto de realização e as dependências entre elas
b. Rede de atividades: diagramas de rede que mostram as
dependências entre as diferentes atividades
● A definição de cada atividade é feita em ferramenta de
planejamento de projetos, incluindo:
a. Duração em dias ou semanas
b. Estimativa de esforço que reflete o nº de pessoas/dia ou
pessoas/mês para concluir a atividade
c. Deadline para conclusão da atividade
d. Ponto de término definido, que representa o seu resultado
Cronograma: Exemplo
ES1: Exercício 7 - Gerência de Projetos
A partir da engenharia de requisitos realizada pelo grupo, realizem as
seguintes atividades de Planejamento de Projeto:
1. Elabore a Introdução e a Organização do Plano de Projeto, cujo
modelo está no Nead, itens 1 e 2, considerando:
a. o prazo para o desenvolvimento do SW, estime a quantidade de
profissionais envolvidos nesse projeto, definindo suas
responsabilidades neste
b. para a estratégia de comunicação, defina ao menos como
ocorrerão as reuniões e uma ferramenta a ser usada para a
comunicação entre a equipe e desta com os demais
interessados, a fim de mantê-los informados sobre os
progressos e as decisões relacionadas ao desenvolvimento
2. Em Resultados Principais, item 3, descreva de forma iterativa, como
será em cada etapa as entregas dos artefatos e as participações do
cliente e da equipe de desenvolvimento
3. Realize o Gerenciamento de Riscos, item 5, incluindo as
classificações quanto a prioridades, impactos e suas estratégias de
mitigação, postando o documento no fórum do grupo até o dia 10/11
Gerenciamento de Qualidade
● Fornece uma verificação independente do processo
de desenvolvimento de SW, sendo realizado pela
equipe de garantia da qualidade ou equipe QA,
do inglês quality assurance
● Idealmente essa equipe deve ser independente
do processo de desenvolvimento de SW, não
devendo ser subordinada ao gerente de projeto
● O planejamento da qualidade para um projeto
consiste no desenvolvimento do plano de
qualidade, estabelecendo as qualidades desejadas
para o SW e como elas devem ser avaliadas
● No desenvolvimento baseado em planos, o plano
de qualidade é mais formal, mas os métodos ágeis
o adotam de maneira menos formal
Gerenciamento de Qualidade: Objetivos
1. Nível organizacional: a equipe de garantia da qualidade
define:
1.1. os processos de desenvolvimento de SW a serem
adotados
1.2. os padrões que devem ser usados nos SW quanto
aos artefatos, incluindo os requisitos de sistema,
projeto e código
2. Nível de projeto:
2.1. Estabelece um plano da qualidade, que define as
metas de qualidade para o projeto e quais processos e
padrões devem ser usados
2.2. Aplica os processos específicos de qualidade,
verificando se o planejado foi executado e a
garantia da qualidade dos entregáveis, para que
estejam em conformidade com os padrões aplicáveis
ao projeto e com os objetivos organizacionais
Qualidade de Software
A avaliação da qualidade de SW é subjetiva, onde a
equipe de QA precisa considerar se está adequado à
sua finalidade, podendo considerar as seguintes
questões:
1. Durante o processo de desenvolvimento os padrões
de programação e documentação foram seguidos?
2. O SW foi devidamente testado?
3. O SW é suficientemente confiável para ser colocado
em uso?
4. O desempenho do SW é aceitável para uso em
condições normais?
5. O SW é útil?
6. O SW é bem estruturado e compreensível?
Padrões de Software
É a definição de padrões que devem ser aplicados no
processo de desenvolvimento de SW, sendo importante
porque:
● Capturam a experiência: são baseados em
conhecimento sobre a prática do que é mais adequado
para a organização, evitando erros já cometidos
● Fornecem um framework: padrões refletem as
expectativas do usuário na organização, com relação a
confiança, usabilidade e desempenho do SW
● Continuidade dos trabalhos: asseguram que os
engenheiros de SW adotem as mesmas práticas
São dois tipos de padrões de qualidade em ES:
1. Padrões de produto: aplicam-se aos artefatos do SW
que está sendo desenvolvido como estrutura dos
documentos, cabeçalho de comentário para objetos, uso
da linguagem de programação
2. Padrões de processo: definem como os processos
devem ser seguidos durante o desenvolvimento de SW,
adotando boas práticas quanto a validação, ferramentas
de suporte ao processo e documentação elaborada
durante este
 Revisões e Inspeções
● São atividades que verificam a qualidade dos entregáveis
de projeto, envolvendo examinar o SW, sua documentação
e os registros do processo a fim de descobrir erros e
omissões, bem como verificar a conformidade com os
padrões de qualidade adotados
● Os artefatos a serem examinados são aqueles elaborados
durante o processo de desenvolvimento de SW, incluindo
planos de testes, artefatos de gerenciamento de
configuração, padrões de processo, manuais de usuário
● As conclusões das revisões devem ser registradas como
parte do processo de gerenciamento da qualidade e os
problemas identificados devem ser enviados ao gerente de
projeto e a quem estiver responsável por corrigi-los
● Os problemas nos entregáveis e a não conformidade com
os padrões são base para a tomada de decisão da equipe
de revisão, da equipe de QA, do gerente de projeto
 Checklist de Inspeção de Programa
Classe de Defeito Verificação de Inspeção (Revisão por Pares)

● Todas as variáveis de programa são iniciadas antes que seus

valores sejam usados?
Defeitos de dados
● Todas as constantes foram nomeadas?
● Existe alguma possibilidade de overflow de buffer?

Defeitos de ● Para cada instrução condicional, a condição está correta?

controle ● E declarações case, todas as possíveis são consideradas?

● Todas as variáveis de entrada são usadas?

Defeitos de ● Todas as variáveis de saída receberam um valor antes de serem
entrada e saída emitidas?
● Entradas inesperadas podem causar corrupção de dados?

● Todas as chamadas de funções e métodos têm o número correto de

Defeitos de
parâmetro?
interface
● Os parâmetros formais e reais correspondem?

Defeitos de ● Se uma estrutura ligada é modificada, todas as ligações foram

gerenciam. de corretamente reatribuídas?
armazenamento ● O espaço é explicitamente alocado após não ser mais necessário?

Def. gerenciam. ● Foram levadas em consideração todas as condições possíveis de

de exceção erro?
 Medições e Métricas de Software
● Métrica de SW é a característica de um programa,
documentação de sistema ou processo de
desenvolvimento que pode ser objetivamente mensurada
● Podem ser o tamanho de um produto em linhas de
código, o número de defeitos relatados em um artefato de
SW, o número de pessoas/dia requerido para
desenvolver um componente de sistema
1. Métricas de controle: suportam os processos de
gerenciamento, sendo associadas aos processos de
SW como o esforço médio e o tempo necessário para
reparar defeitos relatados
2. Métricas de previsão: ajudam a prever as características
do SW, sendo associadas ao produto em si como o
número de solicitações de mudança em requisitos e o
número de atributos e operações associadas com as
classes de objeto em um projeto
 Métricas de Previsão
Duas classes de métricas de previsão ou de produto:
1. Métricas dinâmicas: são coletadas por meio de medições
efetuadas de programa em execução, como relatório de
bugs ou o tempo necessário para concluir um certo
processamento
a. Permitem avaliar a eficiência e a confiabilidade do SW
2. Métricas estáticas: são coletadas por meio de medições
feitas em artefatos do sistema, como projeto, programa e
documentação
a. Permitem avaliar a complexidade, compreensibilidade
e a manutenibilidade de um sistema ou componentes
de SW
● Estudos e experimentos que buscaram derivar e validar os
relacionamentos entre as métricas e os atributos não são
conclusivos, mas o tamanho do programa e a complexidade
parecem ser os mais confiáveis mecanismos de previsão
 Métricas Estáticas de Previsão
Métrica de SW Descrição

Fan-in é a medida do número de funções ou métodos que chamam outras

funções ou métodos (X). Fan-out é o número de funções que são chamadas.
Um valor alto de Fan-in significa que X está fortemente acoplado ao resto do
Fan-in e Fan-out projeto, com alterações em X tendo repercussões extensas. Um valor alto de
Fan-out indica que a complexidade geral de X pode ser alta por causa da
complexidade da lógica de controle necessário para coordenar os componentes
chamados

Comprimento de É uma medida do tamanho de um programa. Quanto maior for o tamanho do

código código de um componente, mais complexo e sujeito a erros este é

Complexidade Medida de complexidade de controle de um programa, que é relacionada à

ciclomática compreensibilidade de programa

É a medida do comprimento médio dos identificadores - nomes de variáveis,

Comprimento de
classes, métodos, etc. - em um programa, sendo que quanto mais longos forem,
identificadores
mais provável que sejam significativos e assim mais compreensível o programa

Profundidade de Medida de profundidade de aninhamento nas declarações if de um programa,

aninhamento onde quanto mais profundamente forem aninhadas, mais difícil de entender será
condicional o programa, que portanto está mais sujeito a erros

Índice de É uma medida de comprimento médio de palavras e sentenças em documentos,

legibilidade(Fog) para os quais quanto maior for esse índice, mais difícil a sua compreensão
ES1: Exercício 8 - Gerência da Qualidade
O grupo continuará a elaboração do Plano de Projeto de SW,
desenvolvendo as seguintes atividades, postando esse documento no
fórum da dupla até o dia 17/11:
1. Faça a introdução do Plano de Qualidade, no item 6,
descrevendo quais os principais objetivos da garantia de qualidade
dos artefatos produzidos no projeto de desenvolvimento do SW
2. Em Critérios de Qualidade identifique e descreva ao menos um
critério, com seu objetivo, para avaliar a documentação e outro
para avaliar os programas entregues
3. Com relação ao Controle de Qualidade, preencha a tabela
sugerida no modelo, com a descrição de quais serão os controles
a serem adotados para a QA de documentos e programas, bem
como qual o respectivo critério de qualidade a ser verificado
4. Em Garantia da Qualidade inclua como serão as verificações de
QA, indicando em que momentos ocorrerão, com os respectivos
entregáveis e os envolvidos, inclusive o analista de QA, além de
definir a estratégia de comunicação a ser adotada para iniciar tais
momentos e para comunicar seus resultados
Qualidade de Documentos
● A qualidade de documentos é tão importante
quanto a de programas
● Sem a informação sobre como usar um sistema e
como compreendê-lo, a sua utilidade do é
degradada
● Alcançar a qualidade de documentos requer um
compromisso de gerenciamento do projeto de
documentos, padrões e processos de garantia de
qualidade
● Produzir bons documentos não é fácil nem
barato
● Muitos engenheiros de SW acham mais difícil
isso do que produzir programas de qualidade
Estrutura de Documentos
● É a maneira como o documento é organizado em capítulos
e, dentro desses capítulos, em seções e subseções
● A estrutura adequada de documento permite que os
leitores encontrem a informação mais facilmente
● Documentos bem estruturados podem ser lidos mais
rapidamente, sendo possível localizar as seções ou
subseções de maior interesse
● Tendo impacto na legibilidade e usabilidade é importante
planejar a estrutura cuidadosamente durante a criação da
documentação
● Geralmente é definida anteriormente e estabelecida nos
padrões de documentação, tendo a vantagem da
consistência ainda que possa causar alguns problemas,
como um padrão não apropriado em todas as ocasiões
● Uma estrutura pouco natural pode ser usada se os
padrões forem impostos sem as devidas considerações
Estrutura de Documentos: Capa
● Todos os documentos,
independentemente do tamanho,
devem ter uma capa que
identifica o projeto, o
documento, o autor, a data de
produção, o tipo de documento,
gerenciamento de configuração
e informação de garantia de
qualidade, os destinatários
planejados e a classe de
confidencialidade do documento
● Devem incluir ainda informação
para recuperação de documento
(um resumo ou palavras chaves) e
uma nota de direitos autorais
Estrutura de Documentos: Tópicos
● Documentos maiores devem ser divididos em capítulos,
com cada capítulo estruturado em seções e subseções.
Uma página com resumo deve introduzir esses
capítulos, seções e subseções
● Um esquema consistente de numeração para capítulos,
seções e subseções deve ser definido, sendo numerados
por página individualmente, onde o número da página
deve ter o formato capítulo-página
● Se um documento contém muita informação de
referência, ele deve ter um índice, permitindo que a
informação seja facilmente descoberta. Sem um índice os
documentos de referência são virtualmente inúteis
● Se um documento é voltado para um espectro grande de
leitores que podem ter vocabulários diferentes, deve ser
fornecido um glossário que define os termos técnicos
e acrônimos usados no documento
Estilo de Escrita
1. Use a voz ativa em vez da voz passiva. É melhor indicar
“Você deve ver um cursor no canto esquerdo superior da
tela” do que dizer “Um cursor deve aparecer no canto
esquerdo superior da tela”
2. Use construções gramaticais e ortografia corretas
3. Não use sentenças longas que apresentem vários fatos
diferentes
4. Mantenha os parágrafos curtos: nenhum parágrafo deve
ser feito com mais de 7 sentenças. Em parágrafos curtos
todos os conceitos podem ser mantidos na nossa
memória de curto prazo
5. Não seja prolixo: se você pode dizer alguma coisa em
poucas palavras, por favor, faça isso
6. Seja preciso e defina os termos que usa, a terminologia
de computação é fluida e muitos termos têm mais de um
significado. Colete as definições em um glossário
 Estilo de Escrita
7. Se uma descrição for complexa, repita a si próprio.
Frequentemente, é uma boa ideia apresentar duas ou
mais descrições com sentenças diferentes da mesma
coisa
8. Use títulos e subtítulos, eles decompõem os capítulos
em partes que podem ser lidas separadamente
9. Enumere os fatos sempre que possível, geralmente é
mais claro apresentar os fatos numa lista em vez de uma
sentença. Use ainda destaque textual (itálico ou
sublinhado) para dar ênfase
10. Não faça referência a uma informação apenas por seu
número de referência. Ofereça o número de referência e
lembre o leitor do que a referência trata. Por exemplo,
ao invés de dizer ‘Na seção 1.3 …’ você deve dizer ‘Na
seção 1.3, que descreve modelos de gerenciamento de
processo, …’
Padrões de Documentação: Tipos
São a base para garantir a qualidade de documentos. Os
tipos de padrões que podem ser usados no processo de
documentação são:
1. Padrões de processo: definem o processo que deve ser
seguido para produção de documentação de alta
qualidade (rascunho, verificação, revisão)
2. Padrões de produto: são padrões que definem os
documentos em si, por exemplo a organização e estrutura
destes (identificação, sumário, apresentação, atualização)
3. Padrões de intercâmbio: todos os documentos são
mantidos virtualmente em formatos eletrônicos, podendo
ser desenvolvidos em momentos diferentes usando
sistemas diferentes. Assim os padrões de intercâmbio são
necessários para garantir que as cópias eletrônicas de
documentos sejam compatíveis (edição e distribuição)
Gerenciamento de Configuração
● Do inglês configuration management (CM), é relacionado a
políticas, processos e ferramentas para o gerenciamento de
mudanças dos sistemas de SW
● Uma equipe de CM é responsável por garantir o controle das
mudanças e versões de componentes incorporadas em cada
versão dos sistemas em evolução, pois pode haver várias
versões em desenvolvimento e em uso ao mesmo tempo
● É útil em projetos individuais, para não esquecer quais
mudanças foram feitas
● É essencial para projetos em equipe, nos quais vários
desenvolvedores trabalham ao mesmo tempo em um SW,
podendo estar em diferentes locais, de maneira que não
interfiram negativamente nos trabalhos uns dos outros
● Políticas e processos de CM definem: como processar
propostas de mudança de SW; decidir quais componentes
alterar; gerenciar diferentes versões de SW e seus
componentes; e como distribuir os programas alterados
G. de Configuração: Ações
1. Gerenciamento de mudanças: mantém o acompanhamento das
solicitações dos interessados por mudanças no SW, permitindo
definir os custos e o impacto de fazer tais mudanças e decidir
quando serão implementadas
2. Gerenciamento de versões: faz o acompanhamento de várias
versões de componentes do SW e assegura que as mudanças
nestes não interfiram umas nas outras, mesmo que feitas por
diferentes engenheiros de SW
3. Construção do sistema: processo de montagem de componentes
de SW, dados e bibliotecas, ligando-os para criar um sistema
executável
4. Gerenciamento de releases: prepara o SW para o release externo
e faz o acompanhamento das versões de sistema que foram
liberadas para uso
● Ferramentas de CM (CMS) são usadas para suportar as políticas
e processos de CM, controlando as solicitações de mudança, o
armazenamento de versões de componentes, a construção de
sistemas a partir destes e a liberação de versões do sistema
Gerenciamento de Mudanças
● Garante que as mudanças sejam aplicadas ao sistema de uma forma
controlada a partir de processos de CM apoiados CMS
● Destina-se a garantir que a evolução do sistema seja gerenciada,
permitindo priorizar as mudanças
● O processo de gerenciamento de mudança, que ocorre a partir do
momento em que o software é implantado, consiste em:
a. Solicitação de mudança (CR, do inglês change request)
preenchida pelo cliente em formulário eletrônico, relatando um
bug (manutenção) ou uma funcionalidade extra (evolução)
b. Validação da CR por uma equipe de suporte ou outro cliente
c. Análise de custo e benefício da CR para avaliar sua viabilidade
d. Aprovação da mudança, caso seja viável, por um comitê de
controle de mudanças (CCB, do inglês Change Control Board),
que decide a partir de uma perspectiva de negócio
e. Acompanhamento dos componentes de sistema alterados
f. À medida que a CR é processada, informação é adicionada ao
CRF (do inglês CR form) a fim de registrar as decisões
tomadas em cada estágio do processo
Solicitação de Mudança: Formulário
Gerenciamento de Versões
● Do inglês version management (VM) é o processo de
acompanhamento de diferentes versões de componentes de
SW ou outros artefatos e os sistemas em que esses são
usados, sendo a implementação mais comum de CM
● Garante que mudanças feitas por desenvolvedores em cada
versão não interfiram umas nas outras, implementando
espaço de trabalho em que eles podem fazer check-out
para alterar um artefato e check-in com suas alterações
1. Codeline é um histórico de versões de código-fonte,
normalmente aplicadas para componentes de sistemas
2. Baseline especifica a versão de cada componente incluída
no sistema, uma especificação de bibliotecas usadas,
arquivos de configuração, etc. São importantes porque
permitem recriar uma versão específica de sistema
3. Mainline é uma sequência de versões de sistema
desenvolvidas a partir de uma baseline original
Codelines e Baselines
Construção do Sistema
● Processo de criação de um sistema completo,
executável, por meio da montagem e ligação
dos componentes de SW, bibliotecas externas,
arquivos de dados e configuração, etc.
● O sistema de desenvolvimento e o servidor de
construção podem interagir com o
gerenciamento de versões
● Envolve a montagem de uma grande
quantidade de informações sobre o SW e seu
ambiente operacional
● Uma ferramenta de construção automatizada
permite construir um sistema completo com um
comando
Gerenciamento de Releases
● Release de SW é uma versão de um sistema distribuída ao
cliente, existindo três tipos:
a. R. principal que fornece nova e significativa funcionalidade
b. R. menor com reparação de bugs e correção de problemas
que os clientes relataram, em geral são gratuitos
c. R. especial produzidos para cada cliente, onde cada um
executa versões diferentes do sistema ao mesmo tempo
● Quando um release de SW é produzido deve ser documentado
para garantir sua futura recriação
● Documentar um release envolve gravar versões de
código-fonte que foram usadas para criar o código executável,
além de todos os dados e arquivos de configuração, com
versões do SO, bibliotecas, compiladores e outras ferramentas
usadas na construção do SW
● Novos releases de SW não podem depender da instalação de
releases anteriores
ES1: Exercício 9 - Ger. de Configuração
Continuem a elaboração do Plano de Projeto de SW das seguintes
atividades, postando esse documento no fórum do grupo até o dia
24/11:
1. Elaborem o Resumo que destaca a importância do CM, no
item 7, no desenvolvimento do sistema
2. Definam quando e de que forma deverá ser feito cada Pedido
de Mudanças
3. Descrevam como será a Avaliação das Mudanças, que
envolve o cálculo de custo e benefício para definição da
viabilidade da mudança, além de incluir quem serão os
responsáveis
4. Definam como será a Aprovação das Mudanças, que envolve
a priorização das mudanças, a definição do tipo de mudança
(manutenção/evolução) e os envolvidos nessa atividade
5. Abordem a Implantação das Mudanças, destacando como
será o controle de versões dos artefatos e do SW e quem
estará envolvido nessa atividade
Melhoria de Processo de Software
Implica na compreensão dos processos existentes e sua
mudança para aumentar a qualidade de produtos, reduzir
custos e o tempo de desenvolvimento. Existem 2
abordagens:
● Maturidade de processo: centra na melhoria do
gerenciamento de processos e projetos, introduzindo
boas práticas de ES em uma organização, onde o nível
de maturidade do processo reflete o grau de boas
práticas técnicas e gerenciais adotadas nestes
○ Os principais objetivos dessa abordagem são produtos
de melhor qualidade e processos mais previsíveis
● Ágil: centra no desenvolvimento iterativo e na redução de
atividades que não estão diretamente envolvidas na
programação (overhead), objetivando a entrega rápida
de funcionalidade e maior capacidade de resposta às
mudanças de requisitos
Qualidade de Processo e de Produto
● A qualidade de SW não é diretamente influenciada por seu
processo de manufatura, mas por seu processo de projeto,
no qual as habilidades e a experiência dos ES são
significativas
● Em alguns casos o processo usado pode ser mais
significativo para determinar a qualidade de produto, mas
para a produção de aplicações inovadoras as pessoas
envolvidas têm mais influência sobre a sua qualidade do
que o processo usado
É preciso definir os
aspectos que se
deseja melhorar:
● Qualidade de
SW?
● Atributos do
processo em si?
Atributos de Processo: Exemplos

● Existem atributos que são relacionados. A visibilidade pode ser

inversamente relacionada com a rapidez, por exemplo
● Assim é impossível implementar melhorias no processo que otimizem
todos os atributos simultaneamente
Melhoria de Processo: Ciclo
A melhoria de processo é cíclica e contínua, que envolve a:
1. Medição: os atributos do projeto ou dos produtos são
mensurados a fim de melhorar as medidas de acordo com os
objetivos da organização, formando uma baseline que ajuda a
decidir se as melhorias no processo são eficazes
2. Análise: o processo atual é avaliado e identificados os
gargalos e pontos fracos, levando em consideração os
atributos de processo, como rapidez ou robustez
3. Mudança: são propostas mudanças para resolver alguns dos
pontos fracos identificados no processo. Ao serem introduzidas
o ciclo recomeça para a coleta de dados sobre a eficácia das
mudanças
Como parte do 1º ciclo de mudanças, pode-se introduzir as
atividades para coletar dados sobre o processo de SW e para
medir as características de produto de SW, sem dados concretos
sobre estes é impossível avaliar as suas melhorias
Melhoria de Processo: Considerações
● Sabe-se que não existe um processo de SW ideal que
seja aplicável a todas as organizações ou para todos os
produtos de um tipo de SW
● Cada organização precisa desenvolver seu próprio
processo considerando seu tamanho, sua experiência
(background), sua cultura, as habilidades dos seus ES, o
tipo de SW que esteja desenvolvendo, o cliente e os
requisitos de mercado
● A melhoria dos processos não significa apenas a
adoção de métodos e ferramentas ou de um processo
genérico publicado
● É raro que a melhoria de processo seja bem sucedida
quando se tenta alterar o processo para um que seja
usado em outros lugares, sem considerar o ambiente e a
cultura locais
Melhoria de Processo: Modelo CMMI
● Em meados de 1980, o SEI (Software Engineering
Institute) iniciou um estudo para avaliar a capacidade dos
prestadores de serviços de SW, tendo como resultado o
CMM, do inglês Capability Maturity Model
● Posteriormente o SEI buscou integrar a multiplicidade de
modelos de capacidade com base na noção de
maturidade de processos, criando o CMMI (Capability
Maturity Model Integration)
● Sua versão por estágios permite que o
desenvolvimento de sistemas e processos de
gerenciamento adotados em uma organização sejam
avaliados, atribuindo-se um nível de maturidade
classificado de 1 a 5
● Esse framework permite classificar 22 áreas de
processo em uma escala de 0 a 5
Processo no CMMI: Áreas
1. Um conjunto de áreas relacionadas às atividades de
processo de SW relevantes para a melhoria e capacidade
de processo de SW, onde as 22 áreas estão organizadas
em 4 grupos
Processo no CMMI: Metas
2. Um conjunto de metas, que são descrições abstratas de
um estado desejável a ser atingido por uma organização,
define o estado desejável para cada área de processo
Processo no CMMI: Boas Práticas
3. Um conjunto de boas práticas, que são as descrições das
formas de como alcançar uma meta, podem ser associadas
com cada meta, em uma área de processo
a. Metas e práticas genéricas não são técnicas, mas estão
associadas com a institucionalização de boas práticas
Ferramentas para Gerentes de Projeto
Aplicam-se a diversas atividades realizadas por gerentes de projetos:
● Chrome Web Store: Gantter, Smartsheet (site), TeamGantt, Viewpath
PM, Wrike, ProjectWork, GroupCamp (G. Marketplace)
● Function point Workbench: métricas
● DataDrill: coleta automática de dados, análise, formatação de gráficos,
geração de relatórios
● PSM Insight: criação e análise de base de dados de medições de projeto
● SLIM Suite: conjunto de métricas e ferramentas de estimativas
● AMS Realtime Projects: recursos de cronograma
● 4C Suite: suporta o planejamento de projeto, incluindo cronograma
● MS Project: ferramenta para cronograma de projeto em PC
● Project Management Software Directory: lista de fornecedores e software
de gerenciamento de projeto
● Configuration Management Tools: lista de ambientes de SCM
● CVS (Concurrent Versions System): SW livre para VM
● Outras: https://taiga.io/, http://www.planitpoker.com/,
https://pt.smartsheet.com/, https://www.planningpoker.com/,
http://dotproject.net/, http://www.tomsplanner.com/,
https://www.projectmanager.com/software/gantt-chart, https://trello.com/
ES1: Exercício 10 - Cronograma
Conclua a elaboração, em grupo, do Plano de Projeto de SW (PPSW)das
seguintes atividades, postando esse documento no fórum até o dia 30/11, em sua
versão final, após essas atividades:
1. Atualize a tabela da Equipe de Trabalho e os itens das Responsabilidades
do Cliente e dos Desenvolvedores, 4.x.1 e 4.x.2, para incluir os envolvidos
nas atividades dos gerenciamentos de qualidade e de configuração
2. Para elaborar o Cronograma e o gráfico de Gantt, no item 4, use uma das
ferramentas para Gerentes de Projeto (Gantter, Smartsheet, TeamGantt),
devendo incluir:
a. Organização por entregas, item 3 do PPSW, refletindo ainda aquelas
feitas durante os exercícios anteriores
b. Tarefas e respectivas subtarefas, definido para cada:
i. Duração, com datas de início e fim
ii. Definição de predecessor(es) (dependências)
iii. Recurso, destacando os papéis (responsáveis)
Obs: o cronograma pode ser incluído como anexo do PPSW ou postado, em
formato PDF, no fórum da dupla
3. Junto ao PPSW também devem ser postados, conforme Avaliação 3:
elaboração da avaliação colaborativa:
a. O relatório do coordenador com as atividades realizadas, etc.
b. A elaboração do seminário com planejamento da apresentação, etc.