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.

italouniandrade@gmail.com

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