1
(QJHQKDULD�GH�6RIWZDUH
Engenharia de Software
Engenharia de Software 2
Sumário� Objectivos� Problemas� Qualidades� Técnicas� Conclusões� Referências
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
2
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
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
3
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
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
4
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
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
5
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
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 ��� ��� � � �� ��
, ����� ��� �� ��� �
e ������� � � �� ������� ��� � � ��� �����
� Os clientes querem o sistema seja utilizado noutros contextos pelo que desejam a sua �!"�#��� � � �� ��
� A equipa de manutenção quer que o sistema seja ��$���� �%��&�#� '(�#�!, ���*) !�� ���'�+ ,��� e
)���-� �#� ��$.,���
6
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
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
0 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
7
Engenharia de Software 25
Conclusões/ P1 – Qualidade é Número 1
0 A qualidade deve ser quantificada e devem ser definidos mecanismos para a motivar e recompensar o seu alcance
0 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
Espectador0 Não existe uma definição de qualidade
1 Desenho elegante para equipa de desenvolvimento
1 Tempo de resposta para os utilizadores1 Preço de desenvolvimento do software se o
projecto é sensível aos custos1 Satisfazer todos os requisitos inclusive os
inesperados0 Cada projecto deve decidir sobre as suas
prioridades !
Engenharia de Software 27
Conclusões/ P3 – Produtividade e Qualidade Técnica
são Inseparáveis0 Quanto maiores forem os requisitos de
qualidade menor será a produtividade0 Quanto maior for a produtividade menor
será a qualidade/ P4 – Software de Grande Qualidade é
Possível0 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 Posteriori0 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 Eficiente0 A falta de fiabilidade é mais difícil de
detectar e de corrigir
8
Engenharia de Software 29
Referências/ Pfleeger98, Capítulo1./ Pfleeger98, Capítulo 10 – 1/ Pfleeger98, Capítulo 11 – 4(Product
Quality Models), 6(People Maturity Model)
/ David95