1 - Engenharia de Software2).pdf · Engenharia de Software 5 Intervenientes — &OLHQWH controla os...
Transcript of 1 - Engenharia de Software2).pdf · Engenharia de Software 5 Intervenientes — &OLHQWH controla os...
1
(QJHQKDULD�GH�6RIWZDUH
Engenharia de Software
Carla [email protected]
Engenharia de Software 2
Sumário� Objectivos� Problemas� Qualidades� Técnicas� Conclusões� Referências
2
Engenharia de Software 3
Objectivos� A engenharia de software trata da
construção de programas cuja complexidade requer a intervenção de HTXLSDV de engenheiros.
� Devido às necessidades de interacção e cooperação entre os membros da equipa de engenheiros, a engenharia de software deve possuir um conjunto de SULQFtSLRV não só aplicáveis aos produtos desenvolvidos como também ao processo de desenvolvimento desses produtos.
Engenharia de Software 4
Gestão da Complexidade� Análise do problema
� Decomposição em subproblemas tratáveis
� Síntese da solução� Composição das soluções para cada um
dos subproblemas
3
Engenharia de Software 5
Intervenientes� &OLHQWH controla os fundos, negocia o
contracto e estabelece requisitos� 3URJUDPDGRU constrói uma
especificação e desenvolve o programa de acordo
� 8WLOL]DGRU define os requisitos e utiliza o sistema
Engenharia de Software 6
Delimitar o Problema� Fronteira do sistema com o exterior,
outros sistemas incluídos� Objectos/entidades do sistema� Actividades do sistema
4
Engenharia de Software 7
Construir a Solução� Por analogia com outras engenharias é
necessário definir um conjunto de etapas que estabeleçam as interacções entre todos os intervenientes.
� Estas etapas podem (não necessariamente) estar associadas à construção de modelos
� Definição e análise de requisitos� Desenho do sistema� Implementação dos programas� Testes� Entrega� Manutenção
Engenharia de Software 8
Problemas� Diferentes disciplinas para a
Engenharia de Software:� Ciência da computação� Ciências da gestão� Ciências cognitivas� Ciências humanas� Ciências sociais� ...
� Experiência tem grande impacto
5
Engenharia de Software 9
Opiniões “Coincidentes”� Comunidade Académica
� A experiência não se transmite no contexto universitário
� Comunidade Profissional� A engenharia de software não é uma
engenharia mas sim um ofício, em que as técnicas se transmitem por um processo baseado no relacionamento mestre/discípulo
Engenharia de Software 10
Opinião “Divergente”� $�(QJHQKDULD�GH�6RIWZDUH�p�XPD�(QJHQKDULD�GH�XPD�&LrQFLD��D�&LrQFLD�GD�&RPSXWDomR
� O desenvolvimento de software é processo de formalização
� Todas as engenharias têm de considerar aspectos não técnicos
6
Engenharia de Software 11
Contudo...� Existem diferenças de fundo
relativamente às engenharias que têm a física como ciência base pois
� o software é construído para incorporar alterações, os sistemas são evolucionários
� existem três tipos de sistemas no que diz respeito à evolução: S, P e E
Engenharia de Software 12
Sistema SMundo Real
Problema
Requisitos
Sistema
Informação
Comparação
Sujeito a Alteração
7
Engenharia de Software 13
Sistema S� O problema e a solução são bem conhecidos� A especificação de requisitos é formal e a sua
implementação é inferida dos requisitos, e.g. multiplicação de matrizes
� O desenvolvimento centra-se na correcção da implementação da solução
� O sistema é estático e não suporta facilmente qualquer alteração ao problema
� Não evolui, se o mundo real se altera o resultado é um problema completamente novo que deve ser especificado
Engenharia de Software 14
Sistema PMundo Real
Problema
Requisitos
Sistema
Informação
Comparação
Sujeito a Alteração
Abstracção
8
Engenharia de Software 15
Sistema P� Nem sempre é possível entender e
especificar completamente o problema� Mesmo que exista uma solução teórica a sua
implementação não é prática ou é impossível, e.g. jogo de xadrez
� Para desenvolver uma solução define-se uma abstracção do problema e os requisitos são escritos tendo como base essa abstracção
� A solução é aceitável se os resultados fazem sentido no mundo que o problema abstrai
� Uma alteração à abstracção do problema provoca a alteração dos requisitos
Engenharia de Software 16
Sistema E
Problema
Requisitos
Sistema
Informação
Comparação
Sujeito a Alteração
Abstracção
Mundo Real
9
Engenharia de Software 17
Sistema E� O sistema está embutido no mundo
real e vai-se alterar quando este se alterar
� A solução é um modelo dos processos abstractos que representam o mundo real, ou seja, o sistema é parte integral do mundo que modela, e.g. um sistema de predição da saúde da economia de um país
� Estes sistemas estão constantemente a ser alterados
Engenharia de Software 18
Qualidades� Qualidade do produto
� Qualidades internas (Modularidade) versusQualidades externas (Fiabilidade)
� Qualidade do processo� Definição de actividades e sua melhoria
� Qualidade dos recursos� A qualidade dos recursos é um dos
factores mais determinantes� Qualidade do negócio
� Relação entre o custo e o resultado
10
Engenharia de Software 19
Qualidade do Produto� O desenvolvimento de software produz
diversos tipos de artefactos:� Requisitos� Desenhos� Componentes de Código� Casos de Teste� ...
� Deve-se avaliar a qualidade de cada um destes artefactos
Engenharia de Software 20
Modelo Boehm� O modelo Boehm baseia-se na ideia de que
um sistema deve ser útil� Assim a utilidade do sistema é avaliada na
perspectiva do utilizador� O utilizador usual quer que o sistema ofereça a
sua funcionalidade com ILDELOLGDGH, HILFLrQFLD e IDFLOLGDGH�GH�XWLOL]DomR
� Os clientes querem o sistema seja utilizado noutros contextos pelo que desejam a sua SRUWDELOLGDGH
� A equipa de manutenção quer que o sistema seja IiFLO�GH�WHVWDU, FRPSUHHQVtYHO e PRGLILFiYHO
11
Engenharia de Software 21
Qualidade do Processo� Um modelo de maturidade do processo
identifica onde o processo incorpora mecanismos de retroalimentação e controlo para que produtos de grande qualidade sejam desenvolvidos de acordo com o calendário e sem grandes “surpresas” de gestão
Engenharia de Software 22
Qualidade dos Recursos� Modelo de maturidade da equipa mede as
capacidades da equipa:� Inicial – não existem actividades para desenvolver
as capacidades da equipa� Repetição – estabelecem-se práticas básicas de
trabalho dentro da equipa� Definição – define-se um plano estratégico para
identificar e desenvolver as capacidades da equipa
� Gestão – os grupos de trabalho são estruturados em termos das capacidades e conhecimento dos elementos da equipa
� Optimização – a gestão tem como objectivo melhorar as capacidades das pessoas e da equipa
12
Engenharia de Software 23
Técnicas� Abstracção
� Permite concentrar nos aspectos relevantes
� Métodos de Análise e Desenho� Meio de comunicação, verificação e
reutilização� Protótipos de Interface
� Comunicação com o cliente e o utilizador� Processo de Software
� Gestão do desenvolvimento
Engenharia de Software 24
Técnicas� Arquitecturas de Software
� Para a qualidade do produto
� Reutilização� Tirar partido de resultados anteriores, requisitos,
desenho, testes, ...
� Métricas� Medir para avaliar do sucesso e melhorar os
resultados
� Ferramentas e Ambientes Integrados� Os ambientes de desenvolvimento integrados
permitem uma aumento de produtividade
13
Engenharia de Software 25
Conclusões� P1 – Qualidade é Número 1
� A qualidade deve ser quantificada e devem ser definidos mecanismos para a motivar e recompensar o seu alcance
� A entrega de um produto de baixa qualidade é catrastrófica no médio prazo
Engenharia de Software 26
Conclusões� P2 – A Qualidade está nos Olhos do
Espectador� Não existe uma definição de qualidade
� Desenho elegante para equipa de desenvolvimento
� Tempo de resposta para os utilizadores� Preço de desenvolvimento do software se o
projecto é sensível aos custos� Satisfazer todos os requisitos inclusive os
inesperados� Cada projecto deve decidir sobre as suas
prioridades !
14
Engenharia de Software 27
Conclusões� P3 – Produtividade e Qualidade Técnica
são Inseparáveis� Quanto maiores forem os requisitos de
qualidade menor será a produtividade� Quanto maior for a produtividade menor
será a qualidade� P4 – Software de Grande Qualidade é
Possível� A equipa de desenvolvimento deve
conhecer as técnicas que já demonstraram contribuir para aumentar a qualidade
Engenharia de Software 28
Conclusões� P5 – Não Tentar Introduzir Qualidade
num Produto a Posteriori� Se já é difícil introduzir qualidade durante
o desenvolvimento, então a sua introdução à posteriori é impraticável
� P6 – Pouco Fiável é Pior que Pouco Eficiente
� A falta de fiabilidade é mais difícil de detectar e de corrigir