1. Caracterização do Problema

Na atualidade, em um mundo em que cada vez mais a tecnologia se faz necessária para facilitar o cotidiano dos indivíduos, sistemas embarcados (SE) estão se tornando presentes em diversas atividades humanas para auxiliar nas tarefas rotineiras, trazendo conforto, segurança, rapidez, entre outros benefícios. À medida que o custo de fabricação e desenvolvimento desse tipo de sistema diminui, a presença dele tende a se tornar cada vez mais comum no cotidiano das pessoas [Carro e Wagner, 2003]. Estima-se que por volta de 2010, softwares em SE na área automotiva terão por volta de 1 Gigabyte de tamanho, sem levar em consideração dados de navegação em DVD, seria algo como termos um computador desktop dentro de um veiculo [Boulanger e Van Quang, 2008]. Para que tais objetivos sejam atingidos com sucesso é necessário que as funções do software de controle trabalhem corretamente [Bostaschanjan et al.,2005]. Segundo Graaf et al (2003), para permitir que processos, produtividade e qualidade do software embarcado sejam incrementados, as empresas necessitam aplicar técnicas de Engenharia de Software durante o processo de desenvolvimento. A área de software na indústria automotiva é considerada um dos campos mais desafiantes da Engenharia de Software, onde encontramos requisitos de tempo real juntamente com requisitos de segurança, distribuídos em diversos microcontroladores e processadores. Com o aumento contínuo das inovações tecnológicas, por exemplo, a tecnologia drive-by-wire, na qual o controle da direção do veículo é de responsabilidade de um SE, torna-se essencial um tratamento sistematizado dos requisitos envolvidos [Botaschanjan et al., 2005]. O propósito geral de um SE é controlar um dispositivo físico enviando sinais de controle a atuadores em reação a entrada de sinais provida pelo usuário, ou por sensores capturando determinados parâmetros de estado relevante do sistema. No desenvolvimento de um SE reativo e de tempo real, a especificação dos requisitos é um dos problemas críticos, pois requisitos não funcionais e outras métricas qualitativas (como por exemplo, custos, restrições de tempo, restrições de hardware, tempo de desenvolvimento, confiabilidade, manutenção, portabilidade, reuso de componentes, manutenibilidade, segurança e consumo de energia), passam a ter grande importância no projeto, pois influenciam diretamente os requisitos funcionais do sistema [Barbiero e Hexsel, 2006], [Vahid e Givards, 2002]. Broy (1997), Carro e Wagner (2003) apontam para o fato de que quando um SE apresenta problemas, mais de 50% dos defeitos encontrados ocorrem depois da entrega do dispositivo e quando são reportados pelos usuários não são problemas de correção de implementação, mas equívocos na captura dos requisitos, chamados de erros conceituais de requisitos. A questão time-to-market faz com que o projeto tenha o tempo de prototipagem encurtado, forçando que o início do desenvolvimento de um projeto seja o mais rápido possível. Projetos de SE são conduzidos geralmente por engenheiros da área de hardware, com visões de mecânica ou eletrônica; na maioria das companhias, pessoal de software não está envolvido nas decisões ao nível de projeto de hardware. O resultado é que muitas vezes o software não cumpre as expectativas do integrador, problema que poderia ser resolvido se no domínio do hardware houvesse o envolvimento de equipes de software, principalmente durante a concepção do sistema. Assim, muitas empresas estão buscando por mudanças em seus processos de desenvolvimento, onde engenheiros de software deverão participar logo no início do projeto [Graaf et al., 2003], [Walls, 2006].

2. Fundamentação Teórica

SE estão cada vez mais presentes em nosso dia a dia, o avanço da Engenharia Eletrônica permitiu uma drástica redução no custo de produção de hardware, juntamente com o aumento da capacidade de processamento. No coração dos SE estão os microcontroladores, encontrados em diversos dispositivos eletrônicos, como DVD players, veículos, aeronaves, telefones celulares, eletrodomésticos, letreiros digitais, equipamentos médicos, entre outros. Os microcontroladores são projetados para ter praticamente todos os componentes encontrados em um computador de propósitos gerais, como memórias voláteis e não voláteis, barramentos, unidade lógica aritmética, conversores analógico/digital etc., dentro de um único circuito integrado, cabendo ao desenvolvedor codificar um programa e adicionar os componentes externos necessários que farão a função de entrada e saída. Chae (2006) ressalta que desenvolver um SE não é simplesmente colocar um microcontrolador e interligar alguns componentes eletrônicos, embora seja comum uma equipe de desenvolvimento escolher inicialmente um microcontrolador, desenvolver o hardware para a aplicação e transferir o projeto para a equipe de software dar continuidade. Neste estilo de desenvolvimento há pouca comunicação ou interação entre os participantes, trazendo diversos riscos ao projeto, como aumento do custo e o não atendimento aos prazos para início de produção. A Engenharia de Requisitos é aceita como uma etapa fundamental na concepção de qualquer software, e vem se consolidando como um processo que desenvolve atividades como elicitação, análise, modelagem, especificação, validação e gerenciamento de requisitos [Robertson e Robertson, 2006]. Martin (2002) enfatiza que SE modernos possuem características que demandam uma nova abordagem para especificação, desenvolvimento e implementação, que pode ser alcançada com a combinação de métodos de desenvolvimento de hardware e software. Para Aoyoma (2006), métodos convencionais da Engenharia de Requisitos são incompletos ou não satisfazem totalmente às necessidades do desenvolvimento de SE, não resolvendo de forma adequada alguns problemas, principalmente para produtos eletrônicos de consumo, onde os usuários são desconhecidos e seus comportamentos dificilmente podem ser observados de forma direta. SE são diferentes de sistemas computacionais tradicionais, pois inúmeras funções a serem implementadas muitas vezes possuem soluções que podem ser programadas por software e por hardware, simultaneamente. Como definir quem realizará essas funções ainda não está claro em nenhuma metodologia de desenvolvimento de SE. Tradicionalmente as organizações desenvolvem primeiramente o hardware, tornando-o fixo para que posteriormente se desenvolva o software (também chamado de firmware), justificando-se tal procedimento devido ao fato de software ser flexível, portanto mais fácil de ser corrigido (uma visão que vem sendo muito questionada ultimamente). Tipicamente um projeto de SE envolve muitos stakeholders, que atuarão no contexto geral para elaborar as especificações de requisitos, passando por clientes, analistas de negócios, analistas de requisitos, engenheiros de hardware e engenheiros de software [Graaf et al., 2003]. Broy (1997) identifica duas fases no processo de elicitação de requisitos para SE: a pré-fase, na qual ocorre a elaboração geral dos requisitos do produto e sua estratégia no mercado (definição de metas e questões mercadológicas do produto planejado); e a fase principal, que se baseia nos resultados da pré-fase para produzir um acordo entre os grupos envolvidos no que diz respeito aos requisitos técnicos, o resultado da fase principal é um documento de especificação dos requisitos técnicos do SE .

3. Caracterização da Contribuição

A área de Engenharia de Requisitos para SE ainda é pouco explorada, muitos projetos são abandonados devido ao fato dos requisitos terem sido mal formulados, evidenciando a carência de uma metodologia que auxilie a capturar requisitos de forma eficaz. Infelizmente a percepção de que os requisitos foram mal capturados ocorre tardiamente durante o ciclo de desenvolvimento do software embarcado, inviabilizando a implementação do sistema como um todo. Este trabalho pretende contribuir com as áreas de Engenharia de Requisitos e de SE, por meio da elaboração de um guia que auxilie o desenvolvedor de SE a elicitar os requisitos informais junto aos stakeholders, e auxilie na transição e refinamento dos requisitos informais para os requisitos técnicos. O guia deverá auxiliar ainda na identificação das funcionalidades a serem implementadas por meio de hardware ou software, definindo o melhor caminho a ser utilizado e proporcionando um particionamento temporário durante a definição dos requisitos, encapsulando-os em pequenos módulos. Ao final deste trabalho espera-se disponibilizar um guia de elicitação de requisitos em que membros envolvidos em um projeto de sistema embarcado baseado em microcontroladores (em princípio acredita-se que este guia esteja mais apto a auxiliar projetistas de SE de pequeno e médio porte), elicitem os requisitos funcionais e não funcionais apoiados por uma metodologia sistematizada, orientando passo a passo a melhor forma de conduzir as atividades elicitação junto aos stakeholders e engenheiros de sistema embarcado (que tipicamente são pessoas com formação em engenharia mecânica, elétrica ou eletrônica). A utilização deste guia irá contribuir para minimizar os erros de desenvolvimento de SE, acelerar o desenvolvimento e melhorar a qualidade da captura dos requisitos funcionais e não funcionais do sistema.

4. Estado atual do trabalho

O trabalho foi dividido em 5 fases: (i) elaboração de um questionário para entrevistar profissionais que atuam no mercado de SE, com o propósito de verificar quais são suas ações durante a pré-fase e a fase principal, obtendo-se assim uma visão do estado da prática adotada no desenvolvimento de SE; (ii) aplicação do questionário na região metropolitana de Campinas-SP, envolvendo empresas da área automotiva, automação industrial, domótica, equipamentos médicos, telecomunicação e entretenimento; (iii) elaboração do guia de elicitação de requisitos, com base nos problemas e dificuldades detectados no estado da prática em SE (evidenciados pelos resultados advindos das respostas do questionário), e nas recomendações previstas no padrão IEEE STD 830-1998 e no template Volere para especificação de requisitos (largamente adotados para elicitação e especificação de requisitos); (iv) desenvolvimento de um estudo de caso aplicando o guia de elicitação de requisitos proposto (o estudo de caso focalizará o nicho de SE para eletrodomésticos); e (v) avaliação dos resultados obtidos com o estudo de caso, esta avaliação envolverá os desenvolvedores de SE que responderam o questionário inicial da pesquisa. A fase (i) já foi concluída e as fases (ii) e (iii) estão em andamento. A figura 1 apresenta a estrutura do guia proposto, baseado sobre o estado da prática em SE no mercado, template Volere e nas recomendações do padrão IEEE STD 830/1998. Figura 1 – Visão geral dos componentes do guia para elicitação de requistos de SE

5 - Trabalhos Relacionados

Alguns estudos relacionados têm sido realizados com a finalidade de propor uma metodologia para desenvolvimento de software embarcado [Liggesmeyer e Trapp, 2009], [Pretschner et al., 2007], e quase são unânimes em tentar adaptar metodologias já existentes para desenvolvimento de software para computação de propósitos gerais, ajustando-as para as necessidades de SE. Outros estudos apontam para a utilização conjunta de notações UML [Boulanger e Van Quang, 2008], [Pretschner et al., 2007], como ferramenta de simulação de modelos, verificação de ciclos e iterações de funcionalidades, buscando diminuir a lacuna entre a concepção de hardware e software para SE [Walls, 2006]. Nos últimos anos a utilização de metodologias ágeis tem sido adotada no desenvolvimento de software para escritórios e projetos baseados em web, mas devido às restrições de ambiente e recursos, bem como as diversidades técnicas, fazem com que modelos ágeis não possam ser facilmente aplicadas para SE [Wang, 2007]. Em nenhum dos trabalhos citados anteriormente foram encontrados um guia específico para elicitação de requisitos para SE, seus autores apenas enfatizam a necessidade de um guia para auxiliar desenvolvedores de SE.

6. Considerações Finais

Com o crescente aumento da demanda por desenvolvimento de SE, e vinculado a esta demanda, também a necessidade da melhoria da qualidade dos SE, que estão se tornando cada vez mais complexos, este trabalho irá contribuir para diminuir a lacuna que existe entre as áreas de Engenharia de Requisitos e SE. Muitos métodos, técnicas e ferramentas têm sido desenvolvidos na área de Engenharia de Requisitos, mas este desenvolvimento pouco tem sido explorado na área de SE. Acreditamos que trata-se de um trabalho necessário, e desafiador, a ligação entre estas duas áreas, e que novos horizontes de pesquisa surgirão a partir da efetiva integração destas.

Referências

Aoyama, M. (2005). Persona-and-Scenario Based Requirements Engineering for Software Embedded in Digital Consumer Products. In 13th IEEE International Requirements Engineering Conference (RE'05), pages 85-94. Barbiero, A. and Hexsel, R. (2006). Ambiente de suporte ao projeto de sistemas embarcados. In WSCAD 2006 Workshop em Sistemas Computacionais de Alto Desempenho, Ouro Preto, MG, pages 1-8. Botaschanjan, J., Kof, L., Kühnel, C. and Spichkova, M. (2005). Towards verified automotive software. In Proceedings of the Second International Workshop on Software Engineering For Automotive Systems, pages 1-6. Boulanger J. and Van Quang, D. (2008). Experiences from a model-based methodology for embedded electronic software in Automobile. In Information and Communication Technologies: : From Theory to Applications. ICTTA 3rd International Conference on, pages 1-6. Broy, M. (1997). Requirements engineering for embedded systems. In Proc. First Workshop Formal Design of Safety Critical Embedded Systems (FemSys). Carro, L. and Wagner, F. (2003) Capítulo 2 das Jornadas de Atualização em Informática. In XXII JAI 2003. (Org.). Sistemas Computacionais Embarcados. Campinas: Sociedade Brasileira de Computação, v. 1, p. 45-94. Chae, H. (2006). The Partitioning Methodology in Hardware/Software Co-Design Using Extreme Programming: Evaluation Through the Lego Robot Project. In Proc. of the sixth IEEE Internacional Conference on Computer and information Techonology, pages 187. Graaf, B., Lormans, M., and Toetenel, H. (2003). Embedded software engineering: the state of the practice. In IEEE Software archive Volume 20 , Issue 6 , p 61 – 69. Liggesmeyer, P. and Trapp, M. (2009). Trends in Embedded Software Engeneering. In IEEE In Software, IEEE, Vol. 26, No. 3, p 19-25. Martin, G. (2002) UML for Embedded Systems Specification and Design: Motivation and Overview. In Proceedings of the 2002 Design, Automation and Test in Europe Conference and Exhibition(DATE’02), p 773-775 Pretschner, A., Broy, M., Kruger, I. H., and Stauner, T. (2007) Software Engineering for Automotive Systems: A Roadmap Future of Software Engineering. In International Conference on Software Engineering - Future of Software Engineering , p 55-71 Robertson, J., and Robertson, S. (2006) Mastering the requirements Process. Second Edition. Addison-Wesley Professional. Vahid, F., and Givargis, T. (2002). Embedded System Design: A Unified Hardware/Software Design. John Willey & Sons. Walls, C. (2006). Embedded Software – The Works. Elsevier. Wang, Z. (2007). Fuxi: An agile development environment for embedded systems. In IEEE 31st Annual International Computer Software and Applications Conference, p 631-632.