A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "1 Marcos Salenko Guimarães - RA 946056 Curso: MO409 – Engenharia de Software I Profa. Eliane Martins Março - 2003 Um Processo de Desenvolvimento de Softwares."— Transcrição da apresentação:

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

2 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 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 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 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 6 CICLO DE VIDA

7 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 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 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 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 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 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 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 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 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 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 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 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 19 Observações 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.


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

Apresentações semelhantes


Anúncios Google