Um Processo de Desenvolvimento de Softwares Embarcados

1. Um Processo de Desenvolvimento de SoftwaresEmbarcados Marcos Salenko Guimarães - RA 946056 Curso: MO409 – Engenharia de Software I Profa. Eliane Martins Março - 2003

2. Definição • “Embedded systems means that their computing power is built into, or embedded in, the system. Embedded processors are usually designed for specific applications rather than general purposes”. Garth Gullekson www.rational.com

3. Tópicos • Introdução • Ciclo de Vida • Especificação de Requisitos do Sistema • Especificação de Requisitos de Software • Projeto • Codificação e Testes Unitários • Testes de Integração • Testes de Sistemas • Diretrizes e Regras • Verificação • Auditoria • Gerenciamento • Observações

4. Referências • http://www.utdallas.edu/research/esc/homepage.html • http://wwwbroy.informatik.tu-muenchen.de/research/research.html • http://epic.onion.it/workshops/w04/ • http://www.parasoft.com/ • http://www.mathworks.com • http://www.embedded.com • http://www.rational.com • http://www.ercim.org/publication/Ercim_News/enw52/nacsa.html • http://www.ddjembedded.com • BERGER Arnold S., “Embedded Systems Design: An Introduction to Processes, Tools and Techniques”, Paperback. • “SOFTWARE” development and documentation. MIL-STD-498. 1994.

5. Introdução • Tem-se esse processo para nortear o desenvolvimento de software embarcado de modo a: • assegurar o desenvolvimento do “software” com qualidade e produtividade, • assegurar controle de modificações de maneira a acompanhar e controlar a evolução do “software”, • assegurar que o “software” atenda aos requisitos e necessidades especificadas, • assegurar suporte (e portanto a satisfação do cliente) durante toda a vida operacional do “software”, • possibilitar o reuso de “software” desenvolvido para outros sistemas de natureza semelhantes. • facilitar a adequação do “software” a novos requisitos do cliente em um espaço de tempo menor.

6. CICLO DE VIDA

7. Especificação de Requisitos de Sistema • Capacidades identificadas => itens de configuração de “software” (CSCIs) e, se aplicável, itens de configuração de “hardware” (HWCI). • Saídas: • Especificação de Requisitos de Sistema • Plano de Desenvolvimento de “Software”

8. Especificação de Requisitos de Software • Técnicas estruturadas e/ou orientadas a objetos. • As ferramentas DOORS, RequisitePro são simplesmente citadas. • Prototipação • Saídas: • Especificação de Requisitos de “Software” • Especificação de Requisitos de Interface. • Plano de Teste de Sistema.

9. Projeto • Projeto Preliminar • Estrutura geral do “software” • Inicia a documentação Documento de Teste de “Software” • Projeto Detalhado • Decomposto em unidades de “software”. • Cada unidade com dados de entrada e saída, sinais, tratamentos de exceção, interrupções, algoritmos, tratamento de erros, conversões de dados, bancos de dados, limitações, etc • Saídas • Documento de Projeto de Software • Documento de Teste de Software

10. Codificação e Testes Unitários • Codificação • A codificação deve seguir estritamente o especificado no documento de projeto e procedimentos normativos tais como padrões de codificação. • Testes Unitários • Cada desenvolvedor deve testar as unidades de “software” sob sua responsabilidade.

11. Testes de Integração • Preconiza a integração do tipo SW-SW. Unidades de “software” são integradas em seus respectivos componentes e os componentes, por sua vez, são integrados até constituírem o item de configuração (CSCI). • Saída: • Documento de Descrição de Teste de Sistema

12. Testes de Sistema • Preconiza a integração do tipo HW-SW. O CSCI(s) é integrado ao sistema e testado com o objetivo de demonstrar que o “software” e o “hardware”, juntos, atendem a todos os requisitos de sistema especificados. • Saídas: • Documento de Descrição de Versão • Manual do Usuário • Documento de Relatório de Teste de Sistema

13. Diretrizes e Regras • REUSO • Na fase de análise de requisitos de sistema, a análise de reuso é executada. • Na fase de projeto – verificação dessa análise. • No projeto detalhado - a extração de unidades de “software” a partir de bibliotecas de “software” reusáveis. • Uma atividade final de reuso ocorre ao final da fase de testes de sistema.

14. Diretrizes e Regras • Controles de Documentação • Responsabilidade, Identificação, Armazenagem e Padrão de documentação • Tipos de Documentações: • documentos de projeto (SDD, STD, etc...) • relatórios de projeto (relatórios de revisões/auditorias, atas de reuniões, decisões de projeto, etc) • documentos de expediente (cartas, fax, memorandos,correios eletrônicos) • formulários (“Problem Reports”, “Investigation Reports” e “Change Proposals”) • Controles de Código • Identificação, Armazenagem e Padrão de codificação.

15. Verificação • São previstas duas revisões: • Revisão de Requisitos de Software; • Especificação de Requisitos de “Software”; • Especificação de Requisitos de Interface. • Revisão Crítica de Projeto • Documento de Projeto de “Software”; • Documento de Teste de “Software”.

16. Auditoria • FCA - Auditoria Funcional da Configuração • verificar que o produto sendo entregue atende aos requisitos especificados para o mesmo. • É opcional se o sistema foi desenvolvido na própria empresa mas é obrigatória se foi desenvolvido por terceiros.

17. Gerenciamento • Gerenciamento de Processo de Software • Planejamento • Procedimentos de acompanhamento • Métricas • Métricas de Gestão • Métricas de Código • Base de Dados de Projeto • Treinamento

18. Gerenciamento • Gerenciamento de Configuração • a evolução do “software” seja ordenada, • os problemas encontrados estão sendo resolvidos, • somente modificações autorizadas estão sendo incorporadas no “software”, • seja possível recuperar versões anteriores de um produto de “software”.

19. Em nenhum ponto do processo não obriga e nem recomenda o uso de alguma ferramenta CASE. Não há definição de papéis da equipe. Conseqüentemente, não há regras de formação de equipes para realizar uma determinada tarefa. Não há especificação de técnica de modelagem no processo Enfoque maior no reuso e na prototipação. Alta adaptabilidade => oferece procedimentos de “tailoring”. Preocupação maior na interface entre SW e HW. Observações