Engenharia de Software

Apresentação em tema: "Engenharia de Software"— 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 Sistema Aceitação

10 Validação Especificação de Requisitos do Sistema Desenho do Sistema
Detalhado Plano de Testes de Integração Plano deTestes de Sub-sistemas Módulos, código unitário e testes Testes de Aceitação Integração Testes de Integração 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 Novo

13 Arquitectura de Sistemas de Informação
“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:

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!!!

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