Post on 01-Jul-2015
description
1. Histórico e Conceitos
2. Melhores práticas
3. Fases
4. Disciplinas
O RUP, Processo Unificado Racional é um processo proprietário deEngenharia de software criado pela Rational Software Corporation,adquirida pela IBM, ganhando um novo nome IRUP e tornando-seuma brand na área de Software, fornecendo técnicas a seremseguidas pelos membros da equipe de desenvolvimento de softwarecom o objetivo de aumentar a sua produtividade no processo dedesenvolvimento.
O RUP usa a abordagem da orientação a objetos em sua concepção eé projetado e documentado utilizando a notação UML (UnifiedModeling Language) para ilustrar os processos em ação. Utilizatécnicas e práticas aprovadas comercialmente.
O RUP é, por si só, um produto de software. É modular eautomatizado, e toda a sua metodologia é apoiada por diversasferramentas de desenvolvimento integradas e vendidas pela IBMatravés de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluemo "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) comoa Programação Extrema (XP), Scrum, FDD (Desenvolvimento Guiadopor Funcionalidades) entre outros.
Objetivo é assegurar a produção de software de alta qualidadedentro de prazos e orçamentos previsíveis (Kruchten 2003, pág. 14)
O RUP define perfeitamente quem é responsável pelo que, como ascoisas deverão ser feitas e quando devem ser realizadas,descrevendo todas as metas de desenvolvimento especificamentepara que sejam alcançadas.
Oferece uma abordagem organizada em disciplinas para atribuirtarefas e responsabilidades dentro de uma organização dedesenvolvimento.
Melhores Práticas Desenvolver software iterativamente
Gestão de requisitos
Uso de arquitetura baseada em componentes
Uso de software de modelos visuais
Verificação da qualidade do software
Gestão e Controle de Mudanças do Software
Desenvolver Software IterativamenteDesenvolver iterativamente significa desenvolver em ciclos. Cadaciclo é contém um objetivo que deve ser alcançado (lançamento deum pré release ou beta, correção de um bug, etc.)
Esta prática acaba dando ao RUP uma série de vantagens, como:
Possibilidade de identificar/modificar requerimentos com maisfacilidade;
Integração progressiva (quase continua) de elementos aosoftware, ocasionando uma melhora no descobrimento eendereçamento de riscos;
Desenvolvimento iterativo provê aos gerentes maneiras defazer mudanças táticas aos produtos; etc.
Gestão de Requisitos
O gerenciamento de recursos acarreta um melhor controle sobreprojetos complexos, além de maior qualidade e redução de custos.
O RUP é uma metodologia dirigida-a-casos-de-uso (use-drivencase), de modo que é possível utilizar os mesmos casos deuso definidos no sistema como base para o resto do processo.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.
Arquitetura Baseada em Componentes
Um componente normalmente se relaciona com um objeto naprogramação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo desistema, focando-se em produzir uma arquitetura executável nasfases iniciais do projeto, ou seja, antes de comprometer recursos emlarga escala.
Estes componentes são normalmente incluídos em infraestruturasexistentes como o CORBA e o COM (Modelo de Componentes deObjetos).
Uso de Software de Modelos Visuais
A modelagem visual permite melhor entender não só a concepção e acomplexidade do sistema, mas também “dimensionar” (no sentido dequal a forma do sistema), além de facilitar a identificação e soluçãode problemas.
Verificação da qualidade do softwareNão assegurar a qualidade do software é a falha mais comum emtodos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou aqualidade é responsabilidade de uma equipe diferente da equipe dedesenvolvimento.
O RUP não toma a qualidade como responsabilidade de apenas umapessoa ou grupo, mas como uma responsabilidade de todos osintegrantes do projeto.
A qualidade é focada especialmente em duas áreas: Qualidade de produto: Sendo desenvolvido (software ou sistema) etodos as partes envolvidas (componentes, subsistemas, arquitetura).
Qualidade de processo: Dentro do projeto de desenvolvimento.
Gestão e Controle de Mudanças do Software
Em todos os projetos de software a existência de mudanças éinevitável. O RUP define métodos para controlar e monitorarmudanças. Como uma pequena mudança pode afetar aplicações deformas inteiramente imprevisíveis, o controle de mudanças éessencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a umprogramador que as mudanças efetuadas noutro sistema nãoafetarão o seu sistema.
Fases de Desenvolvimento
Até agora estas linhas de guia são gerais, a serem aderidas aopercorrer do ciclo de vida de um projeto. As fases indicam a ênfaseque é dada no projeto em um dado instante. Para capturar adimensão do tempo de um projeto, o RUP divide o projeto emquatro fases diferentes:
1. Concepção: ênfase no escopo do sistema;
2. Elaboração: ênfase na arquitetura;
3. Construção: ênfase no desenvolvimento;
4. Transição: ênfase na implantação.
Fases de Desenvolvimento
O RUP também se baseia nos 4 Ps:
1. Pessoas2. Projeto3. Produto4. Processo
As fases são compostas de iterações. As iterações são janelas detempo; as iterações possuem prazo definido enquanto as fases sãoobjetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximasfases e documentam o projeto, além depermitir melhor acompanhamento.
Fase de Concepção
Esta fase do RUP abrange as tarefas de comunicação com o cliente eplanejamento.
É feito um plano de projeto avaliando os possíveis riscos, asestimativas de custo e prazos, estabelecendo as prioridades,levantamento dos requisitos do sistema e preliminarmente analisá-lo. Assim, haverá uma anuência das partes interessadas na definiçãodo escopo do projeto, onde são examinados os objetivos para sedecidir sobre a continuidade do desenvolvimento.
Fase de Elaboração
Abrange a Modelagem do modelo genérico do processo.
O objetivo desta fase é analisar de forma mais detalhada a análise dodomínio do problema, revisando os riscos que o projeto pode sofrere a arquitetura do projeto começa a ter sua forma básica.
Indagações como “O plano do projeto é confiável?”, “Os custos sãoadmissíveis?” são esclarecidas nesta etapa.
Fase de Construção
Desenvolve ou Adquire os componentes de Software.
O principal objetivo desta fase é a construção do sistema desoftware, com foco no desenvolvimento de componentes e outrosrecursos do sistema.
É na fase de Construção que a maior parte de codificação ocorre.
Fase de Transição
Abrange a entrega do software ao usuário e a fase de testes.
O objetivo desta fase é disponibilizar o sistema, tornando-odisponível e compreendido pelo usuário final.
As atividades desta fase incluem o treinamento dos usuários finais etambém a realização de testes da versão beta do sistema visandogarantir que o mesmo possua o nível adequado de qualidade.
DisciplinasAs disciplinas descrevem o aspecto estático do processo, como ele édescrito em termos de componentes, disciplinas, atividades, fluxosde trabalho, artefatos e papéis do processo. São divididas em:
Seis Disciplinas de Engenharia Modelagem de Negócios Requisitos Análise e Projeto ("Design") Implementação Teste Implantação
Três Disciplinas de Apoio/Suporte Ambiente Configuração e Gerência de Mudança Gerência de Projeto
Engenharia - Disciplina de Modelagem de Negócios
Modelagem de negócios, explica como descrever uma visão daorganização na qual o sistema será implantado e como usar estavisão como uma base para descrever o processo, papéis eresponsabilidades.
O objetivo de modelagem de negócios é, primeiramente, estabeleceruma melhor compreensão e canal de comunicação entre engenhariade negócios e engenharia de software. Compreender o negóciosignifica que os engenheiros de software devem compreender aestrutura e a dinâmica da empresa alvo (o cliente), os atuaisproblemas na organização e possíveis melhorias.
Engenharia - Disciplina de Requisitos
Esta disciplina explica como levantar pedidos das partes interessadas("stakeholders") e transformá-los em um conjunto de requisitos queos produtos funcionam no âmbito do sistema a ser construído efornecem requisitos detalhados para o que deve fazer o sistema.
Engenharia - Disciplina de Análise e Projeto (“Design”)
O objetivo da análise e projeto é mostrar como o sistema vai serrealizado. O objetivo é construir um sistema que:
Execute as tarefas e funções especificadas nas descrições;
Cumpra todas as suas necessidades;
Seja fácil de manter quando ocorrerem mudanças de requisitosfuncionais.
Engenharia - Disciplina de Implementação
Os efeitos da implementação são:
Para definir a organização do código, em termos de subsistemasde implementação organizadas em camadas
Para implementar classes e objetos em termos de componentes(arquivos-fonte, binários, executáveis e outros)
Para testar os componentes desenvolvidos como unidades
Integrar os resultados produzidos por implementadoresindividuais (ou equipes), em um sistema executável
Engenharia - Disciplina de Teste
As finalidades da disciplina de teste são:
Verificar a interação entre objetos Verificar a integração adequada dos componentes do software Verificar se todos os requisitos foram corretamenteimplementados Identificar e garantir que os defeitos são abordados antes daimplantação do software Garantir que todos os defeitos são corrigidos, reanalisados efechados
O RUP propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Os testes são realizados ao longo de 4 dimensões da qualidade: Confiabilidade, Funcionalidade,Desempenho da aplicação, e o Desempenho do sistema.
Engenharia - Disciplina de Implantação
O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus usuários finais.
Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de ajuda e assistência aos usuários.
Embora as atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no final da fase de construção.
Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos detalhes do que outros workflows.
Apoio/Suporte - Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar oprocesso para um projeto.
Ele descreve as atividades necessárias para desenvolver as diretrizesde apoio a um projeto.
A proposta das atividades de ambiente é prover à organização dedesenvolvimento de software os processos e as ferramentas quedarão suporte à equipe de desenvolvimento.
Se os usuários do RUP não entendem que o RUP é um framework deprocesso, eles podem percebê-lo como um processo pesado e caro.
Apoio/Suporte - Disciplina de Configuração e Gerência de Mudança
A disciplina de Gestão de Mudança em negócios com RUP abrangetrês gerenciamentos específicos: de configuração, de solicitações demudança, e de status e medição.
A Rational também tem um produto para manter as solicitações demudança chamado ClearQuest.
Apoio/Suporte - Disciplina de Gerência de Projeto
Esta disciplina concentra-se principalmente sobre os aspectosimportantes de um processo de desenvolvimento iterativo:
Gestão de riscos; Planejamento de um projeto iterativo através dociclo de vida e para uma iteração particular; E o processo deacompanhamento de um projeto iterativo, métricas. No entanto, estadisciplina do RUP não tenta cobrir todos os aspectos dogerenciamento de projetos. Por exemplo, não abrange questõescomo:
Gestão de Pessoas: contratação, treinamento, etc.
Orçamento Geral: definição, alocação, etc.
Gestão de Contratos: com fornecedores, clientes, etc.
Embora o RUP não seja um processo adequado a todos os tipos dedesenvolvimento de software, ele representa uma nova geração deprocessos genéricos. A mais importante inovação é a separação defases e workflows, e o reconhecimento de que a implantação desoftware no ambiente do usuário é parte do processo. As fases sãodinâmicas e tem objetivos. Os workflows são estáticos e constituematividades técnicas que não estão associadas a uma única fase, maspodem ser utilizados ao longo do desenvolvimento para atingir osobjetivos de cada fase (Sommerville 2007, pág. 56).
Conclusão
Rational Unified Process
DISCIPLINAS
Vamos agorar conhecer um pouco mais sobre as
6 disciplinas de engenharia do RUP:
Modelagem de Negócios
Requisitos
Análise e Projeto ("Design")
Implementação
Teste
Implantação
DISCIPLINA DE
MODELAGEM DE
NEGÓCIOS
Modelagem de NegóciosÉ uma das 9 disciplinas do RUP e a primeira das 6 consideradas “coredisciplines”. Dentro do ciclo de desenvolvimento de softwarepodemos dizer que essa é sem dúvida a disciplina menos praticada.
RUP não define esta como uma disciplina obrigatória, mas recomendafortemente que ela seja executada especialmente para empresas queestão iniciando um novo negócio e não possuam uma claramodelagem do negócio.
Modelagem de NegóciosFinalidades:
Entender os problemas da organização identificando aspossíveis melhorias;
Avaliar o impacto de mudanças na organização;
Assegurar que os clientes, usuários, desenvolvedores e outrosparceiros tenham uma compreensão comum da organização;
Gerar conteúdo para a fase de requisitos do sistema quesuportará a organização e seus processos;
Entender como o software se ajustará à organização.
Modelagem de NegóciosPapéis e Artefatos
A importância da definição de papéisnão é somente para melhorardivisão do trabalho, mas principalmente para que hajana equiperesponsabilidades definidas para cada atividade realizada, fazendo,assim,com que os membros tenham que cumprir direitinho as suastarefas e que respondam por elas.
Gerente de Projeto
Analista de Processos de Negócio (Dentro da disciplina deModelagem de Negócios, esse é o papel mais importante)
Designer de Negócio
Gerente de Projeto
Talvez seja um dos únicos papéis que estarão presentes em todos osprojetos e em todas as suas fases, independente do tamanho,natureza ou metodologia de desenvolvimento adotada.
Inicialmente, o gerente de projeto era o indivíduo que identificava astarefas necessárias, as delegava aos membros da equipe e ficavapressionando cada um para cumprir os prazos.
Hoje, essa realidade mudou. O gerente de projeto é um indivíduoextremamente participativo: realiza parcerias com os membros daequipe, estimula e valoriza as soluções encontradas e conduz oandamento do projeto, protegendo a equipe de distrações eorganizando cronogramas, defende os interesses do time e realiza acomunicação com o cliente.
Modelagem de Negócios
Analista de Processos de Negócio
Modelagem de Negócios
Designer de Negócios
Modelagem de Negócios
Modelagem de Negócios
Relação com Outras Disciplinas
A disciplina Requisitos utiliza modelos de negócios como um importante subsídio para entender os requisitos do
sistema.
A disciplina Análise e Design utiliza entidades de negócios como subsídio para identificar classes de
entidade no modelo de design.
A disciplina Ambiente desenvolve e mantém artefatos de suporte, como o Guia de Modelagem de Negócios.
DISCIPLINA DE
REQUISITOS
O objetivo da disciplina Requisitos é descrever o que o sistema devefazer e permite que desenvolvedores e clientes concordem com essadescrição. Para conseguir isso, obter, organizar e funcionalidadedocumento desejado e restrições; acompanhar e documentarcompromissos e decisões.
Uma visão do documento é criada, e necessidades das partesinteressadas são extraídas. Atores e casos de uso são identificados.
REQUISITOS
O QUE É UM REQUISITO? Condição ou capacidade que um sistema deve desempenhar
Qualidade de software
Funcionalidade: requisitos funcionais
Requisitos não funcionais
Usabilidade Confiabilidade Performance Suportabilidade – manutenabilidade
TIPOS DE REQUISITOS
Serviços (features)
Expressões de comportamento do sistema em alto nível (o quê)
Solicitações dos stakeholders
Requisitos do software
Requisitos de casos de usos
Processo de levantamento de requisitos proposto pelo RUP (José Martins, 2004)
REQUISITOS
ATIVIDADES
ARTEFATOS
ENGENHARIA DE REQUISITOSÉ fundamental para o desenvolvimento de um software acompreensão dos requisitos. Se a análise e a especificação dasfunções não forem definidas adequadamente o software não atenderáas necessidades do usuário.
A Engenharia de Requisito tem como objetivo a elaboração de umdocumento com as características do sistema. Este documento serve de referência para todas as pessoas envolvidas no processo de desenvolvimento inclusive os clientes.
Com a chegada da engenharia de requisitos, se fez necessário àelaboração de um processo visando organizar as atividades. É o que analisaremos nos tópicos abaixo.
Processo de Engenharia de RequisitosO processo de Engenharia de Requisitos é um conjunto de atividadesa serem seguidas para desenvolver um documento de requisitos.
Sommerville sugere um modelo de atividades que pode descrever amaioria dos processos de Engenharia de Requisitos.
As atividades nem sempre ocorrem sequencialmente, em geralrealizam varias repetições ou são executadas paralelamente.
Elicitação Análise e Negociação Especificação Validação
Processo de Engenharia de Requisitos
Elicitação dos Requisitos
O objetivo é obter conhecimentos relevantes do problema a ser resolvido.Segundo Kotonya e Sommerville existem 4 dimensões na atividade deelicitação de requisitos:
Entendimento do domínio da aplicação – entendes-e a área na qual osistema será aplicado;
Entendimento do problema – com auxilio do sistema a ser resolvido,entende-se os detalhes do problema especifico a ser resolvido;
Entendimento do negócio – entende-se qual a contribuição dosistema para que sejam atingidos os objetivos gerais da organização;
Entendimento das necessidades e das restrições dos stakeholders –entende-se detalhadamente: as necessidades de apoio a seremprovidas pelo sistema à realização do trabalho e aos interesses decada um dos stakeholders; os trabalhos a serem apoiados pelosistema e; o papel de eventuais sistemas existentes na execução econdução dos processos de trabalho.
Análise e Negociação dos Requisitos
Depois da elicitação de requisitos todo esse conhecimento adquirido pelosstakeholders precisa ser representado através de notações diversas. Essasrepresentações precisam estar sempre consistentes.
Negociação de requisitos é uma atividade extremamente complexa, ter umentendimento global de todos os objetivos, soluções e interação entre eles éuma tarefa muito difícil de executar. Assim existem diferentes métodos etécnicas de negociação.
Robinson estabelece uma infraestrutura para modelar o processo denegociação:
Perspectivas de negociação
Processos de negociação
Produtos da negociação
Especificação dos Requisitos
Após serem identificados e analisados os requisitos devem ser documentadospara que possam servir de base para o resto do processo.
Administrar o volume de informações que são gerados pelo processo deengenharia de requisitos é um dos principais problemas que se enfrenta nadocumentação de requisitos. Para se tornar um pouco mais fácil aadministração desse documento usa-se uma notação gráfica que diminui otamanho do modelo.
Cada engenheiro de requisitos usa um modelo para fazer sua documentação.A seguir são mostrados três modelos de documentos que são encontrados naliteratura:
Modelo 1 – Roger S. Pressman
Modelo 2 – RUP (Rational Unified Process)
Modelo 3 – Wilson de Pádua Filho
Validação dos RequisitosEsta atividade acontece no final da especificação de requisitos e seuobjetivo é verificar se a documentação dos requisitos estaconsistente e se contem todas as necessidades dos usuários.
A revisão é uma das técnicas usadas para validar os requisitos.
Uma das maneiras para essa tarefa é utilizar um relatório de revisão.
Um grande desafio para a validação de requisitos é mostrar que aespecificação de requisitos está correta, pois não existe uma formapara isso.
GERENCIAMENTO DE REQUISITOSGerenciamento de requisitos trata-se de um modelo sistemático praidentificar, organizar e documentar os requisitos do sistema,estabelecer e manter acordo entre o cliente e a equipe do projeto nosrequisitos variáveis do sistema.
Para ter um gerenciamento eficiente de requisitos é preciso:
Manter uma declaração de requisitos clara;
Atributos aplicáveis a cada tipo de requisito e;
Rastreabilidade para outros requisitos e outros artefatos doprojeto.
GERENCIAMENTO DE REQUISITOSExistem requisitos funcionais e não-funcionais. Exemplos:
Funcional: o usuário deve selecionar a opção de inclusão paracadastrar um novo aluno no banco de dados.
Não-funcional: o sistema deve ser compatível com asplataformas Windows e Linux.
Não-funcional: o sistema deverá ser desenvolvido em Java.
É natural que alguns requisitos possam não ser definidos corretamente noinício do projeto, para isso serão necessárias várias revisões periódicas, a fim de detectar erros o mais cedo possível e corrigi-los logo em seguida.
DISCIPLINA DE
ANÁLISE E PROJETO
("DESIGN")
Após a etapa de análise de requisitos,temos documentos de requisitos e oscasos de uso em mãos.
Queremos agora gerar um primeiromodelo do sistema a partir dos casos deuso.
Este é chamado de modelo de análise.
Requisitos Análise Projeto
Vai proporcionar um método que permita quecriemos um modelo de classes do sistema apartir dos casos de uso
Trará a resposta para a pergunta:
Quais classes preciso para implementar estescasos de uso?
casos de uso análise
Descritos na linguagem do cliente
Descrito na linguagem dos desenvolvedores
Visão externa do sistema Visão interna do sistema
Captura as funcionalidades do sistema
Mostra, de modo abstrato, como a funcionalidade pode
ser realizada
Estruturado por casos de uso
Estruturado por classes e pacotes
O modelo de análise e projeto contém asrealizações de casos de uso
Pode ser particionado em dois modelos
Modelo de Analise
Modelo de Projeto
Diagramas de Classe Diagramas de Classe
Realização de Caso
de Uso
Caso de Uso
Diagramas de ColaboraçãoDiagramas de Colaboração
Diagramas de SequênciaDiagramas de Sequência
Descreve como ocaso de uso érealizado,associando o casode uso com classese outros elementosde projeto
Requisitos Analise e projeto
MDS - Bacalá
Diagrama de Atividades
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de Estoque
Socket
Para cada caso de uso
Identificar as classes de análise
• Classes de fronteira
• Classes de controle
• Classes de entidade
Para cada classe
Identificar responsabilidades das classes
Identificar relacionamentos
Identificar atributos
Para cada classe
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais
Mapear as classes persistentes em conceitosdo Banco de Dados
Definir os tipos de dados mais adequados parao Banco de Dados
Normalizar se necessário
DISCIPLINA DE
IMPLEMENTAÇÃO
Disciplina de Implementação
OBJETIVOS
Definir a organização do código em termos de subsistemas deimplementação organizados em camadas
Implementar classes e objetos em termos de componentes(arquivos-fonte, binários, executáveis e outros)
Testar os componentes desenvolvidos como unidades
Integrar os resultados produzidos por implementadoresindividuais (ou equipes) ao sistema executável
Modelo de projeto
Modelo de dados
Implementação
Documento daarquitetura
Modelo de implementação
Componentes
Plano de Integração
Documento daarquitetura
Estruturar Modelo deImplementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
Implementar
Componentes
CorrigirDefeitos
Realizar Testes
de Unidade
RevisarCódigo Fonte
Identificar quais componentes participam da iteração (colaborampara os casos de uso da iteração)
: C lie n t e
C o n t ro la d o r
C lie n t e
M a q u in a
D in h e iro
B a n c oLe it o ra C a rt a o C lie n t eF o rm u la rio
S a q u e
in s e re c a rt a o
in ic ia r s e s s a o (d a d o s c a rt a o )
s oli ci t a s e nh a
s o lic it a s e n h a
e n t ra s e n h a
e n t ra s e n h a
n e w C lie n t e (d a d o s c a rt a o , s e n h a )
v e rif ic a s e n h a
so lic it a v a lo r
s o lic it a v a lo r
e n t ra v a lo r
e n t ra v a lo r
v e rif ic a s a ld o (v a lo r)
s o lic it a d e b it o (v a lo r)
s ol ici t a d e v ol uc a o c art a o
s o lic it a e n t re g a d in h e iro
c a rt a o
d in h e iro
Identificar quais pacotes participam da iteração (colaboram paraos casos de uso da iteração)
Applicação
Negócio
Middleware
Básico
*
*
*
*
*
Candidatos a Stubs
x
x
Aplicação
Comunicação
Negócio
Dados
3
Stubs2
2
1
1
aa bb
cc dd
ee gg
ff
hh ii jj
Definir os builds que serão gerados
Avaliar resultados
A ordem de integração reduz a necessidade decriação de stubs?
A ordem de integração facilita a detecção de erros?
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
Implementar
Componentes
CorrigirDefeitos
Realizar Testes
de Unidade
RevisarCódigo Fonte
Modelo de Implementação
Modelo de projeto gerado a partir da engenharia reversa do código fonte do sistema
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
ImplementarComponentes
CorrigirDefeitos
Realizar Testesde Unidade
RevisarCódigo Fonte
Check-out dos componentes
Implementar Operações
Inicialização dos atributos
Estados
Comentar o código implementado Seguindo um padrão de codificação
Avaliar o código implementado
Padrão de codificação
Fatores de qualidade de OO e Java
Compilar o código implementado
Com a última versão estável dos componentes auxiliares
Com a versão mais recente dos componentes implementados
Check-in dos componentes
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
ImplementarComponentes
CorrigirDefeitos
Realizar Testesde Unidade
RevisarCódigo Fonte
Check-out dos componentes
Estabilizar a ocorrência do defeito
Identificar casos de teste mínimos que causam o defeito
Localizar o defeito no código
Isolado do ambiente de produção
Com ferramenta de depuração
Comentando trechos do código
Criando stubs
Corrigir o defeito no código
Check-in dos componentes
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
ImplementarComponentes
CorrigirDefeitos
Realizar Testesde Unidade
RevisarCódigo Fonte
Implementar componentes de teste
Separados dos componentes a serem testados
Usando ferramenta para geração dos componentes de teste
Ex: Junit
Aproveitando componentes implementados anteriormente (Check-out)
Check-in dos componentes de teste
Executar testes e avaliar resultados
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
ImplementarComponentes
CorrigirDefeitos
Realizar Testesde Unidade
RevisarCódigo Fonte
Revisar código
Com base nos seguintes documentos:
Padrão de codificação
Fatores de qualidade de OO e Java
Sem verificar se casos de uso foram corretamente implementados
Função corretiva, mas também educativa
Passar mudanças para o programador responsável
Estruturar Modelo de
Implementação
Revisor de Código
Programador
Integrador doSistema eSubsistemas
Planejar Integração Integrar Sistemae Subsistemas
ImplementarComponentes
CorrigirDefeitos
Realizar Testesde Unidade
RevisarCódigo Fonte
Check-out de todos os componentes do repositório principal
Integrar componentes em um build
Notificar responsável pelos defeitos
Criar tag (identificador) para o build
Divulgar o build
Check-in dos componentes
DISCIPLINA DE
TESTE
Fluxo de Trabalho
Papéis e Atividades
Papéis e Artefatos
DISCIPLINA DE
IMPLANTAÇÃO
Finalidade: Descrever as atividades que garantam que o produto de software será disponibilizado a seus usuários finais.
Disciplina de Implantação
Esta Disciplina descreve três modos de implantação de produto:
A instalação personalizada
O produto em uma forma "compacta"
Acesso ao software por meio da Internet
Em cada instância, a ênfase é testar o produto no local de desenvolvimento, seguido de testes beta, antes de ele ser finalmente oferecido ao cliente.
Fluxo de Trabalho
Atividades
Os papéis envolvidos e os artefatos produzidos na disciplina Implantação.
Formado em Análise de Sistemas
Pós-Graduado em Auditoria em T.I.
Gerente de TI da CLIOC – Coleção de Leishmania do
Instituto Oswaldo Cruz – Fiocruz
Certificado em Gestão de Segurança da Informação e
Gerenciamento de T.I. pela Academia Latino-Americana
(Microsoft TechNet / Módulo Security)
Carlos Henrique M. da Silvacarloshenrique.85@globo.com