| |
| Acadêmico(a): Leonardo Emanuel Pretti |
| Título: Ferramenta de Suporte a Requisitos de Software Baseado em Princípios da Modelagem Ágil |
| |
| Introdução: |
O software tem influenciado a vida de todos, de maneira como poucos tinham previsto, mesmo uma década atrás. Logo, uma base sólida sobre a teoria e a prática de engenharia de software é essencial para se construir um bom software e avaliar os riscos e as oportunidades que ele pode trazer ao dia-a-dia.
Uma evidência da influência do software em nosso cotidiano foi a quase paranóia causada pelo chamado “bug do milênio” na virada de 1999 para 2000. Uma simples linha de código, que é a seqüência de programação de uma determinada função de um software, com defeito poderia causar desde peque-nos problemas no funcionamento de equipamentos de comunicação entre os tripulantes até a queda de
uma aeronave com centenas de passageiros a bordo (JOMORI; VOLPE; ZABEU, 2005).
Hoje em dia, o software está presente, explicitamente ou mesmo sem se fazer notar, em várias situações. Cada vez mais está se lidando com software a todo instante, seja ele utilizado através de um computador desktop, ou um palm top, ou ainda encapsulado em micro-processadores como em alarmes de carros, portões eletrônicos, etc.
Com tanta diversidade de aplicações do software muitas delas desconhecidas, é necessário que seja feita uma boa avaliação sobre as necessidades e funcionalidades básicas que o software deve possuir. Por essa razão, a engenharia de software é mais importante do que nunca. Boas práticas de engenharia de software devem assegurar que o software tenha uma contribuição positiva em suas aplicações, e uma das práticas
exigidas é o levantamento de requisitos.
Para Alencar (1999), um processo de requisitos inadequado faz com que os usuários percam a confiança na equipe de desenvolvedores. Conforme Pressman (1995), uma compreensão completa dos requisitos de software é fundamental para um bemsucedido desenvolvimento de software. Não importa quão bem projetado ou quão bem codificado seja, um programa mal analisado e especificado desapontará o usuário e
poderá trazer problemas ao desenvolvedor. Para Lopes (1999, p. 3), requisitos de um sistema definem os serviços que o sistema deve oferecer e as restrições aplicáveis a sua operação. São em geral descritos de forma textual e sua especificação depende de diversos fatores entre eles: da pessoa que está escrevendo os requisitos, das pessoas para quem os requisitos estão sendo escritos, das práticas gerais da organização que está desenvolvendo os requisitos e do domínio da aplicação do sistema.
Existem vários modelos e métodos para o desenvolvimento e acompanhamento das fases de um projeto de software. Um dos mais conhecido é o Rational Unified Process (RUP). O RUP é um processo de desenvolvimento de software iterativo e incremental. O ciclo de vida do RUP é constituído por ciclos de desenvolvimento, cada um possuindo as seguintes fases: concepção, elaboração, construção e transição. Cada ciclo de desenvolvimento é constituído pelo release de um produto executável, que pode ser um subconjunto da visão completa, mas que deve ser útil sob alguma perspectiva de engenharia ou do usuário. Cada release é acompanhado por artefatos de apoio: planos, descrição do release, documentação do usuário, etc (KRUCHTEN, 2001).
No entanto, seguir todas as etapas e regras de modelagem apresentadas pelo RUP para projetos de pequeno e médio porte, não tem se tornado viável (REIS, 2004). Por isso estes métodos não estão sendo bem aproveitados pelas empresas de desenvolvimento de software. Uma das propostas para minimizar as etapas e regras do RUP é a utilização de métodos ágeis. Entre os métodos ágeis, encontra-se a Modelagem
Ágil (AM – Agile Modeling), que é um processo que visa aumentar a eficiência da equipe dentro de um projeto de desenvolvimento de software.
Ao contrário dos processos “tradicionais” como o sugerido pelo Unified Process, por exemplo, que requer basicamente os mesmos artefatos para todos os tipos de projetos, AM busca a construção e manutenção eficiente de artefatos (Requisitos), criando-os apenas quando agregarem valor real ao projeto, e focando principalmente os esforços no desenvolvimento do software que, em última análise, é o objetivo principal do processo. (SANTOS; MARTINS; LEAL, 2003).
Ambler (2004, p. 27) define que a AM não é um processo completo de software.
O foco da AM é a modelagem e a documentação eficazes. Não inclui atividades de programação, embora indique os testes dos modelos com código. Devido ao foco da AM ser uma parte do processo de software, é necessário utilizá-la com outros processos, como XP, UP, DSDM.
Um, exemplo citado por Ambler (2004, p. 234), é a utilização da AM com o Unified Process (UP). Para tal, é necessário instanciar o UP de uma maneira ágil, porque a AM trabalha melhor quando moldada a um processo ágil. Em segundo lugar, é preciso centrar-se na produção de software de qualidade, ou seja, atendendo e resolvendo os problemas do usuário, e não de documentação do software como faz a
Unified Modeling Language (UML). A AM diminui a carga de trabalho de modelagem dos projetistas, afinal só serão criados os artefatos de que precisam para satisfazer a seus objetivos e nada além disso. As equipes de projeto que usam uma abordagem UP/AM tendem a reduzir o trabalho ao mínimo necessário.
Conforme Ambler (2004, p. 28) em todo o processo de modelagem, é importante adotar a simplicidade para fazer a modelagem, e adaptar-se a mudanças quando estiver desenvolvendo, por que os requisitos realmente variam com o tempo. Para levantar as mudanças nos requisitos é necessária uma comunicação eficaz e rápida com o cliente, para que ele informe suas necessidades, assim como dentro da equipe de
desenvolvimento, para que o software atenda as modificações registradas. |
| |
|
