Engenharia de Software Professor Ítalo Quirino Brilhante
Engenharia de Software
Professor Ítalo Quirino Brilhante
Contrato Pedagógico
•HorárioInício: 19:15hIntervalo: 20:30h às 20:45hFinal: 22:00h
•Controle de FaltasMáximo Permitido: 25% - (16 faltas)
•Chamada:1 chamada por dia
Contrato Pedagógico
•CelularColocar no modo SilenciosoPedir licença aos colegasAtender fora da sala de aula (não próximo a porta)
•LimitesMaturidadeRespeito
Equipamentos Eletrônicos
Contrato Pedagógico
•Equipamentos Eletrônicos
É permitido o uso de notebooks e netbooks durante as aulas;Não será permitido brincar com equipamentos eletrônicos durante a aula.
Contrato Pedagógico
•Avaliações
Não serão permitidos o uso de computadores, calculadoras, telefones celulares, smartphones e outros dispositivos eletrônicos.
Contrato Pedagógico
•Webclasses
Todos os documentos da disciplina estarão disponíveis no portal;
Textos e informações adicionais; Listas de Exercícios; Datas importantes; Comunicados.
Contrato Pedagógico
•Sugestões e Opiniões
Todas as sugestões e críticas poderão ser enviadas por e-mail.
Contrato Pedagógico
•AvaliaçõesMetodologia de avaliação progressiva.Avaliações sem consultaAvaliações Individuais
Prova de Reconstrução no final da Etapa com todo o conteúdo.
Contrato Pedagógico
•Trabalhos:Listas de Exercícios;Pesquisas (ABNT).
Contrato Pedagógico
•Datas e PrazosTodas as datas de prova e de entrega de trabalhos serão negociados. Uma vez definidas somente serão alteradas por motivo de força maior.
Metodologia de Avaliação•Para aprovação
Lançamento das notas de 0 a 10Nota 1º = Prova 1º (Valor7,00) + trabalhos e Atividades (Valor 3,00)Nota 2º = Prova 2º (Valor 7,00) + trabalhos e Atividades (Valor 3,00)Média Final = (Nota 1º + Nota 2º) /2Média Final >= 7,00 -- aprovado sem exameMédia Final < 7,00 e >= 4,00 -- exame finalMédia Final < 4,00 -- reprovadoExame Final >= (10 – Média Final) -- aprovadoExame Final < (10 – Média Final) -- reprovadoFrequência >= 75% das aulas dadas -- aprovado (condição analisada em conjunto com a média final)Frequência < 75% das aulas dadas -- reprovado (independente da média final obtida)
Ementa da DisciplinaConceitos básicos de Engenharia de Software
Sistemas Sociotécnicos
Processo de Software
Requisitos de Software
Processos de Engenharia de Requisitos
Modelos de Sistema
Especificação
Projetos de Arquitetura
Arquiteturas de Aplicações
Desenvolvimento Rápido de Software
Reuso de Software
Engenharia de Software Baseada em Componentes
Evolução de Software
Gerenciamento de Configuração
Engenharia de Software Orientada a Serviços
Desenvolvimento de Software Orientado a Aspectos
Referência Bibliográfica
IAN, Sommerville. Engenharia de Software. Tradução: Ivan Bosnic e Kalinka G. de O. Gonçalves. São Paulo: Pearson Addison Wesley, 2011. ISBN 978-85-7936-108-1. PRESSMAN, Roger S. Engenharia de software. Tradução: José Carlos Barbosa dos Santos. São Paulo: Makron Books, 1995. 1056 p. ISBN 85-346-0237-9. REZENDE, Denis Alcides. Engenharia de software: para excelência em sistemas empresariais. Curitiba: Apta, 1997. 141 p.
Engenharia de Software
É um ramo da engenharia cujo foco é o desenvolvimento dentro de custos adequados de sistemas de software de alta qualidade.
SOMMERVILLE.
Termo utilizado nos anos 1970, quando a engenharia de software era praticamente inexistente.
Expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem. adequadamente ou pudessem ser validados.
Crise de Software
Problemas:
• Software inadequado;• Cronogramas e custos imprecisos;• Inexistência de dados históricos sobre o processo de desenvolvimento.
Crise de Software
Problemas:
• Comunicação deficiente - insatisfação de usuários;• Carência de conceitos quantitativos sobre
confiabilidade, qualidade e reusabilidade;• Software existente e de difícil manutenção.
Crise de Software
Solução:
• Combinar métodos para as fases de desenvolvimento;
• Ferramentas para automatizar esses métodos;• Técnicas para assegurar qualidade.
Crise de Software
• Programas de computador e os dados de documentação e configuração associados.
• Entidade abstrata.
Software
Conceitos mais amplos:
• Comportamento exibido por essa sequência de instruções quando executada em um computador;
• Estrutura de dados para manipular informação;
Software
• Genéricos;
• Sob encomenda.
Tipos de Software
• Saber o que o software deve fazer;• Ferramentas; • Linguagem; • Tempo e custos elevados de desenvolvimento;• Prever falhas (antes de entregar);• Tratar manutenção e versões.
Dificuldades para desenvolversoftware
• Métodos e Técnicas: detalhes de como fazer
• Metodologias: como aplicar
• Ferramentas: automatizam os métodos, dão apoio à utilização.
CASE => (Computer-Aided Engineering):
Ferramentas integradas para desenvolver software.
Engenharia de Software - ES
• Formalidade;
• Abstração;
• Decomposição;
• Generalização;
• Flexibilização.
Princípios da ES
• Formalidade: Ter programas mais confiáveis com baixo custo e bom desempenho e o software deve ser desenvolvido de acordo com passos definitivos com precisão e seguidos de maneira efetiva.
• Abstração: É o processo de identificação de um determinado fenômeno da realidade considerando apenas os aspectos mais relevantes.
Princípios da ES
• Decomposição: É o processo de dividir o problema para que cada subproblema seja resolvido de uma maneira específica. Usado para controlar a complexidade do software.
• Generalização: Reutilizar as soluções dos problemas
• Flexibilização: Alterar o software sem que ele tenha um problema de execução.
Princípios da ES
• 60% dos custos são de desenvolvimento;• 40% dos custos são de teste.
• Para software sob encomenda, os custos de evolução frequentemente excedem os custos de desenvolvimento.
Custos da ES
Abordagens estruturadas para desenvolvimento de SW que incluem modelos de sistemas, notações, regras, recomendações de projetos e guias de processo.
Métodos da ES
• Sistemas de software que têm a intenção de fornecer apoio automatizado para atividades de processo de software.
• É uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de engenharia de software.
• Exemplo:• CaseStudio 2• Dr. Case• ErWin• Visio • Together, etc.
Ferramentas CASE (Computer Aided Software Engineering )
• São elaborados vários diagramas que em conjunto constituem praticamente uma “planta” do sistema a ser desenvolvido.
Com o advento da Orientação a Objetos, surgiu também uma nova maneira de documentar sistemas, que é a UML ( Unified Modeling Language ),
O que é CASE (Computer Aided
Software Engineering )?
• Funcionalidade;• Desempenho;• Fácil de manter;• Confiável;• Usabilidade.
Atributos de um bom software
Estar à altura do aumento de diversidade, demandas para redução do tempo de entrega e desenvolvimento de software digno de confiança.
Desafios da ES
É um conjunto de atividades cujo objetivo é o desenvolvimento ou evolução do software.
Atividades: - Especificação;
- Desenho e Implementação; - Validação;
- Evolução.
Processo de Software
Atividades de Processo de Software
•Especificação:Decidir para que funcionará o software e suas restrições de operação.
•Desenho e Implementação Produção do Software a partir das definições.
•Validação: (V & V)Testar se está de acordo com o que o cliente necessita para ser validado.
•Evolução:O software tem que ser atualizado para sempre garantir as necessidades do cliente.
27/07/13
É uma representação de um processo de software, apresentada sobre uma perspectiva específica. Ou seja, é uma estratégia para o desenvolvimento do software.
Define a ordem de execução das atividades durante as fases de engenharia de software.
Modelo de Processo de Software
Modelo de Processo de SoftwareO modelo de ciclo de vida é a primeira escolha aser feita no processo de software. A partir destaescolha definir-se-á desde a maneira maisadequada de obter as necessidades do cliente,até quando e como o cliente receberá sua primeiraversão operacional do sistema.
27/07/13
Existe um modelo ideal?
O perfil, a complexidade do negócio docliente, o tempo disponível, o custo, aequipe, o ambiente operacional são fatoresque influenciarão diretamente na escolha dociclo de vida de software a ser adotado.
27/07/13
1. Cascata ou ciclo de vida clássico ou tradicional;
2. Modelo evolutivo;
3. Transformação formal;
4. Integração de Componentes reusáveis;
5. Espiral.
Modelos de Processo de Software
O que diferencia um modelo de processo do outro?
• É a ordem em que as fases vão ocorrer;• O tempo e a ênfase dados a cada fase;• As atividades presentes;• Os produtos entregues.
27/07/13
• Modelo mais antigo e o mais amplamente conhecido da engenharia de software;
• Modelado em função do ciclo da engenharia convencional;
• Requer uma abordagem sistemática, sequencial ao desenvolvimento de software;
• O resultado de uma fase é entrada para outra fase.
Modelo Cascata
• Utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos.
• Utilização:• Fazer adaptações ou aperfeiçoamentos em um
sistema já existente.• Necessidade de uma nova funcionalidade e os
requisitos estão bem definidos e são estáveis.
Modelo Cascata
Modelo Cascata
Definição de Requisitos
O processo de coleta dos requisitos é intensificado e concentrado especificamente no software.
Deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos.
Fases - Modelo Cascata
Projeto do Sistema
Tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à
qualidade, antes que a codificação se inicie.
Fases - Modelo Cascata
Implementação
Tradução das representações do projeto para uma linguagem “artificial” resultando em instruções executáveis pelo computador.
Fases - Modelo Cascata
Teste
É a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.
Fases - Modelo Cascata
Manutenção
Provavelmente o software deverá sofrer mudanças depois que for entregue ao cliente.
Causas das mudanças: - Falhas;-Adaptação do software para acomodar mudanças em seu ambiente externo;-Exigência do cliente para acréscimos funcionais e de desempenho.
Fases - Modelo Cascata
Utilização• Existe um conjunto de requisitos do usuário estáveis e
de alta qualidade;• O sistema completo deve estar disponível de um única
vez; • Recomendado para sistemas onde a segurança e a
confiabilidade tem grande importância.
27/07/13
• Projetos reais raramente seguem o fluxo sequencial que o modelo propõe;
• Logo no início é difícil estabelecer explicitamente todos os requisitos. No começo dos projetos sempre existe uma incerteza natural;
• Fases são dependentes uma da outra;• Não é permitida mudança dos requisitos no meio do
processo de desenvolvimento.
Desvantagens
Referências
• Pressman, R. Software Engineering: A Practitioner's Approach. McGraw-Hill, 6th edition, 2006.
• Sommerville, I. Software Engineering:) International Computer Science Series) 8th edition, 2006.
1) O que é software?2) Cite 4 Características de Software.3) O que é a Engenharia de Software? 4) Qual o objetivo da Engenharia de Software? 4) O que é um processo de software?5) O que é um modelo de Processo de Software?6) Dê exemplos de modelos de Processo de Software e descreva o
Modelo cascata.
Sugestão:Vincular a Engenharia de Software a um assunto visto em algumadisciplina cursada na instituição.
Questionário - Introdução