Engenharia de Software Processos Professora: Lucélia Oliveira

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

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

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

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

“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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Modelos de Processos de software Professora: Lucélia Oliveira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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