Engenharia de Software

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
Processos Professora: Lucélia Oliveira

2 Processo de Software Ao falar de processo, no contexto da Engenharia de Software, estamos nos referindo ao processo de desenvolvimento de software. O processo está presente nas etapas iniciais da construção de um software, até o treinamento do usuário final na nova ferramenta. Se refere à metodologia adotada. Professora: Lucélia Oliveira

3 Qual o processo adequado
Existem vários processos que tem a pretenção de serem adequados à construção de software. Mesmo antes da UML, existia um processo não formal, de construção de software, que se resumia ao levantamento de requisitos (necessidades), definição de um modelo (MER) e, finalmente, iniciava-se a codificação. Professora: Lucélia Oliveira

4 Qual o processo adequado (continuação)
Todos os processos de construção de software que apareceram foram apresentando problema no resultado final. Ainda hoje, mesmo os mais decantados processos, apresentam falhas ainda não superadas. Professora: Lucélia Oliveira

5 Qual o processo adequado (continuação)
Ernani Medeiros, cita em seu livro, o exemplo de um amigo que aplicou integralmente os conceitos de Gerenciamento de Projetos que haviam sido utilizados anteriormente para a construção de uma usina hidrelétrica e teve diversas decepções. A construção de uma casa pode ser mais simples que a construção de um software. Professora: Lucélia Oliveira

6 “Somos capazes de apontar os motivos, mas não somos tão felizes em apontar as soluções para esta problemática” Ernani Medeiros A fórmula secreta da boa construção de software ainda não foi desenvolvida, e isso ocorre em conseqüência da grande quantidade de tecnologia existente. Professora: Lucélia Oliveira

7 Por que a Engenharia de Software não apresenta a mesma constância que em outras áreas?
O Grupo Hyunday, na Coréia consegue recordes nos prazos de entrega de grandes navios, não importando onde a encomenda tenha sido feita ou qual o seu tamanho. Nosso primeiro equívoco ocorre no formato da construção:”Nada se inicia em termos de construção, antes que a concepção do projeto seja terminada”. Professora: Lucélia Oliveira

8 Por que a Engenharia de Software não apresenta a mesma constância que em outras áreas?
Na construção civil, tudo é pensado, antes mesmo de um tijolo ser assentado. Tudo é pensado, medido, checado, corrigido, até que os números sejam extemamente precisos. Durante anos tentamos construir software tendo como termo de comparação a construção civil. O problema é que os requisitos de software sofrem mudanças. Professora: Lucélia Oliveira

9 Seis Estágios de mudança de requisitos de software no decorrer do desenvolvimento, independente do tamanho do software. Professora: Lucélia Oliveira

10 Primeiro estágio – Concepção
A idéia inicial existe em formato nebuloso dentro da mente do interessado. O que ele tem como certo é a sua necessidade A forma de resolver ou atender a essa necessidade não tem um formato definido. Isso ocorre por diversas razões como falta de conhecimento tecnológico ou mesmo aversão inicial à tecnologia. Professora: Lucélia Oliveira

11 Primeiro estágio – Concepção
Na construção civil, se o engenheiro civil informar que o que pode ser construído é um sobrado de dois andares, com a metragem de área útil de x metros, dificilmente se discutirá sua sentença. Professora: Lucélia Oliveira

12 Segundo estágio – Aprovação da Concepção
É a aprovação de uma idéia abstrata por parte do interessado. A visão que o interessado tem é de alto nível, porém nada palpável existe para a tomada segura de decisão nesse estágio. Além disso, a idéia inicial do interessado “muda” em relação ao primeiro estágio. Isso é inevitável, pois a idéia nebulosa do primeiro estágio foi, agora, melhorada, com a ajuda de outras pessoas. Professora: Lucélia Oliveira

13 Segundo estágio – Aprovação da Concepção
Na construção civil, quando a planta é mostrada ao interessado, este fala mais à vontade de sua aprovação ou recusa, pelo fato de tratar de assuntos mais concretos. Ele sabe o que é uma parede e um dormitório, então consegue abstrair, com maior fluidez, o resultado final. Muitos resultados indesejáveis, no fututro, são resolvidos nesse estágio (junção de dois dormitórios, por exemplo). Professora: Lucélia Oliveira

14 Terceiro estágio – Detalhamento completo das necessidades do software
O detalhamento completo do software desejado é escrito novamente buscando a aprovação do interessado. Nada é construído, apenas as funcionalidades desejadas são escritas. A idéia inicial do interessado se altera. Isso ocorre pelo fato de que o seu nível de abstração melhorou. Normalmente, a própria equipe de construção descobre inconsistências significativas. Professora: Lucélia Oliveira

15 Terceiro estágio – Detalhamento completo das necessidades do software
Na construção civil, como o segundo estágio foi baseado em fundamentos bem concretos, eses estágio quase não sofre alterações significativas. Professora: Lucélia Oliveira

16 Quarto estágio – Início da construção
O início da construção do software se dá com base na aprovação das idéias surgidas no segundo e terceiro estágios. Nesse estágio o interessado vê algo mais concreto na construção de seu software. Professora: Lucélia Oliveira

17 Quarto estágio – Início da construção
Na construção civil, a idéia inicial do interessado foi concebida e visualizada na planta em que a construção se baseia. Paredes levantadas, desejo alcançado. Alterações no projeto geralmente não são feitas nesse estágio. Professora: Lucélia Oliveira

18 Quinto estágio – construção e testes
O interessado, nesse momento fica afastado do contato com o software de seu interesse. Tudo o que se necessitava foi conversado e “assinado”. Ele deverá fazer visita periódica, apenas para avaliar o andamento do projeto x cronograma. O banco de dados escolhido passa por testes com as interfaces gráficas construídas, e muitos códigos de linguagens e funções do banco de dados são escritos. Professora: Lucélia Oliveira

19 Quinto estágio – construção e testes
No caso de demissão de um programador ou Web designer, ou administrador de dados, os problemas começam a aparecer. Programadores com o mesmo nível de conhecimento e experiência tem visões completamente diferentes sobre como se deve fazer um código. Professora: Lucélia Oliveira

20 Quinto estágio – construção e testes
Na construção civil, a visita do interessado para avaliar o andamento x cronograma é feita com regularidade. No caso da demissão de um empregado, busca-se outro que tenha a mesma experiência. Professora: Lucélia Oliveira

21 Sexto estágio – Entrega
A entrega de um software ao seu interessado ocorre com raros estouros de champanha. Devido aos problemas de adaptação de pessoal, tecnologia e política, as datas de entrega foram negociadas com várias protelações. Não é muito raro se ouvir, do principal investidor, na cerimônia de entrega, a seguinte frase: “Mas não é nada disso que eu queria!” ou “Olha, está bom, mas eu gostaria de fazer algumas mudanças!”. Professora: Lucélia Oliveira

22 Sexto estágio – Entrega
Na construção civil, quando uma edificação é terminada, niguém ouve coisa semelhante ao que foi citado no slide anterior. Isso indicaria uma completa imcompetência por parte do engenheiro responsável. Se a planta foi obedecida e existe a intenção de se fazer alterações, é necessário que essa alteração esteja presente na planta, e que tenha novas aprovações no órgão responsável. Professora: Lucélia Oliveira

23 Qual o formato certo? NÃO existe uma forma de construção de software certa. Ao existir, provavelmente ocupará a primeira página dos principais jornais do mundo! Professora: Lucélia Oliveira

24 A forma de construção do software depende:
Do conhecimento do negócio a ser modelado; Do conhecimento da tecnologia a ser utilizada; Da capacidade de abstração do principal interessado no software; Da capacidade de abstração de quem construirá o software; Do volume de dinheiro dedicado à aquisição de banco de dados, ferramentas de desenvolvimento, hardware e terceiros, como provedores de acesso. Professora: Lucélia Oliveira

25 Considerações Alterando-se apenas uma das variáveis citadas no slide anterior, obtém-se um ganho enorme em termos de produtividade. Não podemos comparar a Engenharia de Software com as outras engenharias. Os trabalhos de engenharias naval, elétrica, civil e música existem há séculos, enquanto a Tecnologia da Informação, em especial a engenharia de software, existem há poucas dezenas de anos. Professora: Lucélia Oliveira

26 Considerações (continuação)
A ciência naval tem séculos de tentativas, erros, acertos, e hoje se constroem verdadeiras cidades flutuantes. Existe um padrão e um censo comum de como fazer um barco! Professora: Lucélia Oliveira

27 Considerações (continuação)
O software se refere à coisas intangíveis, às vezes, inimagináveis. O mesmo não ocorre com as outras ciências citadas. Esse fato alia- se ao desconhecimento dos requerentes de um software, sobre as tecnologias à sua disposição. Assim, conforme o software vai se concretizando, a idéia do interessado se aprimora, ou seja, muda. Professora: Lucélia Oliveira

28 Modelos de Processos de software
Professora: Lucélia Oliveira

29 Modelos de Processos de software
É uma representação simplificada e abstrata de um processo de software, apresentada a partir de uma perspectiva específica. Professora: Lucélia Oliveira

30 Exemplos: Modelo Em Cascata
Separa as fases de especificação e desenvolvimento e estas são executadas em seqüência. Modelo Espiral Cada loop na espiral representa uma fase do pprocesso de software. Desenvolvimento Baseado em Reuso O sistema é construído com base em componentes existentes Professora: Lucélia Oliveira

31 Modelo em Cascata - Estágios
Definição e análise dos requisitos Projeto Implementação e teste de unidades Integração e Testes de Sistema Operação e Manutenção Professora: Lucélia Oliveira

32 Modelo Cascata – Estágios:
1. Análise e definição dos requisitos: As funções, as restrições e os objetivos do sistema são estabelecidos por meio da consulta aos usuários do sistema. Em seguida, são definidos em detalhes e servem como a especificação do sistema. Professora: Lucélia Oliveira

33 Modelo Cascata – Estágios:
2. Projeto de sistemas e de software O projeto de sistemas agrupa os requisitos de sistemas de hardware e software. Estabelece uma arquitetura do sistema geral. Professora: Lucélia Oliveira

34 Modelo Cascata – Estágios:
3. Implementação e teste de unidades Esse estágio compreende um conjunto de programas ou unidades de programa. O teste de unidades envolve verificar que cada unidade atenda a sua especificação. Professora: Lucélia Oliveira

35 Modelo Cascata – Estágios:
4. Integração e teste de sistemas. As unidades de programa ou programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Após os testes, os sistema é entregue ao cliente. Professora: Lucélia Oliveira

36 Modelo Cascata – Estágios:
5. Operação e manutenção Esta é a fase mais longa do ciclo de vida A manutenção envolve corrrigir erros que não foram descobertos em estágios anteriores do ciclo de vida, melhrando a implementação das unidades de sistema e aumentando as funções desse sistema. Professora: Lucélia Oliveira

37 Problemas do Modelo em Cascata:
Divisão inflexível das fases do projeto Dificuldade em reagir às mudanças ao longo do processo Isto dificulta a resposta às alterações de requisitos É apropriado somente quando os requisitos estão bem entendidos. Professora: Lucélia Oliveira

38 Modelo Espiral Proposto, originalmente por Boehm, em 1988.
O processo é representado como uma espiral ao invés de uma seqüência de atividades com retrocesso. Cada loop da espiral, representa uma fase do processo Não há fases fixas como especificação ou projeto, os loops são escolhidos dependendo da necessidade Professora: Lucélia Oliveira

39 Modelo Espiral Os riscos são explicitamente avaliados e resolvidos durante o processo Em vez de representar o processo de software como uma sequência de atividades com retorno de alguma atividade para outra, o processo é representado como um espiral. Cada loop na espiral representa uma fase do processo de software. Cada espiral é dividido em quatro setores: Professora: Lucélia Oliveira

40 Definição dos setores 1. Definição de objetivos, alternativas e restrições: São definidos os objetivos específicos, identificadas as restrições para o processo e o produto e preparado um plano de gerenciamento detalhado. Professora: Lucélia Oliveira

41 Definição dos setores (continuação)
2. Avaliação e redução dos riscos: Para cada um dos riscos de projeto identificados, é realizada uma análise detalhada e são tomadas providências para reduzir os riscos. Professora: Lucélia Oliveira

42 Definição dos setores (continuação)
3. Desenvolvimento e validação Depois da avaliação dos riscos, é escolhido um modelo de desenvolvimento para o sistema. Por exemplo, se forem dominantes os riscos relacionados à interface com o usuário, um modelo apropriado seria o modelo por prototipação evolucionária. O modelo cascata poderá ser o modelo de desenvolvimento mais apropriado se o risco principal identificado for a integração de sistemas. Professora: Lucélia Oliveira

43 Definição dos setores (continuação)
4. Planejamento O projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop da espiral. Se a decisão for continuar, serão traçados os planos para a próxima fase do projeto. Professora: Lucélia Oliveira