SOFTWARE PRODUCTION LINES: AN ORGANAZATION MODEL FOR SOFTWARE FACTORIES FOR THE REUSE OF THE HUMANCOMPUTER INTERFACE

Transcrição

1 SOFTWARE PRODUCTION LINES: AN ORGANAZATION MODEL FOR SOFTWARE FACTORIES FOR THE REUSE OF THE HUMANCOMPUTER INTERFACE Felipe Rustan Reis de Souza (Universidade Salvador, Bahia, Brasil) - feliperustan@gmail.com Colaborador: Paulo Caetano da Silva (Universidade Salvador, Bahia, Brasil) - paulo.caetano@pro.unifacs.br This paper presents a solution to problems related to poor requirements specification, inserting concepts related to software engineering in an organization model of software factories, through an Automation Framework Production Lines with process steps based on flowcharts supported by techniques for the development of Human-Computer Interface, with the goal of improving the efficiency of projects and software products. Key words: Human-Computer Interface - Software Engineering - Software Factories - Flowcharts. LINHAS DE PRODUÇÃO DE SOFTWARE UM MODELO DE ORGANIZAÇÃO DE FÁBRICAS DE SOFTWARE PARA REUSO DA INTERFACE HUMANO-COMPUTADOR Este artigo apresenta uma proposta para solução de problemas relacionados a má especificação de requisitos, inserindo conceitos relacionados a Engenharia de Software em um modelo de organização de fábricas de software, por meio de um Framework de automatização de Linhas de Produção com etapas do processo baseado em fluxogramas apoiados pelas técnicas para o desenvolvimento da Interface Humano-Computador, com o objetivo de melhoria da eficiência de projetos e produtos de Software. Palavras-chave: Interface Humano-Computador - Engenharia de Software - Fábricas de Software - Fluxogramas. 0847

2 Introdução Novas práticas de Engenharia de Software podem garantir a boa qualidade de um projeto de desenvolvimento de software sem afetar o prazo de sua execução. A união dos conceitos de Linhas de Produção de Software (LPS) e Interface Humano-Computador (IHC) (LYNCH & PALMITER, 2002), ambos como áreas afins da Engenharia de Software, pode proporcionar melhorias aos processos de desenvolvimento de software em Fabricas de Software, resolvendo problemas de qualidade do projeto, do produto e prazo para execução do projeto, resultando em um maior índice de acerto no levantamento dos requisitos e também maior rapidez na entrega do produto. 1 Contextualização do problema Em Linhas de Produção de Software o conceito de Fábrica de Software permeia em relação à padronização de todas as etapas da construção de software, que possam ser executadas, buscado uma especialização do profissional que a executa (Eduardo M. F. Jorge, 2011). Nas fábricas de software ou de programas as etapas de análise e projeto não são realizadas pela equipe, então, o programador desenvolve o seu trabalho a partir das especificações existentes em um documento de requisitos previamente elaborado. Nesta técnica de desenvolvimento as possibilidades do produto está em desacordo com o que foi planejado são grandes, pois não há contato direto dos desenvolvedores com a fase de análise e projeto. Os colaboradores envolvidos em um projeto com essa estruturação são passíveis de erros, principalmente erros relacionados ao mau entendimento da necessidade do usuário, este fato acaba sendo agravado pela falta de participação da análise e projeto, como consequência, ao final do trabalho o produto pode não ser entregue de acordo com o que o cliente solicitou. O problema principal a ser abordado neste trabalho diz respeito às Fábricas de Softwares estruturadas por células exemplificado na Seção 2.2, que também possuem problemas, como erros de especificação e de usabilidade, que implicam em retrabalho, o que provoca extrapolação do prazo, logo o problema de qualidade e prazo ficam evidenciados. 1.1 Motivação Atualmente existem técnicas de apoio a gestão de projetos usadas em organizações que operam em forma de fábricas, como o CMMI - Capability Maturity Model Integration e o MPS-Br. Assim como a norma 9126 da ISO que propõe atributos de qualidade para requisitos não-funcionais, com foco no produto, processo e qualidade de uso. Porém, apenas o uso dessas técnicas não garante qualidade ao processo e ao produto. Além disso, o mercado de softwares não é segmentado, pois muitas empresas de desenvolvimento não se especializam em um domínio específico da aplicação e desenvolvem software para qualquer finalidade e para qualquer tipo de cliente. Portanto, ao início de cada projeto é grande a curva de aprendizado para o entendimento do domínio da aplicação. Uma possível solução para lidar com esses problemas é buscar melhoria na especialização e divisão do trabalho, por isso é proposto neste artigo, para a fase de levantamento de requisitos, o uso da abordagem FAST (Family-oriented Abstraction, Specification and Translation) (Weiss e Lai, 1999) a qual separa a engenharia de domínio da engenharia da aplicação proporcionando para a solução de melhoria, a divisão do trabalho. A Engenharia de Domínio é um processo para o desenvolvimento de uma família de aplicações reusáveis em um domínio particular de problema e a Engenharia de Aplicações para a construção de uma aplicação específica da família a partir do reuso de artefatos de software previamente produzidos no processo da Engenharia de Domínio (Leite, A. Girardi, R, 2009). O uso da técnica FAST está sendo proposto conjuntamente com os conceitos Interface Humano- Computador para garantir usabilidade, os conceitos de Marketing tecnológico, para garantir o posicionamento correto da organização em relação ao mercado e o conceito de fábricas de software híbrido (Eduardo M. F. Jorge, 2011), o qual une modelo de organização de fábrica por célula com o modelo por projeto, essa é uma estrutura já utilizada em projetos. Espera-se a otimização dessa 0848

3 estrutura de fábrica de software por meio das melhorias propostas neste artigo. 1.2 Objetivos do Trabalho O objetivo deste trabalho é explorar o uso da abordagem de fábricas de Software híbrida no desenvolvimento de softwares. Especificamente o objetivo deste trabalho é especificar uma ferramenta para ajudar a eliminar problemas relacionados a Linha de Produção de Software, como especificação de requisitos e usabilidade e também reduzir problemas relacionados ao prazo de execução de projetos, causados por requisitos mal especificados. Também será discutido um novo modelo de fabricas de software hibrida estruturada de acordo com os conceitos de marketing e a abordagem FAST. Portanto, para minimizar os problemas citados, uma solução possível é o desenvolvimento de um mecanismo de apoio a LPS. A solução proposta é uma ferramenta de desenvolvimento, que tratará o projeto em termos de sua usabilidade, entendimento e domínio do negócio. Para tal é importante reunir as melhores heurísticas encontradas em soluções relacionadas e às práticas recomendadas pela literatura, é necessário também elaborar um catálogo com informações que possam servir de base para identificar o perfil da organização e também o nível dos usuários, assim espera-se dimensionar o projeto mais próximo dos requisitos que um software precisa possuir para ser aceitável pelos seus usuários. O uso dessa ferramenta pretende auxiliar na redução do tempo das avaliações heurísticas. Espera-se que com a proposta não seja necessário desenvolver um software por completo correndo o risco de ao final ser criticado por uma equipe de profissionais de IHC, ou até mesmo avaliar a cada etapa do desenvolvimento. Além disso, o Engenheiro de Software pode dosar o quanto o sistema precisa ser adaptável ás necessidades do usuário ou se pode ser um sistema de usabilidade genérica com design universal e adaptativo, resultando menos esforço no desenvolvimento de recursos de interface. 2 Conceitos Esta seção tratará dos conceitos envolvidos na proposta apresentada nesse trabalho para resolução dos problemas apresentados na Seção 1. Na Seção 2.1, serão abordados conceitos relacionados à Interface Humano-Computador e Marketing, na Seção 2.2, aqueles relativos às Linhas de Produção de Software. 2.1 Interface-Humano-Computador - IHC Encontra-se na literatura sobre IHC (NIELSEN, 1993) que os projetistas de softwares e profissionais de IHC buscam métodos rápidos e baratos de avaliação de interfaces. Para atender esse objetivo métodos de inspeção de usabilidade foram propostos com a promessa de oferecer informação de usabilidade de modo mais rápido e barato que o tradicional teste de usabilidade(nielsen, 1993). Entre as técnicas mais comuns encontram-se a avaliação heurística (ROCHA & BARANAUSKAS, 2003) e o percurso cognitivo (MACK & NIELSEN, 1994). O percurso cognitivo é uma técnica de inspeção de usabilidade, seu objetivo é avaliar o projeto no que se refere à facilidade de uso. Nessa técnica, o avaliador simula o usuário navegando na interface para executar tarefas típicas. Tarefas mais frequentes como login e cadastro, edição e exclusão de registros são as primeiras a serem analisadas, mas tarefas críticas, como recuperação de erro, também são percorridas. A técnica percurso cognitivo foi desenvolvida para interfaces que podem ser aprendidas de forma exploratória e interfaces que exigem muito treinamento. Avaliação heurística identifica problemas de usabilidade seguindo um conjunto de heurísticas ou diretrizes (guidelines) e baseia-se em melhores práticas definidas por especialistas de IHC, nas quais cada conjunto de elementos gráficos da interface, por exemplo, uma tela de cadastros, seus elementos e seu uso, deve ser analisado pelo seguinte grupo de heurísticas: 0849

4 -Visibilidade do estado do sistema: mantém o usuário informado sobre o estado do sistema através de feedback como mensagens de erro ou de confirmação de uma ação concluída; -Uso de conceitos, vocabulário e processos familiares aos usuários, fazendo correspondência com o mundo real; -Controle e liberdade do usuário: fornece alternativas e saídas de emergência, possibilidades de desfazer uma ação (undo) e refazê-la (redo); -Consistência e padronização: palavras, situações e ações semelhantes devem significar conceitos ou operações semelhantes; -Prevenção de erros: evita que o erro aconteça informando ao usuário as consequências de suas ações; -Reconhecimento em vez de memorização: torna objetos, ações e opções visíveis e compreensíveis; -Flexibilidade e eficiência de uso: oferece caminhos alternativos para uma mesma tarefa, permite que os usuários personalizem ações frequentes; -Design estético e minimalista: evita porções de informações irrelevantes; -Ajuda e documentação: devem ser fáceis de buscar, focadas no domínio e na tarefa do usuário, e devem listar passos concretos a serem efetuados para atingir seus objetivos. Estas heurísticas são relevantes no desenvolvimento de interfaces que se propõem a ser fáceis de aprender e com padrões reconhecidos por testadores de software como importante para se desenvolver um sistema de qualidade que possa ser usado de forma compatível às características dos grupos de usuários. A Figura 1 ilustra o objetivo principal de um projeto de interface genérica, que pode ser usada por níveis distintos de usuários, ou seja, os leigos e os experientes, separados na figura pelas circunferências verde e da azul, com uma pequena interseção que representa uma área em comum de usabilidade que deve ser explorada para alcançar uma interface que possa ser utilizada por qualquer usuário. Figura 1 Divisão dos grupos de usuários. 0850

5 As informações sobre níveis de usuários, perfil de organizações e o conteúdo sobre IHC necessárias neste trabalho estarão disponíveis na solução, que podem ser retiradas da literatura específica que traz o conceito de ciclo de adoção tecnológica (GEOFFREY MOORE, 1999), o qual define que cada cliente consumidor de software tem características próprias relacionadas com a competitividade e concorrência, a depender de qual fase ele está no ciclo de adoção tecnológica, exemplificado na Figura 1.2. Figura 1.2 Divisão do mercado e seus respectivos participantes. As empresas desenvolvedoras de software que buscam maior fatia do mercado consumidor devem passar pelo ciclo de adoção tecnológica desde sua criação. Para conseguir chegar a o mercado principal, a empresa desenvolvedora passa por este ciclo, no qual cada subdivisão possui consumidores com características diferentes no que diz respeito a tecnologia que consome, são eles os inovadores, visionários, pragmáticos e conservadores. A Figura 1.3 mostra algumas características de cada mercado consumidor, na seta amarela pode-se identificar os tipos de usuários, especialista e generalista, e também, apoiantes e ceticos, formando um plano cartesiano com diversos níveis de consumidores, os quadrados vermelhos apontam qual deve ser o foco de uma empresa que desenvolve sistemas. No quadrado tecnologia por exemplo, é informado que consumidores inovadores compram sistema acreditando na tecnologia, os visionários compram acreditando no sistema como um produto e os pragmáticos só compram o software se estiver no mercado principal, já conservadores apenas compram se a organização passar a imagem de companhia, ou seja, segurança no investimento, pois sabe-se que existe uma robustez econômica (GEOFFREY MOORE, 1999). 0851

6 Figura 1.3 Ciclo que mostra as mudanças de características dos consumidores de software. 2.2 Linhas de Produção de Software - LPS A construção de uma LPS possui estratégia similar ao do CMMI definida pela SEI - Instituto de Engenharia de Software ( e indica que a Engenharia de Software, Gerência Técnica e Gerência Organizacional são as áreas centrais da estratégia de construção de uma LPS. (CLEMENTS e NORTHROP, 2002) afirmam que são três as atividades de construção de uma LPS, desenvolvimento do núcleo do artefato, desenvolvimento do produto e gerência da linha de produção. As Fábricas de Software caracterizam-se por atuarem em apenas uma porção do processo produtivo do software. Neste caso o insumo inicial é uma ordem de serviço acompanhada de toda a especificação do software a ser desenvolvido. Sendo assim, as etapas de modelagem do negócio, análise e projeto do sistema já foram feitas, cabendo à fábrica a execução das etapas de construção, testes e ajustes. Para fábricas organizadas por projetos, os profissionais são alocados nas etapas da construção do software, de acordo com o seu perfil e formação. Esta alocação ocorre na etapa de planejamento efetuado no inicio de cada projeto (Eduardo M. F. Jorge, 2011). A Figura 2 exemplifica a estrutura organizacional de uma fabrica de software orientada por células, na qual existem subdivisões técnicas, célula Java, célula.net, célula de testes, codificação e controle de qualidade. 0852

7 Figura 2 Fábrica de Software estruturada por celulas. Fonte: 3 Ferramentas Usadas na Solução Proposta Esta seção discute alguns trabalhos que propõem soluções relacionadas a proposta apresentada neste artigo. Seção 3.1, FAST e na Seção 3.2 o Framework Maker. 3.1 Abordagem FAST A FAST (Family-oriented Abstraction, Specification and Translation) (WEISS, 1999) é uma estratégia de desenvolvimento de família de produtos que proporciona a identificação de características comuns da análise do domínio, as funcões principais da FAST são: identificar o contexto, descrever o domínio, fornecer um conjunto de conceitos fundamentais, identificar as características comuns e variabilidades e identificar e registrar informações úteis durante a fase de análise e projeto. A Figura 3 ilustra a interação das etapas de produção da FAST, o insumo inicial é a análise do dominio que após implementada interage com o ambiente de produção da aplicação onde é desenvolvido o modelo da aplicação e a própria aplicação, o processo continua com o feedback entre a Engenharia de Domínio, Engenharia de Aplicação e o controle de qualidade. 0853

8 Figura 3 Estrutura do FAST. Fonte: (WEISS, 1999) 0854

9 10th International Conference on Information Systems and Technology Management CONTECSI 3.2 Framework Maker O Maker ( é uma ferramenta que possui uma linguagem de programação totalmente visual, possibilitando a rápida construção de sistemas corporativos de pequena, média e alta complexidade. A proposta apresentada neste artigo está baseada em alguns conceitos usados no Framework Maker como o desenvolvimento de softwares baseado em fluxogramas. O Maker abstrai a parte de codificação e implementação, atribuindo o trabalho de desenvolver a solução sob a responsabilidade de um especialista no domínio que analisa o negócio e então começa a desenvolver o fluxograma que servirá de entrada para a ferramenta Maker. A Figura 3.1 mostra a interface gráfica do Maker onde é possível ver no centro da tela um fluxograma que representa todo o processo do software a ser gerado Figura 3.1 Interface gráfica do Framework Maker. Fonte:pt.wikipedia.org 0855

10 4 Ferramenta de Apoio ao desenvolvimento de softwares em Fábricas Híbridas Este trabalho propõe a criação de uma ferramenta, semelhante ao Maker, para ser utilizada em Fábricas de Software híbrida, unindo o modelo por projeto com o modelo de células. Os papéis das células principais é fornecer o apoio a elaboração do percurso cognitivo e caracterização do usuário apartir de informações das entrevistas com os usuários. As células principais também realizarão a análise do domínio de acordo com a abordagem FAST, o papel das sub-células é realizar tarefas relacionadas a engenharia de aplicação, no caso, fazer a montagem dos releases e ajustes de interface. A ferramenta de apoio deverá gerar as telas e os fluxos de navegação para sub-células, nos quais cada tela terá os recursos de IHC implantados. Na ferramenta, o pacote de Geração de Navegação, presente na Figura 4, deve ter como entrada um fluxograma baseado no percurso cognitivo, identificado pelo usuário como o ideal, o sistema de Geração de Navegação retornará páginas HTML interligadas com opções de navegação, que podem ser reaproveitadas automaticamente a partir do catalogo de informações e também de um repositório de componentes comum, como ícones de avançar e voltar, conteúdo auto-explicativo, e assim, posteriormente, sejam acrescentados aos elementos de menor relevância no documento de requisitos. O diagrama ilustrado na Figura 4 descreve brevemente a arquitetura da ferramenta e também o processo de interação dos envolvidos, dos artefatos gerados no projeto e da estrutura organizacional da Fábrica de Software Híbrida. O engenheiro de software da célula de projeto, responsável pelas etapas do ciclo de desenvolvimento do projeto, interage com o Pacote de Engenharia de Aplicação e com o Módulo de Geração de Releases que gera os protótipos. O mesmo engenheiro de software e o analista de negócio da célula de negócio interagem com o Módulo de Gerência de Componentes, Perfil e IHC do Pacote de Engenharia de Domínio que serve para gerenciar os dados e os componentes necessários para que o módulo que gera os releases possa importar e utilizar no projeto. Então os desenvolvedores da sub-célula de projeto fazem a montagem dos releases para serem disponibilizados para os clientes validarem e assim dar continuidade no ciclo incremental do projeto. 0856

11 Figura 4 - Modelo de processo do Framework proposto. 0857

12 A Figura 5 representa como deve ser a estrutura organizacional da Fábrica de Softwares hibrida, mostrando como é a interação das células e sub-células, descrevendo todo o fluxo do processo de desenvolvimento. A célula de gerência de negócios alimenta o processo com as informações necessárias para início do projeto, também interage com as células principais de cada projeto em execução para especificar os detalhes do projeto através de módulos da própia ferramenta, o engenheiro de software na célula de projeto elabora o percurso cognitivo, define o grupo de usuários e especificando aos colaboradores das sub-células qual tipo de perfil pertence o projeto, o ciclo de desenvolvimento termina na sub-célula com os ajustes da solução gerada a partir do módulo de geração de navegação que irá gerar páginas HTML. Figura 5 - Estrutura da Fábrica de Software Hibrida. 0858

13 5 Conclusão e Trabalhos Futuros Este artigo buscou discutir as dificuldades enfrentadas pelas empresas que trabalham com linhas de produção de software. A pesquisa bibliográfica efetuada reuniu as soluções existentes no mercado: IHC, novos modelos de LPS, FAST e conceitos de marketing. Os benefícios esperados com a aplicação da solução proposta são: especialização e divisão do trabalho de equipe, categorizadas em Engenharia do Domínio e a Engenharia da Aplicação, potencializando cada uma dessas divisões da Fábrica de Software utilizada na solução. A solução também proporciona a disseminação da informação e conhecimento, pois todas as células interagem com as informações necessárias de análise e projeto, fazendo que os programadores fiquem envolvidos com o entendimento do negócio apesar da especialização e divisão do trabalho, este envolvimento ameniza as consequências desta separação. Em relação às próximas etapas deste estudo ficam pendentes a etapa de definição dos requisitos e as definições técnicas a respeito das tecnologias que podem ser utilizadas para o desenvolvimento da solução e também da ferramenta que será necessária para gerir os componentes, montar e gerar os releases. Outra etapa que será realizada é o preenchimento dos dados referentes às informações de perfil de clientes, nível dos usuários, heurísticas do IHC e os próprios componentes de tela. 0859

14 9 REFERENCIAS Clements, P. & Northrop, L.Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, Crossing the Chasm: Marketing and Selling High-tech Products to Mainstream Customers(1991, revised 1999) Eduardo M. F. Jorge Estrutura Organizacional Alternativa para Desenvolvimento de Software, em Fábrica de Software Universidade Federal da Paraíba (2011) Leite, A. Girardi, R. (2009) A Process for Multi-Agent Domain and Application Engineering: the Domain Analysis and Application Requirements Engineering Phases, In: 11th International Conference on Enterprise Information Systems (ICEIS 2009), Proceedings of the 11th International Conference on Enterprise Information Systems, Ed. INSTIIC. Milan, Italy. Lynch, G. and Palmiter, S. (2002) Design and Rapid Evaluation of Usable Web Sites, CHI2002 tutorial notes. Mack, R. & Nielsen, J. (1994) Usability Inspection Methods. New York, NY: John Wiley & Sons. Nielsen, J., Usability Engineering, Academic Press, Cambridge, MA,1993. Rocha, H. V. e Baranauskas, M.C. C., Design e Avaliação de Interfaces Humano- Computador, Campinas, SP:NIED/UNICAMP, WEISS, D. M.; LAI, C. T. R. Software product-line engineering: a family-based software development process. Addison-Wesley,