Aula 01 - 07/08/12 - Conhecimentos Iniciais

AP - Análise de Programação - 07/08/12

Professor: Billy

Conhecimentos Iniciais

Quando falamos no processo no contexto da Engenharia de Software, estamos nos referindo ao processo de desenvolvimento de software. Isso é cpncernente as etapas necessárias à conclusão ou construção de um software, desde seu início, passando pelas etapas de homologação e chegando até o treinamento do usuário final na nova ferramenta.

Existem vários processos que se propõe serem adequados à construção de software. Essa tarefa já foi pensada muitas vezes. Mesmo antes de termos a ajuda da UML, tinhamos um processo, não formal, de construção de software, que se resumia ao levantamento de requisitos.





por que a construção de software não apresenta a mesma constância que as outras áreas?

Por anos, tentamos construir software tendo como termo a comparação a construção civil. O problema é que os requisitos de software sofrem mudanças. Elas ocorrem porque o interessado no software passa pelas mudanças mostradas a seguir, não importando o software.

Primeiro estágio- concepção: a idéia inicial existe em um formato nebuloso na mente do interessado na construção do software. O que ele tem como certo a sua necessidade, porém a forma de resolver ou atender essa necessidade não tem um formato definido em sua mente.
Isso ocorre por diversas razões, mas com frequência pela falta de conhecimento tecnológico ou mesmo aversão inicial a tecnologia.

Segundo estágio- Aprovação da concepção: Oestágio seguinte é a provação de uma idéia abstrata por parte do interessado. A ele são entregue calhamaços de papel e diversos diagramas que, para compreensão, requerem conhecimento de nível superior seguido de alguns cursos de especialização e algumas pós-graduações. Mesmo quando o público que deve aprovar tal concepção é da área de TI, carece de conhecimento em subáreas que os software atuais abarcam.


A visão que o interessado tem é de alto nível, porém nada palpável existe para tomada segura de decisão neste estágio. Além disso e com as observações do pessoal de construção do projeto, a idéia do interessado muda em relação ao primeiro estágio. isso é inevitável, pois a ideia nebulosa do primeiro estágio foi agora melhorada com ajuda de outras pessoas.

Terceiro estágio- Detalhamento completo das necessidades do software: Nesse estágio o detalhamento completo do software desejado é escrito e novamente buscamos a aprovação do interessado. Nada é construido, apenas as funcionalidades desejadas são escritas.
Novamente, a ideia inicial do interessado se altera, Isto ocorre pelo fato de que seu nível de abstração melhorou. Sua ideia sofreu um amadurecimento. Normalmente a própria equipe dedicada à cosntrução descobre inconsistências que são significativas e passam uma segurança que não havia sido encontrada até esse momento.

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 pelo interessado. Essa construção tem seu início no modelo de entidade e relacionamento, para planejar onde os dados requiridos serão guardados. Nós carregamos esse erro de estratégia durante anos. Assim a interface gráfica é apresentada. Nesse momento a idéia do interessado sobre a forma como sua necessidade será tendida dofre mudanças . Isso ocorre porque seu nível de abstração melhorou.
Agora ele vê algo mais concreto. Vê como foi concebida sua intenção inicial.


Quinto estágio- Construção e testes: O interessado nesse momento fica afastado do contato com o software de seu interesse. A premissa é de que tudo que necessitava foi conversado e assinado . Isso não invalida a visita periódica, do interessado para avaliar o andamento x cronograma.

O banco de dados passa por testes de aderência com as interfaces gráficas construídas, e muitos códigos de linguagem e função do banco de dados são escritos. A ideia aqui é de que o interessado já informou sobre seu negócio, expôs suas expectativas e validou as interfaces gráficas chamadas de protótipos de tela.

Sexto estágio- Entrega: A entrega de um software ao seu interessado ocorre com raros estouros de campanha. Devido aos problemas de adaptação de pessoal, tecnologia e política, as datas de entregas foram negociadas com várias protelações ao longo do tempo.

Não raro, quando o software é entregue em uma cerimônia com o principal investidor presente, ouve-se a homérica frase: “ Mas não é nada disso que eu queria!” ou “Olha est´pa bom mas eu gostaria de fazer algumas mudanças no forma como isso foi pensado”.

Este formato está correto?

Francamente se uma forma de construção de software for a certa, ela ganhará rapidamente a primeira página de diversos jornais. A forma de construção de software depende:

do conhecimento do negício a ser modelado;
do conhecimento da tecnologia que será utilizada, por parte de que fará a aconstruçã;
da capacidade de abstração do principal interessado no software;
da capacidade de abstração de quem construirá o software; e
do volume de dinheiro dedicado à aquisição de softwares de autoria, banco de dados, ferramentas de desenvolvimento, hardware e terceiros, como provedores de acesso e data centers.



Um padrão de como se construir um software não existe, simplesmente porque os profissionais da área não querem. Este padrão não existe porque ainda estamos buscando-o.

Desenvolvimento em queda d`agua.

Esse formato de desenvolvomento oferece os seguintes problemas:

Pressão do risco de tempo;
custa muito concertar erros, descobertos em tempo, de códigos e testes;
aumenta o risco de cancelamento de projeto; e
tende a mascarar os riscos.


“Se você não atacar os riscos em seu projet, eles vão atacar você”. Tom Gilb

O risco é uma constante que não é problema nas primeiras interações pelas quais passa o sofware, porém, quando este se aproxima da entrega final, o risco é fator de maior pertubação.

Como esse modelo foi muito utilizado em processos de análise estruturada, a orientação a objetos procurou o seu caminho.

Nesse link tem alguns slides com um texto bastante semelhante e completo,relacionado ao tema proposto; pt.scribd.com/doc/56491217/Uml