Arquivo de ‘Análise de Sistemas’

Após uma abordagem geral da análise e projeto orientados a objetos no artigo anterior, hoje vamos entrar em detalhes na fase de concepção do processo unificado (RUP).

A fase de concepção corresponde à primeira etapa do processo unificado, nela devemos gerar alguns artefatos para estudar a viabilidade do sistema. Nessa fase que vamos decidir se o sistema deve ser desenvolvido do zero, se podemos utilizar algo pronto e adaptar ou ainda se devemos desistir do mesmo, esta última acontece, na maioria das vezes, por não se chegar a um acordo entre a empresa desenvolvedora e o cliente com relação a custo ou outros fatores.

Essa fase não deve durar muito tempo, pois geralmente nela não se tem um contrato firmado entre as partes envolvidas.

No processo unificado (RUP) a fase de concepção tem algumas similaridades com a fase de iniciação do PMBoK (Project Management Body of Knowledge), pois ambas estudam o escopo inicial do projeto. O PMBoK possui dois processos na fase de iniciação, a proposta e o termo de abertura. Os artefatos da fase de concepção do RUP, que vamos ver mais adiante, ajudam a definir quais informações irão nesses documentos, por isso essas fases andam em paralelo em uma organização que deseja trabalhar tanto com o RUP, como metodologia de desenvolvimento, quanto o PMBoK para gerência de projetos.

O primeiro artefato da concepção é a descrição geral do projeto, ou sumário executivo. Nesse documento, o analista faz uma breve descrição do sistema, contendo os interesses do cliente, não é necessário descrever detalhadamente o funcionamento dos processos nessa fase, bastam uma ou duas páginas. As entrevistas iniciais com o cliente podem ajudar a elaborar esse documento e a identificar os requisitos do sistema.

Com a descrição geral feita, precisamos identificar os requisitos do sistema, tanto funcionais como não-funcionais. A diferença básica entre esses dois grandes grupos de requisitos é que nos funcionais, definimos O QUE o sistema DEVE fazer e nos não-funcionais, COMO o sistema DEVE fazer.

Alguns artefatos opcionais que podem ser fundamentais, dependendo do sistema, são:

• Glossário: Definição de termos utilizados para evitar conflitos entre aquilo que o analista quis dizer e o que o cliente realmente entendeu;
• Análise de riscos: Esse é um artefato muito importante para identificar possíveis riscos que possam acontecer durante o projeto. Devem ser levados em consideração, a possível causa, a probabilidade e o impacto. O PMBoK possui uma seção que trata somente sobre esse assunto, ele divide o gerenciamento dos riscos em seis processos: o planejamento da gestão de riscos, a identificação, a análise quantitativa e qualitativa, o planejamento de resposta aos riscos identificados e o monitoramento e controle;
• Protótipo e provas: Pode haver a necessidade de elaborar alguns protótipos de telas para esclarecer requisitos estão pendentes. Lembrando que esse procedimento deve ser realizado se tiver tempo disponível e se for realmente necessário.

O levantamento de requisitos nesse momento deve ser focado apenas com os requisitos que compõem os principais processos da empresa. Os requisitos funcionais podem ser classificados em evidentes, aqueles que o usuário interage diretamente, e ocultos, em que não existe o conhecimento explícito do usuário.

Provavelmente os requisitos funcionais terão alguma particularidade que deve ser identificada nos requisitos não-funcionais, que são restrições do sistema. Esses requisitos podem ser classificados por obrigatoriedade, sendo obrigatório ou desejado, e por permanência, sendo permanente ou transitório.

Os requisitos não-funcionais ainda podem ser classificados por atributos:

• Usabilidade: Consistência na interface, ajudas, estéticas, materiais para treinamento, acessibilidade, fatores humanos, etc;
• Confiabilidade: Tratamento de falhas, possibilidade de previsão, não erros de programação;
• Desempenho: Velocidade, eficiência, precisão, tempo de recuperação, tempo de resposta, uso de recurso, etc;
• Configurabilidade: O que pode ser configurado pelos usuários do sistema;
• Suportabilidade: Extensibilidade, adaptabilidade, compatibilidade, instalação, regionalização;
• Interface: Arquitetura da informação;
• Segurança: Permissões de usuários do sistema;
• Implementação: Linguagem, banco de dados, componentes, sistemas operacionais, etc;
• Empacotamento: Forma de entrega do sistema;
• Físicos: Material, peso, tamanho;
• Legais: Assessoria jurídica, cumprimento de leis;

Com os principais requisitos identificados, precisamos agora organizá-los. É nesse momento que os casos de uso de alto nível são descobertos, aqui devemos identificá-los atribuindo a eles os atores envolvidos e suas referências com os requisitos.

As referências cruzadas são usadas para garantir a rastreabilidade dos requisitos, tornando muito importante quando nos deparamos com a mudança dos requisitos, uma situação muito comum na maioria dos projetos. Através desse procedimento temos como saber o impacto que aquela mudança vai ocasionar, e criar um plano para tratar essa situação.

A organização dos requisitos também deve ser feita através das funções de conceitos, nesse caso pode ser necessário elaborar um modelo conceitual preliminar, para associar os conceitos.

Outra organização que deve ser feita é a das consultas e relatórios, que, na maioria dos casos, são as mais importantes, mas também as mais simples. Aqui devemos listar as consultas mais complexas e suas referências cruzadas.

É bom lembrar que o processo unificado trabalha com ciclos iterativos, a partir da fase de elaboração, por isso devemos planejar esses ciclos já na fase de concepção. Esse planejamento contém alguns itens importantes como, a estimativa de esforço, que pode ser feita utilizando técnicas de análise por pontos de função (APF) ou análise por casos de uso (UCP).

No planejamento também devemos ter em mente os casos de uso mais importantes, para priorizar seu desenvolvimento no ciclo iterativo. Podemos levar em consideração dois pontos importantes, o grau de complexidade e o grau de importância dos casos de uso.

Craig Larman, o pai da AOO (Análise Orientada a Objetos), criou algumas perguntas para ajudar no escalonamento dos casos de uso, são elas:

• Representa impacto direto na receita?
• Processo primário na linha de negócio?
• Requer suporte à persistência e provoca impacto no projeto de arquitetura?
• Oferecem rapidamente quantidade significativa nas informações?
• Funções de alto risco, críticas com relação ao tempo ou complexas?

Conforme as respostas das perguntas, temos como escalonar os casos de uso e priorizar o desenvolvimento.

Além disso, não podemos deixar de analisar os recursos disponíveis para o projeto, por isso é necessário a criação de um cronograma de execução e custos, que deve conter a duração dos ciclos iterativos. É recomendado que nesse momento sejam utilizadas técnicas de gerenciamento de tempo previstas no PMBoK.

Agora você deve estar pensando que são elaborados muitos documentos antes mesmo de começar o desenvolvimento. Com certeza, dependendo do projeto, alguns desses documentos não precisam ser feitos, mas precisamos ter em mente, que isso tudo é feito para garantir a qualidade do projeto, o tempo gasto agora é mais barato do que o tempo gasto na fase de construção do sistema.

Acaba por aqui nossa fase de concepção, em um próximo artigo estarei mostrando as próximas fases do processo unificado. Até a próxima.

Muito se fala em classes, objetos, herança, poliformismo, abstração e outros conceitos relacionados ao desenvolvimento orientado a objetos, mas o objetivo desse artigo não é explicar cada um desses conceitos, e sim mostrar o que deve ser feito até chegarmos à fase de construção, ou seja, a análise orientada o objetos (AOO).

Para realizar um projeto, de fato, orientado a objetos é necessário mudar a forma de se pensar, partindo da fase de análise do projeto, que se tornou a mais importante. Hoje em dia não podemos partir direto para fase de desenvolvimento, sem antes passar pela análise, é inevitável. As duas fases devem ser simultâneas.

Estarei apresentando uma metodologia muito eficaz para auxiliar os analistas que querem se aprofundar nos projetos orientados a objeto, essa metodologia é conhecida como processo unificado (RUP). O RUP adota as seguintes premissas básicas:

• Uso de iterações para evitar o impacto de mudanças no projeto,
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

O processo unificado consiste em quatro fases básicas:

• Concepção – visão geral e entendimento da necessidade do projeto,
• Elaboração – especificação e abordagem dos pontos de maior risco,
• Construção – desenvolvimento principal do sistema,
• Transição – ajustes e implantação do sistema

A fase de Concepção tem um foco nos riscos de negócios ou requisitos que possam inviabilizar o projeto. Esta fase é mais importante em projetos novos e mais simples em projetos de melhoria de sistemas já existentes. Porém, o foco é sempre na garantia que o projeto é viável e vale a pena ser feito.

Nesta fase, realiza-se uma das principais tarefas do projeto, que é o levantamento de requisitos. Esse processo é realizado para definir “o porquê” da criação do sistema, é muito difícil de projetar uma boa solução para um problema que não tem uma explicação bem definida. Existem algumas técnicas para auxiliar no levantamento de requisitos, como por exemplo, observação in-loco, entrevista com o cliente e JAD (Joint Application Development). Os requisitos são divididos em dois:

• Requisitos funcionais – são aqueles que detalham o que deve ser feito no sistema. A partir deles o analista segue com as outras etapas do processo unificado.
• Requisitos não-funcionais – detalham como o sistema deve ser feito, por exemplo, facilidades de uso, tempo de resposta, equipamentos, etc. Esses tipos de requisitos podem inviabilizar o desenvolvimento do projeto, por isso são muito importantes.

É muito importante destacar que, nesta fase, nem todos os requisitos foram definidos, mesmo porque o objetivo dessa fase não é esse, e sim testar a viabilidade do sistema. Com os testes devidamente feitos e a certeza da realização do projeto, devemos seguir para a outra etapa, ainda dentro da fase de concepção do processo unificado, que é o desenvolvimento dos casos de uso de alto nível. Essa fase é muito importante também, aqui que devemos especificar os processos que foram encontrados nos requisitos funcionais.

Os casos de uso de alto nível devem conter uma descrição geral dos processos considerados primordiais para a realização do projeto, não podendo se delongar muito. Eu recomendo que eles não ultrapassem seis linhas, sempre levando em consideração a grandiosidade do projeto.

A última etapa da fase de concepção é o escalonamento dos casos de uso, o que seria isso? Com todos os casos de uso de alto nível prontos, precisamos definir a prioridade de desenvolvimento para cada um deles. São levados em consideração dois fatores nesse momento, o grau de importância e o grau de complexidade de desenvolvimento.

Com essa etapa devidamente definida, concluímos a fase de concepção. Claro que esta é uma visão superficial do processo unificado. Essa fase que define também se o projeto vai ser ou não desenvolvido, não podendo ultrapassar 5% do tempo total estimado. Se a concepção demorar mais do que algumas semanas para ser definida, existe algo de errado.

A próxima fase é a de elaboração que será apenas para o projeto do sistema, buscando complementar o levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a versão do manual do usuário.
Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta.

Quando entramos nessas fases devemos seguir um ciclo iterativo que parte do princípio da especificação dos casos de uso, começando sempre daquele que foi designado o de maior importância na etapa de escalonamento. Nessa etapa são desenvolvidos os primeiros casos de uso expandido da lista, um de cada vez. Pelo próprio nome já podemos ver que eles vão fazer um detalhamento bem completo dos casos de uso de alto nível encontrados na fase de concepção.

Figura 1 - Diagrama de caso de uso

No mínimo, cada caso de uso deve ter um fluxo principal de sucesso, ou seqüência típica de eventos, um exemplo desse tipo de caso de uso:

1. O usuário entra com seu nome e email.
2. O sistema verifica a informação de identificação.

Os casos de uso também podem conter fluxos alternativos ou secundários que contém exceções do tema principal, alternativas ou eventuais erros que possam acontecer.
Seguindo com nosso ciclo iterativo, partimos para o modelo conceitual. A primeira impressão que temos ao ver um modelo conceitual é pensar que ele é idêntico ao modelo entidade-relacionamento utilizado na camada de persistência dos dados, mas essa visão está errada. O modelo conceitual está mais para um diagrama de classes do que para um modelo ER.

Figura 2 - Modelo Conceitual

A próxima etapa é o diagrama de seqüência dos eventos do sistema, essa etapa tem como objetivo principal especificar a seqüência de iterações dos atores com o sistema, e definir as operações que são necessárias. Esse diagrama é feito com base nos casos de uso expandidos, a partir deles iremos encontrar as operações e respostas do sistema. As operações poderão se transformar, mais adiante, nos métodos das classes e as respostas, o retorno desses métodos.

Temos ainda a etapa dos contratos, aqui já estamos bem perto da construção do processo. Nessa etapa, as operações são bem detalhadas, contendo suas responsabilidades, pré-condições e pós-condições, essas últimas descrevem as definições de instâncias de objetos, associações formadas e modificações de atributos. Vejamos um exemplo de contrato:

Nome da operação: adicionarCliente(idCliente, nomeCliente)
Responsabilidade: Cadastrar um novo cliente
Pós-Condições:

• Uma instância do Cliente foi criada.
• Cliente.nome recebeu o nome passado como parâmetro.
• Cliente.id recebeu o id passado como parâmetro.
• A instância Cliente foi associada ao sistema.

Podemos ver que nos aproximamos muito da programação, o nome da operação provavelmente será um método da classe Cliente, idCliente e nomeCliente serão propriedades da classe. Ao analisarmos as pós-condições vimos à definição de instâncias de objeto, modificações de atributos e a associação. A última linha das pós-condições tem como objetivo indicar que o objeto vai ser enviado para a camada de persistência, na qual são realizadas todas as operações necessárias para gravação na fonte de dados.

Com tudo isso definido, partimos para a construção do processo, programamos, programamos, programamos, testamos, testamos, testamos e finalizamos uma etapa de cada vez, entrando em loop, espero eu loop finito.

É bom lembrar que tudo que foi falado relaciona-se com a análise orientada a objetos, e dá uma visão superficial. Tentarei escrever um artigo explicando mais sobre a parte de desenvolvimento de um sistema orientado a objetos.

Não poderia terminar sem citar um dos maiores conhecedores da análise orientada a objetos, Craig Larman possui um livro considerado o melhor sobre o assunto: “Utilizando UML e Padrões” da editora Bookman, que vai muito além dos diagramas UML, explicando desde conceitos RUP até o desenvolvimento iterativo. Eu recomendo.

Espero que tenham gostado, e peço desculpa por qualquer erro encontrado, pois esse é meu primeiro artigo, aceito sugestões e críticas construtivas. Até a próxima.