No ano de 2006 elaborei meu trabalho de conclusão de curso sobre este tópico de Análise e Projeto de Sistemas Orientado a Objetos, pode ser acessado aqui ( a partir do capítulo 5 é que se inicia a parte de engenharia de software) . É um assunto pouco comentado, e até mesmo um pouco polêmico, pois é muitas vezes confundido com uma parte de documentação chata no desenvolvimento de software.
Mas muito pelo contrário, é uma fase fundamental para o sucesso na entrega do software. Pois é neste momentos que como já diz no título, analisamos e projetamos o futuro software, tentamos mapear o máximo possível das possibilidades nas regras é onde o usuário já tem uma ideia da carinha do sistema e também tudo que ele vai abranger nesta primeira entrega do software, ou seja, a importantíssima definição do escopo do projeto.
Neste ano de 2006, pesquisei bastante, li vários livros para ter um bom embasamento teórico na escrita do TCC e consequentemente aprendi várias técnicas para a análise e a elaboração de um bom projeto de software. É muito melhor pensar antes de executar, dominar um pouco, não tudo da linguagem UML também é fundamental para documentar esta fase de estudo, análise, reuniões, prototipagem e entendimento do negócio e suas regras que o futuro software irá atender.
A metodologia RUP (Rational Unified Process), também chamado de UP (Unified Process), Processo Unificado, que está fortemente associado à notação UML, é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsível. A figura 1 exibi uma visão geral dos processos envolvido no RUP.
Figura 1 – RUP, visão geral (RUP, 2003).
O RUP comporta, em suas recomendações, as antigas fases de estudo de viabilidade, análise de requisitos, análise de domínio, e o projeto em múltiplas camadas (WAZLAWICK, 2004).
O ciclo de vida de software do RUP é dividido em quatro fases sequenciais (Figura 2), cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais.
Figura 2 – As fases e os marcos de um projeto RUP (RUP, 2003)
WAZLAWICK, 2004 defini da seguinte forma as seguintes etapas.
– A fase de iniciação ou concepção incorpora o estudo de viabilidade e uma parte da análise de requisitos.
– A fase de elaboração incorpora a maior parte da análise de requisitos, a análise de domínio e projeto.
– A fase de construção corresponde à programação e testes,
– e a fase de transição consiste na instalação e manutenção do sistema
A seguir defino melhor cada etapa do processo:
Fase de Iniciação ou Concepção
A fase de concepção, (inception), deve ser a primeira do processo de desenvolvimento de software, na qual se procura levantar os principais requisitos e compreender o sistema de forma abrangente (WAZLAWICK, 2004).
Esta fase inicial indica o nascimento da idéia sobre um novo software. Pode consistir da discussão sobre um problema que ocorre na empresa ou nos clientes e que eventualmente poderia ser resolvido ou minimizado com o desenvolvimento de um sistema informatizado (QUADROS, 2002).
Nesta etapa, não é realizado nenhum tipo de estudo aprofundado sobre o sistema, no entanto, podem ser feitas algumas projeções grosseiras que permitam inferir, ainda que com pouca precisão QUADROS (2002): Quanto tempo o software levaria para ser desenvolvido? Quanto o software custaria para ser desenvolvido? Quais benefícios o projeto traria para a empresa ou para o cliente?
Segundo RUP (2003) os principais objetivos da fase de concepção incluem:
a) Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto.
b) Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design.
c) Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos.
d) Estimar o custo geral e a programação para o projeto inteiro (e estimativas detalhadas para a fase de elaboração imediatamente a seguir).
e) Estimar riscos em potencial (as origens de imprevistos).
f) Preparar o ambiente de suporte para o projeto.
A fase de concepção é onde se buscam as primeiras informações sobre o sistema a ser desenvolvido e contem as seguintes atividades:
- Levantamento de requisitos
- Organização dos requisitos.
A etapa de levantamento de requisitos corresponde a buscar junto ao usuário, seus sistemas e documentos, todas as informações possíveis sobre as funções que o sistema deve executar e as restrições sob as quais o sistema deve operar. O produto desta etapa será o documento de requisitos, primeiro componente do anteprojeto de software (WAZLAWICK, 2004).
A etapa de organização dos requisitos serve para estruturar os requisitos para que possam ser abordados nos ciclos de desenvolvimento. Grande parte dos requisitos será acomodada em processos de negócio conhecidos como casos de uso. Outros requisitos poderão ser associados a operações simples (como cadastros), outros ainda serão meramente consultas. Os casos de uso, cadastros e consultas serão abordados nos diferentes ciclos, priorizando-se os elementos mais críticos (normalmente casos de uso), e deixando-se para o final os mais elementares (cadastros e consultas) (WAZLAWICK, 2004).
Esta etapa é a de definição do escopo do projeto. Ao final desta, tem-se o primeiro Marco (milestone), o Lifecycle Objective Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):
- Sumário Executivo ou Documento de Visão Geral do Sistema, incluindo requerimento, recursos principais e restrições.
- Glossário do projeto, explicando os termos peculiares ao desenvolvimento do mesmo (opcional).
- Caso de uso inicial (descrito utilizando a UML).
- Levantamento dos requisitos.
- Um ou mais protótipos.
Fase de Elaboração
No início da elaboração, o profissional tem uma vaga idéia dos requisitos que o software deverá atender. Nesta fase, o profissional deverá investigar a fundo os obstáculos (riscos) que o projeto pode encontrar. Tais riscos como: Riscos de requisitos, riscos tecnológicos, riscos de habilidades, riscos políticos (QUADROS, 2002).
Além da análise dos riscos, a elaboração é marcada pela definição detalhada do escopo e dos requerimentos do software a ser desenvolvido. Esta definição dos requerimentos deve ser formalizada por escrito através de um documento denominado Documento de Levantamento e Especificação de Requerimentos de Usuário (DLERU). O DLERU deve ser submetido ao usuário/cliente sempre que possível para que ele seja avaliado (QUADROS, 2002).
A meta da fase de elaboração é criar a baseline (a base de sustentação) para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura (RUP, 2003).
A fase de elaboração se inicia com uma sub-fase análise e prossegue com uma sub-fase de projeto. A sub-fase de análise em si comporta três atividades distintas realizadas na seguinte ordem (WAZLAWICK, 2004):
- Expansão dos casos de uso e determinação dos eventos de sistema.
- Construção do modelo conceitual.
- Elaboração dos contratos de operações de sistema.
A expansão dos casos de uso corresponde ao aprofundamento da análise de requisitos. Já a modelagem conceitual corresponde à análise de domínio em seus aspectos estáticos. Por fim, a elaboração dos contratos corresponde à especificação funcional dos aspectos dinâmicos da análise de domínio (WAZLAWICK, 2004).
A subfase de projeto pode se dividir em diversas tarefas com objetivos distintos WAZLAWICK (2004). As tarefas serão:
- Projeto da camada de domínio.
- Projeto da camada de interface.
- Projeto da camada de persistência.
O projeto da camada de domínio compõe-se basicamente de duas atividades: definir os diagramas de colaboração e elaborar o diagrama de classes de projeto (WAZLAWICK, 2004).
O projeto da camada de interface mostra como manter a independência entre a camada de domínio e a interface do software. O projeto da camada de persistência mostra como implementar um sistema de persistência que automatiza o salvamento e a recuperação de dados em disco (WAZLAWICK, 2004).
O objetivo dessa etapa é analisar o domínio do problema, estabelecer uma fundação, desenvolver o plano de projeto e eliminar os elementos de maior risco do projeto. Ao final dela, tem-se o segundo Marco (milestone), o Lifecycle Architecture Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):
- Um caso de uso praticamente pronto com uma descrição completa dos atores e cenários de uso.
- Descrição das operações e consultas de sistema.
- Modelagem Conceitual
- Os Contratos de operações e consultas de sistema.
Fase de Construção
A construção é a fase do processo cujo final é marcado pela disponibilização do produto de software (um arquivo executável ou uma página Web, por exemplo) para os clientes ou usuários (QUADROS, 2002).
Durante essa etapa, os profissionais estarão primeiramente modelando o software utilizando alguma notação, tais como a definida pela UML. Após a modelagem, a fase de construção é marcada pela codificação do software, onde os desenvolvedores estarão fazendo uso de alguma ferramenta de programação, bem como criando as estruturas de apoio, tais como o banco de dados com suas tabelas e outros elementos (QUADROS, 2002).
A fase de construção é também composta pela homologação que consiste na realização de testes de garantia de qualidade como o produto antes do envio para o cliente. A documentação do produto encerra essa fase do processo de desenvolvimento, juntamente com a disponibilização de todo o conjunto do produto para o cliente (software, manuais de treinamento e referência). A vantagem desta abordagem está em se permitir definir deadlines (limites) intermediários pra os vários subprojetos, impedindo que os problemas e os atrasos se evidenciem apenas no final do projeto (QUADROS, 2002).
A meta da etapa de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição (RUP, 2003).
Ao final desta etapa, temos o terceiro Marco (milestone), o Initial Operational Capability Milestone, onde os seguintes resultados devem ser apresentados (QUADROS, 2002):
- O produto (software) completamente operacional.
- Os manuais do produto.
O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta (RUP, 2003).
Fase de Transição
Nesta fase, o produto já foi entregue e são feitas as manutenções corretivas e as otimizações de pequeno porte (que não envolvam uma completa reconstrução do software) (QUADROS, 2002).
O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto (RUP, 2003).
No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado (RUP, 2003).
A Fase de Transição entra quando uma baseline estiver desenvolvida o suficiente para ser implantada no domínio do usuário final. Isso normalmente requer que algum subconjunto usável do sistema tenha sido concluído com nível de qualidade aceitável e documentação do usuário, de modo que a transição para o usuário forneça resultados positivos para todas as partes (RUP, 2003).
Com base na análise feita neste Marco, a empresa poderá decidir finalmente pela disponibilização do produto para os clientes. Ao final do projeto, deve ser feita também uma revisão do cronograma físico-financeiro de forma a avaliar a adequação final do projeto com relação ao planejamento inicial. A fase de transição poderá, dependendo do feedback dos usuários, coincidir com o início de um novo ciclo de desenvolvimento (QUADROS, 2002).
Referências
QUADROS, Moacir. Gerência de Projetos de Software. Técnicas e Ferramentas. São Paulo: Visual Books, 2002.
RUP. Rational Unified Process. 2003. Disponível em <http://www.wthreex.com/rup>.Acessado em: 24/04/2006.
WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Ed Campus Ltda, 2004.