Introdução. Aulas. ltodi.est.ips.pt/es. Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas

Transcrição

1 Sumário Introdução Joaquim Filipe João Ascenso Engenharia de Software 2005/06 EST, Setúbal Detalhes administrativos Definição de engenharia de software Contexto Relação com outras áreas e disciplinas 2 Professor: Sala F267 Dúvidas: Introdução pmacedo@est.ips.pt Página da Web ltodi.est.ips.pt/es Aulas Aulas teóricas e práticas: 2horas por semana Livro de trabalho: Gestão do Risco e da Qualidade no Desenvolvimento de Software, António nio Miguel, FCA ISBN Principle of Software Engineering Management,, Tom Gilb Addisson-Wesley ISBN extreme. NET Introduction extreme Programming Techiniques to.net developers,neil Roodyn Microsoft.net. Development Series,, ISBN

2 Avaliação Modos de Avaliação: T1 Exame (ponderação de 50% na nota final); Nota mínima m 10 valores T2 Projecto em duas partes. (Ponderação de 50% na nota final) Nota mínima 10 valores O que esperam aprender com a? disciplina de Engenharia de Software 5 6 O que o aluno deve ser capaz de fazer no fim deste semestre Enumerar e aplicar os princípios pios da Engenharia de Software. Capturar, especificar e analisar os requisitos de uma aplicação de Software Enumerar os diversos tipos de métricas m de avaliação de Software. Seleccionar as métricas m a aplicar num caso concreto, assim como saber aplica-las. las. Enumerar e descrever os princípios pios orientadores que regem o desenho de software O que o aluno deve ser capaz de fazer no fim deste semestre Enumerar os diferentes métodos m e linguagens para especificação de software Especificar uma aplicação de software utilizando pelo menos duas das abordagens dadas. Explicar qual a importância da verificação do software e enumerar diversas formas e ferramentas de verificação de Software 7 8 2

3 O que o aluno deve ser capaz de fazer no fim deste semestre Desenvolver um plano para verificação de uma aplicação concreta. Identificar as actividades principais que um gestor de projecto de software tem que realizar. Descrever diferentes abordagem de gestão de projecto de software. Enumerar e descrever os princípios pios básicos b que caracterizam as metodologias ageis O Projecto versus trabalho fim de curso Parte I Requisitos - Definição e especificação de requisitos Parte II Verificação - Planeamento e especificação de testes Comparação com a aplicação da metodologia agil O Projecto para quem não faz trabalho fim de curso Parte I Requisitos - Definição e especificação de requisitos de um projecto de software Parte II Verificação - Planeamento e especificação de testes Estudo de uma ferramenta de suporte à Eng de Software. Gestão de Testes Gestão de Versões Gestão de Projecto O que é a Eng. Software? A A ES é o campo da informática que trata dos aspectos relacionados com a construção de sistemas de software de grande dimensão e/ou complexidade, que exigem a existência de uma equipa ou equipas de engenheiros para o seu desenvolvimento [Ghezzi] Construção de software multi-versão multi- pessoa [Parnas]

4 O que é a Eng. Software? Uma campo da informática cujo objectivo é a construção de software sem erros, entregue a tempo e dentro do orçamento e que satisfaz as necessidades do utilizador. Além m disso, o software deve ser de fácil f modificação quando as necessidades dos utilizadores se alteram [Schach] Contexto Histórico Nascimento e evolução da ES como disciplina paralela à programação No início os problemas a resolver eram bem compreendidos e tipicamente mono-utilizador utilizador. Linguagens de alto nível n inventadas nos finais da década de 50 Profissão de programador => separação entre computador e utilizador Grandes projectos: finais dos 60 s OS Contexto Histórico Comparação Grandes projectos => desenvolvimento muito diferente dos pequenos sistemas! Dificuldades de escalabilidade das técnicas t de construção de programas Problemas com desvios de custos e prazos. Em grandes projectos os problemas semânticos são de importância capital => Actividade principal: Comunicação em vez de programação! Mudanças as ao nível n dos RH e das especificações têm grandes repercussões Pequeno projecto vs Grande projecto Uma pessoa vs Uma equipa Sem preocupação com as Tendo como ponto de partida as necessidades do utilizador vs necessidades do utilizador Programação Pequeno projecto vs Grande projecto Pequenas alterções vs Várias alterações Curta duração vs Longa duração Barato vs Caro Engenharia

5 Da Programação á Engenharia Pessoas O factor mais importante no sucesso/insucesso de um produto Variedade de competências Bem escasso Processos Organizar e gerir os esforços os da equipa Essenciais para alcançar ar um produto de qualidade Diferentes tipos (e.g. desenvolvimento, especificação, teste, etc..) Ferramentas: Suportam as pessoas e os processo Simplicidade vs complexidade Pessoas + Processos + Ferramentas Produto Relação com Outras Áreas da Linguagens de Programação Sistemas Operativos Engenharia de Software Teoria da Computação Bases de Dados Inteligência Artificial Relação com Outras Áreas da Linguagens de programação Modularidade (e.g. Compilação por partes). Separação da especificação e implementação. Perspectiva da interface com o sistema de software como uma linguagem (de programação). Formalização conduz/permite a Automatização. Sistemas Operativos Primeiros grandes sistemas de software: máquinas m virtuais, níveis de abstracção (modularização), separação das políticas dos mecanismos (e.g. equidade no tratamento de jobs vs. time- slicing), são conceitos herdados dos SO. Portabilidade dos SO representam a influencia da ES no desenho de SO

6 Relação com Outras Áreas da Bases de Dados Independência dos dados (separação da especificação da instanciação) Programação baseada em componentes (a base de dados pode ser vista como um componente reutilizável) A ES também m influenciou as BD pois a tentativa de usar BDs como suporte para projectos de ES mostrou algumas das suas limitações: Armazenamento de grandes objectos não estruturados (e.g. Código C objecto ou executável) Armazenamento de grandes objectos estruturados (e.g. Programas ou manuais) Manutenção de várias v versões do mesmo objecto Relação com Outras Áreas da Inteligência Artificial Os sistemas de software de IA são dos mais complexos jáj construídos. No entanto começam a ser construídos sem uma noção clara do que se pretende obter. Este facto requer um processo de construção diferente do modelo cascata tradicional. A utilização de Lógica L permite elevar o grau de abstracção na especificação de sistemas e em linguagens de programação (declarativas). Os sistemas periciais beneficiam da utilização de conceitos de ES, nomeadamente a modularização subjacente à separação entre base de conhecimento e motor de inferência. Assistentes de programação (incluindo suporte a actividades de verificação) Relação com outras áreas da Teoria da Computação Máquinas de estados finitas: servem de base à especificação de software e como modelos para o desenho e estruturação de software. E.g. Protocolos de comunicação e analisadores de linguagem. Autómatos push-down servem de base à especificação de compiladores e parsers para linguagens de programação. Petri-nets nets,, inicialmente utilizadas para modelar sistemas de hardware, têm sido utilizadas na especificação de sistemas de software e na verificação das propriedades destes sistemas. Semântica denotacional, tem permitido desenvolver a área de especificação de linguagens de programação. Relação com Outras Disciplinas Gestão Engenharia de Software Engenharia de Sistemas

7 Relação com Outras Disciplinas Gestão Muitos tópicos t de ES têm a ver com a gestão (técnica e de Recursos Humanos). A gestão de projectos inclui: Orçamenta amentação, controlo, planeamento de tarefas e de RH, decomposição de tarefas. Contratação de pessoal, motivação, liderança, a, etc. A ES oferece também à Gestão um novo domínio onde testar as teorias de Gestão. Relação com Outras Disciplinas Engenharia de Sistemas (a área de conhecimento onde se estudam os sistemas complexos) A hipótese é que háh leis que governam o comportamento de sistemas com muitos componentes com relações complexas. Esta área é útil quando se pretende concentrar a atenção no sistema como um todo em vez de nos seus componentes individuais (e.g. fábricas, f edifícios, pontes,...) As competências de um Engenheiro de Software Programar fluentemente em várias v linguagens. Conhecer diferentes abordagens ao desenho de sistemas Capaz de traduzir requisitos indicados de forma vaga e incompleta para especificações precisas. Capaz de entender as necessidades do utilizador do sistema Capaz de entender um problema em diversos níveis de abstracção Capaz de trabalhar em equipa 27 Considerações Gerais O objectivo de qualquer actividade de engenharia é construir algo: tipicamente um produto. A ES pretende construir sistemas de software. Comparativamente, o software é um produto: Abstracto O software requer mais engenharia do que produção Maleável Fácil de modificar Complexidade Mais difícil de representar e gerir 28 7

8 Concreto vs abstracto O software não é palpável Pilha de papel Conjunto de ficheiros O software não pode ser facilmente interpretado Como ler código c? Como ler um milhão de linhas de código c? Como ler uma parte do código c fonte? A abstracção afecta o progresso Como medir progresso Uma grande quantidade de código c significa que se está mais próximo do resultado final do que uma menor quantidade? Imutável vs... Maleável O software pode ser alterado facilmente: Editar o texto, recompilar e testar Cada produto de SW sofre várias v modificações Restrições da maleabilidade: Não se pode alterar o hardware Não se pode alterar o modelo de negócio Uma alteração no código c têm de ser vista como uma alteração nas especificações/ desenho Pequenas mudanças as podem ter resultados desastrosos (não visíveis veis à primeira)