1 - Engenharia de Software2).pdf · Engenharia de Software 5 Intervenientes — &OLHQWH controla os...

15
1 (QJHQKDULDGH6RIWZDUH Engenharia de Software Carla Ferreira [email protected] Engenharia de Software 2 Sumário Objectivos Problemas Qualidades Técnicas Conclusões Referências

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

15

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