processos professora: lucélia oliveira. ao falar de processo, no contexto da engenharia de...

Processos

Professora: Lucélia Oliveira

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.


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.


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.


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.


“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.


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”.


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.


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.


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.


É 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.


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).


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.


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.


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.


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.


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.


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.


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.


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


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.


NÃO existe uma forma de construção de software certa. Ao existir, provavelmente ocupará a primeira página dos principais jornais do mundo!


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.


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.


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!


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.


É uma representação simplificada e abstrata de um processo de software, apresentada a partir de uma perspectiva específica.


Modelo Em CascataSepara as fases de especificação e desenvolvimento e estas são executadas em seqüência.

Modelo EspiralCada loop na espiral representa uma fase do pprocesso de software.

Desenvolvimento Baseado em ReusoO sistema é construído com base em componentes existentes



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

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.


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.


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.


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.


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.


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.


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


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:


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.


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.


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.


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.


processos professora: lucélia oliveira. ao falar de processo, no contexto da engenharia de...

Documents