UFMG - ICEx - DCC
DCC603
– Engenharia de Software – Turma TM
2o.
Semestre de 2018
Notas:
Prova 1
Nota Final
Frequência
---
Aulas: Terças e quintas, sala 2013, 13:00-14:40
Monitoria: ___ _____ [em] dcc ponto ufmg ponto br
---
Livro Texto:
3ª edição (Só serve a 3ª. Edição! Não serve a 1ª nem a 2ª )
Engenharia
de software: fundamentos, métodos e padrões
Wilson de Pádua Paula Filho
LTC – Livros Técnicos e Científicos
3ª EDIÇÃO <<<
---
Existem vários sítios da Web com foco na UML, exemplos
http://www.uml-diagrams.org/uml-25-diagrams.html
buscar no google uml quiz exemplo
http://www.modernanalyst.com/Resources/SelfAssessment.aspx
---
Deve ser aprendido um “conjunto de conceitos” para poder ler&entender certos documentos:
Exemplo de edital
https://sas.cmmiinstitute.com/pars/pars.aspx (Resultados de avaliação CMMI)
Sistema de dados de aprovisionamento (contratos>US$3k) dos eua
https://www.fpds.gov/fpdsng_cms/index.php/reports/62-top-100-contractors-report
Sistema de registro de preços
---
Software vs Sistemas
https://en.wikipedia.org/wiki/ISO/IEC_15288
https://en.wikipedia.org/wiki/ISO/IEC_42010
Sistema de Sistemas
----
It’s All About the Team
...in the realm of programming,
lone craftsmen are extremely rare—and even when they do exist,
they don’t perform superhuman achievements in a vacuum;
their world-changing accomplishment is almost always the
result of a spark of inspiration followed by a heroic team effort.
Creating a superstar team is the real goal, and is
fiendishly difficult.
The best teams make brilliant use of their superstars,
but the whole is always greater than the sum of its parts.
Let’s put this idea into simpler words:
Software development is a team sport.<<<<<<<<<<<<<<<<<<<<<<<<<<
fonte: Team Geek
by Brian Fitzpatrick and Ben Collins-Sussman
----------------------------------------------------------------
Exemplos de dominios de software/sistemas (fonte: doi>10.1145/1340771.1340774)
------------------------------------------------------------
Unidades (ACM CS2013) de Engenharia de Software tabela
---------
Aspectos humanos: produtividade ---- Equilibrio
Aspectos humanos: Matriz de interação pessoal e projeto; Papéis RUP 2003
XP 2004
um exemplo de apresentação de Pontos de Função
pontos de função “modernos” FiSMA - slides – Base Functional Component
Exemplos de questões de provas
Arquitetura & Desenho(design) Fig 8 .1 pag.244 (fonte Software Engineering / Pressman)
Os “donos” do conhecimento, dinheiro https://www.pmi.org/learning/library/earned-value-management-understand-agile-6567
Exemplo de alguns aspectos: processo de desenvolvimento de software, melhoria de processo de software, requisitos, análise, desenho, implementação, testes, projeto, qualidade;
A avaliação será 60% provas e 40% trabalhos práticos, listas e outros.
Avaliação:
60 pontos: duas provas valendo 30 pontos cada (devem ser feitas 3 provas!)
40 pontos: trabalhos práticos, listas de exercícios, testes surpresa etc.
O material da disciplina é o conteúdo do livro texto *&* material discutido em aula ou seja:
NOTAS DE AULA;
Quando o aluno não comparecer à aula, deve arranjar um colega que forneça as anotações de aula.
Provas:
As provas são sem consulta, mas você pode trazer uma folha tamanho A4 contendo
quaisquer anotações de próprio punho; não é para imprimir, não é para copiar
(não faça colagens). A folha de consulta deverá ser entregue junto com a prova.
O objetivo da folha de consulta é evitar que o aluno escreva na carteira, na
régua ou na borracha. O objetivo da folha de consulta não é testar se o aluno
sabe condensar centenas de folhas em uma só folha.
São escolhidas as duas melhores notas caso o aluno faça as três provas. O objetivo de existirem três provas e serem escolhidas duas notas é evitar que o professor tenha que fazer julgamento de mérito no caso de alunos que não podem comparecer em algum dia de prova. A possível melhoria de nota é um efeito colateral.
-----
|
Data |
Aula |
Evento |
Assunto |
|
Agosto |
|
|
|
|
07 |
01 |
|
Introdução |
|
09 |
02 |
|
Visão geral; enunciado do TP |
|
14 |
03 |
|
Cap. 1, 2 |
|
16 |
04 |
|
Cap. 1, 2 |
|
21 |
05 |
|
Cap. 2, Cap. 3 |
|
23 |
06 |
|
Cap. 3, 4, 5 |
|
28 |
07 |
|
Cap. 3, 4, 5 |
|
30 |
08 |
|
Cap. 1, 2, 3, 4, 5 |
|
Set |
|
|
|
|
04 |
09 |
|
Cap. 1, 2, 3, 4, 5, 12:cone da incerteza, Análise de Pontos de Função |
|
06 |
10 |
|
Apresentação 1; Cap 12 contagem & ajuste CGS |
|
11 |
11 |
|
Cap. 6, 7, 8, 9, 10, 16, 17, 18, 19, 20, 21 |
|
13 |
12 |
|
Cap. 6, 7, 8, 9, 10, 16, 17, 18, 19, 20, 21 |
|
18 |
13 |
|
Cap. 6, 7, 8, 9, 10, 16, 17, 18, 19, 20, 21 |
|
20 |
14 |
|
|
|
25 |
15 |
|
Prova 1 |
|
27 |
16 |
|
Apresentação 2; Revisão |
|
Out |
|
|
|
|
02 |
17 |
|
Revisão (cont.) |
|
04 |
18 |
|
Melhoria de Processo de Software |
|
09 |
19 |
|
Cap. 4, Cap 6, 16 |
|
11 |
20 |
|
|
|
16 |
21 |
S Conh |
Arquitetura-Desenho-Implementação Cap. 8, 18, 19 |
|
18 |
22 |
S.Conh |
|
|
23 |
23 |
|
|
|
25 |
24 |
|
|
|
30 |
25 |
|
Revisão |
|
Nov |
|
|
|
|
01 |
26 |
|
Revisão |
|
06 |
27 |
|
Revisão |
|
08 |
28 |
|
Prova 3 |
|
13 |
29 |
|
|
|
15 |
|
Pr. Rep |
|
|
20 |
30 |
|
|
|
22 |
|
|
|
|
27 |
|
|
|
|
29 |
|
|
|
|
Dez |
|
|
|
|
04 |
|
|
|
|
06 |
|
|
|
|
11 |
|
|
|
|
13 |
|
|
|
|
|
|
|
15-dez encerramento do semestre |
------
Enunciado do Trabalho Prático
Cada grupo, conforme instruções complementadas em sala de aula,
deve produzir uma aplicação para plataforma móvel,
com características de "jogos", os chamados "jogos sérios";
Isto pode ser enunciado com outra perspectiva: ludificação (“gamefication”) de
aplicações/aplicativos de ensino na educação terciária.
O conhecimento envolvido no Jogo deve corresponder aos conceitos de uma
disciplina de Engenharia de Software como, por exemplo, Requisitos,
Arquitetura,
Teste, modelos de maturidade da capacidade e Inspeção.
O trabalho é "descolado" do ritmo e assuntos das aulas da
disciplina,<<<<!<!<!<!<!<!<!<
mas deverá seguir a ideia dos “agilistas” de que é possível produzir
software funcionando em 30 dias
---
Software in 30 days
Ken Schwaber and Jeff Sutherland
2012, Wiley
-----
e que é possível soltar novas versões atendendo a requisitos adicionais
a cada 1, 2, 3 ou 4 semanas.
A avaliação é feita em termos de
(i)planejamento e acompanhamento do trabalho do grupo (70%)
(ii) produto elaborado (aplicação-app) (30%)
As notas são individuais baseadas nas avaliações do professor, monitor e colegas,
portanto cada membro não deve apenas “produzir”... deve também saber comunicar sua contribuição e
saber avaliar a contribuição dos colegas em relação ao todo. No nível mais elementar e mínimo
cada membro deverá avaliar em uma escala estilo de "Lickert", para cada colega do grupo,
a afirmação:
"Fulano trabalhou e comunicou, de maneira satisfatória, sua contribuição no avanço dos trabalhos":
1-Discordo fortemente
2-Discordo
3-Talvez
4-Concordo
5-Concordo fortemente
Deverão ser feitas apresentações (cada grupo de 10 a 15 minutos) nos dias
Apresentação 1:????- Plano de avaliação; Tema; requisitos
Apresentação 2: ?????
Apresentação 3:?????
Apresentação 4: ???? – Final
Ao longo do semestre serão estabelecidas outras “regulações” e esclarecimentos
------
Projetos de desenvolvimento de Sofware
Geekonomics: The Real Cost of
Insecure Software David Rice
SWEBOK SEBOK
Era assim agora é assado... Não quebramos as coisas mais...
