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 O ciclo de vida do software define uma sequência de tarefas necess á rias para desenvolver, usar e manter os sistemas de software: –Defini ç ão de Requisitos –Desenho e codifica ç ão –Testes unit á rios –Teste de integra ç ão –Opera ç ão e Manuten ç ão Waterfall; Evolutivo; Baseado em Componentes Modelos para o Processo de Desenvolvimento do Software

3 Ciclo de vida do Software Definição de requisitos Definição de requisitos Desenho do sistema e do Software Desenho do sistema e do Software Implementação e Testes unitários Implementação e Testes unitários Integração e testes do sistema Integração e testes do sistema Operação e Manutenção Operação e Manutenção

4 Defini ç ão de requisitos –Os objectivos da an á lise são: fazer compreender o problema; determinar a essência do problema - An á lise dos requisitos do problemas; modelar o problema independentemente da tecnologia utilizada na sua implementa ç ão; explicita ç ão das restri ç ões impostas pelo enunciado; construir um modelo ideal que satisfaz os requisitos do utilizador; definir quais as fun ç ões e os dados que compõem o sistema num ambiente ideal. dizer o que deve ser implementado. Ciclo de Vida

5 Desenho –O desenho transforma o modelo ideal da an á lise num modelo real. Para isso, precisamos de tomar em considera ç ão as caracter í sticas do ambiente de implementa ç ão; –O desenho tem por objectivo modelar o sistema, determinando como implementar o que foi idealizado durante a an á lise; –Defini ç ão da arquitectura da solu ç ão e a estrutura e comportamento de cada componente; –O desenho diz como o modelo da an á lise deve ser implementado mas não envolve programa ç ão. Ciclo de Vida

6 Codifica ç ão (ou parametriza ç ão) –O objectivo da codifica ç ão é produzir programas correctos e eficientes; –A codifica ç ão é o processo de tradu ç ão do modelo de desenho (arquitectura do sistema), em programas (instru ç ões para serem executadas pelo computador); –Dependendo do tipo de linguagem de programa ç ão escolhido é poss í vel come ç ar j á nesta fase o teste de alguns m ó dulos; –Parametriza ç ão decorre da instala ç ão de packages (SAP, Primavera, etc.) em que o recurso à programa ç ão dever á ser reduzido, mas estão ddispon í veis objectos customiz á veis à s necessidades identificadas. Ciclo de Vida

7 Teste unit á rios e de integra ç ão –O objectivo do teste é eliminar estados inesperados nos programas que possam causar falhas de execu ç ão, e descobrir erros de implementa ç ão. –O teste consiste em demonstrar que os programas constru í dos respondem aos requisitos dos utilizadores e que fazem a transforma ç ão correcta dos dados de entrada. –Se a linguagem de programa ç ão o permitir, o sistema é testado por m ó dulos que vão sendo agrupados à medida que vão sendo testados at é se conseguir o teste do sistema total (constru ç ão bottom-up). Ciclo de Vida

8 Manuten ç ão –A manuten ç ão consiste em manter o software em execu ç ão e em boas condi ç ões de opera ç ão. –Existem três tipos de manuten ç ão: Correctiva: correc ç ão de erros que não foram identificados durante o desenvolvimento; Adaptativa: modifica ç ão do software para adapt á -lo a novos requisitos ou a modifica ç ões em requisitos existentes; Preventiva: modifica ç ões ao software com o fim de prever poss í veis erros. –Todos os recursos e actividades necess á rias para assegurar o bom funcionamento do sistema fazem parte da manuten ç ão. Ciclo de Vida

9 Modelos: –Modelo em cascata/queda de á gua/water fall –Modelo Evolutivo –Modelo Baseado em Componentes Modelos para Processos de Software

10 Modelo em cascata/queda de á gua/water fall WaterFall Manutenção Análise Desenho Codificação Testes

11 Modelo em cascata/queda de á gua/water fall –Processo: Uma fase s ó come ç a quando a anterior estiver conclu í da. –Defeitos do modelo em cascata: Não suporta modifica ç ões nos requisitos; Negar ou ignorar as modifica ç ões aos requisitos não resolve nada; Não prevê a manuten ç ão; É excessivamente sincronizado; Faz aparecer o software muito tarde; Mais de 50% dos custos passam para a manuten ç ão. É necess á rio efectuar a reconfigura ç ão do projecto dinamicamente. Isto é um risco demasiado grande, pois h á imensas coisas que podem correr mal quando se come ç a a escrever c ó digo; dificuldade em detectar erros. Aumento do tempo utilizado na fase de testes. É excessivamente calendarizado. É dif í cil capturar todos os requisitos de uma s ó vez. WaterFall

12 Modelo Evolutivo Desenvolvimento Evolutivo Desenvolver uma ideia inicial, apresentá-la ao cliente e refinar a versão. As actividades de especificação, desenvolvimento e validação são concorrentes Fonte: Sommerville, Ian - Software Engineering 7

13 Modelo baseado em Componentes Component Based Software Engineering Na maioria dos projectos de software é possível reutilizar software anteriormente desenvolvido Esse software é modificado de acordo com as necessidades e incorporado no produto em desenvolvimento Neste modelo a fase de reutilização de software, requer 4 etapas: 1.Análise das componentes 2.Modificações de requisitos 3.Desenho do sistemas com reutilização 4.Desenvolvimento e integração Fonte: Sommerville, Ian - Software Engineering 7

14 Prototipagem –Caracter í sticas: O prot ó tipo é a representa ç ão do sistema final. É apresentado o produto ao utilizador final/cliente. Processo baseado no utilizador final/cliente. O projecto é apresentado ao utilizador ao longo do processo –Benef í cios: diminui ç ão de mal-entendidos entre a equipa que desenvolve o software e o cliente/utilizador final. treino dos utilizadores detectar requisitos essênciais –Desvantagens: não é f á cil gerir os encontros entre a equipa que desenvolve o software e o cliente/utilizador final. neste prot ó tipo não são considerados aspectos como a manuten ç ão ou a qualidade do software Custos associados Prototipagem

15 Modelo Formal –Baseado na especifica ç ão matem á tica do software. –Nota ç ão rigorosa e demonstr á vel –Desvantagens: necessidade de muito treino, dificuldades com o cliente/utilizador final, tempo consumido. Modelo Formal

16 Processos para a Modifica ç ão do Software Como é inevit á vel ter mudan ç as ao produto desenvolvido serão estudados 2 processos que apoiam as diferentes itera ç ões que o software ir á sofrer: –Entregas incrementais –Desenvolvimento em espiral

17 Modelo em espiral Desenvolvimento em Espiral Avaliação / Monitorização Ciclo 3 Ciclo 2 Ciclo 1 Ciclo 0 Planeamento / Revisão Gestão de Riscos Planificação / Construção / Entrega

18 Modelo em Espiral –Pretende melhorar o modelo de queda de á gua incorporando planeamento. Mas a principal diferen ç a é a introdu ç ão de um novo conceito : INCERTEZA! –Onde estão os riscos: A altera ç ão nos requisitos; o software surge antecipadamente no mercado por um concorrente; e equipa de desenvolvimento não se entende; Introduzir modifica ç ões e propagar os efeitos para as fases seguintes. Determinar objectivos, alternativas e restri ç ões. Identificar riscos. Desenvolver e verificar. Planear as fases seguintes. –Vantagem: a calendariza ç ão e os custos dependem do cliente. –Desvantagem: necessidade de uma boa gestão de riscos. Desenvolvimento em Espiral

19 Revisão –Analiza-se o estado actual do Projecto. –Estabelecem-se os Objetivos. –O Ciclo 0 é o in í cio do Projecto (Planifica ç ão Geral e Gestão da Qualidade) –Assegura-se o compromisso dos utilizadores. Gestão de Riscos –Identificam-se e valorizam-se os Riscos. –Planificam-se as Ac ç ões de Contingência Desenvolvimento em Espiral

20 Planifica ç ão –Realiza-se um Plano Detalhado para o ciclo. Analisam-se tarefas e dependências causais. Assignam-se os Recursos. Definem-se os Crit é rios de Aceita ç ão. Monitoriza ç ão –Controlam-se as Tarefas –Avaliam-se os Resultados Desenvolvimento em Espiral

21 Risco: (Probabilidade de Existir) * (Gravidade dos Efeitos) –Ambos componentes valorizam-se qualitativamente mediante o crit é rio {muito baixo, baixo, m é dio, alto, muito alto}. –Ordenam-se. –Planificam-se Ac ç ões Contingentes. –Preparar Documento de suporte. Para cada Risco identificado –Identificador –Causa –Probabilidade de Ocurrência –Efeitos e Gravidade –Classifica ç ão –Ac ç ões de Contingência Desenvolvimento em Espiral

22 Entregas incrementais Este modelo tem a vantagem de permitir a identificação (pelo cliente) de quais as funcionalidades mais importantes, as quais serão desenvolvidas e entregues pela ordem acordada (incrementos) e colocadas em produção. Fonte: Sommerville, Ian - Software Engineering 7

23 Conclusão As quatro actividades associadas ao ciclo de vida do desenvolvimento de software: –Especifica ç ão –Desenvolvimento –Valida ç ão –Evolu ç ão podem organizadas de forma distinta de acordo com o processo de desenvolvimento utilizado; Podemos encontr á -las de forma sequencial (waterfall) ou concorrentes (desenvolvimento evolutivo) Estas actividades são executadas dependendo do tipo de software a desenvolver, das pessoas envolvidas e da estrutura organizacional do cliente. Não h á f ó mulas certas ou erradas, desde que as v á rias etapas produzam os resultados esperados e o produto entregue tenha a qualidade exigida.

24 Efectuar uma busca sobre os modelos identificados; Encontrar projectos-tipo (ou requisitos) que melhor se adaptam a cada modelo. Exerc í cio


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

Apresentações semelhantes


Anúncios Google