quarta-feira, 18 de julho de 2012

DownThemAll trava e Quero Limpar Lista de Downloads

O problema é o seguinte: você deixou coisas demais para baixar no DownThemAll e ele travou. Agora, toda vez que você tenta abrir o gerenciador da ferramenta para baixar alguma coisa, o Firefox trava. Desinstalar a extensão é inútil.

Qual a solução? Limpar a lista de downloads do DownThemAll!

Como fazer isso? Moleza

Vá no menu do Firefox -> Histórico -> Limpar Dados Pessoais


Vai aparecer uma janela. Desmarque todas as opções e deixe apenas a última, que é Histórico e Fila do DownThemAll. Seu problemas acabaram, é só começar a usar novamente.

Gastei umas horas procurando onde apagar essa lista.

Alguém deixou um comentário aqui no blog dizendo o seguinte:

Em meu Firefox, versão 19 o procedimento é o seguinte:
1-No menu do Firefox clique em Ferramentas.
2-Clique em Ferramentas do DownThemAll.
3-Opções.
4-Na tela que abre, clique na aba Privacdade.
5-Marque as opções "Remover da lista os Concluidos" e "Remover da lista downloads cancelados e/ou com erros"

Pode ser que funcione, mas me lembro que, na época eu não conseguia abrir nada relacionado ao DownThemAll e a única forma que eu havia encontrado foi a que descrevi.

quinta-feira, 12 de julho de 2012

Erro PermGen space com Eclipse e TOMCAT? Resolvido

Você possui toneladas de memória na sua maquina e o TOMCAT insiste em dar o erro
javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space?

Vá na aba Servers, clique com o botão direito do mouse em cima do servidor e clique em Properties. Conforme a imagem.

Depois clique em Open lauch configuration na tela que aparecerá.


Aparecerá uma nova janela. clique na aba Arguments e no final do campo VM Arguments coloque a seguinte linha de comando: -Xms512m -Xmx1024m -XX:MaxPermSize=512m Se quiser, aumente o tamanho máximo do PermSize.


 Isso deve ser suficiete para o TOMCAT funcionar normalmente.

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.)

quinta-feira, 31 de maio de 2012

Engenharia de Requisitos para Concursos Parte 2 - Tipos de Requisitos

Tipos de Requisitos

Funcionais: Definem as funcionalidades do sistema. São as capacidades e serviços providos pelo sistema.

Não Funcionais: São as restrições aplicadas ao sistema ou qualidades específicas que o software deve ter. Exemplos: tempo de resposta máximo, quantidade de armezenamento e outras coisas.

De Domínio (coisa do Sommerville): Vêm do domínio (area de negócio) da aplicação do sistema e refletem características específicas do domínio. Algo mais relacionado ao domínio do que ao sistema. Depois são derivados em requisitos funcionais ou não funcionais.

Outros Tipos de Requisitos - Ponto de vista da evolução e manutenção. Visa saber quais requisitos são mais estáveis e quais são instáveis. Todos são modificáveis, mas alguns são mais propensos a mudanças do que outros

Requisitos Permanentes - Estáveis - (enduring): Estão diretamente ligados a atividade principal da organização. É pouco provável que sejam modificados por causa disso. São derivados do Modelo de Domínio. 

Requisitos Voláteis (volatile): São mais propensos a mudança. Se modificam quando o sistema está em desenvolvimento ou em uso. Requisitos resultantes de políticas governamentais fazem parte desse conjunto.

Os requisitos voláteis são divididos em 4 tipos:

Requisitos Mutáveis: se modificam por causa do ambiente do sistema. Ambiente onde o sistema está inserido. Sistemas que cuidam de impostos estão muito sujeitos a essas modificações.

Requisitos Emergentes: surgem à medida que a compreensão do cliente sobre o sistema se desenvolve. Só aparecerão durante o desenvolvimento.

Requisitos Consequentes: são resultado da introdução do sistema no ambiente do usuário. O usuário percebe a necessidade enquanto utiliza o sistema e esses requisitos são uma consequência do uso.

Requisitos de Compatibilidade: dependem de algum outro elemento. Equipamento, processo, componente, etc. Conforme outros elementos mudam, esses requisitos também mudam.

Requisitos Funcionais
Descrevem as funcionalidades ou serviços do sistema. Dependem da área de interesse relacionada ao software (domínio), dependem dos usuário e do tipo de software. Declaram as funções que o sistema deve fazer, seu comportamento, e ainda, o que o sistema NÃO deve fazer.

Podem ser escritos em alto nível, voltado para o cliente, ou podem ser especificados em detalhes para os desenvoldores.

Exemplos: o sistema deve permitir cadastros, gerar relatórios gerenciais, deve executar tarefas agendadas, etc. Tudo o que não é qualidade, atributo ou restrição do sistema, é considerado requisito funcional.

Requisitos Não Funcionais (RNF)
Definem propriedades, atributos, restrições e qualidades do software. E aí podemos colocar questões como usabilidade, confiabilidade, desempenho, manutenibilidade, escalabilidade, portabilidade. Exemplo: o sistema precisa ser fácil de usar, precisa se manter no ar por um tempo x, precisa ter tempo de resposta máximo e etc.

Segundo o Sommerville, os requisitos não funcionais NÃO se limitam a requisitos do produto, mas do sistema como um todo. Para este autor, o próprio processo, a linguagem de programação escolhida, ferramentas case e etc, também são considerados como RNF

Esses requisitos normalmente são mais críticos e adicionam mais complexidade do que os funcionais. Na grande maioria dos sistemas é assim, não é sempre. Acontece isso porque eles afetam diretamente a sensação de qualidade do usuário ao utilizar o sistema. O sistema é rápido? Está sempre disponível? Consegue suportar milhões de acessos ao mesmo tempo?

Tipos de Requisitos Não Funcionais

Requisitos de Produto: especificam que o software deve se comportar de determinada forma: confiável, robusto, rápido e coisas do tipo.

Requisitos organizacionais: são consequências das politicas, prodecimentos, processos, padrões adotados pela empresa que afetam o seu sistema.

Requisitos Externos: requisitos externos ao sistema, à organização e ao desenvolvimento. Leis e regulamentos do país por exemplo. A interoperabilidade, que é a capacidade de um sistema de se comunicar com outro sistema também é um exemplo.

Os requisitos não funcionais podem ser muito difíceis de especificar de forma precisa. Eles podem ser vagos, ambíguos, ou impossíveis de se verificar. Exemplo: o sistema deve ser fácil de usar.

RNF precisam ser VERIFICÁVEIS e mensuráveis. Deve existir alguma forma de medir objetivamente.

Muitas vezes os RNFs são conflitantes entre sí. Uma escolha de ter mais qualidade em uma determinada coisa pode significar menos de outra coisa. Exemplo: Sistemas em Java possuem portabilidade, por outro lado, costumam ser mais lentos. Interfaces muito elaboradas podem reduzir a manutenibilidade do sistema e por aí vai.

Formas de Medir um RNF

Propriedade Medida
Desempenho Transações por segundo; tempo de resposta para eventos, etc
Armazenamento  Megabytes armazenados.
Usabilidade Tempo de treinamento, número de cliques de mouse para executar uma função
Confiabilidade Tempo médio entre falhas, Taxa de ocorrência de falhas, Disponibilidade
Robustez Tempo para recomeçar depois de uma falha, Probabilidade de corrupção de dados em uma falha
Portabilidade Porcentagem de declarações dependentes de platarforma; Número de platarformas-alvo

Requisitos de Domínio
São derivados do domínio da aplicação. Descrevem características e funcionalidades do sistema que são reflexo do domínio envolvido. No final das contas deriavam para requisitos funcionais ou não funcionais. Na verdade, não serve para nada, mas o Sommerville classifica assim.

É algo extremamente específico daquele domínio. Detalhes técnicos da área que está sendo tratada.

Se não forem satisfeitos, podem inviabilizar o funcionamento do sistema ou sacrificar a qualidade. Bem óbvio, já que são funcionais ou não funcionais.

Eles são expressados na linguagem do domínio da aplicação, o que dificulta muito o entendimento do requisito. Imagine um sistema da bolsa de valores. Não é fácil especificar requisitos de domínios complexos. Muitas informações são táticas e não explíticas. Os especialistas da área acham aquilo tão óbvio que não comentam determinados requisitos.

Engenharia de Requisitos para Concursos - Parte 1

Bom galera, esse é mais um resumo que eu faço para os meus estudos. Esses também são baseados nas aulas do Pedrosa. Só lembrando que esses são os meus resumos. Usem como quiser, mas não me culpem por informações imprecisas.

Engenharia de Requisitos é a área da Engenharia de Software preocupada com os objetivos do mundo real para sistemas de software. É uma disciplina muito próxima do mundo real ou natural, próxima das necessidades do cliente. Também se preocupa com as funcões de sistemas de softwares (requisitos funcionais) e restrições em sistemas de software (não funcionais)

"Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema."

O objetivo final é gerar especificações precisas do comportamento do software e de sua evolução.

Os requisitos devem gerar uma concordância entre os clientes e a equipe de desenvolvimento, estabelecer o combinado, um entendimento sobre o que vai ser feito. Além disso, esses requisitos devem fornecer aos desenvolvedores uma compreensão melhor das funcionalidades do sistema a ser desenvolvido.

Por servirem como um entendimento sobre o que será feito, eles também informam, por exclusão, o que não será feito, então delimitam o escopo do sistema. Tudo o que está dentro do Modelo de Casos de Uso pode ser considerado como escopo do produto. Casos de Uso é a forma mais comum de especificação de requisitos, mas é pouco usado em metodologias ágeis.

Os requisitos fornencem a base para o planejamento das iterações, para estimar o custo e o tempo de desenvolvimento do sistema.

Definem uma interface para o sistema de acordo com as necessidades dos usuários. Os casos de uso sozinhos podem deixar dúvidas na cabeça dos usuários. Os protótipos de interface ajudam a clarear os requisitos. Isso gera requisitos de melhor qualidade.

Os documentos de requisitos precisam ser completos (todas as funcionalidades), consistentes, sem ambiguidades e corretos, com as reais necessidades do cliente. Normalmente os requisitos não são corretos porque o analista não consegue entender as necessidades do cliente.


A primeira caixa da figura mostra o Estudo de Viabilidade e como já estamos na especificação requisitos, o sistema já teria sido considerado viável.

A segunda estapa é a Elicitação e Análise de Requisitos. É onde se descobre os requisitos. A etapa mais imporante.

A terceira etapa é a Especificação de Requisitos, pega-se o que foi descoberto na Elicitação e é criada uma especificação formal e padronizada.

A quarta etapa é a Validação de Requisitos. É onde se verifica se os requisitos atendem as reais necessidades do cliente. Os clientes assinam a especificação e assim dão o aceite para a versão final do documento.

A figura tem o foco na geração dos requisitos. Depois ainda existe a etapa de Gestão de Requisitos que foca em gerenciar os requisitos depois que eles são gerados. Cuida da evolução desses requisitos.

Na prática, o processo de engenharia de requisitos é iterativo, pode haver sobreposição de atividades e o Sommerville fala isso. Reparem que as setas vão e voltam de uma etapa para outra.

"Requisito é uma condição ou uma capacidade com a qual o sistema deve estar de acordo." ou "Uma condição ou uma funcionalidade necessária a um usuário para resolver um problema."

Pode ser algo abstrato ou uma especificação matemática detalhada. Tudo depende do grau de detalhe dos requisitos, depende do seu público alvo.


Requisitos definem o que o sistema deve fazer e sob quais limitações deve operar.



O Sommerville define requisitos de 3 níveis:
Requisitos de Usuário: em linguagem natural e escrito para clientes leigos.
Requisitos de Sistema: são documentados formalmente, já para a equipe de desenvolvimento
Especificação do Software: Um terceiro nível que é a própria especificação do software, algo bastante detalhado, bem próximo no nível computacional. (isso precisa ser melhor estudado por mim)

Os stakeholders ou partes interessadas são as pessoas que podem ter interesse nos requisitos do sistema por algum motivo. Entre eles podemos citar os engenheiros de software do sistema, os usuários finais que irão usar o sistema, os gerentes da empresa, os especialista no domínio da organização em que o software será implementado e até mesmo fiscais externos para ver se o sistema satisfaz os requisitos legais.

Problemas com Requisitos

Os requisitos apresentam problemas e dificuldades para serem tratados. Eles podem vir de várias fontes diferentes e com interesses diferentes, então, é preciso compatibilizar esses interesses. Um erro comum é o requisito não refletir as necessidades reais dos usuários. É comum a fonte consultada não conhecer a nessecidade real do usuário. Essa fonte pode ser um cliente, mas não é será um usuário do software. Além disso, o analista pode entender as coisas de forma errada.

Outro problema é o requisito inconsistente ou incompleto. As vezes um requisito contraria outro requisito ou alguém esquece de colocar determinado requisito na especificação.

Poder ser muito caro alterar um requisito depois de longo tempo de execução do projeto. Quanto mais tempo um requisito permanece errado, mas caro será o seu reparo quando o erro for detectado e corrigido. Um erro corrigido durante a ênfase na condificação pode custar até 5 vezes mais. Se o produto já estiver em produção pode custar até 20 vezes mais.



Mal entendido entre clientes e analistas podem gerar erros de interpretação dos requisitos. O sucesso das etapas posteriores do seu software vai depender da qualidade dos requisitos gerados.




domingo, 27 de maio de 2012

RUP para Concursos Parte 4 - Fase de Iniciação e Disciplinas Modelagem de Negócio e Requisitos

As disciplinas do RUP podem ser executadas em qualquer uma das fases. A única exceção é a disciplina de implantação (deployment) que não é executada na fase de iniciação (inception).


Fase de Iniciação ou Concepção
Na fase de iniciação, a ênfase é nas disciplinas de Modelagem de Negócios e Requisitos que estão relalcionadas com definição de escopo, levantamento das necessidades e entendimento dos processos de negócio da organização. Os objetivos dessa fase e dessas disciplinas são semelhantes.

A maioria do esforço é feito na disciplina de Requisitos, mas na Iniciação você já pensa na sua arquitetura candidata para fazer uma análise de viabilidade e provas de conceito. Por isso, alguma coisa já será codificada e testada também.

A meta principal é atingir o consenso sobre os objetivos do ciclo de vida do projeto. Todos os interessados precisam chegar em um consenso. É uma fase muito importante para projetos novos, onde os riscos são desconhecidos. É preciso fazer análise de viabilidade, mapeamento de escopo e objetivos. Para Ciclos de Evolução, pode ser uma fase mais rápida e até mesmo uma fase opcional, caso a evolução seja simples.

Nessa fase você determina se continuar com o projeto compensa ou não. A análise de viabilidade não trata apenas de código, mas é preciso verificar se o projeto é financeiramente viável. Também é preciso fazer um estudo de viabilidade técnica. Quais tecnologias e arquiteturas devem ser usadas? É possível fazer o projeto nessas tecnologias?

Essas perguntas precisam ser respondidas para que a gerência possa determinar se vale a pena ou não executar o projeto.

Objetivos da Fase de Iniciação

Estabelecer o escopo do software: qual é o escopo do meu produto? Que requisitos considerar e quais deixar de fora? É determinado com o levantamento dos casos de uso.

Estimar custos: quanto vai custar o software? Isso é uma estimativa inicial. A cada iteração o custo é ajustado.

Estimar tempo : estimativa inicial de tempo. Também é ajustada a cada iteração.

Estimar riscos: identificar os casos de uso arquiteturalmente significativos (os mais críticos, complexos, arriscados e nebulosos) e principais cenários de operação do sistema.

Propor pelo menos uma opção de arquitetura para alguns cenários básicos.

Principais Artefatos da Fase de Iniciação

Documento de Visão (disciplina de Requisitos): descreve as necessidades e características mais importantes do sistema. Não é um artefato de engenharia de software. É um documento de alto nível que dá uma visão geral do sistema para o patrocinador do projeto, para servir como base para um contrato. Não possui informações técnicas ou arquiteturais. Também pode conter uma especificação de requisitos formal. Fornece informações para o processo de aprovação do projeto e, portanto, está intrinsecamente relacionado ao Caso de Negócio.

Caso de Negócio (disciplina de Gerenciamento de Projetos)
É um documento com informações do ponto de vista do negócio para determinar se vale a pena investir no projeto sobre o ponto de vista do retorno de investimento (ROI). Mostra a estimativa de custos. É este documento que vai basear a decisão do patrocinador de continuar ou não com o projeto.

Plano de Desenvolvimento do Software (disciplina de Gerenciamento de Projetos)
É como o Plano de Projeto do PMBOK e reúne as informações necessárias para o gerenciamento do projeto durante todo o ciclo do desenvolvimento.

Modelo de Caso de Uso
Descreve os requisitos funcionais de um sistema em termos de Casos de Uso e atores que interagem com os casos de uso. Determina o escopo do sistema. Contém as funções pretendidas para o sistema e serve como um contrato estabelecido entre os clientes e os desenvolvedores. O Modelo de Casos de Uso mapeia os casos de uso que existem e determina o escopo, logo, o que não está neste modelo, não deve ser feito.

O modelo de casos de uso é usado como fonte de informações essencial para atividades de análise, design e teste.

Glossário
Conjunto consistente de definições para evitar mal entendidos. Define termos importantes usados pelo projeto. Em muitos domínios, os termos não são simples e é preciso garantir que toda a equipe tenha o mesmo entendimento sobre os itens.

Disciplina Modelagem de Negócio
Entender a estrutura e a dinâmica da organização cliente ou organização-alvo, identificando oportunidades de melhoria. Trata de aspectos anteriores ao software. Antes de automatizar os processos da organização, é preciso entender o problema da organização. Sem isso, corre-se o risco de implementar um software que não resolve os problemas da empresa e não agrega valor nenhum.

Assegurar que todos os interessados tenham um entendimento comum sobre a organização.

Principais Papéis e Atividades:

Papel - Analista de Processo de Negócios
Identifica os processos na organização-alvo e descreve estes processos para entender como a organização trabalha. Depois define o que pode e deve ser melhorado. Em seguida propõe redesenho dos processos se for necessário. Ele está entendendo os processos de Negócio, não existe nada de software aqui.

Artefato Importante

Modelo de Domínio  (modelo de objetos de negócio)
Lembrando que um modelo é um agrupamento de artefatos. Inclui diagramas, especificações, entidades e etc.

É um modelo conceitual e mosta  os tipos de objetos mais importantes para o domínio. Como é um artefado da Modelagem de Negócio, que é anterior ao software, não mostra entidades do software, apenas entidades do mundo real, do negócio.

A figura acima mostra um diagrama de classes. Essas ainda são classes conceituais de entidade e controle.

Relação com outras Disciplinas

Requisitos
Utiliza o Modelo de Negócio como informação fundamental para entender os requisitos de sistema. Ou seja, os requisitos de sistema são derivados dos requisitos de negócio.

Análise e Design
Utiliza as entidades de negócio para identificar classes de entidade no projeto, que são as classes que representam a informação a ser armazenada.

Ambiente
Desenvolve e mantém artefatos de suporte como o Guia de Modelagem de Negócios, que é um padrão que mostra como executar as atividades de modelagem de negócio na organização.

Abmiente é uma disciplina que se relaciona com todas as disciplinas do RUP. É ela quem configura o RUP, estabelece guias, padrões e seleciona as ferramentas a serem utilizadas. Normalmente configura guias e padrões para as outras disciplinas.

Disciplina Requisitos
É uma das disciplinas mais importantes porque estrutura os casos de uso e o RUP é orientado a casos de uso. Estabelece o que o sistema deve fazer e define as fronteiras (escopo) do sistema, que são as funcionalidades descritas nos casos de uso.

Fornece uma base para planejar o conteúdo técnico das iteração e para estimar o custo e o tempo do desenvolvimento do sistema. Tudo isso baseado nos casos de uso.

Principais Papéis, Atividades e Artefatos:
Papel - Analista de Sistemas
É um dos papeis mais importante do RUP. Levanta os requisitos do sistema (Atores e CDU´s). Estrutura o Modelo de Casos de Uso e diagramas de casos de uso.

Papel - Especificador de Casos de Uso
O especificador é quem detalha a especificação dos casos de uso que foram elvantados pelo analista. Faz o passo a passo, detalha os fluxos e etc.

Artefatos Importante para o Marco

Glossário - Explicado acima

Modelo de Casos de Uso
Modelo das funções que são pretendidas pelo sistema. Serve como contrato entre o cliente e os desenvolvedores. Os requisitos funcionais do sistema são dispostos aqui agrupados em diagramas de casos de uso. Além disso, contém também as especificação dos casos de uso. Os requisitos não funcionais ficam em um artefato chamado Especificações Suplementares, também da disciplina de requisitos.

Documento de Visão - Explicado acima
Contém as necessidades e características mais importantes do sistema. Fornece uma base de alto nível para que o leitor possa compreender o sistema a ser desenvolvido. Não possui detalhes técnicos.

Relação com outras Disciplinas

Modelagem de Negócios
A Modelagem de Negócios fornece a entrada para a disciplina de Requisitos. Fornece as regras de negócio e um contexto organizacional para que os casos de uso sejam especificados.

Análise e Design
Usa a saída da disciplina de Requisitos como informações primárias dos requisitos para realizar os Casos de Uso. Mostra como os casos de uso se comunicam e se comportam. Pode encontrar falhas dos casos de uso.

Teste
Os Casos de Teste são gerados a partir dos casos de uso. Portanto, a saída dos requisitos é usada como entrada para validação do sistema. O que gera os objetivos do esforço de teste.

Gerenciamento de Configuração e Mudanças
Fornece o mecanismo de controle para as mudanças nos requisitos e isso se repete nas outras disciplinas. É basicamente o controle de versão dos artefatos.

Gerenciamento de Projeto
Usa o Modelo de Casos de Uso para planejar as iterações. É o Plano de Iteração.

Ambiente
Desenvolve e mantém artefatos utilizados nessa disciplina. É a mesma coisa para as outras disciplinas.

Marco da Fase de Iniciação: Objetivos do Ciclo de Vida
Marco é um resultado a ser alcançado. Um estado em que se encontra o projeto e onde alguns critérios precisam ser satisfeitos. São os critérios de avaliação da fase. É preciso responder sim a essas perguntas que estabelecem os critérios de avaliação.

Os casos de uso definem claramente o escopo? Que é o grande objetivo da fase de iniciação.

Caso necessário, foi possível fazer um protótipo da aquitetura? Se não foi possível, seu sistema pode não ser viável.

Todos os riscos foram encontrados? Se sim, foram mitigados? Os riscos precisam ser encontrados e deve existir um plano para tratar os casos de uso mais complicados.

Existe condição de se fazer o projeto? Todos os interessados, os técnicos, gerentes e usuários, precisam concluir que é possível fazer o projeto.

quinta-feira, 24 de maio de 2012

RUP para Concursos - Parte 3 - As 6 Melhores Práticas do RUP


Desenvolvimento Iterativo
É uma estratégia de resolução de problemas. Percorre-se várias vezes as disciplinas de engenharia durante o ciclo de vida do projeto. Cada iteração é uma passada pelas disciplinas e a cada uma delas a equipe aprende e ganha compreensão a respeito do projeto, dos requisitos e dos componentes. A arquitetura se torna mais robusta a cada incremento. É uma maneira mais flexível de desenvolvimento e impede que o risco seja acumulado para o final do projeto. O risco diminui com o tempo porque é percebido, avaliado e mitigado a cada iteração.

Lida com mudanças com mais facilidade. A cada incremento existe a chance de se verificar as mudanças nos requisitos e é possível se adaptar e replanejar o projeto. O replanejamento acontece a cada iteração.

Diminui os riscos porque são avaliados mais cedo. A cada iteração é possível integrar o código, verificar as interfaces e os usuário também poderão avaliar o que foi produzido para dizer se o caminho está correto.

Melhora a qualidade do software e a equipe aprende e melhora porque a cada iteração os usuários avaliam o que foi feito, passam o feedback e é possível corrigir os rumos do projeto. O conhecimento do negócio aumenta de forma mais precisa a cada interação com os usuários.

Aumenta o reuso porque é mais fácil pensar em reutilizar um componente que já está parcialmente ou totalmente implementado do que pensar em todos os componentes de forma antecipada. É quase impossível prever estes componentes apenas com os casos de uso especificados.

As iterações incorporam um conjunto quase sequencial das atividades. Só não é sequencial de fato porque algumas disciplinas podem não ser executadas em determinada fase.

Gerenciamento de Requisitos
Requisitos mal especificados, mal compreendidos e mal documentados geram problemas para TODO o projeto. Requisito é a necessidade e o propósito do seu cliente. É uma condição ou restrição com a qual o sistema deverá estar em conformidade. Não adianta implementar um requisito errado da melhor forma do mundo, porque isso não atende às necessidades do cliente. A forma como o requisito é entendido nem sempre é o que o cliente precisa e deseja.

Normalmente os requisitos se resumem a funcionais e não funcionais.

O RUP diz que o documento de requisitos deve ser feito de maneira clara. E o Gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis em um sistema. Além disso é preciso manter a integridade dos requisitos através da rastreabilidade.

Os requisitos possuem vários problemas: nem sempre são claros e podem vir de várias fontes diferentes. Cada fonte tem a sua visão e a sua prioridade. Duas fontes diferentes podem ter visões conflitantes. Além disso, existe uma interdependência entre requisitos diversos e os documentos devem tratar isso de forma consistente.

Cada requisito é diferente. A complexidade muda e a importância também. Alguns são simples e pouco importantes e outros podem trazer problemas para todo o projeto. É preciso identificar essa complexidade e tratá-los no momento certo do ciclo de vida do projeto.

Existem várias partes interessadas e pode haver conflito de interesses entre as essas partes. Além disso, o número de requisitos pode se tornar tão grande que fica impossível gerenciá-los.

Os requisitos são alterados a todo tempo.
Mudanças de requisitos identificadas tardiamente são as principais causas de insucesso nos projetos de desenvolvimento de software.

Como gerenciar essas dificuldades? Analisando o problema.
Entenda o "problema por trás do problema".
Estabeleça um vocabulário comum (UML e Glossário).
Proponha soluções em alto nível: nível de análise e não em nível de projeto.

Entenda a necessidade das partes interessadas e evite o desenvolvimento customizado
Todos querem algo. Determine qual é a melhor fonte dos requisitos, a fonte que realmente agrega valor. Utilize técnicas de elicitação de requisitos. Faça acordos, balancie prioridades, ou seja, negocie com as partes interessadas para saber o que é crítico, o que é importante, o que é desejável e dispensável. Alguns requisitos são fundamentais para entrada em produção. Outros não.

Defina o sistema.
Defina o que o sistema deve fazer, em termos gerais, utilizando linguagem natural e linguagem gráfica (UML).

Gerencie  o escopo do sistema
Tudo o que está no Modelo de Casos de Uso faz parte do escopo do sistema. O que está dentro? e fora? Estabeleça as prioridades para selecionar o que entra e o que sai.

Gerencie os requisitos variáveis
Garanta que os requisitos tenham uma estrutura que os tornem facilmente atualizáveis (utilize referências em seus documentos de casos de uso). Rastreie as mudanças em seus requisitos. Toda vez que uma mudança afetar um requisito ela deve ser analisada, o impacto e os riscos devem ser considerados e só poderá ser executada se aprovada após a análise. Mudanças sem análise não devem ser implementadas.

Os Casos de Uso guiam o desenvolvimento
O RUP recomenda a utilização de Casos de Uso como método para a organização dos requisitos funcionais. Assim você consegue organizar uma visão de como o usuário enxerga o sistema.

Os casos de uso definem um conjunto de cenários e cada cenário descreve o comportamento do sistema em uma sequência de ações. Esses cenários devem produzir um resultado de sucesso ou de erro de valor observável para um ator.

Atores são entidades externas que se relacionam com o seu sistema. Podem ser pessoas, outros sistemas e etc.

Quem utiliza os casos de uso? Os clientes utilizam para compreenção do comportamente do sistema e para aprovação do funcionamento antes da implementação. Os arquitetos analisam os casos de uso para definir a arquitetura do sistema logo na fase de elaboração. Os analistas, projetistas e programadores para entender o comportamento do sistema, refinar e implementar. Os casos de testes também são gerados a partir dos casos de uso. O gerente utiliza para acompanhar o progresso do projeto e por aí vai. Por isso se diz que o RUP é guiado por Casos de Uso

Arquitetura de Componentes
A arquitetura é a estrutura organizacional do software. Segundo o RUP é "a sua organização ou estrutura de componentes significativos que interagem através de interfaces". A arquitetura de um sistema reflete as grandes decisões a respeito da implementação. Diz em quantas camadas o sistema é feito, quais frameworks são utilizados, quais padrões de projeto foram implementados e coisas do tipo. E o RUP dá grande ênfase à arquitetura.

Segundo o RUP a arquitetura do software inclui: As decisões significativas sobre a organização de um sistema. A seleção dos elementos estruturadores e suas intefaces, a especificação dos elementos do sistema e como eles colaboram entre si.

A arquitetura não se preocupa apenas com estrutura e comportamento, mas também com funcionlidades, desempenho, segurança, reuso, manutenibilidade, decisões técnológicas e econômicas. Por isso os requisitos não funcionais, podem influenciar fortemente na decisão da arquitetura.

O que é um Componente?
É uma parte independente do seu sistema. Grupos de código coesos com interfaces e comportamentos bem definidos. Possui forte encapsulamento de conteúdo. Pode ser substituído por outro. Os componentes se comunicam através de suas interfaces visíveis e um nunca conhece o comportamenteo interno do outro.

Vantagens
Permite reuso em grande escala. Por serem independentes e coesos, podem ser usados diversas vezes e em sistemas diferentes. O caso do Hibernate é clássico: um componente para mapeamento OO-Relacional que é utilizado em praticamente todos os sistemas de software web em java atualmente.

Bom gerenciamento da complexidade do projeto e mantém a integridade do sistema. A separação em componentes permite que os problemas sejam tratados de forma separada, já que eles são isolados. Isso identifica, isola, projeta, desenvolve e testa as partes bem formadas do sistema em separado.

É possível utilizar componentes de prateleiras disponíveis no mercado.

Visões Arquiteturais
No RUP a arquitetura é representada por uma série de visões de arquitetura diferentes. São perpectivas diferentes da arquitetura. Conhecido como modelo de visão 4 + 1 porque são 5 visões disponíveis. Seria como a construção de uma casa, ondem existem vários projetos diferentes. Um arquitetônico, um de instalações elétricas, um de hiráulica e etc.

Visão Lógica ou Visão de Projeto descreve as principais classes no projeto do sistema. Define as classes de projeto mais importantes, a organização em pacotes e subsistemas, e a organização destes pacotes em camadas. É uma das principais visões e é obrigatória. Os diagramas de classes, sequencia e pacotes aparecem muito nesta visão.

Visão de Implementação contém a organização em termos de módulos, pacotes e camadas. É uma visão opcional que entra nos detalhes da Visão Lógica. Descreve o código da sua aplicação. Tudo o que foi gerado a partir do projeto. Visão mais detalhada do projeto do sistema.

Visão de Processos descreve o ascpecto simultâneo do sistema. As tarefas (processos e threads) que são concorrentes devem ser definidas nessa visão. Só deve ser usado caso o sistema possua alto grau de paralelismo. Por isso é opcional.

Visão de Implantação descreve como serão as configurações das instalações físicas do sistema. Contém a descrição dos vários nós físicos do sistema e a aloção de taréfas atribuídas a eles. É uma visão opcional, que pode ser usada quando o sistema for distriuído.

Visão de Caso de Uso é uma visão externa, o ponto de vista do cliente a respeito da perspectiva funcional. Contém os casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes, ou riscos. É uma visão obrigatória do documento de arquitetura.

Modelagem Visual (UML)
Fazer uso de notação gráfica para exibir o projeto do software. A linguagem gráfica permite que o nível de abstração seja aumentando, escondendo detalhes e faciliando a comunicação com os clientes. Um usuário não consegue entender o código e a linguagem escrita é muito ambígua para isso. Essa notação visual também adiciona precisão à captura dos requisitos. Como a ambiguidade é reduzida, acontece uma melhora na comunicação da equipe.

O RUP determina o uso da UML (Unified Modeling Language)
UML é uma notação padrão para modelagem de software. Oferece diferentes perspectivas de um problema: estática, dinânima, colaborativa e etc. Ajuda a manter o projeto (os diagramas) e o código consistentes.

Os artefatos UML possuem suporte das ferramentas automatizadas recomendadas pelo RUP para ajuda na produtividade da equipe.

Verificação da Qualidade
Qualidade não é algo pontual, não deve ser verificada apenas no fim ou em pontos específicos, mas em todo o seu projeto de forma contínua. "A característica de ter demonstrado a realização de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados".

Você deve estabelecer os critérios de qualidade anteriormente, já com critérios de medida. Para ter qualidade, o produto precisa, no mínimo, atender esses critérios que foram estabelecidos.

O RUP prevê duas atividades para assegurar a qualidade do produto.

Controle de Qualidade
Tem foco no produto e encontra defeitos específicos. Faz o teste no que foi gerado, no final. Verifica se existe um defeito naquilo que foi produzido.

Garantia da Qualidade
O foco fica nos processos e na execução deles. Garante que você está fazendo as coisas de maneira certa. Pode ser alcançado com utilização de boas práticas de mercado e etc.

Qualidade é multidimensional e possui vários critérios ou dimensões.
Andamento: o progresso do projeto.
Variação:  diferença entre planejado e executado.
Confiabilidade: o quanto seu produto é confiável?
Funcionalidade: os casos de uso foram implementados corretamente?

Desempenho: o desempenho está adequado às necessidades.

Muitos outros critérios podem ser utilizados para medir a qualidade, mas o importante é que esses critérios sejam definidos antes da execução do projeto, para que não sejam adaptados para dar uma falsa ideia de qualidade no final de tudo.

A verificação da qualidade é importante porque o custo de uma correção sobe exponencialmente com o passar do tempo. Os defeitos corrigidos após implantação custam muito mais caro do que a correção durante o desenvolvimento. A verificação da qualidade diminui os custos e os riscos.

Gerenciamento de Mudanças
Sempre que existe muito paralelismo no projeto, é preciso controlar o ambiente. Quando existem vários desenvolvedores e equipes, diferentes locais de desenvolvimento, muitas iterações, releases, produtos e plataformas heterogêneas, se não existir um controle disciplindo do processo de desenvolvimento, o projeto tende ao caos rapidamente.

Item de Configuração
Uma entidade que satisfaz algum propósito para o usuário final e que pode ser unicamente identificado. Podem ser código-fonte, especificações, modelos, artefatos e etc.

Primeiro é preciso identificar quais são esses itens que necessitam estar sob a Gestão de Configuração.

Gerenciar Mudanças é utilizar uma abordagem sistemática para avaliar, decidir sobre as mudanças e coordená-las. É o processo de coordenar, avaliar e decidir sobre a realização de mudanças propostas naqueles itens que estão sendo gerenciados.

Apenas as mudanças aprovadas são implementadas nos itens de configuração, nos dados e documentos relacionados. É preciso avaliar o impacto, pertinência e o custo-benefício antes de aprovar.

No RUP existem as atividades de :
Coordenação de atividades e artefatos: procedimento repetíveis para gerenciar as mudanças nos artefatos.

Coordenação de iterações e releases: controle sobre os releases ao final das iterações. (baseline)

Controle de mudanças no software: mantém uma estrutura bem definida para grenciar mudanças no software.

terça-feira, 22 de maio de 2012

RUP para Concursos - Parte 2 - Metodologia e Conceitos Chave

Metodologia
É composta por um Processo de Desenvolvimento que é configurado especificamente para a sua organização. É composta por um conjunto de métodos e práticas bem definidos e que possuem responsáveis (papéis), entradas, saídas e ordem de precedência. Inclui ferramentas, tecnologias, pessoas, padrões e guias.

Ao instânciar um processo de desenvolvimento baseado no RUP, o que se está procurando é definir quem faz (papéis)o que é feito (produtos de trabalho) , como é feito (descrições das tarefas) e quando é feito (fluxos de trabalho). Nas disciplinas existem papéis que executam determinada tarefa ou atividade que resulta em um produto de trabalho ou artefato. Um exemplo seria a disciplina de Requisitos possui o papel Analista de Sistemas que deve executar a tarefa Estruturar Modelo de Caso de Uso e o produto de trabalho gerado será o Modelo de Caso de Uso.

Você terá uma metodologia baseada no RUP e não a metodologia RUP em sí. A organização deve pegar o RUP e adaptá-lo de acordo com as necessidades e assim, criar o seu próprio processo de desenvolvimento de software.

A metodologia conta com alguns componentes: Modelos, padrões, guias, equipes treinadas, linguagem padrão (UML) e ferramentas de automação.

Benefícios da Metodologia embasada no RUP:  

Qualidade de Software através da utilização das melhores práticas de mercado, que já foram testadas e comprovadas.

Maior produtividade e Previsibilidade porque as equipes seguem um processo definido, o que evita conflitos dentro do projeto. As pessoas já sabem quem faz qual atividade e quando fazer.

As características acima, o controle de riscos e a disciplina de gerência de projetos do RUP levam a um Maior controle sobre custos e prazos.

Conceitos Chave do RUP

As 4 Fases do RUP
São as etapas dos projeto de desenvolvimento com base no RUP. (1º eixo, Eixo Dinâmico do Gráfico das Baleias). Cada fase termina com um marco.

Concepção / Iniciação
Determinar o escopo do projeto para que seja possível estimar custos e riscos do projeto. É gerado um macro-planejamento. Estima-se o tamanho do projeto, os custos e os riscos. São definidos os objetivos que a organização pretende alcançar com o projeto. Todas as partes interessadas devem entender os objetivos a serem alcançados.

Elaboração
Assegura que os principais riscos foram diminuídos e uma arquitetura estável foi definida. Dentre os casos de uso, que foram definidos na fase anteior, aqueles mais arriscados, importantes e complexos são identificados e implementados para garantir que a arquitetura está adequada. Isso já reduz o risco do projeto. O marco é a aquitetura do projeto estabilizada.

Construção
Desenvolver o produto de forma iterativa e incremental para a Transição. 20% dos casos de uso foram detalhados e implementados até a fase de Elaboração. Aqui os outros casos de uso são implementados. Nessa fases as equipes trabalham muito em paralelo e com velocidade. O marco da fase é o build estabilizado do sistema ou a capacidade operacional inicial. O produto deve ser capaz de ser operado.

Transição
Disponibilizar o software para o usuário final. Assegurar que o sistema esteja disponível e funcionando corretamente. Inclui documentação do sistema, guias do usuário e etc. O marco é o lançamento do produto.

As fases não são idênticas em termos de esforço e tempo gasto. Abaixo estão alguns números mágicos da metodologia.

  Iniciação Elaboração Construção Transição
Esforço ~5 % 20 % 65 % 10%
Programação (Cronograma) 10 % 30 % 50 % 10%

É possível ver que a fase Construção é a que consome maior tempo (50%) e maior esforço (65%).

Uma passada pelas quatro fases é chamada de Ciclo de Desenvolvimento e gera uma primeira versão do seu software, o que seria a versão 1.0. Uma próxima versão, de evolução do software, seria a versão 2.0. Essa segunda parte é considerada um novo ciclo e é conhecida como Ciclo de Evolução.

Durante o Ciclo de Evolução a ênfase nas fases não é a mesma do Ciclo de Desenvolvimento. Na maioria dos casos, os riscos já são conhecidos e arquitetura já está estabilizada, então, a fase de elaboração, por exemplo, será menor.

Iterações
"Uma sequência distinta de atividades que resulta em um release do seu produto". Uma iteração é uma passada pelas 6 disciplinas de ENGENHARIA do seu projeto. As iterações podem ser consideradas como mini-projetos em cascata.

As 6 disciplinas de engenharia são: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste e Implantação.



A cada iteração as atividades de cada disciplina são executadas e no final é gerado um produto de trabalho (release), que é um incremento no sistema. Pode ser um release interno (para a equipe ou usuários específicos) ou um release externo (para os clientes). Para que o release seja liberado, é perciso estar estabilizado de alguma forma. Para isso é criada uma baseline. A baseline é o estado estável e aprovado que libera o release.

Cada fase possui várias iterações. O que muda de uma fase/iteração para outra é a enfase que é dada nas disciplinas. Durante a passagem por uma disciplina pode não haver necessidade de executar nenhuma atividade de uma disciplina específica. Isso acontence principalmente no início e no fim do projeto.

Disciplinas
Conjunto de atividades (fluxo de trabalho) relacionadas a uma área de interesse do projeto para geração de resultados. As disciplinas do RUP lembram as fases do modelo em cascata, porque são as atividades técnicas que são executadas durante o projeto. Detalham como executar as atividades, quem executa e quais produtos de trabalho são gerados após a execução das atividades.

Algumas disciplinas estão associadas a conjuntos específicos de modelos e os modelos são conjuntos de artefados. Cada disciplina possui seu próprio fluxo de trabalho, que é um diagrama de atividades da linguagem UML.

Disciplinas de Engenharia
Modelagem de Negócios
Requisitos
Análise e Projeto
Implementação
Testes
Implantação

Disciplinas de Suporte
Gerenciamento de Projetos
Gerenciamento de Configuração e Mudanças
Ambiente

M-RAITIGGA

Papéis
Definem o comportamento e as responsabilidades em um processo. Dentro de uma disciplina, os responsáveis por executar as atividades são os papéis. Exemplos de papéis são: programador, testador, gerente de projeto, arquiteto e etc.

No final das contas, os papéis acabam associados a um ser humano, mas a definição de um papel trata de um comportamento e de um conjunto de responsabilidades. Uma pessoa pode executar um, nenhum ou vários papéis.

Tarefas ou Atividades
Uma unidade de trabalho desempenhada por um papel. Algo que um papel faz e produz um resultado dentro do contexto de uma disciplina. São compostas por: finalidade, passos, entradas e saídas, papel responsável, além de guias e padrões para auxiliar a execução. 

Produtos de Trabalho
São o resultado de um processo de trabalho utilizados como entradas e/ou saídas na execução das atividades. São divididos em artefatos (termo genérico), entregáveis (os que são entregados aos clientes) e os resultados (outcomes), que são produtos intangíveis, representam o alcance de algum objetivo. No geral, produtos de trabalho são chamados de artefatos.

Podem ser: modelos, documentos, código fonte, executáveis, etc

Resumindo: Papéis executam Tarefas que geram Artefatos.
Exemplo: O Especificados de Requisitos (papel) executa Atividade chamada Detalhar Caso de Uso e gera um artefato, que é o próprio Caso de Uso.

Um ciclo de vida de desenvolvimento no RUP é a passagem pelas quatros fases: Iniciação, Elaboração, Construção e Transição. Cada fase possui seus objetivos próprios e são delimitadas por marcos. Quando uma fase é executada e seus objetivos são alcançados, o marco é alcançado. Cada fase pode ter N iterações, que são as passadas sequenciais pelas 6 disciplinas de engenharia do projeto. Dentro das disciplinas existem os papéis que executam as atividades e geram artefatos.