Portifolio Unopar

SUMÁRIO

1 INTRODUÇÃO 3

2 modelos de processos agéis vs modelos evolucionários 4

2.1 Métodos de processos ágeis 4

2.1.1 XP 5

2.1.2 SCRUM 5

2.1.3 MSF Agile 6

2.1.4 MSF Agile Software Development 4.0 7

2.2 Modelo de Processo de Software Evolucionário 7

2.2.1 Espiral 8

2.2.2 Incremental 9

2.2.3 Desenvolvimento baseado em componentes 9

2.2.4 SWEBOK 9

3 Entrevista com empresas desenvolvedoras de software 12

3.2.10 Design simples 18

4 CONCLUSÃO 32

REFERÊNCIAS 33

INTRODUÇÃO

Este trabalho tem como por objetivo abordar uma pesquisa bibliográfica sobre os Modelos de Processos Ágeis vs Modelos Evolucionários,suas principais características e especificações necessárias para o desenvolvimento e evolução do processo de engenharia de software. Eles devem ser analisados e aplicados pelo desenvolvedor, de acordo com os requisitos exigidos pelo cliente, fornecendo um software que atenda todas as funcionalidades do sistema que serão de extrema importância nas atividades desenvolvidas pela empresa.

- Considerando a técnica de Modelagem Entidade Relacionamento, explique com suas palavras o que são Entidades, Relacionamentos, Atributos, Cardinalidade, Administrador de banco de dados, modelo conceitual de dados, modelo lógico de dados e modelo físico de dados.

Entidades: São conjuntos de coisas ou objetos relevantes para o que quer representar ou armazenar de maneira concreta ou abstrata, que pode ser encontrado numa descrição textual na língua portuguesa geralmente como substantivos. Para cada elemento desse conjunto pode ser dado o nome de instância ou ocorrência.

Vejamos um conceito importante e interessante, mas que é fatalmente sonegado aos programadores, é o conceito de entidade. Basta tentar pesquisar por este termo, e notar como o conteúdo é escasso.

Talvez por isso, os

resultados são sistemas mal modelados, não normalizados, em que a aplicação tenta resolver diversos problemas da estrutura, e onde qualquer novo requisito, gera um grande transtorno, pois a análise para criação do modelo, não foi feita corretamente, de modo a deixar a estrutura robusta e expansível.

Um exercício rápido

• Volante, Pára-choque, Retrovisores, Câmbio, Chassis, Rodas, Motor, Portas…

O que lhe veio a mente? Qual objeto do nosso mundo agrega essas partes que citei? Espero que a sua resposta seja ‘um carro’. Faz parte do senso comum.

Mais uma vez

• Galhos, Folhas, Raíz, Tronco, Copa, Calotas..

Uma árvore? Só as ‘calotas’ que parecem não estar no lugar correto, pois não combinam com os outros itens, e não conseguimos imaginar que as calotas, devam pertencer a nossa árvore.

Melhor mover as 'calotas' para o 'carro' lá de cima, para se encaixar melhor em uma normalidade aceitável.

Ao iniciar o levantamento de informações, o processo é mais ou menos parecido com esse. O carro, e a árvore são as nossas entidades e cada um dos itens que citei, são os atributos particulares dessas entidades. A idéia é saber a quem deve pertencer cada atributo, e sermos capazes de definirmos as entidades do nosso sistema.

Formalmente

• Uma entidade possui atributos.

• Os atributos são as características e não devem conter um grupo de informações.

• Não existem entidades com menos de 2 atributos. Logo, cada entidade, é em si, um grupo de atributos.

Trazendo de forma livre para a nossa realidade, cada Entidade é uma tabela, e cada Atributo é cada uma das colunas dessas tabelas.

O ponto que quero levantar é a compreensão do conceito. Se tenho que fazer um cadastro de usuário, preciso pensar o que a entidade usuário significa para o meu sistema e o que

preciso saber dela ou não.

CREATE TABLE `test`.`usuario` (

`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,

`nome` VARCHAR( 50 ) NOT NULL

) ENGINE = InnoDB;

A nossa entidade usuario possui um `nome`, e um `id`, que é um identificador único desse objeto no nosso modelo.

Agora o cliente nos informa que ele precisa saber dos usuarios dele, pelo menos:

• um telefone residencial, e

• um celular.

Num primeiro momento, a nossa reação será adicionar essas informações à entidade usuário, pois o telefone e o celular pertencem respectivamente a cada usuário nosso.

ALTER TABLE `usuario` ADD `telefone` VARCHAR( 14 ) NOT NULL ,

ADD `celular` VARCHAR( 14 ) NOT NULL

[pic]

Mas se nosso chefe vem e nos informa que agora ele precisa também do Telefone Comercial do nosso usuário e quem sabe talvez um Telefone de Contato? É nesse momento que o nosso modelo pode naufragar ou não.

Adicionar mais essas 2 colunas a tabela seria um erro no ponto de vista da modelagem de negócios, pois estaríamos novamente, subestimando a aplicação. E se lá pra frente, ele decidir incluir o Pager (ainda usam isso? hahaha), ou o id Nextel do usuário?

Nesta hora, deveria começar a ficar claro que essa expansão clama por uma nova entidade na nossa modelagem.

ALTER TABLE `usuario` DROP `telefone` , DROP `celular` ;

Estrutura da nova entidade

[pic]

Dados cadastrados:

[pic]

Portanto, se precisamos de inserir mais formas de