Processo Racional Unificado em Testes de Software

Metodologia de Processo Racional Unificado (RUP) utiliza a abordagem orientada a objetos em seu desenho e o uso da notação UML (Unified Modeling Language) é projetada e documentada para ilustrar os processos em ação. Utiliza técnicas e práticas comercialmente comprovadas.

É um processo considerado pesado e de preferência aplicável a grandes equipas de desenvolvimento e grandes projectos, mas o facto de ser amplamente personalizável permite a sua adaptação a projectos de qualquer escala.

Específicos

Para o gerenciamento de projetos, o modelo RUP (Rational Unified Process) fornece uma solução disciplinada como as tarefas e responsabilidades delineadas dentro de uma organização de desenvolvimento de software.

RUP (Rational Unified Process) é, em si mesmo, um produto de software. É modular e automatizado, e toda a sua metodologia é suportada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através das suas “Suítes Racionais”

Os métodos de competição no campo da engenharia de software incluem “salas limpas” (consideradas pesadas) e ágeis (leves), tais como Extreme Programming (XP-Extreme Programming), Scrum, FDD, e outros.

Há certas orientações e templates que são definidos, para os membros do pessoal de um ciclo de produção, pelo RUP: parte do cliente e uma avaliação do progresso do projecto pela sua gestão. Ele ajuda os desenvolvedores a manter o foco no projeto.

Requisitos de gerenciamento

Documentação de desempenho é essencial para qualquer projeto de grande escala; observe que o RUP descreve como documentar funcionalidades, limitações do sistema, restrições de design e requisitos comerciais.

Os casos de uso e os cenários são exemplos de artefatos de processo dependentes, que têm sido considerados muito mais eficazes na captura de requisitos funcionais.

O Uso de uma Arquitetura Baseada em Componentes

A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a reutilização e a compreensão intuitiva do software. Um componente geralmente refere-se a um objeto na programação orientada a objetos.

RUP fornece uma forma sistemática de construir este tipo de sistema, focando na produção de uma arquitetura executável nos estágios iniciais do projeto, ou seja, antes de comprometer recursos em grande escala.

Os Componentes aqui referidos são geralmente incluídos nas infra-estruturas já existentes no local. Estas infra-estruturas incluem CORBA assim como Component Object Model (COM).

O Uso de Modelos de Software Visual no Rup Model

Ao abstrair a programação do seu código e representá-lo usando blocos de construção gráficos, o RUP pode ser uma forma eficaz de obter uma visão geral de uma solução.

O uso de modelos visuais também pode permitir que indivíduos com um perfil menos técnico (como clientes) tenham uma melhor compreensão de um determinado problema, e assim estarem mais envolvidos no projeto como um todo.

A linguagem de modelagem UML tornou-se um padrão da indústria para representar projetos, e é amplamente utilizada pelo RUP!

Know More: Leia sobre detalhes exclusivos de Agile Testing

Check Software Quality

Não garante que a qualidade do software seja a falha mais comum em todos os projetos de sistemas computacionais. Normalmente, pensa-se na qualidade do software após a conclusão dos projectos ou a qualidade é da responsabilidade de uma equipa de desenvolvimento diferente.

>

Software de Gestão e Controlo de Alterações

>

Em todos os projectos de software, a existência de alterações é inevitável. O RUP define métodos para controlar e monitorar as mudanças. Como uma pequena mudança pode afetar as aplicações de forma totalmente imprevisível, o controle de mudanças é essencial para o sucesso de um projeto.

RUP (Rational Unified Process)também define as áreas de trabalho e segurança, o que garante a um programador que as mudanças em outro sistema não afetarão seu sistema.

Fases da Metodologia RUP

Tão gerais estas diretrizes são, até agora, a serem seguidas para percorrer a vida de um ciclo de projeto. As fases (ver figura abaixo) indicam a ênfase dada no projeto em um determinado momento. Para capturar a dimensão temporal de um projeto, o RUP divide o projeto em quatro diferentes fases:

Iniciação ou Design: ênfase no escopo do sistema;

Preparação: ênfase na arquitetura;

Construção: ênfase no desenvolvimento;

Transição: ênfase na aplicação.

RUP também é baseado nos 4 Ps:

• Pessoas
• Design
• Produto
• Processo

As camadas são compostas de iterações. Iterações são janelas de tempo; iterações definiram o termo como as fases são objetivas.

Todas as fases geram artefatos. Estes serão usados na fase seguinte e documentam o projeto e permitem um melhor acompanhamento.

Fase de desenho

A fase de desenho ou iniciação contém os fluxos de trabalho necessários para o acordo das partes interessadas – partes interessadas – com os objetivos, arquitetura e planejamento do projeto. Se esses atores tiverem bons conhecimentos, não será necessário analisar. Caso contrário, uma análise mais elaborada é necessária.

Nesta fase, os requisitos essenciais do sistema são transformados em casos de uso. O objetivo não é fechá-los, mas apenas aqueles que são necessários para moldar a opinião.

A etapa é geralmente curta e é usada para definir se é viável continuar com o projeto e definir os riscos e o custo do último. Um protótipo pode ser feito para que o cliente aprove. Como o RUP cita, o ideal é realizar iterações, que devem estar bem definidas em termos de quantidade e objetivos.

Fase de elaboração

A preparação será para o projeto do sistema, como complemento ao levantamento e/ou documentação de casos de uso, em frente à arquitetura do sistema, para rever o modelo de negócio para o projeto e iniciar a versão do manual do usuário. Deve-se aceitar: A descrição do produto (aumento + integração) é estável; o plano do projeto é confiável? Os custos são elegíveis?

Fase de construção

Na fase de construção, o desenvolvimento físico do software é iniciado, códigos de produção, testes alfa. Os testes Beta foram realizados no início da fase de transição.

Você deve aceitar os testes, estabilidade e processos de teste, e o código do sistema é “baseline”.

Fase de transição

Nesta fase é a entrega (“deployment”) do software, que realiza o plano de deployment e entrega, o monitoramento e a qualidade do software. Os produtos (lançamentos, versões) vão ser entregues, e colocar a satisfação do cliente. Nesta fase também se realiza o treinamento dos usuários.

Disciplinas da Metodologia RUP (Rational Unified Process)

>

Disciplina de Modelagem de Negócios

>

As organizações estão cada vez mais dependentes dos sistemas de TI, por isso é imperativo que os engenheiros de sistemas de informação saibam como as aplicações estão integradas no desenvolvimento da organização. As empresas investem em TI, que compreende a vantagem competitiva do valor agregado pela tecnologia.

O objetivo da modelagem de negócios é primeiro estabelecer um melhor entendimento e comunicação entre engenharia de negócios e engenharia de software.

O entendimento do negócio significa que os engenheiros de software devem compreender a estrutura e dinâmica da empresa alvo (o cliente), os problemas atuais que a organização está enfrentando e os métodos e estratégias potenciais para fazer reparações.

Outro aspecto importante que não deve ser prejudicado é que as partes relevantes, como os desenvolvedores, assim como os clientes e também os usuários finais, devem ter um entendimento claro sobre a organização, e uma característica importante desse entendimento é que ele deve ser comum entre todas as partes envolvidas.

A modelagem de negócios explica como descrever a visão de uma organização na qual o sistema será implementado e como usar essa visão como base para descrever os processos, funções e responsabilidades.

Requisitos do curso

Este curso explica como obter solicitações das partes interessadas (“partes interessadas”) e convertê-las em um conjunto de requisitos que os produtos funcionam dentro do sistema a ser construído e fornecer os requisitos detalhados para o que é necessário para o sistema.

Análise e Design da Disciplina (“Design”)

O propósito da análise e do design é mostrar como o sistema será realizado. O objetivo é construir um sistema que:

Executar em um ambiente específico de execução, tarefas e funções especificadas nas descrições de casos de uso

Satisfazer todas as suas necessidades

É fácil de manter quando não há mudanças nos requisitos funcionais, os resultados do projeto em um modelo de análise e design tem opcionalmente um modelo de análise.

O modelo de design é utilizado como uma versão conceitual do código fonte, exibindo apenas o mínimo necessário. Isto permite ao usuário de qualquer um dos inspetores verificar o estilo em que o código fonte foi renderizado.

O modelo de projeto é renderizado de tal forma que contém diferentes divisões de projetos. Estas divisões são armazenadas dentro de subsistemas definidos.

Todos os subsistemas têm uma interface distinta que é desenhada com precisão. Também contém descrições de como os objetos nestas classes colaboram para realizar o projeto de casos de uso.

A Implementação da Disciplina

Os efeitos da aplicação são:

• Com referência aos subsistemas em camadas organizados para uma aplicação, o código da organização é configurado.
• As diferentes classes ou divisões de componentes são realizadas. Estes componentes incluem

1. Arquivos Fonte
2. Executáveis e
3. Binários

• Componentes desenvolvidos como unidades são testados

Incorporar os resultados produzidos pelos executores individuais (ou equipes), em um sistema executável. Os sistemas são alcançados através dos componentes da aplicação.

O processo visa realizar uma função importante, que é definir o procedimento exato a ser utilizado, a fim de reutilizar componentes que já existem ou foram introduzidos recentemente.

Esta possibilidade de manutenção do sistema e uma melhoria substancial nas chances de utilização dos componentes.

Teste de disciplina

Os propósitos do teste de disciplina são:

• Cheque a interação entre objetos
• Cheque a integração correta de todos os componentes do software

>

• Cheque se todos os requisitos foram executados corretamente

>

• Identificar e garantir que os defeitos sejam corrigidos antes da implementação do software

>

• Cheque a correção de todos os defeitos, revisto e encerrado

Conclusão

No caso de haver defeitos no projecto, a sua correcção pode implicar custos desnecessários devido ao facto de os defeitos não serem trazidos à luz dentro do tempo devido.

Se o projeto, no entanto, for testado na sua totalidade, isso seria benéfico, pois qualquer defeito que possa estar rastejando para os projetos pode ser identificado e determinado o mais cedo possível.

Isso, por sua vez, terá uma redução maciça nos custos envolvidos com a retificação dos defeitos. Esta é a abordagem iterativa proposta pelo Processo Racional Unificado.

Para que o teste dê frutos e tenha os melhores resultados possíveis, os testes precisam ser realizados em quatro parâmetros de qualidade e também devem ser estabelecidos padrões que precisam ser cumpridos para que o projeto seja considerado como tendo passado no teste.