sexta-feira, 8 de junho de 2012

Banco de Dados para Concursos - Normalização

O objetivo da Normalização é evitar anomalias de inserção, deleção e atualização. Não é evitar joins ou melhorar performance.

Normalização de dados é a decomposição de esquemas para evitar anomalias de atualização. Uma boa modelagem evita redunância de dados e anomalias. Normalização é um mecanimos formal para analisar relações baseado nas chaves e dependências entre os atributos.

Uma relação em uma forma normal mais alta, está necessariamente em uma forma normal mais baixa. A ordem é a seguinte:

Relação qualquer, sem normalização < 1ª forma normal < 2ª forma normal < 3ª forma normal < FNBC (forma particular da terceira forma normal) < 4ª forma normal < 5ª forma normal e outras.

Uma relação na terceira forma normal encontra-se também na primeira e na segunda formas normais.

Primeira Forma Normal - 1FN
Foi definida para não permitir atributos multivalorados, compostos e suas combinações. Campos compostos podem ser exemplificados com o caso do endereço. Dependendo da semântica, um endereço pode precisar ser dividido em bairro, rua, número e cep. Se tudo isso estiver em uma só coluna e for necessário acessar essas informações separadamente, então, este é um atributo composto. Atributos multi-valorados podem ser exemplificados com o caso do telefone onde existe mais de um número de telefone em uma mesma coluna.

Pela definição de RELAÇÃO, para que uma tabela seja considerada uma relação, ela DEVE estar na primeira forma normal.

"Uma relação está na 1FN se e somente se todos os atributos contiverem apenas valores atômicos (simples e indivisíveis)"

Como resolver o problema dos campos multi-valorados (caso do telefone)? Cria-se uma tabela extra, chamada telefone e essa tabela terá dois campos, a chave estrangeira que vem da primeira tabela e o campo telefone. A chave primária da tabela telefone é composta pela chave estrangeira + campo telefone. 

Como resolver o problema do campo composto (caso do endereço)? Divíde-se este campo em vários campos.

As soluções ficariam formalmente representadas da seguinte forma:

pessoa (cpf, nome, cep, bairro, rua, numero)
telefone (cpf, telefone)
cpf referencia pessoa

Dependência Funcional
Uma coluna C2 depende funcionalmente de C1 (ou C1 determina a coluna C2) quando, em todas as linhas da tabela, para cada valor diferente de C1, sempre aparece um mesmo valor de C2 associado. C1 -> C2.

C1       C2 ... outros campos
A         1
B         2
A         1
C         4
C         4
B         2
D         4
E         1

Traduzindo: sempre que eu vejo um valor de C1, eu já sei qual é o valor de C2.

Exemplo do mundo real: CPF e nome. Sempre que eu vejo o CPF eu já sei qual é o nome. Então CPF determina o nome e nome é dependente funcional de CPF mas o contrário não é verdade, podem existir duas pessoas com o mesmo nome. CPF -> nome

É preciso tomar cuidado, porque em um universo restrito, onde os nomes são todos diferentes, podemos achar que o nome também determina o CPF simplesmente por não percebermos ou não encontrarmos nenhum nome repetido no conjunto de dados disponível.

A dependência funcional é utilizada para se determinar a chave primária da tabela.

Segunda Forma Normal - 2FN
"Uma relação encontra-se na segunda forma normal (2FN) se e somente se estiver na primeira forma normal e não contém dependências funcionais parciais"

Suponha uma tabela empregadoProjeto definida da seguinte forma:

empregadoProjeto (cpf, num-projeto, horas, nome-empregado, nome-projeto, local-projeto)

Reparem que CPF determina nome-empregado. Num-projeto determina nome-projeto e local-projeto e a combinação de CPF e num-projeto determina horas. Ou seja, a dependência não é total da chave primária inteira, alguns campos dependem de uma parte e outros campos dependem da outra parte da chave, existe dependência funcional parcial.


Qual é o problema dessa abordadem? Porque normalizá-la?
 Imagine que um funcionário trabalha em vários projetos. O nome e CPF desse funcionário vai aparecer várias vezes na tabela, uma vez para cada projeto em que ele trabalha. Como um projeto sempre é composto por vários funcionários, o nome do projeto e o local também vão aparecer várias vezes na tabela.

Se você quiser alterar o nome do funcionário, nome ou local do projeto, você terá que alterar em vários locais.

Se o funcionário não estiver trabalhando em nenhum projeto no momento e você excluir todas as tuplas onde ele aparece trabalhando, você irá exlcuir o empregado do seu banco de dados. Se você demitir todas as pessoas de um projeto para contratar outras pessoas, ao excluir essas pessoas você irá excluir também o projeto. 

O correto deveria ser o seguinte

empregado (cpf, nome-empregado)
projeto (num-projeto, nome-projeto, local-projeto)
trabalha (cpf, num-projeto, horas)
cpf referencia empregado
num-projeto referencia projeto

Dependência Funcional Transitiva
Acontece quando uma coluna depende da chave primária e também depende de outra coluna ou conjunto de colunas da tabela. Existe uma coluna não-chave que é funcionalmente determinada por outra coluna (ou conjunto de colunas) não-chave.

Exemplo:
empregado-departamento (cpf, nome-empregrado, endereco, numero-depart, nome-depart, gerente-depart)

Repare que o nome-depart e gerente-depart também são dependentes de numero-depart.

Terceira Forma Normal - 3FN
"Uma relação está na Terceira Forma Normal se e somente se estiver na Segunda Forma Normal e nenhum atributo não-primo for transitivamente dependente da chave primária" Atributo não-primo é um atrbituo que não é membro de uma chave primária.

Traduzindo: para estar na 3FN a relação não pode ter dependência funcional transitiva.

Qual o problema que acontece na 3FN?
O gerente do departamento aparecerá várias vezes na tabela. Se o último funcionário de um departamento for deletado, o departamento some.

Para estar na 3FN, o exemplo anterior deveria ser feito da seguinte forma:

departamento(numero-depart, nome-depart, gerente-depart)
empregado(cpf, nome, endereco, numero-depart)
numero-depart referencia departamento 

Anomalias de Inserção - Inserir um empregado repete dados de departamento.
Anomalias de Exclusão - Excluir o único empregado também exclui o departamento
Anomalias de Modificação - Mudar o gerente de departamento requer a alteração de várias tuplas (linhas)

Forma Normal Boyce Codd (FNBC)
Toda relação na FNBC está necessariamente na 3FN. "Uma relação está na FNBC se para toda dependencia funcional de X em Z (df X -> Z), X é super-chave" É como a 3FN, mas é mais restritiva.

Chave Primária é uma Super-Chave mínima.

Abaixo uma relação da 3FN que não está na FNBC:

Aula (aluno, disciplina, professor)

ALUNO   DISCIPLINA   PROFESSOR
Carlos       Inglês               Joana
Carlos       Física               Antônio
Adriana     Inglês              Joana
Adriana     Português        Marta
Rafael       Português        Manoel

1FN - Não possui atributo atômico
2FN - Não possui dependência funcional parcial. Aluno e disciplina determinam professor. A dependencia funcional não é parcial
3FN - Não possui dependência funcional transitiva. Professor é o único atributo não-primo (que não é membro de uma chave primária) e ele não determina nenhum outro atributo não-primo. A dependência transitiva aconetce quando um atributo não-primo determina outro-não primo.

O problema dessa relação é que professor determina a disciplina e professor não é uma super-chave (Com professor não conseguimos diferenciar as tuplas unicamente).

Se Carlos sair da aula de Física e seu registro for excluído, não teremos como saber que Antônio também dá aula de Física.

Para resolver o problema podemos criar duas tabelas:

T1 (aluno, professor) e T2 (professor, disciplina)

Quarta Forma Normal - 4FN (pouco cobrado)
"Uma relação está na Quarta Forma Normal, se e somente se, estiver na 3FN e não contiver dependências multivaloradas."

O termo a se lembrar é: não possui dependência funcional multivalorada.

Lembrar do caso de ISBN, autores e assuntos, todos na mesma tabela. O ISBN se relaciona de forma independete com o autor e com o assunto. Um ISBN está relacionado a um ou mais autores e um ISBN está relacionado a um ou mais assuntos. O problema é que um IBSN se relaciona de forma independente com assunto e com autor.

ISBN   ASSUNTO   AUTOR
123      Java               Zezinho
123      Java               João
123      OO                Zezinho
123      OO                João

Devemos separar em duas tabelas, uma como ISBN e Assunto e outra com ISBN e Autor

Quinta Forma Normal - 5FN (pouco cobrado)
Não pode ter Dependência Funcional de Junção. Algumas relações precisam ser decompostas para entrar na 4FN. Só que se isso for feito em apenas duas tabelas, como exemplificado na 4FN, pode acontecer perda de semântica. Se for o caso, então é preciso que a decomposição seja feita em 3 ou mais tabelas.

Nesse caso, quando o caso do IBSN é dividido em duas tabelas e não é possível saber todos os relacionamentos originais só com as duas tabelas criadas, aconteceu perda de semântica. Então coloca-se uma terceira tabela para relacionar as outras duas. (algo assim)

"Uma relação R está na 5FN, também chamada de forma normalizada de projeção (PJ/NF) se, e somente se, toda dependência de junção em R for consequência de chaves candidatas de R."

Não boa. Só se preocupe com isso se você já domina tudo de banco de dados e das outras matérias e se for uma prova de TI.

Resumindo o resumo
1FN - Apenas atributos atômicos.

2FN - Estar na 1FN e sem dependência funcional parcial (chave primária composta e algum atributo é parcialmente dependente da chave primária)


3FN - Estar na 2FN e sem dependência funcional transitiva (atributo não-chave determinando atributo não-chave) Onde está escrito não chave, na verdade seria não-primo (não participa de chave) .

FNBC - Estar na 3FN e não pode existir um atributo A determinando outro B e sendo que A não é super-chave.


4FN - Estar na 3FN e não pode existir dependência funcional multivalorada. Caso do ISBN.


5FN - Estar na 4FN e não pode existir dependência funcional de junção. Caso do ISBN, mas com perda de semântica.

quinta-feira, 7 de junho de 2012

RUP Para Concursos - Parte 8 - Disciplinas de Surpote


Disciplinas de Suporte - Gestão de Configuração e Mudanças
Controla as mudanças feitas nos artefatos de um projeto e mantém a integridade entre eles.

Na atividade de Gerenciamento de Solicitações de Mudança (CRM) você recebe as solicitações de mudança. Analisa em termos de impacto e risco, vê o custo benefício e aprova ou recusa a solicitação.

No Gerenciamento de Configuração você identifica os itens de configuração, que são todas aquelas coisas que possuem valor no ambito do seu projeto e que percisam ter a configuração controlda. Esses itens são armazenados em um respositório. É preciso manter esses itens de configuração armazenados, controlados e versionados.

Na Medição você gera relatórios a respeito das mudanças nos itens de configuração e com isso pode responder algumas questões gerenciais a respeito do processo de mudança e configuração. Quantas mudanças estão pendentes? Quanto tempo leva para uma mudança ser implementada?

Objetivos
Identificar e controlar itens de configuração

Restringir as mudanças nesses itens

Auditar as mudanças nos itens - checar se a baseline do projeto contém todos os itens de configuração necessários.

Evitar confusões de atualização simultânea - na fase de construção existem muitas equipes trabalhando em paralelo e isso evita que muitas pessoas atualizem o mesmo aretefato ao mesmo tempo.

Evitar Notificicação Limitada - uma pessoa atualiza um artefato que é de interesse de outras pessoas, mas elas não ficam sabendo dessa atualização.

Controle de Versão - controla as versões dos artefatos.

Benefícios

Estabilidade maior do produto, já que só as mudanças aprovadas são implementadas. Suporte a métodos de desenvolvimento porque várias equipes podem trabalhar ao mesmo tempo em um ambiente controlado. (isso precisa ser aprofundado)

Restrição de mudanças feitas nos artefatos, que seguem as políticas do projeto e uma trilha de auditoria que diz quando e por quem um artefato foi alterado. A gerência tem o controle dos artefatos do projeto.


Principais Papéis, Atividades e Artefatos.

Gerente de Configuração - Configura o ambiente de gerencia de configuração e estabelece as políticas dessa gerência.

Gerente de Mudanças - estabelece o processo de controle de mudanças e aprova ou não as solicitações de mudança.

Repositório do Projeto e As Solicitações de Mundança são os artefatos importantes.

Disciplina Gerenciamento de Projeto
Gerenciar pessoas, equipes, fases e iterações para executar e monitorar o projeto. Planejar o cronograma, gerenciar a qualidade e gerenciar os riscos do projeto.

Gerencia o tempo através do cronograma, os critérios de qualidade através do plano de gerenciamento de qualidade. Gerencia os riscos, que são mapeados na fase de iniciação, com a matriz de riscos e é criada a estratégia de mitigação dos riscos.

Gerenciamento de pessoal, contrato com fornecedores e gestão de orçamento não estão incluídos no RUP. Que recomenda o PMBOK para essas coisas. A visão do gerenciamento de projetos do RUP é limitada.

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou Planos de Fase que descrevem todo o projeto e uma série de alta granularidade ou Planos de Iteração que descrevem os passos iterativos.

Esta disciplina concentra-se principalmente em aspectos importantes de um processo de desenvolvimento iterativo: gestão de riscos, planejamento de um projeto iterativo através do ciclo de vida e para uma iteração particular, processo de acompanhamento de um projeto iterativo e métricas. No entanto, esta disciplina do RUP não tenta cobrir todos os aspectos do gerenciamento de projetos.

Principais Papéis, Atividades e Artefatos

Gerente de Projetos - Um papel atuante em todas as fases do RUP e com atuações diversas. Possiu várias atividades, dentre elas: planejar fases e iterações, identificar e avaliar os riscos, monitorar o andamento do projeto e etc. É o cara que resolve os problemas.

Plano de Desenvolvimento de Software, que é um planejamento macro do projeto.
Planos de Iteração - os planos para cada iteração
Lista de Riscos

Disciplina Ambiente
Configura o processo para o projeto de forma adequada a realidade da organização. Customiza o RUP. O que não é útil para a sua organização deve ser removido.

No Ambiente você seleciona e adquire as ferramentas que são úteis. Desenvolve ou adapta os templates para as outra disciplinas do projeto, também desenvolve e adapta os guias das atividades.

Oferece a organização para o AMBIENTE de desenvolvimento de software que dará suporte à equipe de desenvolvimento.

Principais Papéis, Atividades e Artefatos

Engenheiro de Processo - é quem vai configurar o RUP para a organização. Uma pessoa especialista no framework. É quem inicia o Caso de Desenvolvimento.

Especialista em Ferramentas - é quem seleciona, adquire e configura as ferramentas.

O Caso de Desenvovimento é o principal artefato e é o que configura o RUP para o seu contexto.
Descreve o processo de desenvolvimento que será usado pela organização. É a pesonalização do RUP adaptada ao projeto. É um documento dinâmico. É criado no início da fase de iniciação, mas é alterado durante todo o projeto. A cada iteração e fase, novas disciplinas são adicionadas a este documento.

Esta disciplina é uma das mais importantes e a ausência dela é uma das maiores falhas em projetos. Já que o RUP é grande demais.

RUP para Concursos - Parte 7 - Fase de Transição e Discipina de Implantação

Fase de Transição
Durante essa fase a ênfase é na disciplina de Implantação. Que é a disciplina que cuidaa da disponibilização do software para o usuário final. As outras disciplinas de engenharia possuem muito pouca ou nenhuma atividade.



Outra disciplina importante é a Gestão de Configuração e Mudança. Ela dá o suporte para se estabelecer as versões que são implantadas para os usuários finais e os itens de configuração de cada realease.

Mais de 70% do esforço é direcionado para a disciplina de Implantação. Quase tudo já deve ter sido feito nas disciplinas anteriores. O que sobra para a Transição deve ser apenas ajustes finos em função dos testes Beta (no ambiente do usuário).

O foco dessa fase é disponibilizar o software ao usuário final. Podem acontecer várias iterações e em cada uma delas o release é testado e os ajustes são feitos de acordo com o feedback dos testes.

O feedback do usuário deve ser em relação a ajustes finos, normalmente com relação a usabilidade e visual. Os problemas mais graves devem ter sido tratados nas fases anteriores. Não faz sentido mexer na arquitetura ou tratar questões de segurança neste momento.

Essa fase pode ser muito rápida, ou muito demorada e complexa, dependendo do tipo de produto e ajustes que devem ser feitos.

Teste Beta para validar o novo sistema. Os testes Beta são realizados para obter a aceitação do usuário, no ambiente real de produção e sem acompanhamento direto do desenvolvedor.

Treinamento de usuários e equipe de manutenção. Os usuários devem aprender a utilizar o sistema.

Atividades de ajuste: correção de erros, melhorias de desempenho e usabilidades.

Consentimento dos envolvidos dizendo que o software atende ao que se necessitava no início.

Principais Artefatos

Notas de Release (release notes) - textos informando o que mudou de uma versão para a outra, quais erros foram corrigidos e quais são as novas funcionalidades.

Artefatos de Instalação - tudo o que é necessário para instalação do softwares: scripts, arquivos de configuração e etc.

Material de Treinamento - Guias do usuário, manuais do sistema e etc.

Disciplina de Implantação

Objetivos
Coordenar e gerenciar os testes beta, que são testes de aceitação. A abordagem dos testes foi definida pela disciplina de Teste durante a construção, mas o gerenciamento dos testes é feito na Implantação.

Desenvolver os artefatos de instalação e materiais de treinamento.

Liberar para fabricação (liberação e instalação no ambiente alvo)

O RUP define 3 tipos de instalação do produto

- Instalação personalizada - necessita de configuração do ambiente para o usuário. É a mais complexa.

- Produto em uma forma compacta - disponibilizado em uma mídia para o usuário instalar

- Acesso ao software por meio da Internet - link para download do produto

Papéis, Atividades e Artefatos
Gerente de Implantação - é quem desenvolve o plano de implantação, tudo que precisa ser feito para a implantação, inclusive as notas de release.

Desenvolvedor do Curso - é quem prepara os materiais e guias de treinamento.

Implementador - é quem implementa os artefatos de instalação: instalador, arquivos de configuração, scripts de instalação e etc.

Artefatos: Builds do produto, notas de release, aretafos de instaslação e material de treinamento.

Relação com Outras Disciplinas

Requisitos - é a fonte principaal para elaboração de material de suporte e treinamento.

Teste -  testes são fundamenteias para a implantação do sistema e aceite do usuário.

Ambiente, Gerenciamento de Projeto e Gerenciamento de Configuração e Mudanças funcionam da mesma forma que nas outras disciplinas.

Marco da Implantação: Release do Produto
Implantação da versão 1.0 e depois decide-se se os objetivos foram todos alcançados e se deve existir outro ciclo de desenvolvimento para geração de uma nova versão, uma versão 2.0 por exemplo.

Critérios de Avaliacão
As despesas reais com recursos são aceitáveis quando se compara com o que foi planejado?
O usuário está satisfeito? O sistema atende às necessidades do usuário?

RUP para Concursos - Parte 6 - Fase de Construção e Disciplinas de Implementação e Testes

Nesta fase os principais requisitos já foram identificados e elicitados. O modelo de casos de uso está praticamente completo e a arquitetura já está definida.

Fase de Construção
Na fase de construção a ênfasa vai para as disciplinas de Implementação e Testes.

Essa fase demanda várias iterações e alto paralelismo na equipe. Por isso, o Gerenciamento de Configurações e Mudanças também possui muita ênfase durante a fase de Construção.

O esforço principal é centrato na Implementação e nos Testes, mas ainda podem existir casos de uso a serem especificados. E nessa fase é preciso esclarecer os requisitos restantes. A arquitetura também pode passar por evoluções e ajustes. Assim, as disciplinas de Requisitos e Análise e Design também possuem boa atividade.

A disciplina de Implantação começa a crescer e ter mais atividades. Nela são escritos os manuais de treinamento. As versões preeliminares dos manuais e guias começam a ser feitas na elaboração, mas é na construção que isso acontece com mais ênfase.

A conclusão do desenvolvimento acontece durante a construção com base na arquitetura definida na elaboração.

Segundo o RUP, é um processo de manufatura. Pega-se o projeto e implementa-se conforme projetado. (Na prática é BEM DIFERENTE)

Acontece também uma ênfase  no gerenciamento de recursos e controle de operações para alcançar maior produtividade e qualidade. Essas atividades fazem parte do Gerenciamento de Configuração e Mudanças. O ambiente pode ser caótico em projetos grandes e é preciso uma abordagem sistemática para gerenciar esta fase.

Objetivos
Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A palavra chave é eficiência.

Disponibilizar as versões úteis (alfa, beta e etc) com rapidez. Os testes ALFA são realizados durante a fase de Construção.

Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades.

Verificar e decidir se o software está pronto para implantação.

Principais Artefatos

O Sistema (disciplina de implementação) - O próprio sistema executável, pronto para iniciar os testes beta. Lembrando que os testes beta são executados na Transição.

Plano de Implantação - guia a equipe de implantação e transição para eles disponibilizarem o software. Essa é apenas uma versão inicial do plano, as versões finais são feitas na Transição. Em projetos menores o Plano de Implantação pode estar embutido no Plano de Desenvolvimento de Software.

Conjunto de Testes - Testes implementados e executados para validação e estabilidade das versões (releases)

Disciplina de Implementação

Objetivos
Codificar! Implementar o sistema com qualidade. A qualidade desse código depende da qualidade da Análise e do Projeto que foram feitos nas fases anteriores.

Implementar o código em subsistemas e camadass. As classes devem ser pensadas em termos de componentes para favorecer a reutilização do código.

Testar os componentes desenvolvidos como unidades (testes unitários). Testes unitários são feitos pelos desenvolvedores e não por testadores.

Integrar os componentes gerados pelos implementadores individualmente em um build único. O papel responsável pela integração é o Integrador.

Papeis, Atividades e Artefatos
Implementador - implementa os componentes e faz os testes unitários.
Integrador - integra os códigos e componentes do sistema em um build único.

Artefatos Importantes
O Sistema, Componentes, Builds

Relação Com Outras Disciplinas

Análise e Design fornece a principal entrada para a Implementação através do Modelo de Design (projeto). A implementação do código é feita a partir dessa entrada. Digramas de classes, sequência e etc.

Teste descreve como realizar o teste de integração de cada build. Os testes de integração e os testes Alfa são descritos pela disciplina de testes.

Implantação descreve como utilizar o Modelo de Implementação para empacotar e disponibilizar o sistema em um ambiente, além do preparo dos materiais de treinamento.

Ambiente e Gerenciamento de Projeto funcionam como nos outros resumos.

Disciplina de Testes
Busca responder as seguintes perguntas: você conseguiu implementar a solução que resolve o problema levantado anteriormente? Como você garante que esse código realmente resolve o problema?

Objetivos

Localizar e documentar defeitos na qualidade do software. Testes são feitos para encontrar defeitos e nunca garantem que o sistema está livre de defeitos.

Validar as suposições feitas nas especificações de design e requisito através de uma demonstração de fato. Fala-se que são suposições porque a certeza só aparece após os testes. No levantamento de requisitos os analistas estão supondo que estão fazendo tudo correto.

Validar as funcionalidades dos software de acordo com o projeto e verificar se os requisitos foram implementados de maneira correta.


Papéis, Atividades e Artefatos


Analista de Testes é quem elabora o Plano de Testes. É o plano que define os objetivos dos testes para cada iteração. Se for o caso, pode ser feito um único Plano de Testes Mestre, que serve para todas as iterações.

No Plano de Testes existem os objetivos, a abordagem dos testes (caixa branca ou preta), os tipos de testes (desempenho, funcionais, segurança, etc). O plano també informa quantas pessoas vão trabalhar com isso e quais serão os documentos gerados pelos testes.

Projetista de Testes é quem gera os Casos de Teste, que são gerados a partir dos cenários dos Casos de Uso. Os Casos de Teste são especificações de entradas e saídas, mas os testes ainda precisam ser implementados depois disso.

Testador é quem vai implementar e executar os testes.

Artefato Importante para o Marco - Conjunto de Testes - execução, geração de relatórios e logs de execução dos testes.

Relacionamento Com Outras Disciplinas

Requisitos - fornece os casos de uso para a geração dos casos de teste. Fornece a base para geração dos testes.

Análise e Design: fornece o projeto e a arquitetura que devem ser testados.

Implementação: produz os componentes e builds que serão testados.

As disicplinas de Suporte funcionam como nos outros resumos.
Ambiente: prepara os guias, padrões e ferramentas.
Gerenciamento de Projetos: planeja as atvividades de testes para a iteração.
Gerenciamento de Controle e Mudanças: controlar, gerencia e versiona os artefatos de testes.

Marco da Construção: Capacidade Operacional Inicial
O produto está pronto para ser passado para a equipe de Transição. Todas as funcionalidades foram desenvolvidas e os testes ALFA foram concluídos. Testes ALFA e BETA são testes de aceitação do sistema. O usuário testa o sistema para aceitá-lo.

Os testes ALFA são realizados no final da fase de Construção e conduzidos por um conjunto restrito dos usuários finais, os mais importantes e experiêntes. O teste acontece NO AMBIENTE DE DESENVOLVIMENTO. É um teste controlado.

O manual do usuário é produzido e existe uma descrição do release atual.

Critérios de Avaliação
O produto está estável para ser implantado? Os problemas mais graves foram identificados e resolvidos? O resultado está coerente com o planejado? Os envolvidos estão prontos para a Transição?


RUP para Concursos - Parte 5 - Fase de Elaboração e Discplina Análise e Design

Fase de Elaboração
O que muda entre as fases é ênfase que se dá em cada disciplina e o marco da fase. Na elaboração o foco é na disciplina de Análise e Design. Entretanto, pode ser que todas as disciplinas sejam de fato executadas em uma fase, dependendo do seu plano de iteração.

Na fase de Elaboração ainda existe muita atividade nas disciplinas Modelagem de Negócios e Requisitos. O esforço maior dessa fase é na Análise e Design, mas a Implementação já ocupa grande parte do esforço porque código executável já é gerado para garantir a arquitetura estabilizada. Também começam as atividades de Implantação.

A meta princpal da Elaboração é realizar os requisitos mais significativos do sistema, com grande impacto na arquitetura e desenvolver uma arquitetura exectuável (que funciona) e estabilizada, que garanta a continuidade do projeto. Esses casos de uso são chamados de Arquiterualmente Significativos.

A estabilidade da arquitetura é avaliada através de protótipos arquiteturais.

Ao final da fase de Elaboração é gerado uma baseline arquitetural. Baseline é uma versão revisada da arquitetura ou de algum artefato.

Objetivos da Elaboração

Garangtir que a arquitetua e os requisitos estejam estáveis para mitigar os riscos. 
"Ultrapassar esta marca (Elaboração) significa passar de uma operação de baixo risco para uma operação de alto custo e alto risco". Nas duas primeiras fases os custos são baixos, poucas pessoas estão envolvidas. Dessa fase em diante a equipe aumenta. O custo e risco passam a ser significativos.

Tratar todos os riscos significativos do ponto de vista do projeto.
É aqui onde os riscos são de fato tratados. O RUP entende que estabilizar a arquitetura é tratar riscos porque os piores casos de uso são implementados neste momento.

Selecionar componentes e criar planos de iterações detalhados para a fase de Construção
É preciso pensar quais componentes podem ser reutilizados no futuro.

Principais Artefatos 

Protótipos
São usados de uma maneira direta para reduzir o risco e elicitar requistos significativos. É a implementação de um conceito que precisa ser testado.

Documento de Arquitetura de Software
Fornece uma visão geral da arquitetura do sistema usando as 4+1 visões (resumos anteriores) da arquitetura.

Modelo de Projeto
Modelo de objetos que descreve a realização dos casos de uso. Mostra como implementar os casos de uso em termos de objetos com o passar do tempo. Usa muito os diagramas comportamentais e de interação da UML, mostra como acontece a comunicação entre os objetos do caso de uso. É uma abstração do modelo de implementação e código-fonte.

Modelo de Dados
Modelo de implementação que descreve a representação conceitual, lógica ou física dos dados persistentes no sistema.

Disciplina de Análise e Design (Projeto)

Objetivos
Transformar os requisitos em um projeto do sistema a ser criado. Os casos de uso são realizados em um projeto. Os casos de uso nunca dizem como fazer, mas apenas o que fazer. O projeto vai dizer como fazer, como realizar os casos de uso.

Desenvolver uma arquitetura refinada para o sistema.

Adaptar o projeto para que corresponda ao ambiente de implementação considerando restrições de técnologia.

O nome da disciplina é Análise e Design (projeto), mas as atividades são distintas: análisar e projetar. Análise significa entender o problema, normalmente sem considerar as tecnologias. São modelos conceituais, sem restrições técnológicas.

No projeto você cuida da solução e de modelos concretos para o problema. Leva em consideração as restrições técnológicas.

O RUP diz que as atividades de análise são opcionais e é possível ir diretamente para o projeto. A análise está mais próxima do negócio e é independente da tecnologia. O modelo de projeto é dependente da técnologia. Então, o Modelo de Análise pode ser aproveitado para o projeto em qualquer que seja a técnologia escolhida.

Principais Pepeis, Atividades e Artefatos

Arquiteto de Software
É o cara que projeta a arquitetura em cima dos casos de uso mais complexos. Tem uma visão ampla do projeto.

Designer ou Projetista
É quem analisa e projeta os casos de uso em termos de classes. Esse é o papel que entra nos detalhes de como os casos de uso serão feitos. Analisa os casos de uso, projeta os casos de uso e projeta os subsistemas.

Projetista de Banco de Dados
Gera os modelos lógicos e físicos da sua base de dados para guardar as entidades persistentes do sistema.

Protótipos
São feitos para provar ou esclarecer algum conceito. Podem ser categorizados de algumas formas:

Quanto ao que eles exploram:
Comportamentos - enfatizam a exploração do comportamento do sistema.
Estruturas - trabalham questões arquiteturais ou técnológicas do sistema.

Quanto ao seu resultado:
Exploratório ou descartável - utilizado esclarecer algum requisito complicado ou nebuloso e depois é descartado
Evolutivo - o protótipo é evoluído até se tornar o sistema de fato.

Documento de Arquitetrua de Software - Documento que descreve a arquitetura e é feito pelo arquiteto de software. Já foi explicado antes.

Modelo de Design (ou de projeto) - descreve as realizações dos casos de uso e serve como uma abstração do modelo de implementação. (modelos são agrupamentos) Esse modelo diz como as coisas serão implementadas.

Relação com outras disciplinas

Modelagem de negócio - Fornece o contexo organizacional para o sistema.
Requisitos - Fornece as funcionalidades CRÍTICAS a serem implementadas.
Testes - Testa o sistema projetado durante a disciplina Análise e Design
Ambiente - Gera guias de análise e projeto, etc (a mesma coisa para as outras disciplinas).
Gerenciamento de Projeto - Planeja as atividades da discplina (a mesma coisa para as outras disciplinas).

Marco da Elaboração: Arquitetura do Ciclo de Vida
É o segundo marco mais importante do projeto. Considera a arquitetura executável e a resolução dos riscos principais. Nessa fase os riscos são resolvidos de fato e a arquitetura deve funcionar.

Critérios de Avaliação
A arquitetura está estável e robusta para comportar os requisitos atuais e futuros?
Os riscos críticos foram resolvidos?
Os planejamentos de cronograma, orçamento e qualidade estão bem defindos? Neste momento é mais fácil dar precisão aos planejamentos porque os riscos já foram tratados.
Deve-se seguir com o sistema? (O RUP diz que esse é o momento de fechar o contrato, porque é quando a arquitetura foi estabilizada, na vida real o contrato é fechado antes.)