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/

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

 

http://www.governoeletronico.gov.br/sisp-conteudo/nucleo-de-contratacoes-de-ti/perguntas-frequentes/contratacao-de-ti

 

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

 

Apresentação 2, Cap. 6, 7, 8, 9, 10, 16, 17, 18, 19, 20, 21

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

 

Apresentação 3 Requisitos e Análise

16

21

S Conh

Arquitetura-Desenho-Implementação Cap. 8, 18, 19

18

22

S.Conh

 

23

23

 

Prova 2 Apresentação 3

25

24

 

 Revisão Prova 2

30

25

 

Revisão

Nov

 

 

 

01

26

 

Revisão

06

27

 

Revisão

08

28

 

 Prova 3

13

29

 

Apresentação 4; Revisão

15

 

Pr. Rep

 

20

30

 

 Revisão final- Apresentação 4

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

 

cmm cmmi versões

 

Geekonomics: The Real Cost of Insecure Software David Rice

SWEBOK  SEBOK

Era assim agora é assado... Não quebramos as coisas mais...