quinta-feira, 5 de julho de 2007

Design Conceitual

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.

segunda-feira, 2 de julho de 2007

Design de Software

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.

domingo, 3 de junho de 2007

Modelos de Software

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.

domingo, 27 de maio de 2007

Usando cenários para descobrir requisitos

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

sexta-feira, 18 de maio de 2007

Engenharia de Requisitos

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.

terça-feira, 15 de maio de 2007

Requisitos de Software

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.

terça-feira, 8 de maio de 2007

Planejamento: visão geral resumida

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.

sábado, 28 de abril de 2007

Métricas

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:

  1. Comunicação de dados
  2. Funções distribuídas
  3. Objetivos de desempenho
  4. Configuração utilizada
  5. Taxa de transação
  6. Entrada de dados on-line
  7. Eficiência do usuário final
  8. Atualização on-line
  9. Processamento complexo
  10. Reusabilidade
  11. Facilidade de instalação
  12. Facilidade de operação
  13. Múltiplos locais
  14. 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

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

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.

  1. Introdução
  2. Organização de projeto
  3. Análise de riscos
  4. Requisitos necessários de hardware e software
  5. Estrutura analítica de trabalho
  6. Cronograma de projeto
  7. 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

domingo, 11 de março de 2007

Por que o Windows Vista atrasou?

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)

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

sexta-feira, 2 de março de 2007

O Modelo Espiral

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

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

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

O Modelo Evolutivo

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:

  1. Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
  2. 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.
  3. 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

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:

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

sexta-feira, 23 de fevereiro de 2007

Ciclo de Vida do Software

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