2 - engenharia de software - fenix.tecnico.ulisboa.pt1).pdf · 4 engenharia de software 13 sistema...

1

(QJHQKDULD�GH�6RIWZDUH

Engenharia de Software

Engenharia de Software 2

Sumário� Objectivos� Problemas� Qualidades� Técnicas� Conclusões� Referências


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.


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


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


Delimitar o Problema� Fronteira do sistema com o exterior,

outros sistemas incluídos� Objectos/entidades do sistema� Actividades do sistema


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


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


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


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


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


Sistema SMundo Real

Problema

Requisitos

Sistema

Informação

Comparação

Sujeito a Alteração

4


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


Sistema PMundo Real

Problema

Requisitos

Sistema

Informação

Comparação


Abstracção


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


Sistema E

Problema

Requisitos

Sistema

Informação

Comparação


Abstracção

Mundo Real

5


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


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


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


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


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


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


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


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


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


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 !


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


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


Referências/ Pfleeger98, Capítulo1./ Pfleeger98, Capítulo 10 – 1/ Pfleeger98, Capítulo 11 – 4(Product

Quality Models), 6(People Maturity Model)

/ David95

2 - engenharia de software - fenix.tecnico.ulisboa.pt1).pdf · 4 engenharia de software 13 sistema...

Documents