A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro.

Apresentações semelhantes


Apresentação em tema: "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."— Transcrição da apresentação:

1 Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro

2 Modelos e Modela ç ão Modelo – interpreta ç ão de um problema, num dado dom í nio, de acordo com uma determinda estrutura de conceitos Esquema – é a especifica ç ão de um modelo, usando uma linguagem que pode ser formal ou informal, textual ou gr á fica (diagrama) Modela ç ão – arte ou ciência de criar modelos, associados a uma determinada realidade.

3 Vantagens da Modela ç ão (Booch, 99) Os modelos ajudam a visualizar um sistema Os modelos permitem especificar a estrutura ou o comportamento de um sistema Os modelos permitem controlar e guiar o processo de constru ç ão do sistema Os modelos documentam as decisões tomadas

4 Princ í pios da Modela ç ão Independentemente do projecto, de acordo com [Booch99] são 4 os princ í pios b á sicos –A escolha dos modelos a criar tem uma profunda influência no modo como o problema é encarado e a solu ç ão obtida –Cada modelo deve poder ser expresso em diferentes n í veis de precisão / abstrac ç ão –Os melhores modelos reflectem a realidade –Nenhum modelo é suficiente por si s ó. Qualquer sistema não-trivial é representado de forma mais adequada atrav é s de um pequeno n ú mero de modelos, razoavelmente independentes

5 Actividades no Processo de Desenvolvimento de Software Especifica ç ão de software ou engenharia de requisitos –Processo que permite entender e definir os servi ç os requeridos pelo sistema, bem como identificar os constrangimentos de opera ç ão ou de desenvolvimento; –2 n í veis de detalhe: Alto n í vel para apresenta ç ão e aprova ç ão pelos utilizadores finais e clientes; Baixo n í vel para o desenvolvimento

6 Especifica ç ão São 4 as fases existentes no processo de especifica ç ão: – Estudo de viabilidade – estimativa que permite avaliar se as necessidades dos utilizadores podem ser satisfeitas com as tecnologias dispon í veis (hardware e software). Permite avaliar os custos do sistema e compromissos de or ç amento. É uma fase que deve ser r á pida e de baixo custo, permitindo decidir sobre a continua ç ão do projecto; – Identifica ç ão de requisitos e an á lise - Observa ç ão dos sistemas actuais, discussões com os potenciais utilizadores e clientes, tarefas de an á lise, etc. Poder á ser necess á rio o desenvolvimento de modelos ou prt ó tipos e dever á resultar no entendimento completo, por parte do analista, do sistema a especificar;

7 Especifica ç ão – Especifica ç ão de requisitos – tradu ç ão da informa ç ão obtida durante a fase de an á lise em documentos que definem os requisitos do sistema. Esses requisitos apresentam-se como: Requisitos dos utilizadores Requisitos de sistema – Valida ç ão de requisitos – avalia ç ão real í stica, consistente e completa dos requisitos identificados. Inevitavelmente são identificados erros cometidos nas etapas anteriores, os quais devem ser rectificados Nota : estas actividades raramente são efectuadas de forma sequencial. É normal ao longo de todo o processo de desenvolvimento de software que novos requisitos apare ç am, obrigando à intercala ç ão de actividades.

8 Desenvolvimento de Software Actividades a considerar: –Arquitectura do sistema; –Especifica ç ões abstractas; –Desenho do interface; –Desenho de componentes; –Desenho da estrutura de dados; –Algoritmia

9 Valida ç ão São os seguintes o tipo de valida ç ões que devem ser aplicados; –Testes unit á rios –Testes de sistema (ou integra ç ão) –Testes de aceita ç ão Nota: este tem ser á tratado em detalhe em CES, quando se falar na Qualidade do Software Teste de Componentes Teste de Sistema Teste de Aceitação

10 Valida ç ão Especificação de Requisitos Especificação do Sistema Desenho do Sistema Desenho Detalhado Plano de Testes de Integração Plano deTestes de Sub-sistemas Módulos, código unitário e testes Testes de Aceitação Testes de Integração Testes de Integração de Sub-sistemas Serviços

11 Evolu ç ão A flexibilidade dos sistemas é uma das razões principais porque mais e mais software é incorporada em sistemas grandes e complexos; As alterações aparecem em qualquer altura, durante ou após o desenvolvimento do software; Cada vez mais está a desaparecer a distinção entre desenvolvimento e manutenção de software, olhando-se para estes dois conceitos como algo de contínuo. Donde a Engenharia de Software dever ser encarada como um processo continuamente em evolução, em que o software é continuamente modificado ao longo do seu ciclo de vida, por forma a responder aos requisitos do negócio e do cliente.

12 Evolu ç ão Especificação de Requisitos Avaliar Sistemas Existentes Propor alterações Modificar Sistema Sistemas Existentes Sistemas Existentes Novo Sistema Novo Sistema

13 Arquitectura de Sistemas de Informa ç ão Arquitectura: – conjunto de representa ç ões descritivas (modelos) relevantes para a descri ç ão de um objecto, de forma a que este possa ser constru í do de acordo com os requisitos e mantido ú til ao longo da vida Em 1987, John Zachman introduziu o conceito de Arquitectura de Sistemas de Informa ç ão, baseado na experiência e conhecimento de disciplinas mais antigas

14 Framework de Zachman Zachman apresentou um Framework – estrutura l ó gica que permite a classifica ç ão e apresenta ç ão dos modelos de uma organiza ç ão, relevantes para a gestão e para os Sistemas de Informa ç ão Nesse framework estão representados o quê, como, onde, quem, quando e porquê, cruzados com os perfis dos intervenientes ou respons á veis dos processos (planner, owner, designer, builder e sub-contractor). –Ver: tm tm –http://www.zifa.com/http://www.zifa.com/

15 Framework de Zachman

16 Framework de Index Apresentada por Richard Wurman (1997) considera a arquitectura dos Sistemas de Informa ç ão como um conjunto integrado e consistente de componentes (*) : –alinhados com os objectivos do neg ó cio –suportados por todos os elementos da organiza ç ão (*) Arquitectura aplicacional, tecnol ó gica, dados e organizacional

17 Sistema de Informa ç ão bem sucedido De acordo com Robert Block (1983) e perfeitamente actual, considera-se um Sistema de Informa ç ão bem sucedido se: –For produzido dentro do prazo –For produzido dentro do or ç amento –For fi á vel –For facilmente mantido –Responder aos requisitos –Satisfizer os utilizadores Quantos satisfazem estas permissas??? Ver: - apesar do relat ó rio ser de 1994, infelizmente, muitas das conclusões mantêm-se!!!http://www.standishgroup.com/sample_research/chaos_1994_1.php

18 Atributos de um bom softwarre Manuten ç ão – o software deve estar escrito por forma a permitir evoluir e satisfazer as altera ç ões identificadas pelos utilizadores. Ou seja adaptar-se ao neg ó cio; Eficiência – o software não deve desperdi ç ar recursos de sistema (mem ó ria ou processador), mas deve tamb é m responder em tempo ú til; Utiliza ç ão – o software deve ser facilmente utilizado pelos seus utilizadores, atrav é s de uma correcta interface e documenta ç ão; Seguro, seguro e seguro (reliable, safety e security) – o software não deve causar qualquer tipo de dano f í sico ou econ ó mico se o sistema falhar.

19 Planeamento Estrat é gio de Sistemas de Informa ç ão Processo cujo objectivo é garantir um alinhamento entre a estrat é gia da organiza ç ão (objectivos do neg ó cio) e os sistemas de informa ç ão; Deve permitir identificar e prioritizar as aplica ç ões inform á ticas potenciais; Segue ele pr ó prio uma metodologia: Levantamento Objectivos Estratégicos Análise Detalhada do Negócio Análise Situação Actual dos SI Proposta Situação Futura dos SI Planeamento Implementação

20 Trabalho 2 Por grupo desenvolver os seguintes temas: –RUP – Rational Unified Process –CASE – Computer-Aided Sofware Engineering –ViewPoint –DOORS – Document Object Oriented Requisit System –Requisite Pro –Racional (IBM) –Design Pattern –XP (eXtreme Programming) –AOSD – Aspect Oriented Software Development –CleanRoom


Carregar ppt "Engenharia de Software Prof ª. Isabel Sofia de Brito Prof ª. Maria Fernanda Pedro."

Apresentações semelhantes


Anúncios Google