Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais

Transcrição

1 Proposta de processo de especificação de software a partir de técnicas baseadas em suas funcionalidades sob a óptica de seus usuários finais Vagner Luiz Gava (IPT) vlgava@ipt.br Paulo Antonio de Almeida (EPUSP) paulo.almeida@uol.com.br Mauro de Mesquita Spínola (EPUSP) mauro.spinola@poli.usp.br Resumo Este trabalho tem como objetivo desenvolver um processo de especificação de softwarwe através da combinação de um conjunto de técnicas que se complementam. Será visto como o uso combinado de técnicas de prototipação orientada por casos de uso e JAD e da lista de eventos podem ser utilizados desde a fase de elicitação de requisitos e reaproveitados durante todo o ciclo de vida do processo de desenvolvimento de software, economizando tempo e aumentando a produtividade de todo o processo, permitindo, desde seu início, derivar elementos para a medida do tamanho do sistema informatizado que está sendo construído. Palavras chave: Casos de uso, Processo de software, Gerência de requisitos. 1. Introdução Apesar da evolução que vem ocorrendo no campo da engenharia de software e de ferramentas para seu desenvolvimento como conseqüência do aumento expressivo da demanda por produtos e serviços de sistemas computadorizados, a área de software sofre, ainda hoje, de problemas crônicos, como por exemplo: Como desenvolver aplicações que atendam as reais necessidades dos usuários e da administração da empresa? Como separar as informações realmente importantes no meio do oceano de dados que envolve a empresa? Como identificar e separar os fatos e necessidades da empresa dos desejos e opiniões das pessoas? Por outro lado, existe uma série de ferramentas/técnicas que, no todo, contribuem positivamente para alcançar os anseios das questões acima. O problema é que estas contribuições são, de um modo geral, isoladas entre si, nem sempre permitindo que o resultado final faça proveito da soma destas contribuições. Este trabalho tem como principal objetivo propor um processo de especificação de software que permita utilizar as melhores contribuições, dentro de seus domínios, de algumas das técnicas mais importantes utilizadas na engenharia de software. Assim, este processo deverá ser dirigido por casos de uso, em conjunto com a lista de eventos da análise essencial para se modelar os eventos e a conseqüente descrição dos caso de uso correspondentes, delineando também as fronteiras do sistema. O uso de técnicas de prototipação/storyboarding aproveitando técnicas JAD (Joint Application Development) permitirão uma maior interatividade com os usuários e stakeholders, facilitando a coleta de requisitos através dos casos de uso, assim como provendo meios para a medida da funcionalidade do sistema através da análise de pontos de ENEGEP 2004 ABEPRO 4605

2 função Finalmente o uso destas técnicas permitirá um aumento de velocidade na primeira iteração do ciclo de desenvolvimento do processo RUP (Rational Unified Process), como conseqüência do uso de prototipação. 2. Clientes e funções do sistema Os problemas relacionados ao levantamento e ao gerenciamento de requisitos tem se mostrado os principais fatores responsáveis pelo sucesso ou insucesso dos projetos de software. Um trabalho de pesquisa e análise desenvolvido pelo instituto Standish Group International e publicado em seu CHAOS Report (1994) apontou as causas mais comuns de sucesso (ou fracasso) de projetos de software, resultando nos 10 mais importantes critérios a serem considerados. Esta pesquisa foi realizada com executivos e gerentes de projetos de software a partir de um questionário que procurou estabelecer os principais critérios que poderiam influenciar positiva ou negativamente um projeto de software. Uma vez identificados os 10 principais critérios, cada um deles foi classificado de acordo com a quantidade de pontos obtidos na pesquisa. O objetivo da utilização desta tabela foi obter um índice variando de 0 a 100 pontos, demonstrando o potencial de sucesso que o projeto de software pode ter de acordo com a pontuação conseguida com a aplicação desses critérios. A tabela abaixo, adaptada do CHAOS Report (1994), relaciona os 10 principais critérios e os pontos atribuídos a cada um deles na pesquisa realizada: Ordem de Importância Critério de Sucesso(*) Qtd. Pontos 01 User Involvement Executive Management Support Clear Statement of Requirements Proper Planning Realistic Expectations Smaller Project Milestones Competent Staff Ownership Clear Vision & Objectives Hard-Working, Focused Staff 03 Total 100 Fonte: (CHAOS Report, 1994) - * Foram mantidos no idioma original para reforçar o significado de cada um deles. Tabela 1 Critérios de Sucesso CHAOS Report É importante notar que o primeiro e o terceiro critérios juntos, podem representar até 34 pontos e são relativos à participação e a comunicação constantes que devem existir entre os usuários e a equipe de desenvolvimento de sistemas durante a execução de todo o projeto de software. Pensando-se nos fatores apontados acima como ligados ao processo e tendo-se como meta a maneira como o usuário vê o sistema e a sua correspondente funcionalidade, obtém-se o foco de orientação da solução adotada. Por isso, as técnicas como: casos de uso, lista de eventos, JAD, prototipação/storyboards e pontos de função, devem ser utilizadas de modo ponderado e em conjunto, já que as mesmas possuem, justamente, como ponto focal, o modo como o usuário percebe as funcionalidades ENEGEP 2004 ABEPRO 4606

3 do sistema e métodos e medidas quantitativas para atingí-las. 3. Lista de eventos e casos de uso De acordo com a Análise Essencial, um sistema não existe por si só, ou seja, ele só existe para permitir que eventos que aconteçam no mundo externo, que são iniciados ou solicitados por agentes (entidades externas) e que tenham importância para o contexto definido para estudo do problema possam ser identificados e tratados pelo sistema (MCNEMANIM & PALMER, 1986). Um evento pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema uma resposta pré-planejada. À identificação, tratamento e armazenamento das informações relativas a cada evento, dá-se o nome de funcionalidade do sistema. E é o conjunto de funcionalidades que determina o contexto, as capacidades e as limitações na análise para a construção de um sistema de informações, pois a rigor o valor do sistema está na capacidade de responder com eficiência a todos os estímulos (eventos) a que for submetido. Desta forma, pode-se concluir que a base fundamental para definição do problema é a identificação, definição e detalhamento dos eventos que o sistema deve reconhecer e tratar, dentro dos limites impostos pela área de negócio (problema) em que o mesmo se encontra. Uma lista de eventos corresponde então a uma lista narrativa que mostra o comportamento, ou as respostas que o sistema deve processar para cada evento definido dentro dos limites desta solução. Por outro lado, um caso de uso corresponde a uma sequência relacionada de transações em um diálogo entre ator (entidade externa ao sistema) e o sistema que retorne um valor observável para este ator (JACOBSON, 1992). De certo modo, a lista de eventos e casos de uso são muito similares: ambos tentam definir uma visão externa do sistema sob a ótica de entidades externas ao mesmo (atores). A principal diferença é que a lista de eventos dá um indicação detalhada de qual resposta será dada para certo evento (MARTIN, 1998) e ( WINANT, 1996). Assim, a utilização de casos de uso para dirigir todas as fases do desenvolvimento de um sistema informatizado possue as seguintes vantagens (LEFFINGWELL, 2003): Força os desenvolvedores a pensar através da perspectiva do usuário, Casos de uso dão o contexto dos requisitos do sistema. Pode-se compreender porque um requisito é o que é, bem como o sistema atinge seus objetivos, Casos de uso ligam os usuários nos requisitos do processo, permitindo-os compreender o sistema proposto e dando a eles um meio de documentar e comunicar suas necessidades, Em muitas cirscunstâncias, os desenvolvedores escrevem os casos de uso, significando que estes, além de realmente compreenderem os requisitos, também são responsáveis por determiná-los, Os casos de uso servem como uma ferramenta crítica no processo de análise, permitindo a compreensão de que o sistema necessita fazer e como pode ser feito, Os casos de uso servem como uma ferramenta crítica para o processo do projeto e implementação, reduzindo o risco nas transições destes processos, Casos de uso podem ser utilizados diretamente no processo de teste, assegurando que o sistema faça realmente aquilo que se planeja que faça e Casos de uso servem como entrada para a documentação do usuário, convenientemente ENEGEP 2004 ABEPRO 4607

4 organizados em um formato passo a passo. Uma abordagem que considere o sistema como um mecanismo deste tipo é bastante eficaz para a comunicação entre usuários e desenvolvedores de sistemas, pois, por um lado, contorna a linguagem excessivamente técnica dos analistas de sistemas e a linguagem altamente redundante e ambígua dos usuários, e por outro lado, permanece suficientemente precisa para permitir que se produza uma especificação que seja base para as demais fases do projeto. 4. Storyboarding/Técnicas de Prototipação e JAD Storyboarding basicamente corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Foi utilizada inicialmente no cinema e cartoons e representa um esboço dos personagens e da história. Geralmente, storyboards podem ser categorizadas em três tipos (LEFFINGWELL, 2003): Passivo: Podem ser constituídos de quadros, fotos, esboços, etc. Neste caso é apresentado ao usuário as regras do sistema em sua seqüência, com a explanação do tipo Quando você faz isto, acontece isto, Ativo: Corresponde a uma seqüência de figuras que mostram uma descrição automatizada do modo como o sistema se comporta em um uso típico ou em um cenário operacional, por exemplo em uma apresentação automática de slides e Interativo: Permite ao usuário interagir sobre o sistema de um modo mais realístico, exigindo sua participação. Pode ser uma simulação dos possíveis cenários (protótipo não funcional), ou mesmo um protótipo funcional do sistema simplificado. A prototipação funcional de acordo com Boar (1984), implementa de modo simplificado parte dos requisitos do sistema através de ferramentas específicas e após obter-se os requisitos, o protótipo é descartado, passando-se para o modelo tradicional de desenvolvimento. Hoje, pode-se dizer que uma variante desta técnica é aplicada no processo incremental e iterativo do RUP, onde na verdade, após a primeira iteração de um ciclo de desenvolvimento, tem-se de fato um protótipo funcional do sistema (JACOBSON, 1999) e (KRUCHTEN, 2000). A prototipação não funcional obtém o comportamento dos usuários, stakeholders e do sistema através de interações e iterações com estes, por meio de um conjunto de interfaces gráficas simulando o comportamento real do sistema. Na medida que os casos de uso descrevem uma seqüência de eventos entre um ator e o sistema de modo a dar um resultado de valor para o usuário, sua utilização com prototipação não funcional se torna natural. Outro aspecto que pode ser considerado para a escolha de utilização de prototipação não funcional para a obtenção de requisitos corresponde ao fato de que para o ator basta que a resposta seja aquilo que o mesmo espera do sistema, não importando se esta resposta foi obtida através da implementação de um conjunto de funcionalidades ou somente pela simulação deste comportamento (ação/resposta). Assim, os casos de uso podem ser desenvolvidos em conjunto com uma série de interfaces de usuário, como por exemplo web browsers ou GUI (Graphical User Interface), uma vez que as interações entre os atores e o sistema implicam em uma série destas interfaces, que podem ser construídas visando os passos descritos pelos casos de uso (LEFFINGWELL, 2003). O uso de storyboards interativos, que na realidade são protótipos do sistema (funcionais ou não) permitem uma série de vantagens (BOAR,1984) e (LEFFINGWELL, 2003): ENEGEP 2004 ABEPRO 4608

5 Reduz a distância entre os participantes do projeto: A comunicação é um problema fundamental no desenvolvimento. Mesmo quando uma pessoa sabe o que quer, sempre ocorrem mudanças quando estas necessidades se transformam em requisitos, Permite um aumento da participação e interesse dos atores: Sistemas complexos que envolvem várias áreas de uma empresa requerem um compromisso, concordância e consenso entre vários atores para poderem operar corretamente, Sistemas através de exemplos: Com o passar do tempo, através do uso contínuo desta técnica, serão produzidos uma série de protótipos que poderão ser utilizados para demonstrar diferentes soluções aos usuários, permitindo estimular idéias, identificar estilos, mostrar o que é possível e permitir a explicação de suas necessidades em termos de modificações nos protótipos existentes, Aumenta a eficiência e diminui o tempo para a implementação das iterações planejadas: O uso desta técnica desde a elicitação de requisitos, permite que haja um ganho de produtividade no primeiro ciclo de desenvolvimento dos casos de usos no RUP, pois os requisitos estarão mais maduros antes do início do primeiro ciclo, mudando-se de requisitos não planejados para iterações planejadas, não sendo necessário fechar este ciclo para se ter o primeiro protótipo funcional do sistema, Permite medidas do tamanho das funcionalidades através da análise de pontos de função: a partir da identificação das funções do tipo dados e das funções do tipo transação e um esboço do modelo de dados do sistema é possível o cálculo dos pontos de função desde o início do sistema (elicitação) e seu refinamento durante os diversos ciclos de desenvolvimento (VAZQUEZ, 2003), É um veículo para a validação de requisitos e Permite desde cedo o teste das interfaces. A prototipação, tal como definida acima, tanto funcional, como não funcional pode ser aplicada a um conjunto de sistemas bons candidatos, que devem possuir as seguintes características (BOAR,1984): O sistema não exige grande quantidade de especificação algorítmica. A aplicação deve ser um problema estruturado com uma grande quantia de elementos de dados e relacionamento entre registros mas uma pequena quantia de processos algorítmicos, Os usuários devem estar dispostos e capazes de participar ativamente, assim como o gerente do projeto e O sistema possui muita interação com os usuários através de transações com relatórios associados aos banco de dados, não operando com muito processamento em lote ( batch ). A técnica de storyboarding interativa através do uso de protótipos desde a fase de elicitação de um projeto de software e acompanhando todo o ciclo de desenvolvimento deve ser orientada, sempre que possível, utilizando-se parte das práticas JAD (Joint Application Design) e que podem ser resumidas como se segue (COSTA, 1994): Dar preferência ao uso de reuniões ou sessões de trabalho, ao invés de entrevistas individuais: a principal vantagem é que os usuários se sentem prestigiados e parte integrante do processo de desenvolvimento, visto que suas opiniões são consideradas e as divergências são resolvidas de forma transparente, As decisões são baseadas em consenso: a forma mais produtiva de decisão é aquela alcançada por consenso, isto é, não ocorre necessariamente uma unanimidade, mas sim cada membro concorda que a solução encontrada é a melhor para o grupo e que é possível ENEGEP 2004 ABEPRO 4609

6 conviver com ela sem ferir convicções ou valores essenciais, Utilizar a figura do facilitador: sua responsabilidade consiste em sugerir métodos e procedimentos que ajudem o grupo a se concentrar em tarefas específicas. Também deve ser capaz de consultar a documentação existente sobre o projeto, entrevistar individualmente cada participante buscando entender o que eles fazem, esclarecer os participantes do que é a técnica e o que é esperado de sua participação, Papéis bem definidos: executivo patrocinador, gerente de projetos, equipe, facilitador e documentador e Planejar e preparar as reuniões: Cada reunião deve ter um única finalidade, com escopo e restrições bem definidos. 5. Aplicação Prática O exemplo em questão corresponde a uma parte do projeto ManWapp (Maintenence Wireless Application) que está sendo desenvolvido no LTI da Engenharia de Produção da POLI ( Este projeto tem o seguinte objetivo, retirado de seu documento de visão: O sistema terá com principal objetivo o gerenciamento de serviços de campo, ou seja, o serviço terceirizado, envolvendo as áreas de telecomunicações e energia elétrica, entre outras. Este gerenciamento se dará pelo acompanhamento da solicitação de chamadas (serviços) até o seu término, envolvendo a área administrativa do cliente, infra-estrutura, logística e manutenção e o prestador de serviços. Durante as discussões entre os especialistas do domínio e analistas, foi construída a lista de eventos (LE) do sistema (tabela 2) e a partir dela, vários casos de uso foram identificados, sendo que somente um será utilizado (figura 2 ). No. Evento Resposta Padrão 12 CallCenter informa Solicitação Chamada identifica CallCenter identifica Cliente registra SolicitacaoChamada 13 Atendente informa Solicitacão Chamada identifica Cliente registra SolicitacaoChamada 22 Prestador solicita Ordem Chamada identifica Prestador registra Envio Ordem Chamada Tabela 2 Lista de eventos (LE) parcial do sistema Manwapp Em sessões específicas de JAD para definição e refinamento de cada um dos casos de uso, foram feitas as simulações dos mesmos, através de um trabalho interativo com os participantes das reuniões (usuários, stakeholders, analistas, etc). Pode-se notar, na figura 2, o inter-relacionamento entre a lista de eventos, caso de uso, prototipação e pontos de funções. Assim, dado um caso de uso, pode-se detalhar cada ação e sua respectiva resposta a partir do detalhamento das interfaces gráficas do protótipo. Por exemplo, quando o cliente informa o CPF (passo 1), o atendente entra com esta informação no sistema (interface 1A ) e o sistema responde com uma lista de clientes (interface 1B). No passo 2 deste caso de uso, o atendente seleciona o cliente da lista (interface 1A ) e como resposta são mostrados detalhes da chamada selecionada pelo atendente ENEGEP 2004 ABEPRO 4610

7 (interface 2AB). Finalmente no passo 3 o cliente informa o problema ao atendente, que registra na inteface 2B e é aberta uma ordem de serviço para esta chamada. Call Atendente Center ReceberChamadas Call Atendente Center Caso de uso: Receber Chamada LE 13 Atores Call center e Atendente Entrada CPF, Nome, Descrição, Telefone e para contato Saída Lista de clientes e detalhes do cliente Pré-condiçoes Cliente cadastrado Pós-condições Chamada registrada Passo Descrição da ação Resposta Interface Tabelas função Exceções 1 Cliente informa CPF ou nome ao atendente (1A). Atendente seleciona cliente da lista (1B) Cliente informa para atendente descrição do problema e dados para retorno (2B) O cliente não sabe número de CPF, ou CPF incorreto. Atendente escolhe nome ou número correto da lista (1B) São mostradas informações genéricas sobre o cliente (1B) São mostradas detalhes de informações sobre o cliente (2A) Chamada é registrada São mostradas informações genéricas sobre o cliente (1B) 1.Pesquisa de clientes 1.Pesquisa de clientes e 2.Solicitação de chamada 2.Solicitação de chamada Pesquisa de clientes Clientes Clientes e Contratos Chamada Clientes 1 CE 1 CE 1EE 1 CE Figura 2. Caso de uso Receber Chamadas Mesmo quando o ator não corresponde a uma pessoa, o conceito de prototipação pode ser aplicado, uma vez que as informações trocadas sempre podem ser mostradas como uma ENEGEP 2004 ABEPRO 4611

8 interface gráfica (evento 12 da tabela 2). Na figura 2, no diagrama de caso de uso ReceberChamada, o ator Call Center é um arquivo que é importado pela sistema. A coluna tabelas corresponde às tabelas que o sistema acessa para poder dar suas respectivas respostas, sendo importante para se determinar os pontos de função do tipo dado. A coluna ponto de função permite estimar os pontos de função do tipo transação, identificando-se se é uma entrada externa (EE), uma saída externa (SE), ou uma consulta externa (CE), assim como os tipos de dados (pelas interfaces) e arquivos referenciados. Por exemplo, na figura 2, no passo 1 do caso de uso é necessário uma consulta externa (CE), sendo, neste caso envolvido dois tipos de dados (CPF e Nome) e um único arquivo referenciado (Cliente). Na medida que se conhece melhor o modelo de dados, pode-se refinar estas estimativas, inclusive identificando-se melhor os arquivos referenciados (VAZQUEZ, 2003). 6 Conclusões As diretivas propostas neste trabalho fazem parte do processo de desenvolvimento de software utilizado pelo elabsoft do LTI (Laboratório de Tecnologia de Informação) do Departamento de Engenharia de Produção da Escola Politénica da USP e pelo Labsoft da Divisão de Mecânica e Eletricidade do IPT e tem-se mostrado muito úteis em sua aplicação prática. Estas diretivas caminham no sentido de proporcionar um mecanismo eficaz para a comunicação entre usuários e desenvolvedores de sistemas, obtendo-se requisitos claros e consensuais, além de elementos para a estimativa do tamanho do sistema desde suas fases inicias de desenvolvimento. Os protótipos obtidos pela aplicação destas diretivas permitem o reaproveitamento das interfaces e casos de uso de negócio e facilitam o desenvolvimento de novos sistemas, através da técnica sistema por exemplos. Referências BOAR, B.H. (1985) Application Prototyping. John Wiley & Sons. 1 a Edição. New York. COSTA, O.W.D. (1994) JAD Joint Application Development. Livraria e Editora Infobook S.A. 1 a Edição. Rio de Janeiro. JACOBSON,G.(1992) Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley JACOBSON, G. & BOOCH, G. & RUMBAUGH, J. (1999) - The Unified Software Development Process. Addison Wesley Longaman Inc. 2 a Edição. Massachusetts. KRUCHTEN, P. (2000) The Rational Unified Process: An Introduction. Pearson Education. LEFFINGWELL, D & WIDRIG, D. (2003) Managing Software Requirements. A Use Case Approach. Addison-Wesley. 2 a Edição. Boston MARTIN, D. (1998) Prelimirary Design Use Case: Combining Use cases and Event Response Lists for Reuse and Legacy Enhancement. Sofware Engineering Notes Vol. 23, n. 1, p McMENAMIM, S.M & PALMER, J.P. (1984) - Essential Systems Analysis. Englewood Cliffs. 1 a Edição. N.J. THE STANDISH GRUP SAMPLE RESEARCH, The CHAOS Report, VAZQUEZ, E.V & SIMÕES, G.S. & ALBERT, R.M. (2003) - Análise de Pontos de Função: medição, estimativas e gerenciamento de projetos de software. Érica. 1 a Edição. São Paulo. WINANT, B. & FRANKEL, M. (1996) - Key Dictionary and Use Cases. Object Magazine, SIGS Publications, Vol. 6, p , November. ENEGEP 2004 ABEPRO 4612