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;
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.
Vai ser substituída a menor nota
Distribuição de Pontos
Primeiro Bimestre
Segundo Bimestre
Tipo Pontos
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 situação com a faculdade;
5.
Por Favor colocar RA é Nome na
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;
Avaliar
Agradecer a Participação;
Informar alguns resultados;
Contato
https://sites.google.com/site/thia
goaalves/
thiago.augusto2@anhanguera.co
m
No assunto especificar seu nome e
o nome da disciplina e a sala.
Disciplina
Bibliografia Básica Padrão
MAITINO NETO, Roque. Engenharia de Software. 1.
Londrina: Editora e Distribuidora Educacional S.A, 2016. 9788584824168.
Wazlawick, Raul. Engenharia de Software. 1. Rio De
Janeiro: Elsevier, 2015. 9788535260847.
GUSTAFSON, DAVID A. Engenharia de Software -
Colecao Schaum. 1. Porto Alegre: Bookman Cia Editora Ltda, 2015. 8536301856.
PRESSMAN, ROGER S. Engenharia de Software
7Ed. 7. Porto Alegre: Amgh Editora Ltda, 2015. 9788563308337.
IAN SOMMERVILLE. Engenharia de Software 9
Edicao. 9. São Paulo: Pearson, 2011. 9788579361081.
SCHACH, STEPHEN R. Engenharia de Software:Os
Paradigmas Classico 7Ed. 7. Porto Alegre: Amgh Editora Ltda, 2015. 9788577260454.
Bibliografia Complementar – Biblioteca Virtual
WINDER, Russel; GRAHAM, Roberts. Desenvolvendo Software Em Java, 3ª Edição. 3. Rio De Janeiro: Grupo Gen, 2015. 9788521616580.
COHN, Mike. Desenvolvimento de Software Com Scrum. 1. Porto Alegre: Grupo A, 2015. 97885778080760.
OKUYAMA, Fabio Yoshimitsu; MILETTO, Evandro Manara; NICOLAO, Mariano. Desenvolvimento de Software I: Conceitos Básicos - Série Tekne. 1. Porto Alegre: Grupo A, 2014. 9788582601464.
PADUA FILHO, Wilson de Paula. Engenharia de Software, 3ª Edição. 3. Rio De Janeiro: Grupo Gen, 2008. 9788521619925.
SCHACH, Stephen R. Engenharia de Software, 7ª Edição. 7. Porto Alegre: Grupo A, 2015. 9788577260454.
Bibliografia
Complementar
Noticias a relacionados ao tema;
Artigos relacionados ao tema;
Sites de autores relacionados ao
tema.
Conteúdo Programático - PEA
UNIDADE DE ENSINO:
Desenvolvimento Ágil de
Software
◦
Métodos ágeis - Extreme Programming
(XP): conceitos, características,
princípios/práticas e exemplos.
◦
Métodos ágeis - Scrum: conceitos,
características e princípios/práticas.
◦
Métodos ágeis - Scrum: exemplos e
aplicabilidade.
◦
Métodos ágeis para o desenvolvimento de
software: conceitos, histórico e princípios.
Conteúdo Programático - PEA
UNIDADE DE ENSINO:
Fundamentos de Engenharia de
Software
◦
Fundamentos dos processos de
desenvolvimento de software: conceitos e
principais atividades.
◦
Introdução à Engenharia de Software:
aspectos gerais, objetivos, evolução do
software e crise do software.
◦
Modelos de processos de software:
características e atividades.
◦
Modelos dos processos de software:
aplicabilidade e evolução.
Conteúdo Programático - PEA
UNIDADE DE ENSINO: Gerenciamento
de Configuração e Testes
◦Desenvolvimento dirigido a testes - Test-DrivenDevelopment (TDD): conceitos, processo e benefícios.
◦Evolução de Software - gerenciamento de mudanças e versões: conceitos,
características e processo.
◦Testes de desenvolvimento de software: conceitos, características e tipos.
◦Testes de release e de usuário: conceitos, características e tipos.
Conteúdo Programático - PEA
UNIDADE DE ENSINO: Gerenciamento
de Qualidade de Software
◦Gestão de qualidade de software: conceitos, fundamentos, processo e planejamento.
◦Introdução a revisões, inspeções, medições e métricas.
◦Introdução às normas de qualidade de software: ISO 9001, ISO 9126 e
CapabilityMaturityModelIntegration (CMMI).
◦Padrões de software no gerenciamento de
qualidade de software: conceitos, importância e processo/passos.
Datas Importantes – Turma de
Quinta
Data Tema
OBS. As datas estão com possíveis alterações de acordo com o calendário da faculdade.
Trabalho Interdisciplinar
Modelo de Ensino
KLS 2.0
◦
Divido em 3 momentos;
Pré-Aula; Aula; Pós-Aula.Pré-Aula
Material disponibilizado antes da
Aula;
Textos, Videos, PodCasts tudo
que puder ajudar no
entendimento e preparação da
aula.
Pré-Aula e fora do horário de
Aula
Momento de aprofundamento da
Pré-Aula;
Neste momento o assunto da
aula e abordado e mais
trabalhado;
Momento para reflexões e
Pós-Aula
Momento posterior a aula.
Neste momento tudo que foi visto
e discutido durante a Pré-Aula e a
Aula são trabalhados em uma
forma de fixação.
Normalmente um conjunto de
Pré-Aula
Reflitam sobre a seguinte
afirmação de Pressman:
◦
“Com o crescimento desse segmento
muitas empresas possuem mais
especialistas em TI em que cada um
tem sua responsabilidade no
desenvolvimento de software e é
diferente de antigamente que era
um único profissional de software
que trabalhava sozinho numa
Pré-Aula
Ao passar do tempo, ninguém imaginava
que o software tornaria um elemento
muito importante para o mundo e teria
a capacidade de manipular a
informação. Com muitos elementos
computacionais tiveram mudanças até
hoje e continuam tendo. Com este
crescimento computacional, levam a
criação de sistemas perfeitos e
problemas para quem desenvolvem
softwares complexos.
Aula
As preocupações dos engenheiros
de software para desenvolverem
os software sem defeitos e
entregarem estes produtos no
tempo marcado, assim leva a
aplicação da disciplina de
Reflexão
Software:
“O software é o conjunto de
vários artefatos e não apenas o
código fonte (SOMMERVILLE).”
Aula
Software Realizando uma comparação entre o software
e hardware. Chegamos a seguinte conclusão. O software apenas pode ser desenvolvido
e realizar a manutenção (mudança) no software é uma tarefa complicada, exige
grande esforço da equipe de engenheiro de software. Ao passar do tempo o software
fica deteriorado. Já para o hardware apenas
pode ser fabricado e realizar a manutenção no hardware é simplesmente trocar à peça que esta em desgaste. Ao passar do tempo o
hardware desgasta por vários motivos (PRESSMAN, 2006).
Aula
O software é caro porque torna se
uma atividade difícil e trabalhosa
de ser realizado pelo engenheiro
de software (JALOTE, 2005).
Aula
De acordo Pressman (2006) o
software estão categorizados em
seguintes tipos, tais como:
Aula
Software de sistema. São programas
que apóiam outros programas, como o
software que realiza a comunicação
com o hardware (sistema operacional)
e software que ajuda na construção de
outro software (compiladores).
Aula
Software de aplicação. São programas
que são desenvolvidos para executar
no negocio de uma empresa
Aula
Software embutido. São programas
construídos para executarem dentro
de um produto especifico como a
teclas digitais de um forno micro
ondas.
Aula
Software Legado
O nome de software legado é dado quando refere
se num programa de computador que foi
desenvolvido há muito tempo. A preocupação do engenheiro de software com os softwares legados
esta na baixa qualidade do software. Muitas
vezes não existem documentações e se
existem são pobres de detalhes, os casos de teste são pobres quando tem e sem um
controle de mudanças. E muitas vezes não
mexem no software legado quando eles atentem as necessidades do cliente.
Pós-Aula
Vamos ver alguns mitos da
Pós-Aula
Um bom manual, repleto de
padrões e regras, fornecerá a
equipe tudo que ela precisa saber?
Desenvolvimento não é uma receita de bolo! Os clientes são diferentes, os projetos sãodiferentes, os programadores são diferentes, as prioridades dependem do projeto. Basicamente, TUDO é diferente. Não pense que um site de e-commerce que você desenvolveu para a
empresa X valerá para a empresa Y, e
vice-versa. O planejamento é fundamental e só então você poderá levantar os requisitos necessários e trabalhar em cima de um novo projeto.
Pós-Aula
Caso ocorra atraso no cronograma este
poderá ser contornado alocando-se mais programadores ao projeto.
Por mais que exista o conceito de “Fábrica de
Software” não podemos pensar no processo de desenvolvimento como uma linha de
produção. Ao se inserir um programador em um projeto, ele levará algum tempo para se familiarizar com o código e com o que está sendo feito, para então, começar de fato a produzir. Alocar programadores para resolver um problema de cronograma poderá surgir efeito contrário, causando mais problemas!
Pós-Aula
Uma Gravida demora 9 meses
para gerar um bebe.
Se Juntarmos 9 Gravidas eu vou
Pós-Aula
Terceirizar um projeto é garantia de
tranquilidade e nenhum trabalho.
Quando um projeto é muito trabalhoso, requer
know-how maior do que a sua equipe possui ou o cronograma está apertado, muitos optam pela
terceirização achando que esta é uma garantia de tranquilidade e nenhum trabalho. Contudo, tome cuidado: Se a empresa X contratou você, você é o responsável pelo trabalho que está entregando. Aí fica a pergunta: A terceirização fez o serviço
direito? Comentou o código? Documentou o que foi feito? Sua equipe tem pessoal para trabalhar nesse código? Pense bem antes de terceirizar algo que não poderá trabalhar bem no futuro. É melhor recusar um projeto do que faze-lo mal feito.
Pós-Aula
Um software pode ser construído
observando-se o seu propósito geral – os detalhes podem ser levados em conta
posteriormente.
Se você é desenvolvedor já deve ter se
deparado com um usuário que só queria um
ajustizinho no sistema: “só adicione um botão
que faça isso e busque aquilo e faça isso ficar cor de rosa e brilhar girando”. Sim, essas coisas acontecem! Desenvolvedores geralmente não gostam de destruir algo para faze-lo de outra forma, pois o cliente mudou de ideia. Aliás, ninguém gosta.
Pós-Aula
Mesmo que os requisitos de um software mudem,
as alterações são realizadas facilmente pois temos uma boa equipe que sabe como fazer o serviço muito bem.
Mais uma vez, se você não é desenvolvedor e não
entende do processo, não julgue uma atualização como simples. Somente um programador poderá avaliar o quão simples uma alteração é – e muitas vezes, ela só vai realmente ter a ideia depois que estiver
trabalhando com o código. Mesmo que você tenha
uma boa equipe, modificações devem ser analisadas, discutidas com relação a sua viabilidade e testadas.
Lembre-se sempre: alocar um programador
requer algum tempo para que esse se familiarize com o que vem sendo feito.
Pós-Aula
Se o programa funciona, nosso trabalho está completo. Se o programa ainda não está finalizado e “rodando”,
não posso avaliar sua qualidade.
Esses dois tópicos são assustadoramente passados adiante e
você já deve ter ouvido isso de alguém. Se um programa roda isso não garante que o seu trabalho está feito. Todo o processo de desenvolvimento deve buscar a qualidade e apenas
funcionar não lhe garante isso – ou seja, o processo da
avaliação de qualidade não se limita a essa etapa. O seu código é bem comentado? Está bem feito? Otimizado? A tecnologia
utilizada é adequada? Os banco de dados estão otimizados? Sua relações foram criadas corretamente? A infraestrutura do
cliente suporta o que está sendo desenvolvido? Se o seu sistema foi feito para suportar vários acessos, ele realmente suporta isso? Um programa é mais do que o executável. Você vende todo o processo.
Pós-Aula
O único produto que entregarei ao
cliente é o código executável.
Em alguns casos, o produto “palpável” que o
cliente recebe é somente o executável. Em outros, trabalha-se com o código fonte e com a documentação. Contudo,
independente do caso, lembre que, como foi dito no item anterior: Um programa é mais do que o executável. Você vende todo o
processo de desenvolvimento. Por isso, deve-se pensar e faze-lo com perfeição.
Pós-Aula
O processo de planejamento fará com
que criemos documentação volumosa que atrasará a execução do projeto, atrasando o cronograma.
Planejamento é fundamental! Muitas pessoas
aindam confundem planejamento com
“papelada” e estas estão terrivelmente
enganadas! Mesmo trabalhando-se em um time Agil, planejar é fundamental! A
documentação do projeto será trabalhada na melhor metodologia adotada mas um plano do que será feito deverá ser estudado antes de “colocar a mão na massa.
