Thiago Augusto Alves
Professor
Nome: Thiago Augusto Alves
Graduação: Bacharelado em Sistemas de
Informação pela Faculdade COTEMIG – 2004-2007
Pôs Graduação Lato Sensu:
Gerenciamento de Projetos de Software pela PUC Minas – 2009- Junho de 2010.
Professor
Atuação Profissional:
◦ Consultor Freelance de Analise de Sistemas desde 2008;
◦ Consultor Freelance de Gerencia de Projetos desde 2009;
Distribuição de Pontos
Primeiro Bimestre Segundo Bimestre Tipo Pontos Prova 7 Trabalho 1 1,5 Trabalho 2 1,5 Tipo Pontos Prova 7Trabalho 3 (Relacionado com o trabalho 2)
Datas Importantes
Data Tema
20/09/2016 Apresentação do Trabalho 2 27/09/2016 Aplicação da Primeira Avaliação
04/09/2016 Correção, Entrega e revisão das notas.
08/11/2016 Apresentação do Trabalho 3 21/11/2016 a 24/11/2016 SIP
29/11/2016 Aplicação da Segunda Avaliação
13/12/2016 Aplicação da Prova de Recuperação. OBS. As datas estão com possíveis alterações de acordo com o calendário da faculdade.
Prova
Matéria da Primeira Prova: Toda Disciplina
lecionada ate a realização da mesma(Prova Fechada de 10 Questões);
Matéria da Segunda Prova: Toda Disciplina do
Semestre; (Prova Fechada de 10 Questões)
Matéria da Prova Substitutiva: Toda Disciplina
do Semestre; (Prova aberta de 20 Questões).
Dicas de Ouro...
1. Sempre lembre seu RA, isso ajuda a
lançar sua nota;
2. Sempre se identifique para o seu
professor, isso ajuda ele “a te ajudar”;
3. Não deixe nada para ultima hora,
acredite que isso faz diferença;
4. Regularize o mais rápido possível a sua
Novidades
No caso do aluno perder alguma prova
ele tem que fazer a substitutiva, vale tanto para o primeiro e segundo bimestre.
◦ Caso perca as duas provas o caso tem que ser visto com a coordenação e o colegiado.
Pontuação
1. Trabalhos Peso 3 Valor 10 = 3 Pontos; 2. Provas Peso 7 Valor 10 = 7 pontos;
3. Pesos dos Bimestres:
1. Primeiro Bimestre Peso 4;
Contato
https://sites.google.com/site/thiagoaalves/
thiago.augusto2@anhanguera.com
No assunto especificar seu nome e o nome da disciplina e a sala.
Disciplina
Bibliografia Básica Padrão
KOSCIANSKI, André; SOARES, MICHEL
DOS SANTOS (orgs.). Qualidade de
Software : Aprenda as Metodologias e
Técnicas mais Modernas para o
Desenvolvimento de Software. 2ª ed. São Paulo: Novatec, 2007.
Bibliografia Básica Unidade: Faculdade
Anhanguera de Belo Horizonte (FAB)
SOMMERVILLE, Ian. Engenharia de
Software. 8ª ed. São Paulo: Pearson
-Addison Wesley, 2010.
PRESSMAN, Roger S.. Engenharia de
Bibliografia Complementar: Faculdade
Anhanguera de Belo Horizonte (FAB)
PAULA FILHO, Wilson de Padua. Engenharia de
Software : Fundamentos, Métodos e Padrões. 1ª ed. Rio de Janeiro: LTC -Livros Técnicos e Científicos, 2010.
MECENAS, IVAM. Qualidade em Software: uma
metodologia para homologação de sistemas. 1ª ed. Rio de Janeiro: Alta Books, 2005.
PFLEEGER, Shari Lawrence. Engenharia de
Software : teoria e prática. 2ª ed. São Paulo: Pearson, 2007.
HIRAMA, Kechi. Engenharia de Software :
Qualidade e Produtividade com Tecnologia. 1ª ed. São Paulo: Elsevier, 2011.
BARTIÉ, Alexandre. Garantia da Qualidade de
Bibliografia Complementar
Noticias a relacionados ao tema; Artigos relacionados ao tema;
Conteúdo Programático
Apresentação da disciplina e
metodologia de trabalho.
Apresentação do Plano de Estudo e Aprendizagem. Introdução à
Qualidade de Software.
Estudo dos fatores técnicos e
humanos que influenciam a qualidade de um software.
Garantia da Qualidade de Software
(SQA): conceito, importância e apresentação das técnicas.
Conteúdo Programático
Garantia da Qualidade de Software (SQA):
Impactos de um sistema de má qualidade.
CMMI. Introdução, diferenciação entre
qualidade de software e de processo. Estudo dos níveis CMMI. Abordagem das Key
Process Areas (KPA)
CMMI: abordagem dos aspectos práticos de
implantação do modelo. Apresentação de casos de sucesso na implantação, níveis
obtidos pelas principais empresas de TI ou não.
Conteúdo Programático
Norma ISO 15504 (Spice): conceituação,
utilização, metodologia de avaliação.
Normas MPS:BR e ISO 12207.
Modelos de Processo Pessoal e de Equipe
na Melhoria da Qualidade do processo de desenvolvimento de Software
Conteúdo Programático
Métricas de software: conceituação,
motivos para medição de um produto de software. Principais tipos e utilizações.
Qualidade de código. Programação:
Fatores de qualidade
Atividades de revisão de conteúdo e/ou
Trabalhos
Trabalho 1 – Resenha-Critica do Capitulo
1 do Livro. (Disponível do site do professor).
◦ http://pucrs.br/gpt/resenha.php - Link para ajudar a entender o que é uma resenha.
Trabalho 2 – Apresentação e Comparação
entre o Mps.BR e o CMMI.
Trabalho 3 – Aplicabilidade do Mps.BR e
CMMI para solução do problema de uma determinada empresa.
Reflexão
O que vocês entendem por qualidade?
Qualidade de Software
Qualidade segundo o MICHAELIS:
◦ Atributo, condição natural, propriedade pela qual algo ou alguém se individualiza,
distinguindo-se dos demais; maneira de ser, essência, natureza.
◦ Grau de perfeição, de precisão, de conformidade a um certo padrão.
◦ Conjunto de aspectos sensíveis da percepção resultantes de uma síntese efetuada pelo
Qualidade de Software
Segundo Somerville Software
“Programas de computador e
documentação associada. Os produtos de software podem ser desenvolvidos para um cliente específico ou para um
Qualidade de Software
Então o que é considerado a Qualidade
de Software?
Como desenvolver Softwares que vão
Qualidade de Software
Qualidade e igual para todos?
O que é considerado um Software de
qualidade?
E um software que funciona?
Que foi entregue no prazo e custos
Qualidade de Software
Conceitos de Qualidade em Software:
◦ Qualidade é um conceito subjetivo, que varia para cada local, época, tipo de produto e
Qualidade de Software
Uma rápida reflexão:
◦ A qualidade é relativa. O que é qualidade para uma pessoa pode ser falta de qualidade para outra. (Weinberg)
Qualidade de Software
Mas como Contornar essa Relatividade?
Como trabalhar com um padrão pra
Qualidade de Software
E isso que vamos conversar durante o
Qualidade de Software
Reflexão:
Qualidade é:
◦ Superar as expectativas;
◦ Produto sem defeito;
◦ Fazer melhor com menos recursos;
◦ Adequação ao uso ;
◦ Produzido por empresa certificada;
Qualidade é o que cada cliente percebe como
Qualidade de Software
Qualidade
"Qualidade nada mais é do que satisfazer
a necessidade do cliente dentro do projeto." - Ricardo Vargas.
O que o Autor Ricardo Vargas defende
Qualidade de Software
A qualidade esta associada as
necessidades do cliente. Vai ser um produto de qualidade aquele que
apresentar os requisitos solicitados pelo cliente.
Qualidade de Software
“Existem empresas que já estão na versão 5
de seu software, mas tem clientes que ainda usam a versão 3, porque os clientes morrem de medo de atualizar, por causa dos
históricos de erros em novas versões – eles preferem os problemas já conhecidos. Empresas que levam o software ao cliente e uma tela não funciona, ou uma correção de um problema que afetou outro lugar no
Qualidade de Software
Alguns Fatores que levam a erros na
qualidade de Software:
◦ Não existem requisitos ou documentação;
◦ Não existe a fase de projeto de software;
◦ Controle de mudanças e de versões inadequadas (ou inexistentes);
◦ Foco na entrega;
◦ Inexistência de um time de testes (ou mesmo a fase de testes);
Reflexão
Dentre os seguintes fatores quais são os
mais Críticos quando estamos lidando com Qualidade?
◦ Não existem requisitos ou documentação;
◦ Não existe a fase de projeto de software;
◦ Controle de mudanças e de versões inadequadas (ou inexistentes);
◦ Foco na entrega;
◦ Inexistência de um time de testes (ou mesmo a fase de testes);
Qualidade de Software
Podemos definir a Qualidade de Software
como:
◦ “Qualidade de software e atender as
necessidades do cliente, trabalhando em cima dos requisitos passados e trabalhados. Qualidade
também pode ser considerado a entrega de
um produto no tempo especificado
Estudo de Caso 1 – 20 Minutos
A SPM LTDA uma empresa no ramo de
transportes, contratou a sua empresa para o desenvolvimento de um sistema para controle da sua frota. O foco e manter informações dos Veículos, Rotas, Clientes e Fornecedores. Os Requisitos passados pela SPM estão
incompletos e ambíguos levando sua equipe de analistas a realizar varias interpretações.
O projeto não pode ser entregue depois de
31/12/2015 devido a questões legais.
Realize o Levantamento dos principais
problemas de qualidade que podem acontecer neste projeto.
Fatores Técnicos e Humanos
Situações de estresse e problemas de
relacionamento:
◦ Existem em qualquer ambiente de trabalho
O estresse do dia-a-dia bem como do
ambiente de trabalho pode ser levar a queda de qualidade.
Fatores Técnicos e Humanos
As empresas podem tratar esses
problemas até certo ponto:
◦ Investir em qualidade de trabalho e de vida;
◦ Oferecer opções de conforto e lazer;
◦ Prever necessidade de substituir ou remanejar funcionários;
Fatores Técnicos e Humanos
E quando a empresa está em dificuldade?
Não os funcionários:
◦ Quando cronogramas deixam de funcionar, número de defeitos torna-se incontrolável e ninguém mas tem certeza do que fazer para salvar o projeto;
◦ Os indivíduos sofrem com estresse,
discussões podem surgir a cada minuto e a pressão é combatida com mais pressão;
Reflexão 3 Perguntas Básicas
A realidade da empresa reflete na
qualidade dos seus funcionários?
A realidade do Funcionário deve ser
Refletida dentro da Empresa?
Qualidade de vida tem que ser
Fatores Técnicos e Humanos
Comparando com linhas de montagem
(diferença)
◦ Grande volume de trabalho intelectual não repetitivo;
◦ É uma bênção para um pessoa inteligente;
◦ É, também, um problema do ponto de vista organizacional:
Como administrar algo que, por princípio, é
Fatores Técnicos e Humanos
Essa aleatoriedade é menor do que se
costuma pensar
◦ Ex: música, que depende da criatividade:
Quem estuda música vê que ela pode ser
sistematizada;
◦ Um software deve ter requisitos mais precisos que um música;
◦ A “linha de produção” de software deve ser definida e organizada;
Fatores Técnicos e Humanos
Organização do trabalho:
◦ É essencial trabalhar em sintonia;
◦ A falha de um ou mais membros em dividir os objetivos do grupo afeta o desempenho do grupo;
◦ Boas relações informais e liderança que faça convergir;
◦ Weinberg: fazer o grupo partilhar a
responsabilidade de definir os objetivos;
Fatores Técnicos e Humanos
◦ Aplicação é menos óbvia:
Pressupõe organização perfeita; Vários itens a administrar;
Usar metodologias como CMMI, PSP e XP;
Boa comunicação, para todos saberem porque usar
Fatores Técnicos e Humanos
Comunicação:
◦ Para uma especificação de requisitos é possível criar infinitos programas diferentes;
◦ Problema: garantir que todos os envolvidos tenham em mente a construção da mesma e única solução;
◦ Boa comunicação facilita a compreensão do que se está trabalhando;
Todos os envolvidos (programadores, projetistas,
gerentes, etc);
◦ Pode revelar posturas e atitudes nocivas ao trabalho em equipe;
Ex: “eu disse a ele que não funcionaria dessa forma”; Gerentes devem estar atentos a esse tipo de
Fatores Técnicos e Humanos
Individualismo:
◦ Forte componente de criatividade;
◦ Nas engenharias é bastante clara a existência de um prazer estético associado com uma nova solução;
Pode haver importante influência do ego dos
Fatores Técnicos e Humanos
Relação comercial-desenvolvimento:
◦ Ideias que na prática não são feitas;
◦ Há conflitos de interesses entre as áreas comercial e técnica;
◦ Comercial trabalha sobre pressão por resultados;
Grande competição, margem de lucro pequena;
Vendedores são levados a realizar promessas irreais ;
◦ Técnica sofre com seus próprios problemas;
Prazo, modificação nos requisitos, correções de erros;
Tendência do desenvolvedor é simplificar o máximo possível; Oposta a área comercial;
◦ Possível solução: área intermediária entre as duas;
Pessoas com conhecimento nas duas áreas;
Harmonizar as expectativas do setor comercial com as possibilidades de realização do setor de desenvolvimento;
Reflexão
Uma empresa que possuiu uma alta
rotatividade de funcionários e uma empresa que apresenta qualidade?
Práticas das Organizações Maduras
Interação com o cliente:
◦ Fator de fracasso: alteração dos requisitos e escopo;
◦ Inevitável, porém deve ser entendido pelas duas partes;
◦ Ver o cliente como um parceiro com interesse comum:
O sucesso do projeto;
◦ Toda não conformidade com o planejado é informada ao cliente;
◦ Cliente é incentivado a se comunicar com os desenvolvedores;
Práticas das Organizações Maduras
Gerenciamento de projetos:
◦ Planos de projeto realísticos e honestos;
Propor custos ou prazos reduzidos: desleal e
desastrosa;
◦ Análise e gerência contínua de riscos;
◦ Busca de métricas mais precisas para calcular prazos e custos;
◦ Projetos anteriores servem de base;
Práticas das Organizações Maduras
Métricas:
◦ Alimentam suas bases de projetos anteriores constantemente;
◦ Métricas auxiliam a definição de tarefas e alocação de recursos;
◦ Medidas para conhecer o desempenho individual e coletivo;
Relatórios de emprego de tempo, por exemplo;
◦ Pode trazer receio aos desenvolvedores;
Constantemente avaliados;
◦ Deve haver um feedback positivo do gerente do projeto;
Não punir erros, mas sim aprimorar estimativas;
Práticas das Organizações Maduras
Treinamento e coaching:
◦ Treinamentos formais para novos contratados;
Apresentar os padrões usados na empresa;
◦ Programas de reciclagem para os mais antigos;
Sentem-se valorizados;
Pode ser necessário, em novos projetos, processos,
linguagens ou ferramentas ainda não conhecidas; ◦ Coaching: funcionários mais experientes
acompanham e auxiliam o desenvolvimento da carreira dos mais novos;
Práticas das Organizações Maduras
Revisões por pares:
◦ É difícil um desenvolvedor encontrar seus próprios erros;
◦ Designa-se outro para realizar uma revisão;
◦ Cada artefato produzido passa pela revisão de outro funcionário;
Documento de requisitos, diagramas de análise ou
código;
◦ Deve haver preocupação em evitar atritos;
Estudo de Caso 2 – 20 minutos
Faça um comentário sobre a solução adotada pelo Analista. Levante os pontos Positivos e Negativos.
Previsões
◦ O analista de sistemas Ubiratã está desenvolvendo seu software, tentando ser o mais eficaz possível. Quando o gerente aparece:
Em quanto tempo você acha que consegue implementar relatórios com consultas por data e valor?
Não sei ainda, preciso ver quando teremos acesso ao mainframe. No ambiente de desenvolvimento nossa aplicação funciona, em produção, não temos acesso às tabelas necessárias. Preciso conversar com os analistas do sistema ABC sobre isso.
Não quero saber, preciso isso agora. Quanto tempo você leva? Ele pensa: “vou levar umas 4h no máximo:”, mas responde: Vou precisar de 5 dias
Ok, vou lançar isso no cronograma
◦ No final do dia estava pronto. Ele usou os outros 4 dias documentando e testando a aplicação inteira, coisas que ainda não tinha feito por falta de tempo
