Introducao a Engenharia de Software

Prévia do material em texto

U N I V E R S I D A D E T E C N O L Ó G I C A F E D E R A L D O P A R A N Á 
D E P A R T A M E N T O A C A D Ê M I C O D E E L E T R Ô N I C A 
P R O F . V I T O R Y A N O 
Introdução à Engenharia de 
Software 
O que é Engenharia de Software? 
 O que é Engenharia? 
 O que é Software? 
 Engenharia de Software 
 Por que Engenharia de Software? 
 Qualidade de software 
O que é Engenharia? 
 “Ciência ou profissão de adquirir e de aplicar os 
conhecimentos matemáticos, técnicos e científicos na 
criação, aperfeiçoamento e implementação de utilidades, 
tais como materiais, estruturas, máquinas, aparelhos, 
sistemas ou processos, que realizem uma determinada 
função ou objetivo.” 
 “Arte de aplicar conhecimentos científicos, 
conhecimentos empíricos e habilitações específicas para 
a criação de estruturas, dispositivos e processos que se 
utilizam para converter recursos naturais em formas 
adequadas ao atendimento das necessidades humanas.” 
O que é Engenharia? 
 Ramos da engenharia: 
 Elétrica 
 Eletrônica 
 Civil 
 Mecânica 
 Química 
 Agrária 
 Ambiental 
 Genética 
 Tráfego 
 Florestal 
 Naval 
 Aeronáutica 
 Segurança 
 Sanitária 
 Biomédica 
 Alimentos 
 Nuclear 
 Produção 
 Aeroespacial 
 Computação 
 ... 
O que é Engenharia? 
 Características da Engenharia (SWEBOK, 1999): 
 Educação de iniciação profissional validada e legitimada pela 
sociedade 
 Registro da adequação à prática através de certificação 
voluntária ou licenciamento compulsório 
 Desenvolvimento de habilidades especializadas e educação 
profissional continuada 
 Suporte através de sociedades profissionais 
 Compromisso a normas de conduta frequentemente 
estabelecidas em um código de ética 
O que é Engenharia? 
 Hoje, Engenharia tornou-se um título profissional, 
regulamentado, em áreas específicas do 
conhecimento; 
 A diferença fundamental entre as Engenharias está 
nos materiais e nas teorias utilizadas; 
 A Engenharia de Software, particularmente, se difere 
das outras Engenharias por não tratar de materiais 
concretos nem de teorias da Física. 
O que é Software? 
 “Sentença escrita em uma linguagem computável, 
para a qual existe uma máquina capaz de interpretá-
la. A sentença é composta por uma sequência de 
instruções e declarações de dados, armazenável em 
meio digital. Ao interpretar o software, a máquina 
computável é direcionada à realização de tarefas 
especificamente planejadas, para as quais o software 
foi projetado.” 
O que é Software? 
 “(...) o termo „Programa‟ significa o programa 
original e todas as cópias completas ou parciais do 
mesmo. Um Programa consiste em instruções 
legíveis por máquina, seus componentes, dados, 
conteúdo audiovisual (tal como imagens, texto, 
gravações ou figuras) e materiais licenciados 
relacionados.” (Licença de uso de software da IBM) 
O que é Software? 
 Sistema é um conjunto de elementos e processos que 
se relacionam para o desempenho de um objetivo 
comum; 
 O software afeta e depende do sistema utilizado; 
 Sistema e Software não são a mesma coisa! 
Engenharia de Software 
 Engenharia de Software é uma área da Ciência da 
Computação voltada especificamente ao 
desenvolvimento de software; 
 “É a aplicação dos princípios científicos, métodos, 
modelos, padrões e teorias que possibilitem 
gerenciar, planejar, modelar, projetar, implementar, 
medir, analisar, manter e aprimora um sistema de 
software” 
 
Engenharia de Software 
 As técnicas muito se assemelham as utilizadas por 
engenheiros no projeto e desenvolvimento de 
equipamentos, automóveis, construções, etc. 
 Alguns conceitos estão mais relacionados à 
Administração empresarial do que Ciência da 
Computação. 
Engenharia de Software 
 Corpo de conhecimentos da Engenharia de Software: 
 Matemática 
 Ciência da Computação 
 Administração de Projetos 
 Ciências Cognitivas e Fatores Humanos 
 Engenharia de Computadores 
 Administração e Ciências Administrativas 
 Engenharia de Sistemas 
Engenharia de Software 
 Conceitos fundamentais: 
 Abstração 
 Métodos e Notações de Análise e Design 
 Prototipação de Interface com Usuário 
 Modularidade e Arquitetura 
 Ciclo de Vida e Processo de Software 
 Reuso 
 Métricas 
 Suporte Automatizado 
Engenharia de Software 
 10 áreas da Engenharia de Software (SWEBOK, 
1999): 
 Gerência de Configuração de Software 
 Gerência de Engenharia de Software 
 Processo de Engenharia de Software 
 Ferramentas e Métodos 
 Qualidade de Software 
 Requisitos de software 
 Design de software 
 Construção de Software 
 Teste de Software 
 Manutenção de Software 
Engenharia de Software 
 Quem é o Engenheiro de Software? 
 Programador / Gerente de projetos / Analista de negócios 
 Contato com o cliente 
 Conhecimento das necessidades do cliente e requisitos para o 
desenvolvimento do software 
 
Por que Engenharia de Software? 
 O processo de desenvolvimento de software não está 
restrito à programação; 
 Pesquisa do Gartner Group (2002) sobre problemas 
no desenvolvimento de software: 
 80% estão relacionados ao levantamento de requisitos 
 20% erros de implementação 
Por que Engenharia de Software? 
 Mitos no desenvolvimento de software (Pressman): 
 Mitos administrativos 
 Mitos do cliente 
 Mitos do profissional 
Mitos administrativos 
 Mito: Se a equipe dispõe de um manual de padrões e 
procedimentos de desenvolvimento de software, 
então a equipe está apta a encaminhar bem o 
desenvolvimento. 
 Realidade: É necessário que o que conste no dado 
manual reflita a prática de desenvolvimento de 
software e que esta prática seja verificada com 
frequência, para confirmar o uso do conhecimento. 
Mitos administrativos 
 Mito: A equipe tem ferramentas de 
desenvolvimento de software de última geração, uma 
vez que eles dispõe de computadores de última 
geração. 
 Realidade: Mais importante que ter um hardware 
de última geração é ter ferramentas para a 
automatização do desenvolvimento de software. As 
chamadas ferramentas CASE (Computer-Aided 
Software Engineering). 
Mitos administrativos 
 Mito: Se o desenvolvimento do software estiver 
atrasado, basta aumentar a equipe para honrar o 
prazo de desenvolvimento. 
 Realidade: Quanto mais pessoas pegarem “o barco 
andando”, pior. Por que os novos profissionais 
deverão ser treinados e isto será feito por membros 
da equipe, o que vai implicar em maiores atrasos no 
cronograma. 
Mitos do cliente 
 Mito: Uma descrição breve e geral dos requisitos do 
software é o suficiente para iniciar o seu projeto. 
Maiores detalhes podem ser definidos 
posteriormente. 
 Realidade: Este é um dos problemas que pode levar 
um projeto ao fracasso. O cliente deve ser 
questionado a fim de definir o mais precisamente 
possível os requisitos importantes para o software: 
funções, desempenho, interfaces, restrições de 
projeto e critérios de validação. Estes são pontos 
fundamentais para o sucesso do projeto. 
Mitos do cliente 
 Mito: Os requisitos de projeto mudam 
continuamente durante o seu desenvolvimento, mas 
isto não representa um problema, uma vez que o 
software é flexível e poderá suportar facilmente as 
alterações. 
 Realidade: O software é mais flexível que a maioria 
dos produtos manufaturados, mas não existe 
software que suporte uma alteração significativa em 
seu escopo sem influenciar no custo e no prazo de 
entrega. 
Mitos do profissional 
 Mito: Após a edição do programa e a sua colocação 
em funcionamento, o trabalhoestá terminado. 
 Realidade: A realidade é justamente o contrário. 
Segundo estatísticas, após a implantação ocorrerão 
50% a 70% do esforço do desenvolvimento de 
software (manutenção). 
Mitos do profissional 
 Mito: Enquanto o programa não entrar em 
funcionamento, é impossível avaliar a sua qualidade. 
 Realidade: A preocupação com a qualidade do 
software deve ocorrer durante todo o processo de 
desenvolvimento, ao final de cada etapa deve ser 
feita uma verificação dos critérios de qualidade. 
Mitos do profissional 
 Mito: O produto a ser entregue no final do projeto é 
o programa funcionando. 
 Realidade: O produto final não é apenas o software 
funcionando, mas também um conjunto importante 
de documentos, que acompanham o mesmo. 
Por que Engenharia de Software? 
 
Qualidade de software 
 O objetivo da Engenharia de Software é melhorar a 
qualidade dos produtos desenvolvidos. Mas o que é 
qualidade de software? 
 Cliente: baixo custo, produtividade, agregação de 
valor ao negócio; 
 Usuário: facilidade de uso, estabilidade, eficiência; 
 Desenvolvedor: bem documentado, código 
otimizado, fácil manutenção; 
 Infraestrutura: baixo consumo de recursos, 
portabilidade. 
Qualidade de software 
 Qualidade de software, como qualidade de produto, 
depende do propósito do software; 
 Exemplos: controle de tráfego aéreo / editor de 
textos, software educacional / venda de passagens 
aéreas; 
 A qualidade deve ser incorporada ao longo do 
processo de desenvolvimento; 
 A qualidade do software depende da qualidade dos 
processos usados para desenvolvê-lo e mantê-lo. 
Processo de software 
 Processo de software é o conjunto de atividades, 
métodos, práticas e transformações que guiam a 
produção de software; 
 A definição do processo envolve análise e 
especificação de requisitos, projeto, desenvolvimento 
e testes, mas também escolha de um paradigma, 
métodos, técnicas e procedimentos; 
 “Não existe uma abordagem em particular que seja a 
melhor para a solução da aflição de software.” 
(Pressman) 
Processo de software 
 A definição do processo deve levar em conta: 
 Tipo de software (sistema de informação, sistema de tempo real, 
etc.); 
 Paradigma de programação (estruturado, orientado a objetos); 
 Domínio da aplicação; 
 Tamanho; 
 Complexidade; 
 Características da equipe. 
 Diversas normas já foram propostas: ISO 9001, ISO/IEC 
12207, ISO/IEC 15504, CMM e CMMI, porém o objetivo 
não é apresentar uma receita pronta a ser repetida, mas 
sim apontar caraterísticas de um bom processo. 
Ciclo de vida clássico 
 Planejamento/Engenharia de Sistemas: 
obtenção de dados a nível de sistema, com base em 
conversas com o usuário. Ter uma visão global do 
sistema, incluindo hardware, software e as pessoas 
envolvidas. Também chamado estudo de viabilidade. 
Ciclo de vida clássico 
 Análise/Especificação de Requisitos: definição 
dos requisitos de software, com relação a recursos. 
Devem ser documentados e revistos com o cliente 
antes de iniciar a execução do projeto. 
Ciclo de vida clássico 
 Projeto: envolve muitos passos, para transformar os 
requisitos da análise, o modelo lógico em modelo 
físico. Nesta etapa, definem-se estruturas de dados, 
arquitetura de software, detalhes procedimentais e 
interface. 
Ciclo de vida clássico 
 Construção/Codificação: o projeto é 
transformado em programa, usando uma linguagem 
de programação. 
Ciclo de vida clássico 
 Teste e Integração: realizar os testes no sistema e 
realizar as integrações com eventuais sistemas 
atuais. 
Ciclo de vida clássico 
 Operação e Manutenção: indubitavelmente o 
software sofrerá mudanças depois que foi entregue 
ao cliente. A manutenção ocorre basicamente com a 
correção de erros (manutenção corretiva), adaptação 
da aplicação a mudanças do ambiente (manutenção 
adaptativa) e adição de novas características ao 
software (manutenção evolutiva). 
Ciclo de vida clássico 
Planejamento 
Análise 
Projeto 
Codificação 
Teste 
Manutenção 
Gerência de projetos de software 
 A gerência de projetos envolve: 
 Produto: a primeira coisa a se fazer é definir o escopo do 
projeto. A idéia é decompor o problema. O sistema deve ser 
decomposto em subsistemas que são, por sua vez, 
decompostos em módulos. Os módulos podem, ainda, ser 
recursivamente decompostos em sub-módulos ou funções, até 
que se tenha uma visão geral das funcionalidades a serem 
tratadas no projeto; 
 Processo; 
Gerência de projetos de software 
 A gerência de projetos envolve: 
 Pessoas: diversas pessoas são envolvidas em diferentes 
papéis: gerente de projeto, analistas, projetistas, engenheiros 
de software, programadores, engenheiros de testes, gerente de 
qualidade, clientes, usuários, etc. Estes papéis e denominações 
variam bastante dependendo da organização e até mesmo do 
projeto. As pessoas devem ser organizadas em equipes, o que 
não é uma tarefa fácil. 
Gerência de projetos de software 
 Atividades típicas da gerência de projetos: 
 Determinação do Escopo do Software 
 Definição do Processo de Software do Projeto 
 Estimativa de Tamanho 
 Estimativa de Esforço 
 Estimativa (Alocação) de Recursos 
 Estimativa de Tempo (Elaboração do Cronograma do Projeto) 
 Estimativa de Custos 
 Gerência de Riscos 
 Elaboração do Plano de Projeto 
Gerência de projetos de software 
 Ferramentas CASE auxiliam no gerenciamento de 
projetos de desenvolvimento de software; 
 A documentação é de vital importância em todas as 
etapas do desenvolvimento. Sem documentação não 
há Engenharia de Software; 
 A UML (Unified Modeling Language) é a linguagem 
padrão para elaboração da estrutura de projetos de 
software. É empregada para empregada para a 
visualização, a especificação, a construção e a 
documentação de artefatos que façam uso de 
sistemas complexos de software. 
UML 
 Unified Modeling Language 
 A UML pretende ser a linguagem de modelagem 
padrão para modelar sistemas concorrentes e 
distribuídos; 
 Os objetivos da UML são: especificação, 
documentação, estruturação para sub-visualização e 
maior visualização lógica do desenvolvimento 
completo de um sistema de informação. 
Objetivos da UML 
 Ajudar a conceber as ideias, em relação ao sistema 
projetado; 
 Apresentar as ideias ao grupo de forma que todos 
possam interagir e discutir; 
 Documentar as ideias quando elas já estiverem bem 
consolidadas. 
Conceitos UML 
 Ator 
 Atividade 
 Interface 
 Pacote (Package) 
 Classe 
 Evento 
Diagramas UML 
 Estrutural: estática 
 Diagrama de Classes 
 Diagrama de Objetos 
 Diagrama de Componentes 
 Diagrama de Implantação 
 Comportamental: dinâmica 
 Diagrama de Casos de Uso 
 Diagrama de Sequência 
 Diagrama de Atividades 
 Diagrama de Estados 
 Diagrama de Colaboração 
Diagrama de Casos de Uso 
Diagrama de Casos de Uso 
Diagrama de Atividades 
Diagrama de Sequência 
Diagrama de Estados 
Diagrama de Pacotes 
Diagrama de Componentes 
Diagrama de Implantação 
Diagrama de Objetos 
Diagrama de Classes 
 Uma classe é representada por um retângulo. 
Internamente deve constar seu nome, em negrito 
com primeira letra em maiúscula; 
 
 Uma classe possui atributos, que são exibidos em 
sessão inferior ao nome da classe; 
Pessoa 
Pessoa 
+nome 
+idade 
Diagrama de Classes 
 Atributos e operadores possuem uma visibilidade, 
que pode ser: 
 Public (+): atributos e métodos sempre acessíveis em todos os 
métodos de todas as classes. É o nível menos rígido de 
encapsulamento,que equivale a não encapsular; 
 Private (–): acessíveis somente nos métodos (todos) da própria 
classe. É o nível mais rígido de encapsulamento; 
 Protected (#): acessíveis no pacote, nos métodos da própria 
classe e suas subclasses; 
 Package (~): visível no pacote e na classe. 
Diagrama de Classes 
 Atributos têm um tipo de dado e podem ainda 
apresentar um valor padrão; 
 Por fim, as operações são representadas em uma 
terceira sessão do retângulo, abaixo dos atributos: 
Pessoa 
+nome: String 
+idade: int = 18 
#posiçãoXY: float[2] = {0,0} 
+andar(float direcaoX, direcaoY): bool 
+dormir(): bool 
Diagrama de Classes 
 Relacionamentos: 
 Agregação 
 Associação (bidirecional ou unidirecional) 
 Composição 
 Generalização 
Diagrama de Classes 
 Conceitual 
Diagrama de Classes 
 Especificação 
Diagrama de Classes 
 Implementação