Engenharia de Software

Padrões de Projeto

2011-12-07T23:12:00.001-03:00

Padrões de projeto (em inglês, Design Patterns) são soluções para problemas específicos que ocorrem de forma recorrente em um determinado contexto que foram identificados a partir da experiência coletiva de desenvolvedores de software.

A proposta original de padrões veio do trabalho de Christopher Alexander na área de arquitetura. Sua definição para padrões é que "Cada padrão é uma regra (esquema) de três partes que expressa uma relação entre um certo contexto, um problema, e uma solução".

O contexto descreve uma situação no desenvolvimento na qual existe um problema.O problema que ocorre repetidamente no contexto deve também ser descrito bem como as forças (requisitos, restrições e propriedades) associadas a ele. A solução descreve uma configuração ou estrutura de componentes e suas interconexões, obedecendo às forças do problema. As forças, denominação dada por Alexander, descrevem:

os requisitos que caracterizam o problema e que a solução deve satisfazer,
as restrições que devem ser aplicadas às soluções
as propriedades desejáveis que a solução deve ter.

Exemplo: Observer (Observador)

Considere uma interface gráfica que permita representar uma estrutura de dados de diversas formas - tabela, gráfico de barras e gráfico de tortas. A solução mais simples é ativar cada uma das classes que implementam as três diferentes visualizações cada vez que a estrutura de dados for ativada. Isso, no entanto, torna o núcleo do software dependente da interface (maior acoplamento). Além disso, para adicionar novas visualizações, é preciso modificar também a estrutura de dados.

Um bom design de software requer um única estrutura de dados independente das três diferentes visualizações e atuando como observadores. Para isso, é preciso que a implementação das visualizações sejam observadores (ouvintes) da estrutura de dados e que sejam avisados quando ocorrer um evento de atualização.

O padrão Observer oferece uma solução para isso:

Contexto: Situações nas quais vários componentes dependem de dados que são modificados em outro componente (sujeito).
Problema: Os dados do componente sujeito modificam-se constantemente e precisam ser atualizados nos outros componentes. O número de componentes pode variar.
Solução: Utilizar um mecanismo de registro que permite ao componente sujeito notificar aos interessados sobre mudanças.

A visualização das classes e a interação dos objetos são ilustrados na figura abaixo.

Para saber mais:

Pattern-Oriented Software Architecture (POSA) – A System of Patterns – F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal John Wiley and Sons Ltd, Chichester, UK, 1996

Usando cenarios para descobrir requisitos

2011-10-17T08:04:00.002-03:00

O levantamento de informações sobre as tarefas e os usuários pode ser melhor realizado quando os analistas procuram descrever situações do processo de trabalho. Os métodos baseados em cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir.

Os cenários têm como foco as atividades que as pessoas realizam nas organizações possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido, explicando porque ele é necessário. Eles proporcionam um desenvolvimento orientado a tarefas possibilitando maior usabilidade do sistema.

Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar a discussão e estimular novos questionamentos. eles permitem também documentar o levantamento de informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos.

Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os clientes e usuários envolvidos que podem avaliar, criticar e fazer sugestões, proporcionando a reorganização de componentes e tarefas do domínio. Cenários oferecem um "meio-intermediário" entre a realidade e os modelos que serão especificados, possibilitando que clientes, usuários e desenvolvedores participem do levantamento das informações e especificação dos requisitos. Em resumo, os cenários permitem compreensão dos problemas atuais pelos analistas e antecipação da situação futura pelo clientes e desenvolvedores.

Elaborando Cenários

Como toda atividade de análise e especificação de requisitos, a descrição do domínio através de cenários requer técnicas de comunicação e modelagem.
A descrição de cenários deve ser apoiada pelas três técnicas de comunicação vistas anteriormente. Antes de descrever os cenários, os analistas devem entrevistar clientes para entender os problemas e requisitos iniciais. A entrevista com usuários permite que cada um descreva as suas tarefas e os problemas associados a cada uma delas. A observação direta in loco é fundamental para que os analistas possam descrever a situação de uso como ela realmente vem ocorrendo na prática.

Após a elaboração dos cenários, clientes, usuários e analistas podem participar de encontros para que possam discutir cada um destes cenários. Eles podem ser afixados em quadros na parede onde os participantes possam analisá-los e fazer comentários, possivelmente afixando pequenos pedaços de papel a cada uma das cenas.

Cenários podem ser descritos em narrativas textuais ou através de storyboarding. As narrativas textuais podem ser descritas livremente, identificando os agentes e as ações que eles participam. É possível utilizar notações para descrever roteiros de cinemas ou notações mais precisas como aquelas utilizadas pela Inteligência Artificial para representação de conhecimento.

Uma técnica que está bastante relacionada com cenários, por permitir descrever situações de uso, é o storyboarding. Essa técnica envolve a descrição através de quadros com imagens que ilustram as situações do domínio. Cada quadro deve apresentar a cena que descreve a situação, os atores e as ações que cada um deve desempenhar. Abaixo de cada quadro devem estar descritas ações que os atores desempenham. Os storyboards são bastante utilizados em cinemas como forma de comunicação entre roteiristas, diretores, atores e técnicos.

Exemplos de cenários

Como exemplo, vamos considerar o domínio de uma locadora de vídeos.

Cena 1: Cliente procura um filme com uma certa atriz

Agentes: Cliente, Atendente, Balconista

Ações:

Cliente entra na loja e dirige-se até a atendente.
Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum específico?
Cliente: - Não, mas que não seja policial ou ação.
Atendente: Você sabe o nome dela?
Cliente: Não.
A atendente pergunta à balconista.
Atendente: - Você sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. É um nome bem complicado. Só sei que começa com G e o sobrenome é algo parecido com Paltrow.
Cliente: É isto mesmo.
A atendente então procura no fichário de atrizes as que começam com G. Não encontra nenhum nome parecido com o que a balconista falou. Ela então lembra-se de consultar uma revista especializada com os ganhadores do Oscar 99 e lá descobre o nome correto da atriz. Entretanto, não existe realmente ficha alguma com os filmes estrelados por esta atriz. O fichário está desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que não gosta do gênero destes filmes e pergunta pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda não saiu em vídeo.

Cena 2: O cliente procura por filmes de um certo gênero

Agentes: Cliente, Atendente, Balconista

Ações:

Cliente: - Eu gostaria de comprar um filme de ação.
Atendente: - Nós apenas alugamos.
Cliente: - Tudo bem. Então, por favor, me dê algumas dicas de filmes de ação.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dúvida se já assistiu outros três. Ele também pergunta à atendente se os outros dois filmes são bons. Após conversar durante alguns minutos com a atendente que entende muito do gênero, decide ficar com seis fitas. A atendente encaminha o cliente à balconista para calcular o valor da locação e o prazo de devolução. Após consultar as tabelas de preços e prazos, a balconista apresenta três planos de pagamento.
Balconista: - Se você devolver em um dia, paga apenas R$ 6,00. Se devolver em seis dias paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Após este prazo paga mais R$ 2,00 por fita, por dia.

Cena 3: Cliente procura por filme usando o sistema de consulta

Agentes: Cliente e Sistema de Consulta

Ações:

João gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e, chegando lá, utiliza um sistema de consulta. Ele não lembra o título nem o diretor, mas sabe que se passava na guerra do Vietnã e lembra bastante da trilha sonora. Utilizando o sistema ele solicita as opções de filmes de guerra. Os sistema oferece a ele as possibilidades de escolher os filmes por local da guerra ou por época. João escolhe a sua opção (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam. Ele pode organizar esta lista, por diretor, atores e título. Na tela do sistema aparecem a ilustração com o cartaz de divulgação do filme e uma opção para ele visualizar o trailler. O sistema, entretanto, não possibilita ele ouvir a trilha sonora.
Após analisar algumas opções ele finalmente encontra o filme desejado, mas uma informação na tela do sistema indica que o filme está alugado. João quer saber quando o filme será devolvido, mas esta informação não consta no sistema. Ele entretanto pode reservar e o sistema enviará para ele um e-mail avisando quando o filme estiver disponível. Ele sai da loja pensando "Que tempo perdido. Seria melhor que eu pudesse consultar o sistema de casa".

O emprego dos sonhos nos Estados Unidos é ser engenheiro de software.

2011-01-05T19:10:00.000-03:00

Engenharia de software, uma profissão que envolve o design e a criação de software para diversos dispositivos desde sistemas operacionais a aplicativos de telefones celulares e videogames, foi classificado como o melhor emprego de 2011 nos EUA pelo relatório Jobs Rated da CareerCast. Foram analisadas 200 diferentes profissões em uma ampla variedade de indústrias e foram analisados níveis de habilidades e salários de acordo com cinco critérios: ambiente de trabalho, esforço físico, estresse, salários e perspectivas. O objetivo do estudo é indicar qual emprego é mais gratificante para a maioria dos empregados (e não apenas para os mais bem sucedidos).

O que torna a engenharia de software como a melhor opção são as possibilidades de duas indústrias em expansão: sistemas Web e Computação-em-Nuvem. Um grande número de empresas está investindo em desenvolver aplicações para smartphones e tablets que fazem uso de recursos situados na "nuvem", ou seja, em servidors ligados à internet com grande capacidade de armazemento e processamento, segurança e disponibilidade.

Fonte:

http://www.careercast.com/jobs-rated/10-best-jobs-2011

O que é Arquitetura de Software?

2010-11-23T10:10:00.000-03:00

A arquitetura de software é descrição abstrata, na forma de modelos, de diferentes visões do sistema em termos de unidade (partes) que interagem entre si.

Arquitetura não é uma fase do desenvolvimento, mas o resultado das decisões de design sobre a estrutura e o comportamento do software. Mesmo que esta atividades não tenha sido deliberadamente realizada, vale ressaltar que:

Todo software tem uma arquitetura
A arquitetura pode ser analisada por diferentes pontos de vista (visões arquiteturais)

A arquitetura deve dar suporte à funcionalidade do sistema (requisitos funcionais) e deve estar em conformidade com a qualidade (requisitos não-funcionais).

O design arquitetural é o processo de tomar as decisões que visa definir estrutura e comportamento para atender aos requisitos funcionais e não-funcionais. Um bom arquiteto deve conhecer diferentes modelos e estilos de arquitetura e saber aplica-los de forma a atender aos requisitos.

Um dos princípios básicos para organização da estrutura e comportamento é manter uma alta coesão e um baixo acoplamento entre as unidades, como ilustrado na figura abaixo. Uma unidade com alta coesão mantém unidades dependentes entre si agrupadas em uma unidade maior. Isto implica que unidades dependentes e com alto grau de comunicação e dependência entre si estejam localizadas numa mesma unidade mais abstrata. Os benefícios deste princípio são:

Facilitar a manutenção e modificação de uma determinada unidade.
Permitir a substituição de unidade por outra.
Diminuir a comunicação entre as unidades mais abstratas, o que pode significar um baixo tráfego na rede.

As unidades (ou partes) que formam podem variar dependendo da visão utilizada. Por exemplo, numa visão de execução, as partes podem ser vistas como componentes e conectores. Os componentes podem ser partes que estão em execução como processos ou threads e os conectores os mecanismos de comunicação entre estes processos. Exemplos de conectores são memória compartilhada ou pipes entre processos do Unix/Linux.

Numa visão de implementação ou de código, as unidades podem ser módulos que oferecem serviços a outros módulos. Estes módulos devem estar ligados entre si através de interfaces bem definidas (API) e organizados de acordo com os serviços. É muito comum termos APIs organizadas em camadas, como nas interfaces de usuário gráficas (GUI).

Existem na literatura várias propostas de visões arquiteturais, como em :

Hofmeister, Nord e Soni, - Applied Software Architecture, Addison Wesley, 2000;
Bass, L.; Clements, P. and Kazman, R. - Software Architecture in Practice - Second Edition, Addison-Wesley 2003.

Design de software, de IHC e o Ipad

2010-01-28T17:46:00.002-03:00

Já dissemos anteriormente que o desenvolvimento de software deve começar pelo seu design. O design de um software interativo consiste na elaboração do seu modelo conceitual, na representação visual de seus elementos e na forma de interação com as suas funcionalidades.

Para entender isso na prática vejamos os vídeos da apresentação do Ipad.

O Steve Jobs está falando o tempo todo sobre como humanos podem interagir com programas que já conhecemos há tempos: player de mp3, player de vídeos, leitor de emails, browser de páginas Web, visualizador de fotos, leitor de livros eletronicos (e-reader), e outros.

Existem dois aspectos importantes:
1. Jobs está o tempo todo chamando a atenção sobre com podemos interagir com estes programas com os dedos, sentando numa poltrona ou sofá, e ter umaexperiência de uso.
2. Os diferentes produtos foram idealizados para uma plataforma única, compartilhando alguns elementos comuns

Ou seja, houve um design destes programas, com seus elementos visuais e interativos acoplados a um hardware simples (com poucos elementos, embora tecnologicamente sofisticadíssimo), com um modelo de interação baseado em toques na tela.

A apple já disponibilizou a SDK, mas não acho que alguém vai ter sucesso em desenvolver aplicações se começar diretamente programando. É preciso desenhar, prototipar, definir a seqüencia de interações para depois transformar isso em código.

Observe que alguem que não entende de programação, pode ser capaz de idealizar e desenhar uma boa aplicação para um Ip*d, que posteriormente precisará ser codificada por um programador. Mas um bom programador que esteja mergulhado em códigos fontes, não necessariamente conseguirá idealizar tais produtos.

Diferenças entre engenharia de software e as engenharias de artefatos físicos.

2009-10-29T12:11:00.005-03:00

As engenharias mais tradicionais lidam com artefatos materiais onde propriedades físicas estão fundamentadas em teorias das ciências.

O software é um artefato intelectual cuja matéria prima é a informação e o conhecimento humanos representados por códigos e linguagens. A sua construção é um processo de transformação e comunicação de representações através de seus códigos e linguagens que envolve todos os stakeholders (clientes, desenvolvedores, usuários). Nenhuma outra engenharia tem estas peculiaridades. Isto torna a ES diferenciada com processos bem particulares.

Nas engenharias tradicionais, o design é tratado separadamente pelas disciplinas de desenho industrial e arquitetura (na civil). Na engenharia de software, o design, isto é a transformação de requisitos em solução, ocorre de forma integra à engenharia de requisitos, à arquitetura de software e ao design de interfaces de usuário.

Nas engenharias tradicionais, o processo de verificação é quase sempre nas qualidades do artefato. O aspecto humano, quando considerado, é tratado pelo profissional de fatores humanos ou ergonomia. Em um software, o ser humano e a sua capacidade de interpretar informações, da racionar sobre elas para interagir e resolver problemas, é parte integrante do produto. Um software interativo não funciona sem o componente humano, tal como um software embutido não funciona sem a máquina na qual ele está embarcado. Dessa forma, a avaliação da interação usuário-sistema precisa ser parte necessária e não complementar da verificação. Métodos de desenvolvimento iterativos, com prototipagem e experimentação com usuário ao longo do ciclo é fundamental.

Por fim, lidar com sistemas legados, robustos e confiáveis, é um grande desafio e um outro aspecto diferencial da engenharia de software. Como o software não se desgasta ou sofre fadiga material, o processo de reforma ou reciclagem também é diferente. Técnicas de migração por transformação de código é algo particular da indústria de software.

Assim, engenharia de software tem em comum com qualquer engenharia a necessidade de compreender problemas, desenvolver soluções criativas e garantir a qualidade do seus produtos, aliada aos aspectos gerenciais e econômicos. Mas as características do artefato software requer uma engenharia com fundamentos, métodos, técnicas e ferramentas próprios.

Qual a melhor linguagem de programação?

2009-08-15T17:32:00.006-03:00

Sempre perguntaram-me qual a melhor linguagem de programação. Esta é uma pergunta difícil de responder.

Recentemente, participei de uma discussão com colegas sobre quais linguagens deveriam ser ensinadas ao alunos e em qual ordem. Não tenho muita experiência com ensino de programação. Assim, não tive muito como contribuir sobre o aspecto pedagógico desta discussão. Mas dei a minha colaboração com a minha experiência e por considerar a linguagem um instrumento de interação humano-computador.

Tenho apenas experiência com o auto-aprendizado de várias linguagens, em diferentes paradigmas. Comecei com Basic, do Bill Gates, e Assembly 6502, em casa. Minha motivação: aprender o que é computador. Fui para a universidade e aprendi Fortran, Pascal, Assembly 8086 e Cobol, durante graduação. Estudei C, sozinho, para meu trabalho de IC. Também auto-aprendi Prolog e LISP, para o mestrado; C++ e Java para o doutorado; e Perl, Javascript, PHP, HTML e CSS para desenvolvimento Web.

Não fiz nenhum planejamento pedagógico para o meu aprendizado, mas acho que consegui dar conta de todas. Não sou fluente na maioria, mas programador não é o que sou de profissão. O melhor para mim foi a diversidade, saber pensar de forma diferente utilizando variadas linguagens e saber ler programas escritos por alunos em seus trabalhos, independente da linguagem.

Poucos trabalhos investigaram cientificamente qual a melhor linguagem? Melhor em que? para ensino? para a pratica profissional? para um certo domínio de aplicação?

Linguagens naturais e artificiais, são instrumentos de cognição (ação de conhecer) e comunicação (ação de por em comum). E estas são atividades humanas!

As linguagens de programação têm vários propósitos. Vou destacar 2 deles relacionados à cognição e comunicação:

- ser um instrumento para codificar conhecimento de pessoas na forma de instruções para um computador executar (para outras pessoas);

- ser um instrumento para comunicação e documentação do conhecimento em um time de engenharia de software.

Ou seja, são atividades de cognição e comunicação humanas que precisam ser eficazes e eficientes para que o programa tenha qualidades.

A interpretação destas linguagens pelos computadores é a parte mais fácil. O computador aprende facilmente a interpretar qualquer linguagem. Desde que alguém codifique um programa para tal, claro.

Afirmar qual a melhor linguagem para o processo ensino-aprendizado requer uma investigação científica com métodos adequados para avaliar cognição e comunicação humanas. Atualmente, o foco em CC tem sido quase sempre em avaliar as qualidades objetivas (desempenho, paradigmas, tipagem, etc.) destas linguagens. E nem sempre isto é feito! Linguagens de programação são instrumentos de interação humano-computador. Métodos de avaliação da disciplina IHC podem e devem ser aplicados para este fim.

Ensinar programação é ensinar um instrumento que seja mais adequado a estes propósitos. Ensinar apenas a utilizar o instrumento não é suficiente.

Não sou favorável a um profissional que apenas sabe falar "Javanês". Chamo Javanês ao estilo de programação utilizando sentenças lingüísticas em Java que são exclusivas daquela linguagem (expressões idiomáticas) praticadas por programadores extremamente competentes e especializados. Além soar pedante, como nos textos dos intelectuais letrados ou das sentenças dos magistrados que muitas vezes são propositadamente escritos para mostrar que eles estão acima dos mortais comuns, não incentiva o entendimento do código pelos seus pares. Isso não cabe numa atividade profissional coletiva, como é a engenharia de software, que visa a colaboração e a evolução da programação.

Temos seguidores?

2009-07-30T22:55:00.003-03:00

Este blog está parado há bastante tempo, mas as estatísticas indicam que ele continua sendo visitado. Que bom!

Estou me dedicando bastante na implantanção de um curso de graduacão em Engenharia de Software na UFRN. Além disso, temos projetos e aulas em andamento.

Caso você ache que este blog está sendo útil e merece ser continuado, você pode enviar um comentário ou ser um seguidor. Ainda temos muito a falar sobre engenharia de software!

Graduação em Engenharia de Software

2009-05-29T21:46:00.002-03:00

Em 2010, a UFRN iniciará um curso de Engenharia de Software (Bacharelado). Veja mais!

Design Conceitual

2007-07-05T18:33:00.001-03:00

O software pode ser considerado como um artefato virtual que compreende as soluções que foram concebidas de acordo com os requisitos. Este artefato virtual é uma entidade abstrata que existe na mente dos usuários quando eles estão interagindo com o software.

Esta entidade virtual é o modelo conceitual do software. Este modelo determina quais conceitos (ou objetos virtuais) estão presentes no software, quais as funções (ou tarefas) que o usuário pode utilizar –funcionalidade – e como ele pode interagir com o software – interatividade. Este modelo também é conhecido como metáfora da aplicação.

Por exemplo, num editor de texto, como o MS Word, temos diversos conceitos que permitem ao usuário entender como está estruturado um documento e o que ele pode fazer com ele. No Word, encontramos os conceitos de página, bordas de página, margens, parágrafos, recuos de parágrafos, espaçamento entre linhas, distância-da-primeira-linha, distância-antes-do-parágrafo, tamanho da letra, estilo da letra e diversos outros. Todos esses conceitos são baseados em conceitos que estão presentes na tipografia ou mesmo em maquinas de escrever.

A elaboração de um modelo conceitual é fator determinante no sucesso de uma aplicação. O modelo conceitual precisa ser concebido e especificado adequadamente pelo designer, de acordo, com as necessidades, capacidade e limitações dos usuário. Para que o modelo seja adequado aos usuários, a especificação dos requisitos é fundamental. Nela encontramos, os papéis de usuários, o modelo de tarefas, os casos de uso, os conceitos do domínio e outras informações. A partir delas temos condições de elaborar um modelo conceitual que seja adequado aos requisitos dos usuários.

Para que a aplicação seja utilizada adequadamente é preciso que o usuário conheça o modelo conceitual da aplicação que foi elaborado pelo designer. Para isto é preciso que ele seja comunicado adequadamente ao usuário. Uma das formas de comunicar este modelo é através dos manuais de usuário ou de treinamento feito por pessoas especializadas. A outra forma é tentar expressar os conceitos através da interface de usuário. A interface é quem oferece a imagem externa do sistema e que deve ser interpretada de maneira correta pelo usuário. Ela deve comunicar para o usuário quais os objetos do domínio estão representados, o que ele pode fazer (a funcionalidade) com este conceitos e como ele pode interagir (o modelo de interação) com esta funcionalidade.

Exemplo: o modelo conceitual de um sistema operacional

Ao utilizarmos um sistema operacional, como o unix/linux, sabemos que podemos construir, armazenar e organizar arquivos de software em diretórios. Um arquivo é na verdade uma seqüência de bits como endereço e tamanho definidos. No entanto, para o usuário o arquivo é algo conceitual que se refere a documentos, programas, dados, etc. Esta entidade conceitual é compreendida por usuários por que ele tem um nome, um tipo, uma data de criação e um tamanho em bytes.

Os arquivos são armazenados em discos em trilhas e setores e podem ser localizados a partir de uma tabela que associa o seu nome ao local físico. Para o usuário, arquivos são colocados "dentro" de uma outra entidade conceitual: o diretório.

Arquivos e diretórios são os conceitos do software e podem ser criados, destruídos ou modificados por diversas funções do software. Estas funções são, por exemplo, copiar arquivo, apagar arquivos, construir diretórios, remover diretórios, colocar arquivos em um diretório, mover arquivo de um diretório para outro, etc. Esta funções são também entidades conceituais representadas por um nome que devem indicar, para o usuário, o que o sistema faz.

Por exemplo, o sistema operacional não coloca arquivos “dentro” de um diretório. Isto só existe na mente do usuário. O que o sistema faz é trocar o endereço físico do arquivo na tabela de arquivos e diretórios. Entretanto, a visão de que diretórios são recipientes que armazenam arquivos é muito mais útil para o usuário. Ela permite ao usuário criar na sua mente conceitos que permitem a ele entender o que fazer com o sistema e raciocinar melhor sobre ele.

O sucesso de uma aplicação vai depender justamente da criação deste modelo conceitual. Quanto mais claros forem o conceitos e as operações que se pode fazer com eles, mais o usuário vai saber como aplicá-los na resolução de seus problemas. O sucesso de sistemas como o Macintosh ou o Windows deve-se à construção de modelos conceituais mais familiares para o usuário. Os conceitos de pastas e objetos e a representação deles através de janelas e ícones permite ao usuário criar imagens mentais mais clara. O conceito de pasta como recipiente é mais claro que o de diretório (que na verdade é uma lista). No ambiente Windows o usuário move objetos (documentos, aplicativos, figuras, etc.) de uma pasta para outra e para o topo-de-mesa (desktop) como faria no seus escritório.

A interface de usuário é fundamental para que este modelo conceitual seja comunicado ao usuário. Ela é o melhor meio para que expressar os conceitos da aplicação e as funções que podem ser utilizadas. No MS DOS, a interface é muito pouco expressiva. Na interface o conceito de diretório é visualizado por ele como uma lista de nomes, tipos, tamanhos e datas, que representam cada arquivo do diretório. Cada arquivo é referenciado individualmente pelo seu nome. No Windows 95, o modelo conceitual é representado por desenhos gráficos que representam os conceitos da aplicação de maneira mais clara.

Design de Software

2007-07-02T21:38:00.001-03:00

A atividade de design de software ainda é uma das mais mal compreendidas da engenharia de software. Muitos utilizam o termo para referir-se a definição de “como” o software ser desenvolvido em contraste como a definição do “que” o software deve fazer – determinado pela especificação dos requisitos.

Design de software também é utilizado como sinônimo de arquitetura de software. No entanto, a arquitetura do software, no sentido proposto na década de 90, como sendo a estrutura e o comportamento do software em termos de unidades abstratas interconectadas entre si – componentes e conectores – é apenas um dos produtos do design de software.

Na nossa visão, design é mais do que isso. Design é a atividade de criar, idealizar ou conceber o software. O resultado disso precisa ser expresso através de modelos ou protótipos do software. O design visa apresentar uma solução que satisfaça a especificação de requisitos (funcionais e não-funcionais), definindo o que precisa ser implementado. Este conceito de design é de certa forma contrario àquele tradicionalmente conhecido na engenharia de software, mas segue a linha proposta por Terry Winograd e outros no livro Bringing Design to Software. Precisamos trazer para o desenvolvimento de software a atividade de design que é realizada no desenvolvimento de qualquer produto industrial.

Design poderia ser traduzido tanto por projeto como por desenho. Entretanto, estes dois termos não expressam exatamente o que é design. Projeto é um termo mais abrangente do que design, pois se aplica a projeto de pesquisa, projeto de desenvolvimento de um produto e envolve planejamento, metodologia, cronograma, recursos, etc. Desenho é uma tradução utilizada no sentido de Desenho Industrial (industrial design), mas leva a conotação de que a atividade resume-se a elaborar os diagramas que descrevem os modelos do produto. Por estes motivos vamos utilizar o termo em inglês: design.

Segundo David Liddle, "o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário". [David Liddle, Design of The Conceptual Model, em Winograd, T.]

O design de software compreende a concepção, especificação e prototipação da partes "externas" e "internas" do software. A parte externa compreende o modelo conceitual e a interface de usuário. A parte interna compreende a arquitetura de software e os algoritmos e estruturas de dados que implementam estes componentes.

Resumindo, o design de software envolve:
Design do modelo conceitual,
Design da interface de usuário,
Design da arquitetura de software e
Design dos algoritmos e estruturas de dados

Mais adiante, discutiremos estas atividades.

Modelos de Software

2007-06-03T18:12:00.000-03:00

Modelos são essenciais em qualquer atividade de engenharia. O software, por ser um artefato invisível e conceitual, mas do que qualquer outro artefato, precisa ser construído com base em modelos.

Existem diversos tipos de modelos de software, cada um deles proporcionando visões e níveis de abstração distintos. Diagramas são a forma mais utilizada de modelagem na engenharia de software. Um protótipo também é um tipo de modelo de software que vem sendo utilizado para apoiar diversos métodos de desenvolvimento.

Modelos de software são construídos para uma visualização do sistema a ser construído, permitindo uma melhor compreensão e entendimento. Eles podem também ser utilizados para a especificação e para a documentação do software. O modelo quando utilizado para especificação possibilita uma descrição precisa do será desenvolvido pelos programadores. A documentação através de modelos deve refletir o que foi desenvolvido e será a base para as atividades de manutenção.

De acordo com Booch, Rumbaugh e Jacobsonm (1998), alguns princípios devem ser seguidos:

• A escolha de qual modelo construir tem uma profunda influência em como um problema é atacado e como uma solução é delineada.
• Todo modelo pode ser expresso em diferentes níveis de precisão.
• Os melhores modelos estão conectados à realidade.
• Nenhum modelo único é suficiente. Todo sistema não trivial é melhor abordado através de um conjunto pequeno de modelos proximamente independentes.

O uso de modelos em ambientes integrados de desenvolvimento de software vem sendo utilizado para auxiliar a construção de software. Algumas ferramentas permitem que código seja gerado a partir de modelos. Esta abordagem é conhecida como desenvolvimento dirigido por modelos e tem como base o uso de arquiteturas dirigidas por modelos que são construídas utilizando a UML (Linguagem de Modelagem Unificada).

Veja slides com conceitos e exemplos sobre modelos de software.

Linguagens de modelagem

Durante muitos anos, o maior problema para a utilização de modelos de software foi a falta de uma linguagem de modelagem comum. As diferentes notações e linguagens existentes foram desenvolvidas visando software com características especificas. Por exemplo, desenvolvedores de software de controle e tempo real utilizavam notações como Statecharts e Redes de Petri; desenvolvedores de sistemas de banco de dados utilizavam Diagramas Entidade-Relacionamento (DER); e desenvolvedores de sistemas de informação utilizavam Diagramas de Fluxos de Dados (DFD), como parte de metodologias estruturadas.

Como o surgimento do paradigma de programação orientada-a-objetos, o número de métodos com suas notações associadas aumentou bastante, vindo somar-se aos diversos já existentes. No final da década de 90, o OMG (Objetc Management Group) incentivou a criação de uma linguagem padrão para métodos orientados a objetos. A UML que unificou diferentes notações já existentes foi aprovada para ser um padrão da industria de software.

Veja slides com uma visão geral da UML.

Usando cenários para descobrir requisitos

2007-05-27T21:02:00.001-03:00

Os cenários consistem de uma coleção de narrativas de situações no domínio que favorecem o levantamento de informações, a identificação de problemas e a antecipação das soluções. Cenários são uma maneira excelente de representar, para clientes e usuários, os problemas atuais e as possibilidades que podem surgir.

Os cenários têm como foco as atividades que as pessoas realizam nas organizações possibilitando uma perspectiva mais ampla dos problemas atuais onde o sistema será inserido, explicando porque ele é necessário.

Não é objetivo dos cenários oferecer uma descrição precisa, mas provocar discussões e estimular novos questionamentos. Eles permitem também documentar o levantamento de informações a respeito dos problemas atuais, possíveis eventos, oportunidades de ações e riscos.

Por sua simplicidade, cenários são um meio de representação de fácil compreensão para os clientes e usuários envolvidos (muitas vezes de formação bastante heterogênea) que podem avaliar, criticar e fazer sugestões, proporcionando a reorganização de componentes e tarefas do domínio. Cenários oferecem um "meio-intermediário" entre a realidade e os modelos possibilitando que clientes, usuários e desenvolvedores participem do levantamento das informações e especificação dos requisitos. Em resumo, os cenários permitem compreensão dos problemas atuais pelos analistas e antecipação da situação futura pelo clientes e desenvolvedores.

Antes de descrever os cenários, os analistas devem entrevistar clientes para entender os problemas e requisitos iniciais. A entrevista com usuários permite que cada um descreva as suas tarefas e os problemas associados a cada uma delas. A observação direta in loco é fundamental para que os analistas possam descrever a situação de uso como ela realmente vem ocorrendo na prática.

Após a elaboração dos cenários, clientes, usuários e analistas podem participar de reuniões conjuntas para que possam discutir cada um destes cenários. Eles podem ser afixados em quadros na parede onde os participantes possa analisá-los e fazer comentários, possivelmente afixando pequenos pedaços de papel a cada uma das cenas.

Uma técnica que está bastante relacionada com cenários, por permitir descrever situações de uso, é o storyboarding. Essa técnica envolve a descrição através de quadros com imagens que ilustram as situações do domínio. Cada quadro deve apresentar a cena que descreve a situação, os atores e as ações que cada um deve desempenhar. Abaixo de cada quadro devem estar descritas as ações que os atores desempenham. Os storyboards são bastante utilizados em cinemas como forma de comunicação entre roteiristas, diretores, atores e técnicos.

Exemplos de cenários

Como exemplo vamos considerar o domínio de uma locadora de fitas de vídeo.

Cena 1: Cliente procura uma fita com uma certa atriz
Agentes: Cliente, Atendente, Balconista
Ações:

Cliente entra na loja e dirige-se até a atendente.
Cliente: - Eu gostaria de alugar um filme com a atriz que ganhou o oscar este ano.
Atendente: - Algum específico?
Cliente: - Não, mas que não seja policial ou ação.
Atendente: Você sabe o nome dela?
Cliente: Não.
A atendente pergunta à balconista.
Atendente: - Você sabe o nome da atriz que ganhou o Oscar 99?
Balconista: - Ih. É um nome bem complicado. Só sei que começa com G e o sobrenome é algo parecido com Paltrow.
Cliente: É isto mesmo.
A atendente então procura no fichário de atrizes as que começam com G. Não encontra nenhum nome parecido com o que a balconista falou. Ela então lembra-se de consultar uma revista especializada com os ganhadores do Oscar 99 e lá descobre o nome correto da atriz. Entretanto, não existe realmente ficha alguma com os filmes estrelados por esta atriz. O fichário está desatualizado.
A atendente procura nas estantes alguns filmes e lembra-se de dois: O Crime Perfeito e Seven e mostra-os ao cliente. O cliente recusa-se dizendo que não gosta do gênero destes filmes e pergunta pelo filme vencedor do Oscar.
A atendente responde: - Shakespeare Apaixonado? Ainda não saiu em vídeo.

Cena 2: O cliente procura por filmes de um certo gênero
Agentes: Cliente, Atendente, Balconista
Ações:

Cliente: - Eu gostaria de comprar um filme de ação.
Atendente: - Nós apenas alugamos.
Cliente: - Tudo bem. Então, por favor, me dê algumas dicas de filmes de ação.
Atendente: Com algum ator especial.
Cliente: Pode ser com Chuck Norris, Van Dame, Statellone, Charles Bronson
Atendente: Temos estes aqui.
A atendente apresenta dez filmes. O cliente escolhe cinco e fica em dúvida se já assistiu outros três. Ele também pergunta à atendente se os outros dois filmes são bons. Após conversar durante alguns minutos com a atendente que entende muito do gênero, decide ficar com seis fitas. A atendente encaminha o cliente à balconista para calcular o valor da locação e o prazo de devolução. Após consultar as tabelas de preços e prazos, a balconista apresenta três planos de pagamento.
Balconista: - Se você devolver em um dia, paga apenas R$ 6,00. Se devolver em seis dias paga R$ 12,00 e se devolver em uma semana paga R$ 15,00. Após este prazo paga mais R$ 2,00 por fita, por dia.

Cena 3: Cliente procura por filme usando o sistema de consulta
Agentes: Cliente e Sistema de Consulta
Ações:

João gostaria de assistir a um filme de guerra. Ele vai a uma locadora de fitas e, chegando lá, utiliza um sistema de consulta. Ele não lembra o título nem o diretor, mas sabe que se passava na guerra do Vietnã e lembra bastante da trilha sonora. Utilizando o sistema ele solicita as opções de filmes de guerra. Os sistema oferece a ele as possibilidades de escolher os filmes por local da guerra ou por época. João escolhe a sua opção (guerra) e obtem uma lista com dezenas de filmes sobre o vietnam. Ele pode organizar esta lista, por diretor, atores e título. Na tela do sistema aparecem a ilustração com o cartaz de divulgação do filme e uma opção para ele visualizar o trailler. O sistema, entretanto, não possibilita ele ouvir a trilha sonora.
Após analisar algumas opções ele finalmente encontra o filme desejado, mas uma informação na tela do sistema indica que o filme está alugado. João quer saber quando o filme será devolvido, mas esta informação não consta no sistema. Ele entretanto pode reservar e o sistema enviará para ele um e-mail avisando quando o filme estiver disponível. Ele sai da loja pensando "Que tempo perdido. Seria melhor que eu pudesse consultar o sistema de casa".

Engenharia de Requisitos

2007-05-18T18:17:00.001-03:00

Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples é a decisão de requisitos de segurança mais restritos que podem ir de encontro ao requisito de melhor desempenho.

A importância e complexidade de todas as atividades relacionadas aos requisitos levaram, no início dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.

Os objetivos da Engenharia de Requisitos podem ser categorizados em três grupos principais [Zave]:

Investigação de objetivos, funções e restrições de uma aplicação de software

Ultrapassar as barreiras de comunicação
Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
Compreender prioridades e graus de satisfação
Associar requisitos com os vários agentes do domínio
Estimar custos, riscos e cronogramas
Assegurar completude

Especificação do software

Integrar representações e visões múltiplas
Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
Obter uma especificação completa, consistente e não ambígua
Validar a especificação - verificar que ela satisfaz aos requisitos
Obter especificações que sejam apropriadas para as atividades de design e implementação

Gerenciamento da evolução e das famílias do software

Reutilização de requisitos durante o processo de evolução
Reutilização de requisitos no desenvolvimento de software similares
Reconstrução de requisitos

A engenharia de requisitos é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de observações do mundo real através de notações apropriadas.

Os benefícios da Engenharia de Requisitos são:

Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e quais os critérios de aceitação do sistema.
Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos)
Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
Atingir os objetivos com o mínimo de desperdício

Uma boa especificação de requisitos deve ser:

Clara e não-ambígua
Completa
Correta
Compreensível
Consistente
Concisa
Confiável

(Veja mais em Dorfman, Merlin - Requirements Engineering)

Técnicas de levantamento de requisitos

Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os clientes e usuários e os analistas para que os requisitos possam capturados e modelados corretamente.

Dentre as técnicas mais importantes para a comunicação podemos citar três:

Entrevistas
Observação in loco
Encontros

Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas.

Na observação in loco os analistas devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários.

Os encontros são reuniões envolvendo analistas, clientes e usuários que têm por objetivo exclusivamente realizar o levantamento de informações, a descrição dos problemas atuais e indicar metas futuras e requisitos do sistema. Os encontros devem ser realizados em um local neutro (fora da organização), coordenados por um moderador que também não deve pertencer ao grupo dos envolvidos (stakeholders) e normalmente duram de 1 a 3 dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em painéis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.

Modelos de documentos de especificação de requisitos

O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção deve ser apresentado aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.

Vamos apresentar, a seguir, dois modelos de documentos encontrados na literatura. Estes modelos descrevem não apenas a especificação dos requisitos, mas os resultados do estudo de viabilidade e o processo de desenvolvimento.

Pressman apresenta o seguinte documento de especificação de requisitos de software:

I. Introdução

1. Referências do Sistema
2. Descrição Geral
3. Restrições de projeto do software

II. Descrição da Informação

1. Representação do fluxo de informação

a. Fluxo de Dados
b. Fluxo de Controle

2. Representação do conteúdo de informação
3. Descrição da interface com o sistema

III Descrição Funcional

1. Divisão funcional em partições
2. Descrição funcional

a. Narativas
b. Restrições/limitações
c. Exigências de desempenho
d. Restrições de projeto
e. Diagramas de apoio

3. Descrição do controle

a. Especificação do controle
b. Restrições de projeto

IV. Descrição Comportamental

1. Estados do Sistema
2. Eventos e ações

V. Critérios de Validação

1. Limites de desempenho
2. Classes de testes
3. Reação esperada do software
4. Considerações especiais

VI. Bibliografia
VII Apêndice

Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de requisitos deve possui as seguintes seções:

Visão geral do produto e Sumário
Ambientes de desenvolvimento, operação e manutenção
Interfaces Externas e Fluxo de Dados
Requisitos Funcionais
Requisitos de Desempenho
Tratamento de Exceções
Prioridades de Implementação
Antecipação de mudanças e extensões
Dicas e diretrizes de Design
Critérios de aceitação
Índice Remissivo
Glossário

Referências

Dorfman, Merlin - Requirements Engineering

Zave, Pamela - Classification of Research Efforts in Requirements Engineering - ACM Computing Surveys, vol. 29, no 4, 1997.

Requisitos de Software

2007-05-15T10:20:00.000-03:00

Vimos que o software é parte de um sistema computacional mais abrangente e que a Análise de Sistemas é a atividade de identificar os problemas do domínio, apresentar alternativas de soluções e o estudo da viabilidade de cada uma delas. Uma vez que se tenha feito a análise do sistema computacional, e delimitado o escopo do software, os requisitos do software devem ser definidos e especificados.

O objetivo da definição dos requisitos é especificar o que o sistema deverá fazer e determinar os critérios de validação que serão utilizados para que se possa avaliar se o sistema cumpre o que foi definido.

O que são requisitos?

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários que definem as suas diversas propriedades do sistema. Os requisitos de software são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir (1) para que o usuário possa resolver um problema ou atingir um objetivo ou (2) para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça. Eles definem a funcionalidade desejada do software. O termo função é usado no sentido genérico de operação que pode ser realizada pelo sistema, seja através comandos dos usuários ou seja pela ocorrência de eventos internos ou externos ao sistema.

São exemplos de requisitos funcionais:

"o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal".
"o software deve emitir relatórios de compras a cada quinze dias"
"os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz. É importante diferenciar a atividade de especificar requisitos da atividade de especificação que ocorre durante o design do software. No design do software deve-se tomar a decisão de quais a funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem.

Requisitos não-funcionais são as qualidades globais de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente estes requisitos são descritos de maneira informal, de maneira controversa (por exemplo, o gerente quer segurança mas os usuários querem facilidade de uso) e são difíceis de validar.

São exemplos de requisitos não-funcionais:

"a base de dados deve ser protegida para acesso apenas de usuários autorizados".
"o tempo de resposta do sistema não deve ultrapassar 30 segundo".
"o software deve ser operacionalizado no sistema Linux"
"o tempo de desenvolvimento não deve ultrapassar seis meses".

A necessidade de se estabelecer os requisitos de forma precisa é crítica na medida que o tamanho e a complexidade do software aumentam. Além disso, os requisitos exercem influência uns sobre os outros o que determina uma maior dificuldade no processo. Por exemplo, o requisito de que o software deve ter grande portabilidade (por exemplo, ser implementado em Java) pode implicar em que o requisito desempenho não seja satisfeito (programas em Java são, em geral, mais lentos). Devido à esta complexidade, faz-se necessário que as atividades associadas aos requisitos sejam gerenciadas durante todo o ciclo de vida do sistema.

Análise e especificação de requisitos de software

A análise e a especificação de requisitos de software são atividades para determinar os objetivos de um software e as restrições associadas a ele, bem como elaborar a especificação precisa do software.

Estas atividades devem ser vistas como parte da análise de sistemas. Normalmente, elas são iniciadas juntamente com a análise do sistema, podendo se estender após a elaboração do documento de especificação do sistema, quando serão refinados os requisitos do software.

Análise e especificação são atividades inter-dependentes e devem ser realizadas conjuntamente. A análise é o processo de observação, classificação e modelagem dos elementos do domínio. Deve-se identificar as pessoas, as atividades, as informações do domínio para que se possa decidir o que fará parte do sistema. Pessoas e as atividades que não serão informatizadas deverão ser consideradas entidades externas ao software.

A especificação é a descrição sistemática e abstrata do que o software deve fazer, a partir daquilo que foi analisado. Ela apresenta a solução de como os problemas levantados na análise serão resolvidos pelo software do sistema computacional. Visa descrever de maneira sistemática quais as propriedades funcionais são necessárias para resolver o problema do domínio. A especificação é também a forma de comunicação sistemática com os arquitetos, programadores e testadores do software.

Veja Slides de aula em PDF.

Planejamento: visão geral resumida

2007-05-08T11:58:00.001-03:00

Agora que já conhecemos o processo de estimativas e algumas das métricas utilizadas, vejamos um exemplo de como podemos realizar o planejamento.

A figura a seguir mostra uma visão geral do planejamento.

Com base no modelo de processo de software podemos definir as atividades que precisam ser realizadas. Estas atividades devem ser organizadas em uma estrutura de divisão do trabalho (WBS - Work Breakdown Structure).

Para cada uma das atividades estão definidos os artefatos resultantes e podem ser realizadas estimativas de tamanho destes resultados. Por exemplo, o número de linas de código fonte de uma atividade de codificação ou o número de elementos de diagrama em uma atividade de modelagem.

Com as atividades definidas, pode-se montar a equipe de software. Dados históricos podem indicar as estimativas de produtividade dos membros desta equipe nas atividades definidas no WBS.

As estimativas de tamanho do software podem ser utilizadas para o cálculo das estimativas de esforço para cada atividade. Este valor permite que a alocação pessoa-atividade seja mais eficiente. Por exemplo, para tarefas com maior esforço, pode-se dividir as tarefas entre vários membros da equipe de forma a encurtar o prazo de conclusão da atividade (veja mais informações no post anterior).

Com as estimativas de esforço e a alocação pessoa-atividade, podemos elaborar o cronograma e o orçamento do projeto.

O cronograma deve incluir a definição dos marcos, a análise do caminho crítico através de técnicas PERT/CPM e o diagrama de Gantt.

Os gastos com pessoal são fundamentais para o orçamento do projeto. Assim, apenas com a definição do cronograma é que se pode concluir o orçamento. Além dos custos de RH, não se pode deixar de incluir os custos com equipamentos, ferramentas, infra-estrutura e outros. Veja mais sobre custos.

Métricas

2007-04-28T21:39:00.000-03:00

Várias métricas podem ser utilizadas na elaboração de estimativas. As mais utilizadas são: o tamanho do software, a produtividade dos desenvolvedores, a taxa de defeitos e o esforço humano.

Linhas de código fonte

Uma das métricas mais comuns para software é o número de linha de código fonte (LOC – lines-of-code, em inglês). As linhas de código são, de fato, um resultado imediato da atividade de desenvolvimento do produto final. No entanto, ela não considera diretamente, diversas outras atividades envolvidas, como requisitos, arquitetura, testes e outras. Alguns autores consideram que estas atividades estão implicitamente consideradas, ou seja, para se produzir um certo número de LOC, livre de defeitos, utilizando um certo processo de software, é necessário especificar os requisitos, projetar e modelar a arquitetura e testar o código, por exemplo.

Linhas de código têm a vantagem de ser uma métrica bastante objetiva. Basta analisar o código e se tem o valor do que foi produzido. Estimar LOC é prever quanto precisará ser feito para se obter o produto final.

O tamanho de um software em linhas de código varia de uma linguagem de programação para outra. Isto significa que as estimativas devem considerar dados de projetos similares apenas naquela mesma linguagem. Ou seja, se existe uma métrica de produtividade com uma certa linguagem, não se pode aplicar a mesma métrica numa outra linguagem. O mesmo vale para a funcionalidade. Se numa certa linguagem, para implementar uma certa função, são necessárias 200 LOC, numa outra linguagem a funcionalidade pode ser implementada com apenas 100 LOC. Por fim, pode-se argumentar que programadores mais eficientes conseguem implementar uma mesma funcionalidade, numa mesma linguagem utilizando menos LOC que outro programador. No entanto, em um processo de software bem controlado, a exigência de padrões e normas de programação limita esta variação.

Ponto de função

Análise de pontos de função é um método para identificar uma métrica que é independente da linguagem de programação utiliza e depende apenas da funcionalidade do software. Os pontos-de-função (FP) são dependentes de fatores relacionados aos serviços que o software precisa realizar. Eles são calculados com base em 5 valores que precisam ser atribuídos:

Número de entradas externas (EI)
Número de saídas externas (EO)
Número de consultas externas (EQ)
Número de tabelas lógicas internas (ILF)
Número de interfaces externas (EIF)

Uma vez que todos os valores tenham sido atribuídos, eles precisam ser aplicados numa fórmula empírica para se determinar o número de pontos-de-função. Estes valores são multiplicadores que variam de acordo com a complexidade, sendo classificada em baixa, média e alta.

A tabela a seguir mostra o cálculo do número de pontos-de-função não ajustados (UFP).

	Complexidade
	Baixa	Média	Alta	Total
Entradas externas (EI)	__* 3=EI1	__* 4=EI2	__* 6=EI3	EI1+EI2+EI3
Saídas externas (EO)	__* 4=EO1	__* 5=EO2	__* 7=EO3	EO1+EO2+EO3
Consultas externas (EQ)	__* 3=EQ1	__* 4=EQ2	__* 6=EQ3	EQ1+EQ2+EQ3
Arquivos Lógicos Internos (ILF)	__* 7=ILF1	__* 10=ILF2	__* 15=ILF3	ILF1+ILF2+ILF3
Interfaces externas (EIF)	__* 5=EIF1	__* 7=EIF2	__* 10=EIF3	EIF1+EIF2+EIF3
Total UAF	(EI1+EI2+EI3) + (EO1+EO2+EO3) + (EQ1+EQ2+EQ3) + (ILF1+ILF2+ILF3) + (EIF1+EIF2+EIF3)

O valor final de pontos de função precisa ser ajustado de acordo com 14 características gerais de sistemas, com valores que variam numa escala de 0 a 5 graus, com um menor indicando “sem influência” e o maior indicando “forte influência”.

As 14 características são:

Comunicação de dados
Funções distribuídas
Objetivos de desempenho
Configuração utilizada
Taxa de transação
Entrada de dados on-line
Eficiência do usuário final
Atualização on-line
Processamento complexo
Reusabilidade
Facilidade de instalação
Facilidade de operação
Múltiplos locais
Facilidade de mudança

A soma dos valores de 0 a 5, atribuídos a cada uma das características, é utilizada na fórmula do valor ajustado (VAF), descrita abaixo.

O valor de ajuste VAF é dado pela fórmula abaixo:

VAF = 0.65 + (soma dos valores)/100

O valor final de pontos de função é dado pela fórmula

FP = UAF + VAF

Estimar estes valores para um sistema de informação não é difícil. No entanto, para sistemas de controle, sistemas multimídia, sistema embutidos e outros, não é fácil identificar os valores para estas variáveis.

Esforço Humano

Estimar o esforço humano é fundamental para o planejamento. O esforço humano define uma métrica que estabelece a relação entre o tempo necessário para realizar uma atividade e o número de pessoas envolvidas. Isto porque a duração da atividade pode variar de acordo com o número de pessoas envolvidas com ela. Para isto é necessário que a tarefa possa ser dividida e compartilhada entre os desenvolvedores.

Por exemplo, um trabalhador pode colher um laranjal em 10 dias. Se 10 trabalhadores forem utilizados, em apenas 1 dia o laranjal será colhido. No entanto, nem sempre é possível compartilhar uma tarefa, pois embora uma mulher possa gerar 1 filho em 9 meses, 9 mulheres não podem gerar 1 filho em 1 mês!

Estimar o esforço é indicar a quantidade de pessoas necessária para realizar uma atividade num certo período de tempo. As unidades utilizadas são: pessoa-mês, pessoa-hora, homem-mês, ou qualquer combinação entre ser humano e unidade de tempo.

Para entender melhor, o esforço reflete a relação inversa entre o número de trabalhadores e o tempo para realizar a atividade. Isto, no entanto, não pode deixar de levar em consideração fatores externos que limitam o aumento do número de trabalhadores. Quanto mais trabalhadores compartilhando uma tarefa, mais canais de comunicação são estabelecidos, mais compromissos são gerados, maior cooperação é necessária e maiores conflitos podem existir. Tudo isso pode limitar o aumento da produtividade global da equipe.

No livro “The Mythical Man-Month", um clássico da engenharia de software, Fred Brooks relata sua experiência no desenvolvimento do OS 360 da IBM e mostra que tentar cumprir prazos de projetos atrasados com o aumento do número de trabalhadores pode ter efeito contrário.

Para saber mais:

Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.

Estimativas de Software

2007-04-28T21:31:00.002-03:00

As estimativas do produto e do processo são a base para o planejamento do projeto de software. As estimativas fornecem dados que permite prever a quantidade de pessoas que serão necessárias, o tempo necessário e os custos do projeto. Não é possível elaborar cronograma e orçamento sem o uso de estimativas.

É importante ressaltar que os diversos elementos do planejamento estão relacionados entre si. Por exemplo, um dos maiores impactos nos custos de um software são os recursos humanos. Normalmente, um desenvolvedor ganha um salário mensal tornado este custo diretamente proporcional ao tempo de desenvolvimento.

Para determinar o tempo de desenvolvimento é necessário estimar a duração das atividades do software. Estimativas da duração do software dependem do tamanho do software que é necessário produzir e da produtividade dos desenvolvedores.

Estimativas são realizadas com base em métricas. Métricas de tamanho, duração, produtividade e esforço estão entre as mais utilizadas. Para fazer as estimativas, pode optar por duas estratégias:

Métricas com base no histórico da organização
Métricas estatísticas de diferentes organizações

As métricas históricas funcionam bem quando a organização é estável e já possui informações colhidas em anos de experiência. Para isso, é fundamental que exista um processo de gerenciamento do processo de software cuidadoso e que todos os dados sejam obtidos para serem analisados e avaliados. Como isso, pode-se estimar como a equipe irá produzir ou qual será o tamanho do software a partir de casos anteriores semelhantes.

Neste caso, as estimativas podem ser realizadas por especialistas que atribuem valores com base em sua experiência de projetos anteriores. Neste caso, pode-se utilizar analogias com projetos anteriores e estimar quais seriam os valores para o novo projeto.

A métricas estatísticas são elaboradas por empresas especializadas que obtêm dados de diversas organizações de desenvolvimento de software. Estes dados devem levar em consideração as diversas condições e características que causem impacto no desenvolvimento do software. Com base nestes valores, os especialistas elaboram tabelas, fórmulas e algoritmos que podem ser aplicadas no planejamento de um processo de software. Isto permite que as organizações de desenvolvimento possam elaborar o seu planejamento ajustando os valores às suas próprias condições.

Os métodos algorítmicos para a realização de estimativas oferecem uma opção mais independente e objetiva. Um exemplo desses métodos são as estimativas de esforço. Esses métodos estão centrados no tamanho do software e da produtividade da equipe:

Esforço = Produtividade*Tamanho^B*M

Existem diversas variantes desta fórmula de maneira que se possa realizar ajustes de acordo com as características da organização e de outros fatores relacionados ao produto.

Um exemplo de modelo baseado nesta fórmula é o COCOMO (Modelo de custos construtivo). A versão inicial foi proposta em 1981, por Barry Boehm. Esta versão evoluiu para o COCOMO II que considera características dos software atuais. O COCOMO II permite associar multiplicadores que levam em consideração o nível (fase) do projeto e a sua complexidade.

Veja a apresentação powerpoint sobre este assunto.

Para saber mais:

COCOMO II

Planejamento e Gerenciamento de Projetos de Software

2007-04-28T01:32:00.001-03:00

Quase todas as atividades que desempenhamos precisam ser planejadas e gerenciadas. Atividades de engenharia requerem um planejamento cuidadoso. Normalmente, os produtos são complexos, com muitas partes envolvidas, e as atividades são realizadas por um grupo muito grande de pessoas.

Na engenharia de software não é diferente. Um projeto de engenharia de software deve estar baseado em um planejamento para que se possa gerenciar adequadamente a sua realização.

Planejamento

Planejar é estimar quais as atividades deverão ser realizadas; quem deverá realizá-las; quando devem ser realizadas e finalizadas; e quanto elas deverão custar. Tudo isto requer a elaboração de estimativas em relação ao número e à dimensão dos artefatos, do número de pessoas necessárias, dos prazos e dos custos.

Para isto, a atividade de planejamento deverá resultar:

Na realização de estimativas
Na elaboração da estrutura de divisão do trabalho (WBS – Work Breakdown Structure)
Na definição da equipe e demais recursos
Na alocação de pessoa-atividade
Na elaboração do cronograma
Na elaboração do orçamento

Além disso, a análise de riscos e as revisões periódicas do plano são fundamentais para garantir que ele seja cumprido.

O planejamento está diretamente ligado ao processo de software. Conforme dissemos anteriormente, um processo de software é resultado do planejamento associado a um modelo de processo (método). O modelo de processo indica quais atividades devem ser realizadas e qual a dependência entre elas. Por exemplo, no modelo cascata, deve-se especificar os requisitos, desenhar a arquitetura, fazer o design detalhado, implementar as unidades, integrar as unidades e, finalmente, entregar o software. O planejamento deve indicar quem faz estas atividades, quanto tempo é necessário para eles, quando elas serão realizadas e quanto custará cada um delas.

Sem um planejamento adequado, os desenvolvedores não saberão o que fazer e não terão datas para iniciar ou terminar o trabalho. Sem estimativas, o responsável pelo planejamento não terá como dimensionar o tamanho e a quantidade dos artefatos a serem produzidos e o esforço necessário para produzi-los. Por fim, sem um orçamento, não se terá noção quanto o software irá custar e se haverá recursos para o desenvolvimento.

Gerenciamento

Gerenciar é fazer cumprir o que foi planejado. O papel do gerente de projetos de software é coordenar a equipe, controlar a produção dos artefatos, fazer cumprir prazos e custos, analisar métricas de produção.

O gerenciamento de software está diretamente ligado à garantia da qualidade do processo e do produto de software. O uso de métricas de qualidade, tanto do produto como do processo, são fundamentais para o gerenciamento. Com base em métricas, o gerente tem condições de avaliar se o planejamento está sendo cumprido ou não. Neste caso, as métricas podem apontar as causas dos problemas e permitir as revisões no planejamento.

Exemplos de métricas do produto utilizadas no planejamento são: tamanho do software em linha de código fonte; número de pontos-de-função; número de diagramas de arquitetura; números de defeitos; entre outras.

Exemplos de métricas de processo utilizadas no planejamento são: o esforço; a produtividade; entre outras.

Plano de Projeto de Software

O resultado de um plano de projeto de software é um documento contendo a equipe, o WBS, a alocação pessoa-tarefa, a análise de riscos, o cronograma, o orçamento entre outros.

A estrutura de um plano de projeto de software, segundo Ian Sommerville (2004) é a seguinte.

Introdução
Organização de projeto
Análise de riscos
Requisitos necessários de hardware e software
Estrutura analítica de trabalho
Cronograma de projeto
Mecanismos de monitoramento e elaboração de relatórios

Esta estrutura pode variar de acordo com as características do projeto.

Diversos outros documentos podem complementar informações importantes:

Plano de qualidade – descreve os procedimentos de testes de qualidade que serão utilizados.
Plano de validação – descreve a abordagem, os recursos e o método utilizados pa validação.
Plano de manutenção – prevê requisitos, custos e esforço necessário para a manutenção.
Plano de desenvolvimento da equipe – descreve como as habilidades e a experiência serão desenvolvidas.

Veja mais em nosso slides.

Referência

Ian Sommerville - Engenharia de Software

Por que o Windows Vista atrasou?

2007-03-11T12:00:00.000-03:00

A empresa de desenvolvimento de software mais poderosa do mundo não conseguiu entregar o seu produto dentro do prazo previsto. O Windows Vista tinha entrega prevista para março de 2006, mas acabou sendo entregue 10 meses depois. Os principais motivos foram problemas com a sua arquitetura e gerência de software. Estes problemas vêm, há anos, sendo descritos na literatura da Engenharia de Software.

O código do Vista cresceu para o espantoso número de aproximadamente 50 milhões de linhas de código fonte e sua arquitetura tornou-se um caótico “spaghetti”. Uma arquitetura spaguetti é aquela na qual o código torna-se tão dependente de outras partes que o acompanhamento do fluxo de controle possui tantas idas e vindas de uma parte para a outra que fica praticamente impossível entendê-lo. Além disso, qualquer pequeno ajuste em uma pequena parte do sistema é imprevisível e pode desestabilizar o código, levando-o a um comportamento defeituoso.

Os problemas e causas do código spaguetti foram diagnosticados no final da década de 60 e durante os anos 70 diversas estratégias foram apontadas para evitá-lo. Dentre elas estão as técnicas de programação estruturada, o princípio da informação escondida e a modularização. Para solucionar o problema do código spaguetti, a Microsoft jogou fora o código trabalhado e voltar ao código de base do servidor do Windows 2000/XP que possuía bem menos defeitos. A equipe foi orientada a construir módulos a partir desta base.

Outro fator fundamental foi que a equipe cresceu para a enorme quantidade de 4000 programadores e 4000 testadores. Este número cresceu devido a um fator condenado há vários anos na engenharia de software no clássico livro “The Mythical Man-Month” de Frederick Brooks, engenheiro de software da IBM, responsável pelo sistema operacional OS-360, na segunda metade da década de 60 (Brooks, 1975). Em seu livro de 1975, Fred Brooks aponta que quando uma empresa está com prazos apertados, o aumento no número de pessoas na equipe de desenvolvimento, o que teoricamente poderia reduzir os prazos de entrega, não necessariamente causa o aumento de produtividade. Quando o número de pessoas em uma equipe aumenta, os canais de comunicação aumentam de forma exponencial e a gerência do projeto torna-se extremamente complexa. Quanto mais gente, mais atrasos.

A Microsoft tornou-se a mais poderosa indústria de software por uma boa estratégia política e de marketing – algumas das quais levou a empresa a responder a processos judiciais – e também pela produção de produtos de qualidade. Produtos como o Office são um sucesso pela forma como foram projetados e como o seu processo foi conduzido. A Microsoft conduziu este processo numa estratégia conhecido como “sincronizar-e-estabilizar”(Cusumano, 1997). Neste processo são definidos marcos a partir da divisão do produto em pequenas partes. As partes são entregues a times pequenos de jovens programadores, recém saídos das universidades, que trabalham no estilo “hacking” em salas que lembram alojamentos universitários, movidos a junk food (Coupland, 1995). No processo de sincronizar e estabilizar da Microsoft, builds (código compilado) são produzidos diariamente e em reuniões de sincronização são testados e corrigidos de forma a produzir versões estáveis. Esta estratégia, na década de 90, era bastante diferente daquelas conduzidas pela IBM nas quais milhares de engenheiros eram recrutados para o desenvolvimento de seus produtos de software. Na Microsoft, a equipe que desenvolveu o NT tinha algo em torno de 400 pessoas, na época a maior da empresa.

No entanto, mesmo com o seu bem sucedido processo de software de “sincronizar e estabilizar”, a Microsoft teve bastante dificuldade de realizar sincronização diária com uma equipe de 8000 pessoas e consertar defeitos em um código mal arquitetado com 50 milhões de linhas de código.

A versão beta do Windows Vista ficou pronta em agosto de 2005. Um ano e meio de foi reservado para testes e em janeiro de 2007 foi colocada à venda no mercado mundial. O projeto total levou 6 anos e consumiu 2 bilhões de dólares de investimento em programação e testes (Cusumano, 2006).

O que ocorreu com o desenvolvimento do Vista mostra que mesmo as poderosas empresas ainda cometem erros básicos de engenharia de software. O Windows 95 tinha cerca de 11 milhões de linhas de código e foi construído por um time de 200 pessoas. O Windows 98 tinha cerca de 15 milhões de código e o Windows XP cresceu para 25 milhões, construídos por uma equipe de 2000 pessoas. Terá a próxima versão do sistema operacional da Microsoft a astronômica quantidade de 100 milhões de linhas de código fonte? A empresa será capaz de desenhar uma arquitetura para este código e de gerenciar um time com 16 mil pessoas?

Referências

Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.

Brechner, Eric. "Journey of Enlightenment: The Evolution of Development at Microsoft" - ICSE’05 May 15–21, 2005, St. Louis, Missouri, USA.

Coupland, D. Microserfs. HarperCollins, 1995.
Cusumano, M & Selby, R. How Microsoft Builds Software - Communications of the ACM, jun1997, vol. 40, no. 6

Cusumano, M. ""What road ahead for Microsoft and Windows? Communications of the ACM archive, Volume 49 , Issue 7 (July 2006)

Programação Extrema (XP)

2007-03-11T11:54:00.000-03:00

O método Programação eXtrema (XP, do inglês eXtreming Programming) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a melhoria constante do código (re-trabalho).

A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta é uma das características importantes para o método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação ativa.

Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.

O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.

Estórias de Usuários

A elaboração de estórias de usuário é uma das atividades fundamentais no XP. As estórias de usuário descrevem cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Elas deve devem ser escritas pelos próprios usuários. As estórias de usuário são semelhantes aos casos de uso da UML, mas não são a mesma coisa. A diferença é que elas não se limitam a descrever o processo de interação do usuário com o sistema.

No XP, as estórias de usuário ocupam o lugar dos longos documentos de requisitos nos métodos tradicionais. Cada estória deve ser um texto escrito com aproximadamente 3 sentenças.

As estórias de usuário são a base para a criação de estimativas de tempo que serão utilizadas nas reuniões de planejamento de entregas (releases). O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iterações para cada iteração individual. Cada estória deve levar de 2 a 3 semanas para ser implementada em uma iteração individual. Se levar mais do que isso, a estória precisa ser dividida em duas. Um número de 80 estórias aproximadamente é suficiente para definir um plano de entregas.

As estórias de usuário são também a base para a elaboração dos testes de aceitação. Um ou mais testes de aceitação automatizados deve ser criados para verificar se o programa implementa a estória corretamente.

O envolvimento do usuário, portanto, como autor das estórias, é fundamental para a elaboração do plano de entregas e dos testes de aceitação em cada iteração de desenvolvimento.

Práticas de programação

O processo de programação tem como características a programação em pares e a propriedade coletiva do código.

Na programação em pares, dois programadores ocupam um único computador. Embora, a princípio, isto possa ser visto como um desperdício de esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a qualidade do código e não altera o tempo de entrega, uma vez que haverá um ganho posterior nas etapas de retirada de erros (defeitos). Os dois programadores atuam de forma colaborativa. Enquanto o que está com o teclado e mouse está pensando diretamente na codificação (sintaxe, variáveis, fluxos de controle, etc.), o outro pode pensar estrategicamente em como o código irá interagir como outras partes do programa. Além disso, um atua com uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente prática do codifica-e-conserta, criticada nas origens do desenvolvimento de software, possa ser realiza sem perda da qualidade do software.

A propriedade coletiva do código é outra característica fundamental do método XP, com a rotatividade do código entre os programadores e reuniões freqüentes para estabilizar o código. A propriedade coletiva encoraja o time todo a contribuir com novas idéias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém para aprovar as mudanças. Reuniões freqüentes devem ser definidas como parte do processo iterativo de programação. Estas reuniões devem ser curtas e são realizadas com todos de pé.

A prática do codifica-e-conserta também requer um processo constante de teste de unidade e integração. Para isto funcionar bem, os desenvolvedores devem trabalhar com uma ferramenta de testes automático e um repositório coletivo do código fonte. Os desenvolvedores devem criar testes de unidades e liberar o código apenas quando estiver 100% testado. Uma vez no repositório, qualquer um pode fazer alterações e adicionar novas funcionalidades. Uma ferramenta de controle de versões é fundamental.

O re-trabalho ou re-fabricação é uma atividade fundamental e necessária para o XP funcionar. Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para remover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura obsoletas. O re-trabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do código e aumenta a qualidade do software produzido.

Regras e Práticas

Planejando

Estórias do usuário
Planejando liberações (releases) e pequenas liberações
Dividir projetos em iterações (ciclos)
Medindo velocidade do projeto
Dinâmica de pessoal
Reuniões diárias em pé

Projetando (designing)

Simplicidade (não adicione funcionalidades antes do tempo)
Metáfora
Cartões CRC (Classes, Responsabilidades e Colaboração)
Re-fabricar (refactor)

Codificando

O cliente deve estar sempre disponível.
Programação em pares.
Codificar de acordo com padrões acordados.
Codificar testes de unidade primeiro.
Integrar com freqüência.
O código é propriedade coletiva.
Não atrase.

Testando

Todo código deve ter os testes de unidade.
Cada unidade deve ser testada antes de liberada.
Quando um erro é encontrado, testes devem ser realizados.
Testes de aceitação devem ser freqüentes.

A programação extrema tem sido bem sucedida em projetos pequenos com times pequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.

Para saber mais, consulte www.extremeprogramming.org

O Modelo Espiral

2007-03-02T22:49:00.001-03:00

O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.

Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje uma atividade importantíssima no desenvolvimento de software devido à imaturidade da área e à falta de conhecimento, técnicas e ferramentas adequadas.

O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro estágios.

No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições.
No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou realizar-se simulações do software.
O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente.
O estágio 4 compreende a revisão das etapas anteriores e o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo.

Para saber mais:

Boehm, B. "A Spiral Model of Software Development and Enhancement" - IEEE Computer, vol.21, 5, May 1988, pp 61-72

O Modelo Transformação

2007-03-02T22:38:00.000-03:00

Um programa é uma descrição formal, isto é, ele é descrito por uma linguagem de programação cuja sintaxe e semântica são definidos formalmente. Apenas desta forma é que temos a garantia de que o programa será sempre executado da mesma forma pelo computador.

O modelo Tranformação tem suas raízes na abordagem de métodos formais para o desenvolvimento de software. A idéia é que o desenvolvimento deve ser visto como uma seqüência de passos que gradualmente transforma uma especificação formal num programa. O passo inicial é transformar os requisitos informais numa especificação funcional formal. Esta descrição formal é então transformada numa outra descrição formal mais detalhada, e assim, sucessivamente, até chegar-se a programas que satisfaçam a especificação. Durante este processo de transformações sucessivas - chamado de otimização - as especificação formais produzidas podem ser executadas por um processador abstrato, permitindo uma verificação formal da sua validação antes mesmo que o programa venha a ser implementado. Antes de serem transformadas cada especificação formal deve ser verificada em relação às expectativas dos clientes e usuários.

As transformações devem ser realizadas pelo engenheiro de software. A natureza formal da transformação possibilita a aplicação de verificações matemáticas como prova, consistência e completude da especificação. As transformações podem ser realizadas de maneira automática por ferramentas que traduzem especificações formais mais abstratas em especificações mais detalhadas.

Este modelo prevê que o engenheiro de software deve ter a sua disposição uma biblioteca de componentes reutilizáveis que satisfaça especificações formais. Na otimização, à medida que as especificações de mais baixo nível vão sendo obtidas verifica-se quais componentes da biblioteca implementam parte desta especificação. Um ambiente automatizado de desenvolvimento (uma ferramenta CASE - Computer Aided Software Engineering) pode auxiliar este processo armazenando o histórico de decisões dos engenheiros de software.

Para se aprofundar, leia:

Helmut A. Partsch, Specification and transformation of programs: a formal approach to software development, Springer-Verlag New York, Inc. New York, NY, USA

O Modelo Cascata

2007-03-02T22:35:00.001-03:00

O modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são:

estudo de viabilidade
análise e especificação de requisitos
design da arquitetura
Design detalhado
codificação e testes de unidades
integração e teste do sistema
entrega e instalação
manutenção

Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente.

Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização. Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software.

O modelo Cascata também é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

Características particulares do software (ser conceitual, por exemplo) e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo seqüencial, permitindo volta atrás para eventuais modificações. Veremos mais adiante modelos que propõem maior flexibilidade no fluxo de execução.

As métricas utilizadas nas estimativas de prazos e recursos humanos são ainda bastante imprecisas e quase sempre o planejamento de atividades precisa ser revisto. Normalmente, os prazos não são cumpridos, pois o planejamento, neste modelo, é feito unicamente nas etapas iniciais do desenvolvimento. A estrutura seqüencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

Para saber mais, recomendo os seguintes artigos (em inglês):

The standard waterfall model for systems development NASA webpage, archived on Internet Archive March 10, 2005.
Parnas, David, A rational design process and how to fake it (PDF) .

O Modelo Evolutivo

2007-03-02T22:25:00.001-03:00

O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que é prototipação (ou prototipagem).

Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído.

Objetivos da Prototipação

Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação:

Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória quando se busca examinar uma variedade de opções de design de maneira a evitar a escolha de uma abordagem específica não adequada. Com esses objetivos os desenvolvedores adquirem informações sobre o domínio, os usuário e tarefas. Os usuários podem emitir informações e sugestões mais precisas, tornando-se parceiro das decisões que envolvem o desenvolvimento.

Experimental - é quando a prototipação foca aspectos técnicos do desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para tomada de decisões de design e implementação. Um aspecto essencial é a viabilização de uma base de comunicação entre os usuários e desenvolvedores para soluções de problemas técnicos de viabilidade e usabilidade, dentre outros. As principais vantagens para os desenvolvedores são a verificação e validação das decisões tomadas e soluções apresentadas.

Evolutiva - A prototipação pode ser aplicada de maneira bastante proveitosa num processo de reengenharia em organizações, para avaliar o impacto que a introdução de novas tecnologias pode trazer. Nesse caso o protótipo não é visto apenas como uma ferramenta em projetos individuais, mas como parte de um processo contínuo de evolução dos processos organizacionais. Os desenvolvedores não são mais os protagonistas da prototipação, mas consultores que trabalham em cooperação com os usuários no processo de reengenharia.

Tipos de Protótipos

O relacionamento entre um protótipo e as atividades do processo de desenvolvimento - início do projeto e análise de requisitos, design da interface e da aplicação, e implementação - permite a identificação de quatro tipos de protótipos:

Protótipo de Apresentação - oferece suporte ao início do projeto e é usado para convencer o cliente de que o futuro sistema é viável e que a interface do usuário se adequa aos requisitos. Na maioria dos casos é usado para mostrar visão que o usuário têm do sistema e revelar aspectos importantes da interface.
Protótipo Autêntico - é um sistema de software provisório e funcional, geralmente projetado para ilustrar aspectos específicos da interface de usuários ou parte da funcionalidade, ajudando na compreensão dos problemas envolvidos.
Protótipo Funcional -- é derivado do modelo do domínio do problema ou da especificação do software e serve para ajudar à equipe de desenvolvimento compreender questões relacionadas com a construção do sistema. Esse protótipo não interessa aos usuários.
Sistema Piloto - é usado não apenas com propósitos ilustrativos, mas como um núcleo básico operacional do sistema. Esse sistema deve ser instalado no ambiente de aplicação e experimentado com os usuários.

O fluxo de atividades do modelo evolutivo caracteriza-se por ser cíclico ou iterativo. Ele começa com o design e desenvolvimento de um protótipo inicial, que deve ser mostrado aos usuários e avaliado. Durante a avaliação novos requisitos são definidos e alterações e incrementos ao protótipo inicial devem ser feitas. Este ciclo deve ser repetido em direção ao produto final.

A grande vantagem deste modelo está em permitir a verificação antecipada do produto final por engenheiros, clientes e usuários, permitindo a correção dos problemas detectados.

A extrema flexibilidade deste modelo e a sua falta de rigor leva a software que embora satisfaça aos requisitos dos usuários têm deficiências de desempenho, portabilidade, manutenção e outras qualidades internas.

Embora a prototipação tenha enormes vantagens e deva ser incentivada, basear o desenvolvimento no incremento de protótipos pode levar a software mal documentados e com arquiteturas mal definidas. Como os requisitos estão sempre sendo revistos a cada ciclo de desenvolvimento, torna-se praticamente impossível estimar custos e prazos e planejar as atividades de desenvolvimento.

Leituras recomendadas:

Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 17.
S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.

Processo de Software

2007-03-02T21:52:00.001-03:00

Vimos que a engenharia de software requer que as atividades para desenvolver o software sejam feitas de forma planejada, gerenciada, com pessoal capacitado, custos e prazos estimados e utilizando teorias, métodos, técnicas e ferramentas adequadas.

Elaborar um processo de software significa determinar de forma precisa e detalhada quem faz o que, quando e como. Um processo pode ser visto como uma instância de um modelo de processo ou método com suas técnicas e ferramentas associadas. O processo é definido durante a etapa de planejamento, no qual as atividades que o compõem foram alocadas aos membros da equipe de desenvolvimento, com prazos definidos e métricas para se avaliar como elas estão sendo realizadas.

Enquanto um método é algo teórico, o processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos. O processo é o resultado do planejamento e precisa ser gerenciado no decorrer de sua execução.

Não é objetivo deste texto a elaboração de processos de desenvolvimento. Apenas podemos fazê-lo após estudarmos técnicas de planejamento e gerenciamento. Neste capítulo vamos nos limitar a estudar alguns modelos de processo que nos indique como as diversas etapas e atividades do desenvolvimento podem ser estruturadas.

Conceitos importantes

Um processo é organizado em atividades.
Atividades são de responsabilidade de um membro da equipe (trabalhador).
Atividades devem gerar um artefato de saída, que possa ser verificado, e podem requisitar um artefato de entrada.
Um artefato é um modelo, documento ou código produzido por uma atividade.
Uma entrega (liberação) é um artefato entregue ao cliente
Um processo deve estabelecer uma série de marcos.
Um marco é um ponto final de uma atividade de processo.

Modelos de Processo

Um modelo para um processo de desenvolvimento é uma proposta teórica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem. Nesta seção vamos apresentar alguns dos mais conhecidos modelos do processo de desenvolvimento. Eles são o modelo Cascata, o modelo Evolutivo, o modelo Incremental, o modelo Espiral, o modelo Transformação, o modelo XP (eXtreme Programming), e RUP (Processo Unificado da Rational).

A escolha de um destes modelos envolve diversos fatores. Um deles é o tipo de software - se é um software de banco de dados, um software de tempo-real, um software embutido, um sistema especialista. Outro fator importante é se a equipe de desenvolvimento é uma empresa de desenvolvimento (software house), uma fábrica de software (desenvolvimento em linha de produção) ou se é a equipe de engenheiros da própria organização que utilizará o produto. A maneira como o produto será vendido e instalado é um outro fator importante - se o software é para ser vendido para um público amplo (software genérico) ou se será instalado em uma única empresa, sob encomenda.

Um conjunto de modelos de processo ou métodos, as técnicas de desenvolvimento é uma metodologia de desenvolvimento.

Para saber mais, recomendo os artigos:

Fuggetta, A. Software process: a roadmap, in Finkelstein, A. (ed.) The Future of Software Engineering, ACM Press, 2002
Sommervile, I.Software Process Models, ACM Computing Surveys, Vol.28, no.1, March 1996.

Veja os slides em PDF.

Ciclo de Vida do Software

2007-02-23T22:23:00.000-03:00

O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum.

O conceito de ciclo de vida de um software é muitas vezes confundido com o de modelo de processo (assunto do próximo artigo).

Existem várias propostas e denominações para as fases do ciclo de vida de um software. Nossa proposta identifica 4 fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas. Essas fases são:

Definição
Desenvolvimento
Operação
Retirada

Fase de Definição

A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de solução de sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução será a escolhida.

O resultado desta atividade deve incluir a decisão da aquisição ou desenvolvimento do sistema, indicando informações sobre hardware, software, pessoal, procedimentos, informação e documentação.

Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software, é necessário elaborar o documento de proposta de desenvolvimento de software. Esse documento pode ser a base de um contrato de desenvolvimento.

Profissionais de engenharia de software atuam nesta atividade com o objetivo de identificar os requisitos de software e modelos de domínio que serão utilizados na fase de desenvolvimento. Os requisitos são também fundamentais para que o engenheiro possa elaborar um plano de desenvolvimento de software, indicando em detalhes os recursos necessários (humanos e materiais), bem como as estimativas de prazos e custos (cronograma e orçamento).

Não existe um consenso sobre o caracteriza o final da fase de definição. Isto varia de acordo com o modelo de processo adotado. Em algumas propostas, a fase de definição é considerada concluída com a apresentação da proposta de desenvolvimento apenas. Outros modelos de processo, considera que o software apenas está completamente definido com a especificação de requisitos e com a elaboração do plano de desenvolvimento de software.

De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de desenvolvimento mesmo que a fase de definição não esteja completamente concluída.

Fase de Desenvolvimento

A fase de desenvolvimento ou de produção do software inclui todas as atividades que tem por objetivo a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e validação do software.

Design

A atividade de design compreende todo o esforço de concepção e modelagem que têm por objetivo descrever como o software será implementado. O design inclui:

Design conceitual
Design da interface de usuário
Design da arquitetura do software
Design dos algoritmos e estruturas de dados

O design conceitual envolve a elaboração das idéias e conceitos básicos que determinam os elementos fundamentais do software em questão. Por exemplo, um software de correio eletrônico tradicional inclui os conceitos: mensagem, caixa de entrada, caixa de saída, etc. A mensagem, por sua vez, inclui os conceitos de para, cc, bcc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos software, novos modelos conceituais podem vir a ser adotados. O conceito de conversação do Gmail é um exemplo.

O design conceitual exerce influência na interface de usuário e na arquitetura do software.

O design da interface de usuário envolve a elaboração da maneira como o usuário pode interagir para realizar suas tarefas, a escolha dos objetos de interfaces (botões, menus, caixas de texto, etc.), o layout de janelas e telas, etc. A interface deve garantir a boa usabilidade do software e é um fundamental fator de sucesso do software.

O design de arquitetura de software deve elaborar uma visão macroscópica do software em termos de componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a visão arquitetônica adotada. São exemplos de visões arquitetônicas, a visão conceitual, visão de módulos, visão de código e visão de execução.

Na visão conceitual, os componentes de software são derivados do design conceitual. Estes componentes são abstrações que devem definir outros elementos menos abstratos. Exemplos são arquiteturas cliente-servidor e arquitetura em camadas. Na visão de código, deve-se determinar como as classes e/ou funções estão organizadas e interagindo entre si. Estas classes implementam os componentes abstratos ou conceituais. Na visão de módulos, deve-se determinar quais são os módulos que serão utilizados na implementação e como eles organizam as classes e/ou funções. Na visão de execução, a arquitetura deve descrever os diferentes processos que são ativados durante a execução do software e como eles interagem entre si. Enquanto as anteriores oferecem uma visão estática, esta é uma visão dinâmica do software.

O design de algoritmos e estrutura de dados, também conhecido como design detalhado, visa determinar, de maneira independente da linguagem de programação adotada, as soluções algorítmicas e as estruturas de dados associados. Deve-se decidir, por exemplo, como as informações podem ser ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista encadeada) elas vão ser armazenados.

Implementação

A implementação envolve as atividades de codificação, compilação, integração e testes. A codificação visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificação deve refletir a estrutura e o comportamento descrito no design. Os componentes arquiteturais devem ser codificados de forma independente e depois integrados. Os testes podem ser iniciados durante a fase de implementação. A depuração de erros ocorre durante a programação utilizando algumas técnicas e ferramentas. É fundamental um controle e gerenciamento de versões para que se tenha um controle correto de tudo o que está sendo codificado.

Verificação e validação

Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de testes podem ser aplicadas para cada um destes fatores

Fase de Operação

A fase de operação envolve diferentes tipos de atividades:

Distribuição e entrega
Instalação e configuração
Utilização
Manutenção

A distribuição e entrega pode ser feita diretamente pelo desenvolvedor (em caso de software personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou para ser baixado pela Internet (em caso de software genéricos).

O processo de instalação e configuração, normalmente, pode ser feito com a ajuda de software de instalação disponibilizados pelos fabricantes dos ambientes operacionais.

A atividade de utilização é o objeto do desenvolvimento do software. A qualidade da utilização é a usabilidade do software.

A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A manutenção corretiva visa a resolução de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade, etc.). A manutenção evolutiva ou adaptativa visa a produção de novas versões do software de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanças no domínio de aplicação implicam em novos requisitos e incorporação de novas funcionalidades. Surgimento de novas tecnologias de software e hardware e mudanças para uma plataforma mais avançada também requerem evolução.

Fase de retirada

A fase retirada é um grande desafio para os tempos atuais. Diversos software que estão em funcionamento em empresas possuem excelente níveis de confiabilidade e de correção. No entanto, eles precisam evoluir para novas plataformas operacionais ou para a incorporação de novos requisitos. A retirada desses software legados em uma empresa é sempre uma decisão difícil: como abrir mão daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de treinamento e utilização?

Processos de reengenharia podem ser aplicados para viabilizar a transição ou migração de um software legado para um novo software de forma a proporcionar uma retirada mais suave.

O material de aula pode ser baixado aqui (arquivo em PDF).

O que é Engenharia de Software?

2007-02-22T16:08:00.001-03:00

O que é Engenharia?

Vejamos duas definções:

Engenharia é a atividade em que os conhecimentos científicos e técnicos e a experiência prática são aplicados para exploração dos recursos naturais, para o projeto, construção e operação de objetos úteis (Origem: Wikipédia, a enciclopédia livre).

Engenharia é a aplicação de métodos científicos ou empíricos à utilização dos recursos da natureza em benefício do ser humano (Dicionário Houaiss)

Essas definições não são suficientes para designar tudo aquilo que envolve engenharia. Para entender melhor o que é engenharia, propomos que você faça uma pesquisa para responder as seguintes questões:

Qual a diferença entre o desenvolvimento de um produto de forma artesanal e o desenvolvimento seguindo os princípios de engenharia? Em outras palavras, qual a diferença entre o trabalho de um artesão e o de um engenheiro?
Qual a diferença entre cozinhar e fazer engenharia de alimentos?
O que as diferentes engenharias (civil, mecânica, elétrica/eletrônica, química, ambiental, etc.) têm em comum?

Uma engenharia não é uma atividade específica. Um engenheiro é aquele que tem o conhecimento científico e a experiência para desempenhar uma ou mais das diversas atividades da engenharia.

Além disso, a atividade de engenharia não pode prescindir da garantia da qualidade do produto, da conformidade às normas, e do planejamento e gerenciamento de custos e prazos.

Objetivos da Engenharia de Software

A engenharia de software tem por objetivos a aplicação de teoria, modelos, formalismos e técnicas e ferramentas da ciência da computação e áreas afins para a produção (ou desenvolvimento) sistemática de software.

Associado ao desenvolvimento, é preciso também aplicar métodos, técnicas e ferramentas para o gerenciamento do processo de produção. Isto envolve planejamento de custos e prazos, montagem da equipe e garantia de qualidade do produto e do processo.

Finalmente, a engenharia de software visa a produção da documentação formal do produto, do processo, dos critérios qualidade e dos manuais de usuários finais.

Definições de Engenharia de Software

Os autores apresentam diversas definições para engenharia de software. Vamos apresentar três que consideramos complementares.

A engenharia de software é a disciplina envolvida com a produção e manutenção sistemática de software que são desenvolvidos com custos e prazos estimados.
Disciplina que aborda a construção de software complexo - com muitas partes interconectadas e diferentes versões - por uma equipe de analistas, projetistas, programadores, gerentes, "testadores", etc.
O estabelecimento e uso de princípios de engenharia para a produção economicamente viável de software de qualidade que funcione em máquinas reais.

A primeira destas definições enfatiza que a engenharia visa não apenas o desenvolvimento, mas também a manutenção do produto. Além disso, ela ressalta a importância da estimativa de custos e prazos de desenvolvimento.

A segunda definição enfatiza a complexidade do produto e do processo. O software é formado por diversos componentes interconectados e o seu desenvolvimento é realizado por uma equipe com diferentes funções e especialidades, cujo trabalho precisa ser gerenciado.

A terceira ressalta que o desenvolvimento de software deve seguir os princípios comuns a todas as engenharias e deve visar a qualidade.

Veja o material apresentado em aula ( arquivo em PDF).

Para saber mais:

James D. Herbsleb. Beyond computer science. Proceedings of the 27th international conference on Software engineering 2005, Pages: 23 - 27.
Boehm, B. "A view of 20th and 21st century software engineering", Proceeding of the 28th international conference on Software engineering 2006, Shanghai, China May 20 - 28, 2006.
Brooks, Jr., Frederick P. No Silver Bullet - Essence and Accidents of Software Engineering, in The Mythical Man-Month.Essays on Software Engineering, Twentieth Anniversary Edition, Reading, MA: Addison-Wesley1995
Finkelstein, A. Kramer, J. "Software engineering: a roadmap", in Finkelstein, A. (ed.) The Future of Software Engineering, ACM Press, 2002
Shaw, M. Software Engineering Education: a roadmap.in Finkelstein, A. (ed.) The Future of Software Engineering, ACM Press, 2002
Shaw, M. What Makes Good Research in Software Engineering. ETAPS, Grenoble, 2002.

Sistemas Computacionais

2007-02-15T23:18:00.000-03:00

Um sistema computacional (ou baseado em computador) é aquele que automatiza ou apóia a realização de atividades humanas através do processamento de informações.

Um sistema baseado em computador é caracterizado por alguns elementos fundamentais.

Hardware
Software
Informações
Usuários
Procedimentos ou Tarefas
Documentação

O hardware corresponde às partes eletrônicas e mecânicas (rígidas) que possibilitam a existência do software, o armazenamento de informações e a interação com o usuário. A CPU, as memórias primária e secundária, os periféricos, os componentes de redes de computadores, são exemplos de elementos de hardware. Um único computador pode possibilitar a existência de diversos sistemas e um sistema pode requisitar diversos computadores.

O software é a parte abstrata do sistema computacional que funciona num hardware a partir de instruções codificadas numa linguagem de programação. Estas instruções permitem o processamento e armazenamento de informações na forma de dados codificados e podem ser controladas pelo usuário. Este controle, bem como a troca de informações entre o usuário e o sistema é feita através da interface de usuário, composta por hardware e software.

A informação é um componente fundamental nos sistemas baseados em computador. Por isto eles podem também ser chamados de sistemas baseados em informação. Sistemas processam e armazenam dados que são interpretados como informações pelos usuários através da interface. São os dados que representam elementos do domínio que tornam o sistema útil para os usuários.

Os usuários são também elementos centrais no desenvolvimento de um sistema baseado em computador. As metas de cada usuário, de acordo com o papel que cada um desempenha no domínio, devem poder ser satisfeita pelo sistema.

As tarefas ou procedimentos compreendem as atividades que o sistema realiza ou permite realizar. As tarefas caracterizam a funcionalidade do sistema e devem permitir aos usuários satisfazer as suas metas. Elas devem estar de acordo com os processos da organização (ou do negócio).

A documentação do sistema envolve os manuais de usuário, que contém informações para o usuário utilizar o sistema (documentação do sistema) que descrevem a sua estrutura e o funcionamento. Estes últimos são fundamentais durante o desenvolvimento do sistema para a comunicação entre a equipe de desenvolvimento e para a transição entre as suas diversas etapas e durante a manutenção de um sistema em sua fase operacional.

Um sistema baseado em computador funciona num determinado domínio de aplicação que corresponde a um tipo de ambiente ou organização onde o sistema é utilizado.

Exemplos de sistemas baseados em computador

Sistema de Automação Bancária
Sistema de Folha de Pagamento
Sistema de Controle Acadêmico
Sistema de Biblioteca
Sistema de Controle de Tráfego Urbano
Sistema de Controle de Elevadores
Sistema de Editoração de Jornais e Revistas

Engenharia de Sistemas Computacionais

O desenvolvimento do sistema deve ser pensado como um todo. Os problemas que o sistema deve resolver devem ser analisados e uma solução envolvendo todos os componentes deve ser proposta. O desenvolvimento de cada componente do sistema pode ser conduzido utilizando um "engenharia" específica. É importante ressaltar que o termo engenharia está sendo utilizado de forma imprecisa.

Inicialmente é necessário realizar a análise do sistema. A análise de sistemas tem por objetivo:

a identificação necessidades dos usuários e dos problemas que o sistema deve vir a resolver na organização;
Definição dos requisitos do sistema;
O estudo de viabilidade técnica, econômica (análise custo-benefício) e jurídica de possíveis soluções;
Apresentação das possíveis soluções;
Planejamento do desenvolvimento (custos e cronograma);

Após ter sido escolhida a solução mais viável, parte para a engenharia propriamente dita.

Engenharia de Hardware - construção dos diversos equipamento de hardware, engenharia de redes, etc.
Engenharia de Software - desenvolvimento dos diversos componentes de software que compõe o sistema.
Engenharia de Informações - modelagem e estruturação das informações para que possam ser processadas e armazenadas.
Engenharia de Fatores Humanos ou Usuário - É necessário definir os papeis e os perfis das pessoas que irão utilizar o novo sistema. Os fatores humanos devem ser analisados para que as atividades humanas sejam desempenhada com qualidade.
Engenharia de Procedimentos ou Métodos - Novas tarefas dos usuários devem surgir e outras podem ser extintas. Outras atividades podem ser automatizadas pelo sistema.
Engenharia de Documentação - Toda a documentação do sistema precisa estar claramente descrita, organizada e catalogada. Técnicas da ciência da informação e biblioteconomia, aliada à novas ferramentas para documentação devem ser utilizadas.

Todas estas "engenharias" devem ser concebidas de forma integrada uma vez que o seus elementos estão bastante relacionados entre si. A ênfase em apenas um dos aspectos pode levar a deficiências do sistema em alguns outros componentes.

Na construção de um sistema não podemos nos concentrar apenas na engenharia de software. É preciso considerar que o hardware, bem como as informações e os procedimentos do domínio precisam ser analisados e construídos de forma integrada ao sistema.

Para maiores informações, consulte o material de aula (em PDF).

O que é software?

2007-02-15T22:11:00.001-03:00

Nesta aula você vai saber o que é software, conhecendo também uma perspectiva não convencional.

Um software é um conjunto de programas de computadores, em suas diversas formas (código fonte, objeto, executável, APIs, scripts, etc.) e toda a sua documentação associada.

Um programa é um conjunto de soluções algorítmicas, codificadas numa linguagem de programação, executado numa máquina real.

Os produtos de software podem ser desenvolvidos para um cliente em particular (Software personalizado, sob encomenda) ou para o mercado geral (Software genérico ou COTS – Commercial Off-The Shelf).

O software é um produto conceitual e lógico. Isto significa que o software não é um produto material, ele um produto ou artefato virtual. Ele apenas existe na mente das pessoas envolvidas com o seu desenvolvimento e utilização.

Exemplo

Para exemplificar esta perspectiva de software como artefato, vejamos o exemplo exemplo de um programa trivial que, com pequenas alterações no programa, mas sem alterar a essência do algoritmo, pode ser visto como aplicações de software de distintas.

Vejamos o seguinte trecho de interação entre o usuário (U) e o sistema (S).

S: Forneça um número:
U: 5.3
S: Você deve digitar apenas números inteiros:
U: 5
S: Forneça outro número:
U: 8
S: O resultado é -3

Observando a interação do usuário com o sistema podemos concluir que o software realizou uma subtração. Assim, a funcionalidade deste software é realizar subtrações de dois números inteiros. Vejamos, agora o algoritmo que está por trás deste software.

escreva("Forneça um Número:");
leia A;
enquanto A não for inteiro faça
escreva(Você deve digitar apenas números inteiros:)
leia A;
escreva("Forneça outro Número:");
leia B;
C = A - B;
escreva("O resultado é ", C);

Vejamos agora o que acontece se modificarmos as linhas 1, 6 e 9 deste algoritmo para

escreva("Forneça o valor de venda");
escreva("Forneça o valor de compra");
escreva("O lucro é",C);

Para o programador muito pouca coisa mudou, mas para o usuário deste sistema este software agora é visto como uma aplicação de cálculo de lucros de vendas. As alterações no programa foram bastante pequenas, mas produziu um efeito significativo. A perspectiva de software como artefato deve considerar como o usuário vê a aplicação. Os modelos conceituais da funcionalidade do software são distintos. Desta forma, temos software distintos com aplicações em domínios distintos. O programa nos fornece uma visão de funcionamento. O usuário possui apenas a visão de funcionalidade.

Podemos modificar as mesmas linhas do programa para:

escreva("Salário Bruto");
escreva("Descontos");
escreva("Salário líquido,C);

que produz um novo software.

Como este exemplo podemos entender melhor que embora o software seja um programa, ele precisa ser considerado como um artefato. Nestes exemplos, temos artefatos virtuais diferentes para programas com um mesmo algoritmo.

Para maiores informações, consulte o material de aula (em PDF).