UNIDESC – CENTRO DE DESENVOLVIMENTO UNIVERSITÁRIO DO CENTRO OESTE

APOSTILA

DE

ENGENHARIA DE SOFTWARE.

Prof. Fábio Aurélio Sales

www.aureliosales.bl.ee

fabio.sales@professor.unidesc.edu.br

Valparaíso

2014

AOS ACADÊMICOS DO 5º E 6º SEMESTRES DO CURSO DE SISTEMA DA INFORMAÇÃO DA UNIDESC. ESTE MATERIAL FOI DESENVOLVIDO COM BASE EM PESQUISAS, EM LIVROS, ARTIGOS, MONOGRAFIAS DE VÁRIOS AUTORES. TORNANDO-SE UM COMPILADO ESSENCIAL DE TÓPICOS RELEVANTES AO CONHECIMENTO DE VOCÊS.

É IMPORTANTE RESSALTAR QUE AS PESQUISAS, CITAÇÕES, E CONTEÚDO DOS AUTORES UTILIZADOS NESTE ARTIGO. SÃO DE FORMA ÚNICA E EXCLUSIVAMENTE PARA FINS DIDÁTICOS, ONDE FICOU-SE PROIBIDA QUALQUER ATIVIDADE COM FINS LUCRATIVOS COM ESTE MATERIAL.

O OBJETIVO DESTA APOSTILA, É SERVIR DE BASE DE CONHECIMENTO AUXILIAR PARA AULAS MINISTRADAS PARA O CURSO DE SISTEMA DE INFORMAÇÃO – PARA QUE VOCÊS ACADÊMICOS, E QUE SE ASSIM POSSAM TER ALGO QUE SE BASEAR. MAS É IMPORTANTE LEMBRA-LOS QUE O USO DE LIVROS, PERIÓDICOS E PESQUISAS SERVEM DE BASE PARA AUXILIÁ-LOS NOS SEUS ESTUDOS – E QUE ESTE MATERIAL NÃO SUBSTITUI A NECESSIDADE DE TAIS FORMAS COMPLEMENTARES DE CONHECIMENTO E SIM ATUA COMO CONTEÚDO ESSENCIAL.

ASSIM COMO UM PROJETO DE APOSTILA “PILOTO” CONTÉM, ERROS DE FORMATAÇÃO, DE DIGITAÇÃO – BEM COMO PODE AINDA SER APROFUNDADO DE FORMA MAIOR, DO QUE SERIA NECESSÁRIO, POR ISSO CONTO COM A COLABORAÇÃO E EMPENHO DE VOCÊS, QUE SERÃO MEUS CRÍTICOS E AUXILIADORES, NA CORREÇÃO, DESTA APOSTILA. – ESTAMOS ABERTOS A DEBATES E SUGESTÕES DE TEMAS RELEVANTES A DISCIPLINA, A COMPLEMENTO DO CONTEÚDO. CONTO COM VOCÊS

SumárioINTRODUÇÃO...............................................................................................................................5

ENTENDENDO O QUE É SOFTWARE.............................................................................................6

Engenharia o que isso tem haver?...............................................................................................8

Crise do Software.....................................................................................................................8

Será que a crise acabou?......................................................................................................9

ERRO, DEFEITO e FALHA - Frutos da Engenharia de Software................................................10

ASPECTOS DA ENGENHARIA DE SISTEMAS COMPUTACIONAIS..................................................17

SISTEMAS E SUBSISTEMAS.................................................................................................18

ENGENHARIA DE SISTEMAS COMPUTACIONAIS.........................................................................21

PROJETO ARQUITETURAL...........................................................................................................27

Processo e métodos de Software...............................................................................................30

Ciclo de Vida Clássico – CASCATA...........................................................................................32

Prototipação...........................................................................................................................34

O Modelo Espiral....................................................................................................................35

Modelo Por Iterativo e Incremento........................................................................................36

Processo Unificado de Desenvolvimento de Software - RUP (Rational Unified Process).......38

Gestão de requisitos.......................................................................................................39

Uso de arquitetura baseada em componentes – importante.....................................39

Gestão e Controle de Mudanças do Software.............................................................39

Fase de Concepção........................................................................................................40

Fase de Construção........................................................................................................41

Fase de Transição...........................................................................................................41

Disciplinas de Engenharia Relacionada ao RUP........................................................44

Desenvolvimento Baseado em Componentes (DBC)..............................................................49

Desenvolvimento Orientado a Reuso.....................................................................................51

O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE................................................................53

ATIVIDADES DE DESENVOLVIMENTO DE SOFTWARE.................................................................53

MODELAGEM DE NEGÓCIO....................................................................................................53

PLANEJAMENTO.....................................................................................................................61

ENGENHARIA DE REQUISITOS................................................................................................61

Características Específicas da Engenharia de Requisitos....................................................63

ANÁLISE DO PROJETO DE SOFTWARE.....................................................................................69

IMPLEMENTAÇÃO..................................................................................................................70

TESTES DE SOFTWARE -..........................................................................................................70

GERÊNCIA DE CONFIGURAÇÃO e MUDANÇÃS.......................................................................72

OPERAÇÃO E MANUTENÇÃO DE SOFTWARE..........................................................................73

FERRAMENTAS CASE..............................................................................................................73

Escopo do Projeto -EAPe Kanban...............................................................................................75

Escopo....................................................................................................................................75

Estrutura Analítica de Projeto (EAP).......................................................................................75

ESTRUTURA ANALÍTICA DE PROJETO – ERROS COMUNS........................86

KANBAN.................................................................................................................................89

Metodologias Ágeis....................................................................................................................93

FDD FEATURE-DRIVEN DEVELOPMENT - Desenvolvimento Dirigido por Funcionalidade...........................................................................................................111

ANALISE DE PONTOS DE FUNÇÃO............................................................................................115

TESTE DE SOFTWARE................................................................................................................124

Particionamento em classes de equivalência[12]........................................................128

Análise do valor limite...................................................................................................129

Grafo de causa-efeito....................................................................................................129

Outras técnicas..............................................................................................................130

Técnicas não funcionais..........................................................................................131

SOA – Arquitetura Orientada a Serviços...................................................................................141

Origem de SOA...................................................................Erro! Indicador não definido.

O que SOA não é..............................................................Erro! Indicador não definido.

Definição de SOA.............................................................Erro! Indicador não definido.

Princípios Básicos de SOA............................................Erro! Indicador não definido.

INTRODUÇÃO.

Nos anos 40, quando se iniciou a evolução dos sistemas computadorizados, grande parte dos esforços, e conseqüentes custos, era concentrada no desenvolvimento do hardware, em razão, principalmente das limitações e dificuldades encontradas na época. À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, no início dos anos 50, para o desenvolvimento dos sistemas operacionais, onde surgiram então as primeiras realizações destes sistemas, assim como das chamadas linguagens de programação de alto nível, como FORTRAN e COBOL, e dos respectivos compiladores. A tendência da época foi de poupar cada vez mais o usuário de um computador de conhecer profundamente as questões relacionadas ao funcionamento interno da máquina, permitindo que este pudesse concentrar seus esforços na resolução dos problemas computacionais em lugar de preocupar-se com os problemas relacionados ao funcionamento do hardware.

Já no início dos anos 60, com o surgimento dos sistemas operacionais com características de multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável crescimento, para o que contribuíram também, de forma bastante significativa, as constantes quedas de preço do hardware.Uma conseqüência deste crescimento foi a necessidade, cada vez maior, de desenvolver grandes sistemas de software em substituição aos pequenos programas aplicativos utilizados até então. Desta necessidade, surgiu um problema nada trivial devido à falta de experiência e à não adequação dos métodos de desenvolvimento existentes para pequenos programas, o que foi caracterizado, ainda na década de 60 como a "crise do software", mas que, por outro lado, permitiu o nascimento do termo "Engenharia de Software".

Atualmente, apesar da constante queda dos preços dos equipamentos, o custo de desenvolvimento de software não obedece a esta mesma tendência. Pelo contrário, corresponde a uma percentagem cada vez maior no custo global de um sistema informatizado. A principal razão para isto é que a tecnologia de desenvolvimento de software implica, ainda, em grande carga de trabalho, os projetos de grandes sistemas de software envolvendo em regra geral um grande número de pessoas num prazo relativamente longo de desenvolvimento. O desenvolvimento destes sistemas é realizado, na maior parte das vezes, de forma "ad-hoc", conduzindo a freqüentes desrespeitos de cronogramas e acréscimos de custos de desenvolvimento.

A partir de 1961 o mundo presenciou o surgimento de novos computadores, mais modernos e com mais poder computacional. A partir dessa data o software ganhou notoriedade e, por conta disso, uma série de problemas relacionados ao “amadorismo” utilizado para sua construção ficou evidente. Esses fatores originaram a Crise do Software, em meados de 1968. O termo expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda existente, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimentode sistemas que funcionassem adequadamente ou pudessem ser validados.

Em 1968 aconteceu a NATO Software EngineeringConference, um evento criado com o objetivo de discutir alternativas para contornar a Crise do Software. Essa conferência marcou assim o início dessa nova área na computação. A Figura 1 mostra registros dessa conferência, que teve como um dos participantes o ilustre professor de Matemática, da Universidade Eindhoven de Tecnologia,EdsgerDijkstra. Em 1972 Dijkstra recebeu o Prêmio Turing (Turing Award), que é dado anualmente pela Association for ComputingMachinery (ACM), para uma pessoa selecionada por contribuições de natureza técnica feitas para a comunidade de computação. Seu discurso para recebimento do prêmio, intitulado “O Pobre Programador” (The HumbleProgrammer) tornou-se um clássico da Engenharia de Software. Um trecho desse discurso, traduzido para o português e que resume a crise, é exibido a seguir:

“A maior causa da crise do software é que as máquinas tornaram-se várias ordens de magnitude mais poderosas! Para esclarecer melhor: quando não havia máquinas, a programação não era um problema; quando tínhamos poucos computadores, a programação tornou-se um problema razoável, e agora, que nós temos computadores gigantes, a programação tornou-se um problema igualmente

grande.”.

ENTENDENDO O QUE É SOFTWARE.

Pode-se definir o software, numa forma clássica, como sendo: "um conjunto de Instruções que, quando executadas, produzem a função e o desempenho desejados, estruturas de dados que permitam que as informações relativas ao problema a resolver sejam manipuladas adequadamente e a documentação necessária para um melhor entendimento da sua operação e uso".

Entretanto, no contexto da Engenharia de Software, o software deve ser visto como um produto a ser "vendido". É importante dar esta ênfase, diferenciando os "programas" que são concebidos num contexto mais restrito, onde o usuário ou "cliente" é o próprio autor. No caso destes programas, a documentação associada é pequena ou (na maior parte das vezes) inexistente e a preocupação com a existência de erros de execução não é um fator maior, considerando que o principal usuário é o próprio autor do programa, este não terá dificuldades, em princípio, na detecção e correção de um eventual "bug". Além do aspecto da correção, outras boas características não são também objeto de preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.

Um produto de software (ou software, como vamos chamar ao longo do curso), por outro lado, é sistematicamente destinado ao uso por pessoas outras que os seus programadores. Os eventuais usuários podem, ainda, ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados deforma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade) de detectar e corrigir os eventuais erros de execução.

Dentro desta ótica, é importante, para melhor caracterizar o significado de software, é importante levantar algumas particularidades do software, quando comparadas a outrosprodutos, considerando que o software é um elemento lógico e não físico como a maioriados produtos:

O software é concebido e desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico;

O software não se desgasta, ou seja, ao contrário da maioria dos produtos, o software não se caracteriza por um aumento na possibilidade de falhas à medidaque o tempo passa (como acontece com a maioria dos produtos manufaturados);

A maioria dos produtos de software é concebida inteiramente sob medida,sem a utilização de componentes pré-existentes.

Em função destas características diferenciais, o processo de desenvolvimento desoftware pode desembocar um conjunto de problemas, os quais terão influência direta naqualidade do produto.

A nível industrial, algumas questões que caracterizaram as preocupações com oprocesso de desenvolvimento de software foram:

por que o software demora tanto para ser concluído? por que os custos de produção têm sido tão elevados? por que não é possível detectar todos os erros antes que o software seja entregue

ao cliente? por que é tão difícil medir o progresso durante o processo de desenvolvimento de

software?.

Estas são algumas das questões que a Engenharia de Software pode ajudar a resolver. Enquanto não respondemos definitivamente a estas questões, podemos levantaralguns dos problemas que as originam:

Raramente, durante o desenvolvimento de um software, é dedicado tempo paracoletar dados sobre o processo de desenvolvimento em sí; devido à poucaquantidade deste tipo de informação, as tentativas em estimar a duração/custo deprodução de um software têm

conduzido a resultados bastante insatisfatórios;além disso, a falta destas informações impede uma avaliação eficiente dastécnicas e metodologias empregadas no desenvolvimento;

A insatisfação do cliente com o sistema "concluído" ocorre freqüentemente,devido, principalmente, ao fato de que os projetos de desenvolvimento sãobaseados em informações vagas sobre as necessidades e desejos do cliente(problema de comunicação entre cliente e fornecedor);

A qualidade do software é quase sempre suspeita, problema resultante da poucaatenção que foi dada, historicamente, às técnicas de teste de software (atéporque o conceito de qualidade de software é algo relativamente recente);

O software existente é normalmente muito difícil de manter em operação, o quesignifica que o custo do software acaba sendo incrementado significativamentedevido às atividades relacionadas à manutenção; isto é um reflexo da poucaimportância dada à manutenibilidade no momento da concepção dos sistemas.

O software pode ser aplicado a qualquer situação em que um conjunto previamente especificado de passos procedimentais (um algoritmo) tiver sido definido. O conteúdo de informações e a previsibilidade são fatores importantes na determinação da natureza de um aplicativo.

Desenvolver categorias genéricas para as aplicações de softwares é uma tarefa muito difícil. Quanto mais complexo é o sistema, mais difícil é determinar de forma clara os vários componentes do software.

Pode-se dividir as aplicações em:

Software Básico – que é um conjunto de programas para dar apoio a outros programas. Tem como característica uma forte interação com o hardware, operações concorrentes, compartilhamento de recursos, uso por múltiplos usuários e múltiplas interfaces.

Software de Tempo Real – são programas que monitora, analisa e controla eventos do mundo real, devendo responder aos estímulos do mundo externo com restrições de tempo pré-determinadas.

Software Comercial – é a maior área de aplicação de softwares, são aplicações que gerenciam as operações comerciais de modo a facilitar o gerenciamento comercial do negócio da empresa, permitindo também a tomada de decisões.

Software Cientifico e de Engenharia – são caracterizados por algoritmos de processamento numérico, dependentes da coleta e processamento de dados para as mais variadas áreas do conhecimento.

Software Embutido – são desenvolvidos para executar atividades muito específicas e inseridos em produtos inteligentes tanto para atividades comerciais como para atividades domesticas.

Software de Computador Pessoal – são produtos desenvolvidos para o uso pessoal docomputador, tais como planilhas eletrônicas, processadores de textos, jogos, etc..

Software de Inteligência Artificial – faz uso de algoritmos não-numéricos para resolver problemas complexos que não apresentam facilidades computacionais numéricas oude análise direta.

É um conjunto integrado de métodos e ferramentas utilizadas para especificar, projetar, implementar e manter um sistema.

Segundo Ariadne Carvalho & Thelma Chiossi no livro Introdução à Computação, a Engenharia de Software é “Uma disciplina que reúne metodologias, métodos e ferramentas a deixa de ser operacional, visando resolve problemas inerentes ao processo de desenvolvimento e ao produto de software.” Pode-se definir como:

Um método é uma prescrição explícita de como chegar a uma atividade requerida por um modelo de ciclo de vida, visando otimizar a execução das atividades que foram especificadas.

As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos.

Os Métodos de Desenvolvimento de Sistema se diferenciam pela maneira como o problema deve ser visualizado e como a solução do problema deve ser modelada. São eles:

1.8.1 Método baseado na Decomposição de Funções:Abordagem estruturada caracterizada pela decomposição das funções. Os tipos demodelos que representam as funções são:

DFD (Diagrama de Fluxo de Dados) – se caracteriza pela decomposição hierárquicade processos.

MHT (Modelo Hierárquico de Tarefas) – se baseia na decomposição hierárquica detarefas.

1.8.2 Método baseado na Estrutura de Dados:Abordagem baseada na decomposição de um problema a partir dos dados. Exemplos detipos de modelos dessa classe:

MER (Modelagem Entidade-Relacionamento) Técnica de Warnier

1.8.3 Método de Análise baseado na Orientação a Objeto.Os tipos de modelos que representam essa classe são:

UML (UnifiedModellanguage) – notação de modelagem, independente de processos dedesenvolvimento.

Cenários

Engenharia o que isso tem haver?

Agora que já sabemos o que é um software, e qual seus conceitos e aplicações. O que isso tem haver com “engenharia”. Por que existe essa associação.

Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos anos, a produção de software confiável, correto e entregue dentro dos prazos e custos estipulados ainda é muito difícil. Dados do STANDISH GROUP, de 2004, usando como base mais de 8000 projetos mostrou que apenas 29% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas. Aproximadamente 18% dos projetos foram cancelados antes de estarem completos e 53% foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no início do projeto.

Dentre os projetos que não foram finalizados de acordo com os prazos e custos especificados, a média de atrasos foi de 222%, e a média de custo foi de 189% a mais do que o previsto. Considerando todos os projetos que foram entregues, além do prazo e com custo maior, na média, apenas 61% das funcionalidades originais foram incluídas. Mesmo os projetos cuja entrega é feita respeitando oslimites de prazo e custo, possuem qualidade suspeita, uma vez que provavelmente foram feitos com muita pressão sobre os desenvolvedores, o que pode quadruplicar o número de erros de software, segundo a mesma pesquisa.

Crise do SoftwareA noção da crise do software emergiu no final dos anos  1960. Uma das primeiras e mais conhecidas referências ao termo foi feita por  Edsger Dijkstra, na apresentação feita em 1972 na Association for Computina Machinery, Premio turing, intitulada "The Humble

Programmer" As causas da crise do software estão ligadas a complexidade do processo de software e a relativa imaturidade da engenharia de software como profissão. A crise se manifesta de varias formas:

Projetos estourando o orçamento;

Projetos estourando o prazo;

Software de baixa qualidade;

Software muitas vezes não atingiam os requisitos;

Projetos ingerenciáveis e o código difícil de manter.

Medidas pobres de eficiência e qualidade.

Insatisfação do usuário é frequente

Pouco entendimento dos requisitos

Problemas de Comunicação entre o usuário e o analista

A qualidade do software é frequentemente suspeita

Poucas medidas e critérios de qualidade

Software existente é muito difícil de manter

E tem que ser mantido até ser substituído

Será que a crise acabou?

Uma pergunta que devemos nos fazer atualmente é: será que a crise acabou? Para respondê-la é necessário fazer uma série de análises.

Dificuldades durante o desenvolvimento de software.

A figura acima apresenta uma ilustração muito conhecida na área de Engenharia de Software. Ela apresenta um grande problema, relacionado à falta de entendimento entre os grupos que fazem

parte de um projeto. O quadro inicial da figura apresenta uma ilustração tentando expressar como o cliente explicou o que necessitava para a equipe de desenvolvimento. O quadro seguinte exibe como o líder do projeto entendeu. Podemos notar que existe uma diferença significativa entre as figuras. Isso não deveria acontecer, ou deveria haver o mínimo possível de diferenças. Desse ponto adiante existe uma série de entendimentos diferentes, algumas vezes causados por falhas na comunicação, outros por comodidade, uma vez que certos entendimentos favorecem alguns grupos. O resultado de tudo isso é que o produto resultante tende a ser algo totalmente discrepante do que foi solicitado e ainda mais diferente do que realmente era necessitado. Observe que, o último quadro na figura apresenta o que o cliente realmente desejava, que é bastante diferente do que ele relatou que necessitava. Mais adiante, quando.

Falarmos de requisitos e na próxima disciplina relacionada à Engenharia de Software, que trata exclusivamente de requisitos, vamos entender isso com muito mais clareza. Embora problemas durante o desenvolvimento de software Aconteçam, e com certa freqüência, os processos, métodos e ferramentas existentes auxiliam muito o desenvolvimento. Uma vez aplicados por pessoas com os conhecimentos adequados, podemos ter certeza do sucesso em um projeto. Por conta disso é que existem diversos projetos grandes com sucesso absoluto. Para isso, é necessário aplicar, corretamente, a Engenharia de Software! Ou seja, respondendo à questão inicialmente formulada nesta seção: a crise acabou, mas apenas para aqueles que utilizam a Engenharia de Software como base para a construção de produtos de software.

ERRO, DEFEITO e FALHA - Frutos da Engenharia de Software.

A Crise de Software, teve um foco sob ótica da melhora continua do software, afim de fornecer qualidade ao produto entregue ao usuário (cliente), entretanto essa não é uma simples qualidade (veremos melhor no capítulo referente a qualidade). A qualidade oferece um maior fator maior que vai desde o processo de criação até o encerramento do projeto de software, e sendo assim claro que não se pode deixar de lado conceitos importantes que vieram a fazer parte da correção e melhora continua do software.

Os conceitos Apresentados diante do processo de engenharia, visaram criar um método sistemático de criação e aperfeiçoamento do software produzido. E para tanto um software tem que ser submetido a testes, (conceito importante que estudaremos em outro capítulo), - onde “todo” software tem defeitos que são disparados por erros que acarretam em falhas do software. E o proceso de encontrar essas irregularidades do software e corrigirem, traz qualidade ao produto final.

Falha é uma divergência entre o comportamento requerido para o sistema e o comportamento real.

Defeito é uma visão interna do sistema, observada pelo ponto de vista dos desenvolvedores, enquanto uma falha é vista a partir de um referencial externo ao sistema, ou seja, um problema que o usuário vê.

Erro (error) é uma Ação geralmente Humana. diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução do programa constitui um erro; - é uma manifestação concreta de um defeito num artefato de software

Essências Complexidade dos sistemas Dificuldade de formalização

Acidentes Má qualidade dos métodos, linguagens, ferramentas, processos,

e modelos de ciclo de vida Falta de qualificação técnica

O que é Engenharia de Software?

Já comentamos sobre as origens da Engenharia de Software mas até agora não fizemos uma definição precisa do que seja exatamente isso. Nesta seção faremos isso. Mas antes da definição, vamos fazer uma analogia muito interessante: você sabe como funciona o processo de fabricação de um carro?

A figura acima apresenta os passos para desenvolvimento de um carro. Sua construção inicia a partir do momento que tem-se a idéia de iniciar essa tarefa. A partir disso, é iniciado o levantamento das características, necessidades e desejos relacionados ao produto. Tudo isso irá compor a especificação de requisitos do carro. São exemplos desses requisitos porta-malas com capacidade de 500l, motor 1.6, câmbio automático, etc. Com a identificação dos requisitos é possível iniciar a montagem de um protótipo, para se avaliar diversos pontos que necessitam de esclarecimento antes da construção efetiva do carro. Essa prototipação pode ser feita via ferramentas de simulação, como as famosas ferramentas CAD existentes ou a partir da criação de versões em miniatura do produto (Projeto e Simulações).

O modelo criado, seja qual for, normalmente é utilizado para responder diversas questões, para em seguida dar-se início ao desenvolvimento das partes que irão compor o automóvel. Essas partes são chamadas de unidades, como por exemplo, a barra de direção, a porta, o motor, as rodas, etc (Unidades). Cada componente do carro possui especificações e precisa ser verificado com relação a isso. Por exemplo, a barra de direção deve ser retilínea, com 1,80m de extensão e deve suportar até 500 kg em seu ponto central. A verificação consiste em analisar se isso realmente foi atendimento pelo processo de fabricação do componente. Se o item não passar nessa verificação, não podemos continuar com a construção do produto, pois certamente haverá mais problemas quando utilizarmos o componente com problemas.

Caso os componentes sejam aprovados na verificação, podemos iniciar a combinação desses componentes, integrando-os, para em seguida verificar se eles continuam atendendo às especificações (Integração). Como exemplo, imagine que a barra de direção do carro foi integrada às rodas. Ela deveria sustentar os 500 kg em seu ponto central. Embora isso já tenha sido verificado após a fabricação do item, uma nova verificação é necessária após sua integração com demais elementos, uma vez que agora o ponto de falha pode não ser a barra de direção em si, mas os pontos de conexão entre a barra e as rodas. Caso os componentes agrupados continuem funcionando conforme o esperado, poderemos continuar o agrupamento até que tenhamos o produto completo. Uma vez tendo terminado o produto, teremos que submetê-lo a uma série de avaliações para verificar o seu nível de qualidade. No caso de um carro são necessários testes de desempenho, consumo, segurança, etc. Após essa verificação poderemos afirmar que o produto foi concluído com sucesso.

Mas por que conversar sobre carros se o objetivo desta seção é apresentar o conceito de Engenharia de Software? Justamente por que o processo de fabricação de um carro tem tudo haver com a Engenharia de Software. De modo geral, podemos dizer que Engenharia de Software poderia ser resumida à utilização de princípios de engenharia para o desenvolvimento de software, ou seja, levantar os requisitos associados, construir modelos para representar a solução a ser desenvolvida, implementar as diversas unidades que irão compor o produto, verificando se tais unidades atendem aos requisitos identificados, realizar a integração entre as unidades, também verificando seu funcionamento, até que tenhamos o produto por completo, que deve passar por uma série de verificações (teste funcionais, desempenho e estresse, usabilidade, etc.) para que possamos concluir o desenvolvimento. Em resumo e utilizando termos mais formais, podemos dizer que a Engenharia de Software é a aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento de software.Na literatura, podem-se encontrar mais definições para Engenharia de Software, dentre eles destacamos:

"O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável eque funcione eficientemente em máquinas reais.", NAUR PETER, 1969.

“A aplicação prática do conhecimento científico para o projeto e a construção de programas computacionais e a documentação necessária à sua operação e manutenção.”, BARRY BOEHM, 1976.

“Conjunto de métodos, técnicas e ferramentas necessárias à produção de software de qualidade para todas as etapas do ciclo de vida do produto.”, SACHA KRAKOWIAK, 1985.

Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendo a aplicação da ciência e da matemática através das quais os equipamentos computacionais são colocados à disposição do homem por meio de programas, procedimentos e documentação associada. De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessária para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial, apesar dos esforços desenvolvidos nesta direção. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos decontabilidade tenham sido corretamente efetuados. Um grande problema facilmente percebido hoje é justamente o fato de boa parte das organizações não encararem o desenvolvimento de software como um projeto de verdade,aplicando as técnicas, métodos e ferramentas necessárias. Por conta disso, boa parte desses projetos fracassa. Na próxima seção vamos discutir alguns dos aspectos que fazem isso acontecer.

Problemas no desenvolvimento de software.

Embora a Engenharia de Software seja uma área consolidada e existam várias empresas que a utilizam com muito sucesso em projetos de desenvolvimento de software, isso não é verdade namaioria dos casos. A crise continua em muitos locais, não mais por ausência de métodos, técnicas e ferramentas, mas pela falta do seu uso!

Tripé da Engenharia de Software.

As figuras acima apresenta o tripé no qual a Engenharia de Software é baseada: processos, pessoas e tecnologia. Não adianta termos os melhores profissionais do mundo se não possuímos boas tecnologias para uso ou se não possuímos um processo que guie o desenvolvimento de software. Da mesma forma, não adianta possuir as tecnologias mais avançadas se as pessoas não conseguem utilizá-las. Além disso, mesmo que pareça inconcebível para alguns, de nada adianta termos a melhor tecnologia e as melhores pessoas se não existe um processo que guie as atividades dessas pessoas utilizando tais tecnologias. Existem grande chances de termos problemas relacionados à falta de controle ou desorganização, caso não tenhamos um processo que discipline as tarefas das pessoas.

Componentes básicos de um sistema.

Um conceito que muitas vezes causa confusão é o de sistema, que muito se confunde ao conceito de software. Pode-se definir o software, numa forma clássica, como sendo: "um conjunto de instruções que, quando executadas, produzem a função e o desempenho desejados, estruturas de dados que permitam que as informações relativas ao problema a resolver sejam manipuladas adequadamente e a documentação necessária para um melhor entendimento da sua operação e uso".

Entretanto, no contexto da Engenharia de Software, o software deve ser visto como um produto a ser "vendido". É importante dar esta ênfase, diferenciando os "programas" que são concebidos num contexto mais restrito, onde o usuário ou "cliente" é o próprio autor. No caso destes programas, a documentação associada é pequena ou (na maior parte das vezes) inexistente e a preocupação com a existência de erros de execução não é um fator maior, considerando que o principal usuário é o próprio autor do programa, este não terá dificuldades, em princípio, na detecção e correção de um eventual "bug". Além do aspecto da correção, outras boas características não são também objeto de preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização. Um produto de software (ou software, como vamos chamar ao longo da disciplina), por outro lado, é sistematicamente destinado ao uso por pessoas diferentes dos seus programadores. Os eventuais usuários podem ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade) de detectar e corrigir os eventuais erros de execução.

Resumindo, um programa desenvolvido para resolver um dado problema e um produto de software destinado à resolução do mesmo problema são duas coisas totalmente diferentes. É óbvio que o esforço e o conseqüente custo associado ao desenvolvimento de um produto serão muito superiores.

Um sistema é bem mais que o software. Na verdade, o sistema é o conjunto de elementos, coordenados entre si e que funcionam como uma estrutura organizada. Embora o software seja uma parte importante de um sistema, ele não é a única. Se não existir o hardware para execução do software, de nada servirá. Da mesma forma, é necessário existir bases de dados, uma vez que praticamente todos os sistemas com algum tipo de utilidade devem armazenar dados. Atualmente, com o advento da Internet, dificilmente um sistema seja útil se não tiver certos mecanismos de comunicação associados. Tudo isso junto, forma o sistema. Por diversas vezes tendemos a utilizar software e sistema como algo similar, mas é importante ressaltarmos suas diferenças, de forma adeixar claro o que representa cada um desses termos.

Os produtos de software desenvolvidos utilizando a Engenharia de Software sempre estão envolvidos em algum processo de negócio, seja ele simples ou complexo. Assim, é fundamental entender esse processo de negócio para que seja possível informatizá-lo. Embora isso seja óbvio, em muitas ocasiões isso é simplesmente ignorado. O desenvolvimento de software muitas vezes acontece sem sabermos o que deve ser feito. Logicamente isso tem grande chance de resultar em fracasso. É importante ressaltar que isso é inconcebível em qualquer área, mas parece que muitos acreditam que quando tratamos de software algo é diferente. Imagine adentrar em uma construtora de respeito e perguntar: quanto custa construir uma casa? Se a empresa for séria, certamente não vai dar nenhuma estimativa de custo nem de prazo, uma vez que nada foi dito sobre o projeto. Uma casa pode ser feita gastando-se R$1.000,00 ou R$1.000.000,00.

Tudo depende dos requisitos relacionados à casa. Com o software é exatamente o mesmo. Se não soubermos quais são os requisitos é simplesmente impossível fazer qualquer estimativa de tempo e custo. Qualquer ação nesse sentido é irresponsabilidade ou extrema ignorância!

Em resumo, os sistemas informatizados normalmente não fazem o que deveriam fazer por que os problemas têm que ser minuciosamente definidos para que possam ser resolvidos. Se não entendermos bem sobre o domínio do problema, certamente não desenvolveremos uma boa solução. É fundamental levantarmos os requisitos de um software antes de procedermos com sua construção. O custo para levantamento desses requisitos é um fator a ser considerado, mas não fazer tal levantamento provavelmente seja bem mais caro! Além disso, é importante que os usuários do produto participem desse levantamento, caso contrário, os dados obtidos no levantamento não deverão expressar aquilo que realmente é importante para o processo de negócio.

Software: Mitos e Realidade

Muitas causas de problemas relacionados ao desenvolvimento de software são provenientes de mitos que surgiram durante a história inicial dessa atividade, conforme descrito por ROGER PRESSMAN. Diferente dos antigos mitos, que são interessantes histórias e freqüentemente fornecem lições humanas merecedoras de atenção, os mitos de software propagam desinformação e confusão. Esses mitos tinham certos atributos que os tornavam parecidos com afirmações razoáveis, tendo aspecto intuitivo e, muitas das vezes, eram divulgados por profissionais experientes e que deveriam entender do assunto. Atualmente, boa parte dos profissionais reconhece os mitos por aquilo que são: afirmações enganosas e que já causaram problemas. No entanto, cabe a todos nós conhecê-los, para tentar evitá-los em locais que isso ainda esteja acontecendo.

Mitos de Gerenciamento

Mito 1. "Se a equipe dispõe de um manual repleto de padrões e procedimentos de desenvolvimento de software, então a equipe será capaz de conduzir bem o desenvolvimento." Realidade 1. Isso não é o suficiente! É preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual. É necessário que o manual reflita a moderna prática de desenvolvimento de software e que este seja exaustivo com relação a todos os problemas de desenvolvimento que poderão aparecer no percurso.

Mito 2. "A equipe tem ferramentas de desenvolvimento de software de última geração, uma vez que eles dispõem de computadores modernos."Realidade 2. Ter à sua disposição o último modelo de computador pode ser bastante confortável para o desenvolvedor do software, mas não oferece nenhuma garantia quanto à qualidade do produto desenvolvido. Mais importante do que ter um hardware de última geração é ter ferramentas para a automação do desenvolvimento de software e sabê-las utilizar adequadamente.

Mito 3. "Se o desenvolvimento do software estiver atrasado, aumentando a equipe poderemos reduzir o tempo de desenvolvimento."Realidade 3. Acrescentar pessoas em um projeto atrasado provavelmente vai atrasá-lo ainda mais. De fato, a introdução de novos profissionais numa equipe em fase de condução de um projeto vai requerer uma etapa de treinamento dos novos elementos da equipe; para isto, serão utilizados elementos que estãoenvolvidos diretamente no desenvolvimento, o que vai, conseqüentemente, implicar em maiores atrasos no cronograma.

Mitos do Cliente

Mito 4. "Uma descrição breve e geral dos requisitos do software é o suficiente para iniciar o seu projeto. Maiores detalhes podem ser definidos posteriormente." Realidade 4. Este é um dos problemas que podem conduzir um projeto ao fracasso, o cliente deve procurar definir o mais precisamente possível todos os requisitos importantes para o software: funções, desempenho, interfaces, restrições de projeto e critérios de validação são alguns dos pontos determinantes do sucesso de um projeto. O “deixar pra depois” pode simplesmente não acontecer, a não ser em casos previstos pelos processos ágeis em que os clientes estão sempre presente e dentro da organização desenvolvedora. No entanto, é sabido que essa prática é uma das mais difíceis de serem seguidas...

Mito 5. "Os requisitos de projeto mudam continuamente durante o seu desenvolvimento, mas isto não representa um problema, uma vez que o software é flexível e poderá suportar facilmente as alterações."Realidade 5. É verdade que o software é flexível (pelo menos mais flexível do que a maioria dos produtos manufaturados). Entretanto, não existe software, por mais flexível que suporte alterações de requisitos significativas sem um adicional em relação ao custo de desenvolvimento. O fator de multiplicação nos custos de desenvolvimento do software devido a alterações nos requisitoscresce em função do estágio de evolução do projeto, como mostra a figura abaixo.

Mitos do Profissional

Mito 6. "Após a finalização do programa e a sua implantação, o trabalho está terminado."Realidade 6. O que ocorre na realidade é completamente diferente disto. Segundo dados obtidos a partir de experiências anteriores, ilustrados no livro de Roger Pressman, 50 a 70% do esforço de desenvolvimento de um software é empregado após a sua entrega ao cliente (manutenção).

Mito 7. "Enquanto o programa não entrar em funcionamento, é impossível avaliar a sua qualidade."Realidade 7. Na realidade, a preocupação com a garantia do da qualidade do software deve fazer parte de todas as etapas do desenvolvimento. O teste, por exemplo, pode iniciar antes do produto atingir um estado funcional, a partir do planejamento dos casos de teste.

Mito 8. "O produto a ser entregue no final do projeto é o programa funcionando." Realidade 8. O programa em funcionamento é um das componentes do software. Além do software em si, um bom projeto deve ser caracterizado pela produção de um conjunto importante de documentos. Um produto de software sem um manual de operação pode ser tão ruim quanto um software que não funciona!

ENGENHARIA DE SISTEMAS COMPUTACIONAIS

Para entender melhor a Engenharia de Software, precisamos compreende eu seu sentido mais amplo pois é importante reconhecer o fato óbvio de que o software não consiste de um elemento autônomo, ou seja ele é apenas uma parte Muito “ importante” de um composto tecnológico. Sendo assim para que suas funções possam ser realizadas, ele deverá ser integrado a outros componentes, especialmente elementos de hardware, como processador, circuitos de memória e outros. Um componente de um sistema computacional são as pessoas – que contam como um processo importante de manipulação.

Técnica de solução de problemas

1. A análise do problema para determinar a sua natureza;

2. Síntese da solução com base em nossa análise.

A Capacidade de Dividir, Entender…E através disso criar

um processo solucionar

….

Por esta razão, o software deve, antes de tudo, ser visto como um elemento de um sistema mais amplo, ao qual denominaremos um Sistema Computacional. No contexto deste curso, um Sistema Computacional deverá ser entendido como o resultado da união de diferentes componentes, entre os quais se enquadram o software, o hardware e elementos de outras naturezas como por exemplo o elemento humano, representado pelo usuário do sistema.

A Engenharia de Sistemas Computacionais corresponde ao conjunto de atividades que deverão ser realizadas para definir o sistema computacional como um todo. Dentre as atividades a serem conduzidas, pode-se citar a especificação, o projeto, a implementação, a validação, a instalação e a manutenção. Cada uma das disciplinas componentes da Engenharia de Sistemas está relacionada a uma tentativa de estabelecimento de uma ordem no desenvolvimento de sistemas computacionais.

Nestes sistemas, o software vem, há muitos anos, substituindo o hardware como o elemento de mais difícil concepção, com menor probabilidade de sucesso em termos de prazos e custo e de mais difícil administração. Além disso, a demanda por software cresce a cada dia, até como conseqüência do grande desenvolvimento do hardware dos sistemas computacionais.

O objetivo deste capítulo é discutir as principais definições e aspectos relacionados com a Engenharia de Sistemas Computacionais, procurando definir o papel da Engenharia de Software neste contexto.

ASPECTOS DA ENGENHARIA DE SISTEMAS COMPUTACIONAIS

Sistema ComputacionalAntes de discutir os principais pontos relativos à Engenharia de Sistemas Computacionais, é imprescindível estabelecer uma definição do que é um sistema computacional. Isto é particularmente importante, uma vez que a palavra "sistema" é uma das mais empregadas em qualquer área da atividade humana (sistema político, sistema educacional, sistema de avaliação, etc...).

Dentro do contexto do que será discutido aqui, pode-se definir um Sistema Computacional como sendo um conjunto de elementos interrelacionados que operamjuntos para o alcance de algum objetivo.

Um sistema de processamento de texto, por exemplo, integra funções de entrada e edição de texto com funções de produção de documentos (software e hardware) manipuladas por um usuário (um elemento humano) para transformar um dado texto (uma entrada) num documento (a saída).

Pode-se listar os elementos de um sistema computacional como sendo: Software, no caso, programas de computador, estruturas de dados, e documentação

associada que serve a efetivar os métodos, procedimentos ou processo de controle lógico; Hardware, que são os dispositivos eletrônicos que definem as capacidades de

umcomputador e dispositivos eletromecânicos que oferecem funcionalidades ao ambiente externo;

Pessoal, usuários/operadores do hardware e do software; Bancos de dados, uma coleção de informações organizada sistematicamente, acessada

através do software; Documentação, manuais, formulários e outros documentos que podem auxiliar

noconhecimento do uso e operação do sistema; Procedimentos, as regras que especificam o uso específico de cada elemento dosistema

computacional.

As combinações destes elementos podem ser as mais diversas para permitir a transformação das informações. Um robô, por exemplo, é um sistema computacional que transforma um arquivo contendo instruções específicas num conjunto de movimentos e ações.

Composição dos Sistemas Computacionais e as Propriedades Emergentes

É importante reconhecer o papel das atividades relacionadas à Engenharia de Sistemas Computacionais como determinantes para as tarefas que se desenvolveram com base em seus

resultados. Embora tenhamos dito que um Sistema Computacional é composto de diferentes elementos, não se deve negligenciar o fato de que a integração destes diferentes elementos é uma tarefa longe de ser trivial. O fato de se ter elementos concebidos com exemplar nível de qualidade não garante que a reunião destes vá originar um sistema excepcional.

Em tais sistemas, as dependências de um elemento do sistema com relação a outros podem se dar em muitos níveis. Por exemplo, o software só pode automatizar a solução de um problema se o processador estiver funcionando de forma adequada. Por outro lado, uma máquina de comando numérico só irá realizar corretamente o seu trabalho se o software de pilotagem tiver sido adequadamente concebido.

Entender o papel da Engenharia de Sistemas Computacionais é constatar que um sistema é algo mais do que a simples união de seus diversos elementos. Num sistema de grande porte, existe um conjunto de propriedades que são verificados somente a partir do momento em que os diferentes elementos do mesmo são integrados. São as chamadas Propriedades Emergentes. Alguns exemplos destas propriedades são:

o peso global do sistema, é um exemplo de propriedade que pode ser previamente determinada a partir de propriedades individuais dos componentes;

a confiabilidade do sistema, que está fortemente dependente da confiabilidade de cada elemento;

a facilidade de uso, que vai estar relacionada aos diferentes elementos do sistema como o hardware o software, mas também aos usuários do mesmo.

SISTEMAS E SUBSISTEMAS

Pode-se observar ainda que elementos de um determinado sistema podem operar de forma autônoma, constituindo-se num sistema independente. No entanto, ao serem incorporados ao sistema, suas funcionalidades vão estar dependendo de outros elementos deste. Uma câmera de vídeo, por exemplo, pode ser vista como um sistema independente.

Por outro lado, quando ela está embutida num sistema de segurança automatizado, a maior parte de seus ajustes (enquadramento da imagem, foco, ativação e desativação) serão completamente dependentes de outros componentes do sistema de segurança.

Isto significa que, nos sistemas computacionais é comum um dado sistema compor um outro sistema computacional de nível hierárquico superior. Diz-se então que o sistema considerado é um macro elemento ou subsistema do sistema de nível superior.

Um exemplo típico desta situação é aquela dos equipamentos de manufatura, como por exemplo os robôs, máquinas de comando numérico e controladores lógicos programáveis, que são sistemas computacionais e ao mesmo tempo subsistemas de um sistema computacional de nível hierárquico superior: a célula de manufatura. A célula de manufatura pode ser definida como um sistema computacional, uma vez que esta é caracterizada por todos os elementos definidos acima. Se for feita uma análiseconsiderando outros níveis hierárquicos, é possível visualizar a célula como um macroelemento de outro sistema computacional: o sistema de manufatura. A figura abaixo ilustra esta relação entre os diferentes sistemas computacionais descritos.

HIERARQUIA E AMBIENTE DE UM SISTEMAReconhecido o fato de que um sistema pode ser obtido a partir de outros sistemas, como o exemplo ilustrado à figura 3.1, surge então o conceito de hierarquia de sistemas, que vai permitir utilizar a definição de subsistema, introduzida anteriormente.

Por esta razão, o ambiente de um sistema deve ser cuidadosamente estudado nesta etapa de concepção. A importância do entendimento completo do ambiente de um sistema é justificada pelos fatores seguintes:

Em grande parte das vezes, o sistema é concebido para provocar alterações no ambiente; sendo assim, a compreensão dos principais aspectos de funcionamento do ambiente serão fundamentais para especificar de que forma o sistema deve agir para provocar as alterações de forma precisa; exemplos de tais sistemas são um sistema de iluminação, um sistema de aquecimento (ou refrigeração) de ambiente;

Mesmo quando a função do sistema não está relacionada a alterações de seu ambiente, é importante se conhecer o quanto o ambiente pode influenciar no funcionamento do sistema; por exemplo, numa rede de computadores a ser instalada numa unidade fabricação de uma empresa, o fato de naquela unidade existir um grande número de motores e inversores operando pode ser determinante para decidir que tipos de protocolos e meios de transmissão deverão ser empregados, devido à alta incidência de fontes de interferência que podem causar erros de comunicação.

Um outro aspecto a ser considerado é o conjunto de requisitos originado no próprio ambiente. Os exemplos deste aspecto são os mais diversos, mas pode-se citar normas de qualidade ou segurança de produtos, requisitos de interface numa dada plataforma, requisitos de vedação, para um sistema computacional que irá operar num ambiente úmido ou sujeito a poeira.

Por todas estas razões, é fundamental que um sistema seja visto sempre como um componente de um sistema maior, o estudo aprofundado das características mais importantes relativas ao ambiente e dos requisitos impostos por este sendo uma tarefa essencial.

A AQUISIÇÃO DE SISTEMAS

No desenvolvimento de sistemas, principalmente daqueles mais complexos, é comum que determinados componentes sejam adquiridos em lugar de serem completamente desenvolvidos pela equipe ou empresa envolvida no projeto. Em alguns casos, o próprio sistema pode ser completamente adquirido num fabricante específico e, em outros, partes do sistema serão obtidas de um mesmo ou de diferentes fornecedores. Por outro lado, pode haver sistemas onde todos os componentes podem ser completamente desenvolvidos pela equipe.

O processo de decisão sobre a compra ou o desenvolvimento de um sistema ou de parte dele é uma tarefa que requer um esforço e um tempo considerável, principalmente se o grau de complexidade do mesmo for elevado. Uma decisão baseada numa análise superficial pode conduzir ao fracasso do projeto.

Normalmente, para servir de referência à decisão, uma especificação do sistema e um projeto arquitetural devem ser conduzidos. Os resultados obtidos nesta tarefa são importantes pelas seguintes razões:

Para que o processo de aquisição seja encaminhado com sucesso, é necessária a existência de uma especificação e de uma visão arquitetural do sistema

custo de aquisição de um sistema é, na maioria dos casos, menor que do desenvolvimento deste; por esta razão, o projeto arquitetural é importante como forma de decidir quais subsistemas serão adquiridos e quais serão desenvolvidos.

A SUBCONTRATAÇÃO

As situações em que uma empresa desenvolve completamente todos os componentes de um sistema são extremamente raras. Geralmente, a organização "usuária" vai encomendar o sistema a uma organização "fornecedora". A organização fornecedora, eventualmente, vai "terceirizar" o desenvolvimento do sistema, contratando outras empresas fornecedoras dos diferentes subsistemas. A figura abaixo ilustra este processo.Um aspecto interessante deste processo é a otimização, no que diz respeito aos contatos, entre a organização do usuário e as organizações desenvolvedoras. Na realidade, o único contato mantido pela organização usuária é com a principal contratante. As subcontratantes vão projetar e construir os subsistemas cujos requisitos foram especificados pela principal contratante que exerce o papel de aglutinadora de todas as empresas envolvidas no desenvolvimento.

A IMPORTÂNCIA DO SOFTWARE

No desenvolvimento de sistemas computacionais, é comum a utilização de componentes customizados (construídos sob medida) e componentes de "prateleira". Por esta razão, o componente de software assume um papel bastante importante no desenvolvimento do sistema, isto porque é este que pode assumir a função de elo de ligação entre os diferentes componentes, permitindo a adequação do funcionamento dos diferentes componentes de hardware (principalmente aqueles de "prateleira") aos requisitos do sistema.

Um exemplo deste fato está num dos sistemas computacionais mais utilizados nos dias atuais — os microcomputadores da linha PC. O PC da IBM, quando foiconcebido, foi totalmente construído a partir de componentes de hardware disponíveis no mercado. Esta decisão foi tomada devido à urgência em ocupar o espaço do mercado no setor de computadores pessoais. Entretanto, a fórmula mágica da IBM para fazer com que todos estes elementos funcionassem harmonicamente foi buscada no software, no caso o ROMBIOS, que continha todas as rotinas de programação e acesso aos dispositivos de hardware que compunham a arquitetura do PC.

Só a partir do momento em que as outras empresas conseguiram copiar o conteúdo do ROM-BIOS é que surgiram os conhecidos "clones" do PC que difundiram a tecnologia pelo mundo todo.

ENGENHARIA DE SISTEMAS COMPUTACIONAIS

O papel essencial da Engenharia de Sistemas Computacionais é a resolução deproblemas, onde a atividade de base é a identificação, análise e atribuição aos elementos constituintes do sistema das funções desejadas para o sistema. A palavra que melhor define a Engenharia de Sistemas é a interdisciplinaridade, uma vez que, na maior parte dos sistemas a serem concebidos, devem entrar em jogo diferentes competências. Além dos Engenheiros de Hardware e de Software, devem intervir nesta etapa especialistas como Engenheiros Eletricistas, Engenheiros Hidráulicos, Engenheiros de Telecomunicações, Químicos, Físicos, Psicólogos, Médicos, etc. O ponto de partida do trabalho do Engenheiro de Sistemas são os requisitos e restrições formuladas pelo cliente, que vão permitir um primeiro delineamento das funções a serem executadas pelo sistema, de requisitos de desempenho, das interfaces a seremoferecidas, das restrições de projeto e das estruturas de informação que serão processadas por cada um dos elementos constituintes do sistema (software, hardware, pessoal, etc...).

Neste trabalho, é importante que se estabeleça da forma mais precisa possível as funções a serem realizadas. Por exemplo, no caso do sistema de controle de um robô, não é suficiente dizer que "ele deve reagir com rapidez se a bandeja de ferramentas estiver vazia"... na realidade, é importante especificar cuidadosamente os diferentes aspectos deste requisito:

O que vai indicar a bandeja vazia para o robô; Os limites de tempo relacionados com a reação; De que forma deve ser esta reação.

Uma vez identificados e analizadas todas as funções, requisitos e restrições, passase à fase de alocação, onde o objetivo é atribuir, aos diferentes elementos que constituem o sistema, as funções analizadas anteriormente.

Nesta tarefa, é comum estabelecer alternativas de alocação para posterior definição. Consideremos, por exemplo, um sistema de tratamento gráfico, onde uma das funçõesprincipais é a transformação tridimensional de imagens. Deste exemplo, é possível imaginar algumas opções de soluções existentes:

Todas as transformações serão resolvidas por software; As transformações mais simples (redimensionamento e translação) serão realizadas em

hardware e as mais complexas (rotação, perspectivas, etc...) em software; Todas as transformações serão realizadas por um processador geométrico implementado

em hardware.

A escolha da solução deve ser baseada num conjunto de critérios, onde entram fatores como custo, realizabilidade, desempenho, padronização de interfaces, portabilidade, etc.

Nas seções a seguir, serão descritas atividades encaminhadas no contexto da Engenharia de Sistemas Computacionais.

DEFINIÇÃO DOS REQUISITOS

O objetivo das tarefas a serem desenvolvidas nesta etapa é identificar os requisitos do Sistema Computacional a ser concebido. Considerando que grande parte dos sistemas computacionais são construídos sob demanda, a forma usual de encaminhar esta etapa é caracterizada por um conjunto de reuniões estabelecidas entre a equipe de desenvolvimento do sistema e os clientes ou usuários. Nesta etapa, pode-se considerar basicamente três categorias de requisitos:

Os requisitos básicos, que estão associados às funções a serem desempenhadas pelo sistema; neste momento do desenvolvimento, estesrequisitos são definidos num nível de abstração relativamente elevado,uma vez que o detalhamento será necessariamente realizado numa etapaposterior;

As propriedades do sistema, que estão relacionadas às propriedadesemergentes do sistema; desempenho, segurança, disponibilidade, sãoalguns exemplos desta categoria de requisitos;

As características indesejáveis, que são propriedades que o sistemanão deve possuir; é tão importante, muitas vezes, definir quecaracterísticas não devem ser encontradas num dado sistema, quantodefinir aquelas que são consideradas essenciais; num sistema decomunicação de dados, por exemplo, algumas característicasindesejáveis são os erros, as perdas e as duplicações de mensagens.

De forma geral, é importante que sejam estabelecidos, da forma mais completapossível, os objetivos e as funções a serem providas pelo sistema. Neste nível, deve-seenfatizar o papel do sistema computacional no ambiente em que ele será instalado,podendo-se deixar para etapas mais à frente, a especificação dos aspectos funcionais domesmo.Observemos a distinção através de um exemplo, onde são apresentadas duasversões de especificação dos requisitos de um sistema de segurança para um edifíciocomercial:

a. O objetivo do sistema é prover um sistema de proteção contra incêndio eintrusão que vai ativar um alarme interno e externo em caso de princípio deincêndio ou invasão por pessoas não autorizadas;

b. O objetivo do sistema é assegurar a continuidade do funcionamento normal conduzido no edifício, mesmo na ocorrência de eventos como o princípio de incêndio ou intrusão.

Neste nível do desenvolvimento do sistema, a segunda versão apresentada é a maisadequada, uma vez que ela é, por um lado, mais abrangente e, por outro, limitante emalguns aspectos. A forma como está estabelecido o objetivo do sistema está maiscompatível com as necessidades do ambiente, e dá uma maior abertura à adoção detécnicas mais evoluídas de prevenção de incêndio e intrusão. Por outro lado, o fato deestabelecer como requisitos a garantia de continuidade das atividades realizadas noescritório, elimina algumas soluções como o uso de alarme interno ou irrigadores contraincêndio.

O PROJETO DO SISTEMA

Os principais passos envolvidos no projeto de um sistema computacional estãoesquematizados na figura Abaixo e serão descritos nos parágrafos que seguem.Particionamento dos Requisitos. Uma vez estabelecidos os requisitos do sistema naetapa anterior, o objetivo deste primeiro passo de projeto é particioná-los segundo algumcritério lógico. A escolha do critério de particionamento é importante pois deste vai dependeras diferentes categorias de requisitos que serão criadas.

Identificação dos Subsistemas. Este passo busca definir os diferentes subsistemas que irão compor o sistema computacional. O particionamento realizado no passo anterior será determinante para a obtenção dos subsistemas, uma vez que, dependendo do critério utilizado, cada grupo de requisitos poderá definir um subsistema. Por outro lado, outros aspectos podem ser considerados para a definição dos subsistemas, particularmente aqueles relacionados a questões do ambiente onde o sistema será instalado.

Alocação dos Requisitos. O próximo passo a ser conduzido é a alocação dosrequisitos aos subsistemas estabelecidos no passo anterior. Pode parecer estranho considerar tal etapa, quando se utiliza o resultado obtido no Particionamento dos Requisitos para realizar a Identificação dos Subsistemas, mas, na verdade, isto não ocorre de forma tão imediata.

Por exemplo, no caso da adoção de sistemas de prateleira para implementar algum subsistema, as limitações do sistema adotado podem impor a realocação de requisitos.

Especificação das Funcionalidades. Neste passo, serão definidas as funções que serão implementadas por cada subsistema. No caso de um subsistema de software, esta atividade pode ser encaminhada como parte da análise de requisitos do mesmo.

Definição das Interfaces dos Subsistemas. Este é um passo de extrema importância na condução do projeto do sistema. A definição, de forma precisa das interfaces entre os subsistemas é fundamental para as etapas posteriores de integração dos diferentes componentes. Não se deve negligenciar o fato de que muitos subsistemas podem ser adquiridos em lugar de serem desenvolvidos e mesmo aqueles que são especialmente construídos no contexto de um projeto, usualmente são desenvolvidos por diferentes equipes ou por diferentes empresas. Qualquer má definição neste item pode comprometer o sucesso do projeto ou implicar num aumento de custo ou de prazo de desenvolvimento.

As linhas contendo setas nas duas direções entre cada par de passos sugere a necessidade de revisões e realimentações em cada passo. Na maioria dos projetos, onúmero de soluções possíveis é bastante grande, podendo-se chegar a diferentes visões de como as funções são alocadas a subsistemas de hardware, de software ou aos elementos humanos que vão interagir com o sistema.

A escolha da solução a ser encaminhada vai ser feita em função de critérios técnicos, mas também terá influência de critérios políticos e organizacionais da instituição.

No caso de projetos desenvolvidos para instituições militares, por exemplo, fornecedores nacionais serão escolhidos em lugar de fornecedores estrangeiros, mesmo que em termos técnicos, a solução oferecida não seja a ideal.

DESENVOLVIMENTO DOS SUBSISTEMAS

Esta etapa agrupa as atividades relacionadas ao desenvolvimento de cada subsistema definido no projeto. Cada subsistema terá suas funções bem definidas e suas especificidades quanto às competências necessárias ao seu desenvolvimento. No caso de um subsistema de software, um

processo de desenvolvimento caracterizado pelas etapas clássicas de desenvolvimento será iniciado.

Em raras situações, o desenvolvimento de um sistema impõe a construção, a partir do zero, de todos os subsistemas que o compõem. O mais comum é que alguns subsistemas sejam adquiridos e incorporados ao sistema. Embora seja o caso mais comum, nem sempre é fácil integrar subsistemas "de prateleira" a um sistema; em muitos casos, são necessárias modificações no sentido de adaptar o subsistema adquirido às necessidades do sistema a ser desenvolvido. Além disso, nem sempre é possível prever a disponibilidade de um subsistema de prateleira no momento em que ele é necessário.

A Engenharia de Hardware, para efeito de definição de um dado sistema, consiste no trabalho de seleção dos componentes que vão compor o hardware do sistema e que serão capazes de assumir as funções atribuídas a este elemento. Atualmente, o trabalho de seleção dos componentes de hardware é mais simples do que o de software, sendo facilitado pelos seguintes fatores:

Os componentes são montados como blocos de construção individuais;

As interfaces entre os componentes são padronizadas;

Existem numerosas alternativas "de prateleira" à disposição;

Aspectos como o desempenho, custo e disponibilidade são de fácil obtenção.

A Engenharia de Hardware é baseada na execução de três principais fases:

O Planejamento e a Especificação, cujo objetivo é estabelecer a dimensão do esforço necessário ao desenvolvimento, assim como o estabelecimento de um roteiro para o projeto e implementação do hardware; ainda nesta fase, é conduzida a análise de requisitos, cujo resultado deve ser uma especificação a mais completa possível das funções e outros requisitos para o hardware e das suas restrições;

O Projeto e Prototipação, a qual consiste na fase que, com base nos requisitos e restrições especificadas na fase anterior, define uma configuração preliminar do hardware; atualmente, as tarefas relativas a esta fase são semi ou completamente automatizadas com o auxílio de ferramentas de software CAE/CAD; o resultado final desta fase é um protótipo montado que será testado para garantir a satisfação de todos os requisitos;

A Produção, Distribuição e Instalação, onde o protótipo obtido na fase anterior vai sofrer as evoluções para tornar-se verdadeiramente um produto de hardware;

Alterações na embalagem, interfaces, componentes, etc..., são então realizadas; definição de métodos de controle de qualidade é um ponto fundamental nesta fase; a criação de um estoque de peças de reposição é uma outra preocupação conduzida neste momento, assim como a definição de esquemas de instalação e manutenção.Um dos resultados da Engenharia de Sistemas é a definição de aspectos como funcionalidade e desempenho do software. O trabalho essencial do engenheiro de software é acomodar os requisitos de funcionalidade e desempenho da forma mais eficiente possível, tendo que, para isto, adquirir e/ou desenvolver os componentes de software. A dificuldade que surge na Engenharia de Software é a falta de padronização nos componentes de software (o que não ocorre no caso do hardware), uma vez que, na maior parte dos projetos, estes componentes são "customizados" para atender às exigências de software do sistema a ser desenvolvido.

Como já foi discutido anteriormente, a Engenharia de Software envolve as seguintes fases:

Definição, que é iniciada com o Planejamento do Desenvolvimento do Software, englobando todas as tarefas discutidas no capítulo III do curso, obtendo um documento de Plano do Software, o qual será produzido e revisado pelo Gerente do Projeto; ainda nesta fase é realizada a Análise de Requisitos do Softwa, a qual vai permitir que funções, dentro do sistema como um todo serão atribuídas ao software; a última tarefa relacionada a esta fase é a revisão da Especificação de Requisitos do Software, o qual é o documento resultante da Análise de Requisitos;

Desenvolvimento do Software, que é a fase que tem, como ponto de partida, os documentos produzidos na fase anterior, particularmente, o Plano do Software e a

Especificação de Requisitos do Software; com base nestes documentos, inicia-se a etapa de Projeto do Software, onde serão descritos aspectos relacionados ao funcionamento do software como a sua arquitetura e as estruturas de dados; após avaliada esta definição, inicia-se a etapa de Projeto Detalhado, onde os aspectos algorítmicos e comportamentais do software são definidos; finalmente, a etapa de codificação é encaminhada, seja com base no uso de uma linguagem de programação clássica ou com o auxílio de uma ferramenta CASE, o resultado desta etapa sendo a listagem dos programas-fonte do software em desenvolvimento;

Verificação, Entrega e Manutenção, é a última fase do processo, a qual envolve as atividades de teste do software, preparando-o para a entrega; uma vez entregue, inicia-se, ao longo de toda a vida útil do software a etapa de manutenção, a qual permitirá manter o software em funcionamento a partir da correção de novos erros que tenham sido detectados com o software em funcionamento, da introdução ou melhorias de funções do software, da adaptação do software para novas plataformas de hardware existentes.

Por razões óbvias, os diferentes subsistemas definidos na etapa de projeto são desenvolvidos em paralelo. No caso de ocorrência de algum problema relacionado à interface dos diferentes subsistemas, uma solicitação de modificação no sistema pode ser necessária. Em sistemas envolvendo a utilização de muitos subsistemas de hardware, a realização de modificações após o término da implementação podem representar um aumento considerável no custo de desenvolvimento. Uma forma bastante utilizada nos projetos, neste caso, é utilizar os subsistemas de software para facilitar estas modificações, devido, particularmente, à flexibilidade inerente dos sistemas de software. É lógico que, para que as modificações nos subsistemas de software não representem custos tão elevados ou maiores quanto o dos subsistemas de hardware, é necessário que estes subsistemas tenham sido concebidos tendo como princípio sua manutenibilidade.

INTEGRAÇÃO DO SISTEMA

O conjunto de atividades a ser desenvolvido nesta etapa é o de conexão dos diferentes subsistemas construídos ou adquiridos para compor o sistema. É uma atividade bastante complexa, devido principalmente, à grande diversidade de tecnologias envolvidas na concepção dos diferentes sistemas.

Um problema comumente encontrado nesta etapa é o mal funcionamento de um subsistema como conseqüência de uma definição imprecisa de funcionalidade de outro subsistema.

Uma forma de realizar a integração de um sistema é o processo "big-bang", onde todos os seus subsistemas são conectados num passo único. Entretanto, por razões técnicas e gerenciais, a forma mais adequada é a integração incremental dos diferentes subsistemas. As principais razões para adoção desta estratégia são:

1) Na maior parte dos casos, é impossível sincronizar o fim do desenvolvimento de todos os subsistemas;

2) A integração incremental reduz os custos de identificação e correção de erros de integração. Quando um número muito grande de subsistemas são integrados simultaneamente, uma falha no sistema pode ser conseqüência de um ou mais erros presentes nos diferentes subsistemas. No caso da integração incremental, a ocorrência de uma falha pode ser mais facilmente controlada, pois ela será, muito provavelmente, conseqüência de um erro no subsistema mais recentemente integrado.

No caso de sistemas em que os subsistemas foram construídos por diferentes fornecedores, é muito comum ocorrer desentendimentos quando um problema de integração acontece. Os fornecedores tendem a acusar um ao outro como o responsável do problema detectado. Este tipo de ocorrência é bastante prejudicial ao desenvolvimento dosistema, podendo tomar muito tempo para que o problema seja resolvido.

Instalação do SistemaEsta etapa envolve todas as atividades relacionadas à colocação do sistema emfuncionamento no ambiente para o qual ele foi concebido. Embora possa parecer umproblema menor, a instalação de um sistema pode ser caracterizada pela ocorrência demuitos problemas que coloquem em risco o cumprimento de estimativas de prazo ou decusto.

Alguns problemas típicos desta etapa são:

O ambiente para o qual o sistema foi concebido não é precisamente o mesmoque foi especificado no início do projeto; este é um problema bastante comumem sistemas de software, particularmente no que diz respeito à utilização decertas facilidades do sistema operacional; quando a versão do sistemaoperacional do ambiente não é a mesma que foi utilizada para odesenvolvimento do sistema, o resultado pode ser catastrófico;

A resistência dos usuários à implantação do novo sistema é um outro problemaimportante; nem sempre a adoção de um sistema computacional para arealização de uma tarefa que vinha sendo realizada de outra forma é bem vistapelos funcionários, pois este vai, na quase totalidade dos casos, na necessidadede treinamento ou de alteração na sistemática de trabalho; um exemplo bastanteóbvio é o da utilização de sistemas de software para a declaração de imposto derenda; quando os primeiros programas foram lançados, muitas pessoas quetinham computadores ainda insistiam em utilizar os formulários impressos pararealizar suas declarações;

A necessidade de coexistência entre um sistema antigo e o novo sistema é outrafonte de problemas de instalação. No caso dos sistemas compartilharem algumrecurso, pode ser impossível instalar completamente o novo sistema semdesativar o antigo;

Obstáculos físicos à instalação do sistema são problemas muito comuns nestaetapa; ausência de pontos de energia ou tubulação apropriada, falta de sistemade ar-condicionado, são exemplos de obstáculos comumente encontrados nainstalação de sistemas computacionais.

Ativação do Sistema

Uma vez instalado, o sistema deverá ser ativado. Uma etapa de apresentação etreinamento relativo à utilização pode estar associada à ativação do sistema. Os problemasque podem ocorrer nesta etapa são os mais diversos. No caso de sistemas que deverãooperar conjuntamente a outros sistemas existentes, problemas de incompatibilidade podemocorrer e a dificuldade de resolução destes problemas pode provocar grandes atrasos à suacolocação em operação.

Outra fonte de problemas pode ser a inadequação ou a má utilização das interfacesde operador do novo sistema. Muitos erros de operação poderão ser cometidos até que ooperador crie intimidade com o novo sistema.

Evolução do Sistema

Os grandes sistemas computacionais são desenvolvidos para funcionar durantelongos períodos tempo. É inevitável que, durante este período, ocorram problemas queimponham modificações no sistema. As razões que podem conduzir a esta necessidadepodem ser erros do próprio sistema, novas necessidades em termos de função oualterações ambientais.

As evoluções a serem promovidas num dado sistema podem representar um custobastante alto, o que é justificado pelas razões abaixo:

Necessidade de estudos relativos às modificações a serem feitas para nãocomprometer o bom funcionamento do sistema;

O alto grau de dependência dos diversos subsistemas pode conduzir ànecessidade de alterações em muitos subsistemas, como conseqüência daalteração de um componente;

A falta de documentação relativa ao desenvolvimento do sistema original vai ser,sem dúvida, um grande obstáculo para o desenvolvimento do sistema;

Á medida que o tempo passa e que alterações vão sendo realizadas, a estruturaoriginal dos sistemas vai sendo modificada, de modo que futuras mudançaspodem ser fortemente comprometidas.

Desativação do Sistema

Esta etapa consiste em retirar o sistema de operação, quando seu tempo previsto defuncionamento esgota ou quando ele será substituído por um novo sistema. A desativaçãodeve ser feita de forma bastante rigorosa, principalmente no caso de sistemas cujoscomponentes podem ser nocivos ao ambiente. Sistemas que utilizam componentesradioativos são os exemplos mais comuns de sistemas cuja desativação deve ser feita como maior cuidado possível.

Por outro lado, no caso dos sistemas de software, a desativação pode serextremamente simples. A maior parte dos sistemas de software construídos atualmente jávem dotada de um utilitário de desativação (ou "desinstalação") que retira automaticamentetodos os componentes do sistema e as referências a estes componentes do sistemacomputacional.

Outro aspecto importante da desativação dos sistemas são as informações que estemanipulava ou gerava. Esta, normalmente, deverão ser armazenadas em mídia específicapara posterior adaptação à utilização num novo sistema.

PROJETO ARQUITETURAL

O Modelo do Sistema

Um importante resultado da especificação de requisitos e do projeto de um sistemacomputacional é a sua organização em termos de subsistemas e dos relacionamentos entreestes. A forma mais usual de representar esta organização é, sem dúvida, os modelosbaseados em linguagem gráfica.

Invariavelmente, a utilização de diagramas em blocos destacando os principaissubsistemas e como estes estão relacionados é bastante aceita nos projetos de sistemasem geral, incluindo os sistemas computacionais. A figura 3.4 ilustra tal mecanismo, atravésdo exemplo de projeto arquitetural de um sistema de controle de tráfego aéreo. O objetivoaqui não é descrever o funcionamento de um tal sistema, mas mostrar como se poderepresentar os diferentes componentes deste e como estes relacionam-se. As setas ligandoos diferentes subsistemas indicam os fluxos de informação que existem no sistema.

No caso de sistemas relativamente complexos, é comum que os subsistemasdefinidos neste primeiro nível sejam, por si só, sistemas complexos. Isto significa que, parase ter uma idéia mais completa de como o sistema deve operar, os subsistemas podem,eventualmente, ser representados utilizando a mesma linguagem.

Num sistema computacional, os diagramas de arquitetura destacam, na forma de subsistemas, os elementos que deverão ser desenvolvidos em hardware e em software, permitindo o encaminhamento das atividades relativas às diferentes engenharias, normalmente conduzidas em paralelo.

Na maior parte dos sistemas atuais, é comum que os componentes de hardware incluam um ou mais computadores e o software associado. Isto se justifica pela quedaconstante nos preços de equipamentos computacionais, permitindo a substituição de outras alternativas pelos sistemas computacionais, além das vantagens de tais equipamentos, particularmente para tarefas de controle e supervisão.

No nível de projeto arquitetural, nem sempre é importante definir que funções serãoexecutadas por software ou por hardware. O mais importante é definir subsistemas com base nas funções a serem executadas pelo sistema. A definição sobre a forma como cada função será implementada (em software ou em hardware) pode ser feita numa etapa posterior, levando em conta não apenas fatores técnicos. Por exemplo, a existência ou não de um componente de hardware que implemente adequadamente uma dada função pode ser determinante para definir se esta função deverá ser implementada em hardware ou software.

5 O DESENVOLVIMENTO DE SISTEMAS E AS SUAS ETAPAS

5.1 O Desenvolvimento na visão Pressman,O desenvolvimento, segundo Presman é realizado em três fases:5.1.1 Fase de DefiniçãoPlanejamento do software: descrição do escopo, análise do esforço, análise de riscos, levantamento dos recursos exigidos, estimativas de custos e de prazos. O objetivo é fornecer uma indicação da viabilidade do software; fase de análise e requisitos do software: a análise forma do domínio da informação é utilizada para estabelecer modelos de fluxo de dados e da estrutura da informação. Alternativamente pode ser feito um protótipo. Estes modelos são detalhados para se tornar uma especificação do software, que é o documento produzido com resultado desta fase.

5.1.2 Fase de Desenvolvimento

Descrição de estrutura modular, definição de interfaces, uma estrutura de dados é estabelecida. Uma especificação de projeto é produzida. E a codificação é realizada.

5.1.3 Fase de Verificação, Liberação e ManutençãoRealização de testes para descobrir o máximo de erros. Faz-se a manutenção do softwareao longo da sua vida útil.

5.1.4 Conceitos utilizados no desenvolvimento:Metodologias de Desenvolvimento - maneira de se utilizar um conjunto coerente ecoordenado de métodos para atingir um objetivo. Em outras palavras, a metodologia devedefinir quais as fases de trabalho previstas no desenvolvimento de sistemas.

Processo e métodos de Software Um processo de software pode ser definido como um conjunto coerente de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessáriospara conceber, desenvolver, implantar e manter um produto de software (FUGGETTA, 2000).

Um processo de software bem definido deve indicar as atividades a serem executadas, os recursos (humanos, de hardware e de software) requeridos, os artefatos consumidos e produzidos e os procedimentos a serem adotados (métodos, técnicas, modelos de documentos, entre outros) (FALBO, 1998) (GRUHN, 2002).

O conceito de modelo de ciclo de vida está relacionado diretamente com a noção de processo de software, definindo os principais estágios na vida do produto de software e suas relações. Tipicamente um modelo de ciclo de vida envolve as seguintes atividades: especificação e análise dos requisitos, projeto, implementação, verificação e validação, distribuição, operação, manutenção e retirada de uso (FUGGETTA, 2000).

A área de processos de software, como uma disciplina autônoma, surgiu em meados da década de 80. Ao longo desses anos, vários esforços vêm sendo realizados, com destaque para a criação de padrões de qualidade de processo (FUGGETTA, 2000), tais como a norma ISO/IEC 12207 (ISO/IEC, 2008) e o modelo de maturidade CMMI (SEI, 2006).

A qualidade de um produto de software depende fortemente da qualidade do processo de software utilizado em seu desenvolvimento (FUGGETTA, 2000). Entretanto, se por um lado ter processos de software é fundamental, seguir um processo de software mal definido pode ocasionar danos consideráveis ao andamento do projeto. Logo, é essencial possuir processos de software bem definidos.

Os processos padrão são vistos como elementos primordiais das normas e modelos de maturidade e o uso deles como base para o planejamento dos processos de software específicos de projetos torna mais direta a definição dos planos em conformidade com os padrões de qualidade da organização (BERGER, 2003).

Sendo assim, Entenda o que são os conceitos Racionais das palavras Citadas: FERRAMENTA, MÉTODO, PROCESSO.

Processo palavra com origem no latim procedere, que significa método, sistema, maneira de agir ou conjunto de medidas tomadas para atingir algum objetivo. Relativamente à sua etimologia, processo é uma palavra relacionada com percurso, e significa "avançar" ou "caminhar para a frente“ Pode ter os mais variados propósitos: criar, inventar, projetar, transformar, produzir, controlar, manter e usar produtos ou sistemas.

O processo é a camada mais importante da ES, esta camada constitui o elo de ligação entre as ferramentas e os métodos. É através do Processo que se chega a Algum lugar – a qualidade.

Um processo define :

A seqüência em que os métodos serão aplicados.

Quais os responsáveis por cada tarefa.

Quando e como o software será entregue.

Possibilitam aos gerentes de software avaliar o

progresso do desenvolvimento.

Uma empresa pode usar métodos e ferramentas e não seguir nenhum processo estabelecido. Existem até classificações para empresas quanto ao uso de processos. Em suma um Processo È a estrada até chegar a qualidade!

Ferramenta Palavra que deriva do latim que no plural: ferramentum. É um utensílio, dispositivo, ou mecanismo físico ou intelectual utilizado por trabalhadores das mais diversas áreas para realizar alguma tarefa. - Qualquer instrumento que se usa para a realização de um trabalho.

As ferramentas de engenharia de software proporcionam apoio automatizado ou semi-automatizado aos métodos.

• Se elas são integradas (troca de informação), chamamos de Ferramentas CASE (Computer-Aided Software Engineering), em português Engenharia de Software Auxiliada por Computador. o que são?

Método é uma palavra que provém do termo grego methodos (“caminho” ou “via”) e que se refere ao meio utilizado para chegar a um fim. O seu significado original aponta para o caminho que conduz a algures. Por sua vez, o método científico é o conjunto de passos seguidos por uma ciência para alcançar conhecimentos válidos podendo ser verificados por instrumentos fiáveis. O método científico é, por assim dizer, o conjunto de passos que permite que o investigador descarta a sua própria subjectividade.

Os detalhes de “como fazer” para construir o software,

existem métodos para as diferentes tarefas.

Definições de como será: Planejamento e estimativa de projeto Análise de requisitos

Definições de como vai ser: Projeto da estrutura de dados Codificação, teste, manutenção

“conjunto de atividades sistemáticas e racionais que, com maior segurança e economia, permite alcançar o objetivo - conhecimentos válidos e verdadeiros -, traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do cientista.” (Lakatos & Marconi, 1991).

O Nucleo da Engenharia de Software (Comunicação, Planejamento, Modelagem, Construção, Emprego).

De acordo Com Presmam : ferramentas, métodos e processo e Foco em qualidade. (ou seja para produzir um software de qualidade ela envolve estas três camadas)

FOCO NA QUALIADE –

A busca pela qualidade é o objetivo de usar qualquer engenharia (não apenas da ES).• Ela deve ser buscada em cada fase do processo de desenvolvimento.• Permite ao

gerente um controle e ao

desenvolvedor uma referência.

MODELOS DE PROCESSO DE SOFTWARE - OS PARADIGMAS DA ENGENHARIA DE SOFTWARE

Um paradigma de engenharia de software é escolhido tendo como base: a natureza doprojeto e da aplicação, os métodos e as ferramentas a serem usadas, os controles e osprodutos que precisam ser entregues ao usuário.Modelos de Processos de Softwares foram criados para tornar a atividade de desenvolvimento de software menos caótica e visam organizar o desenvolvimento utilizando técnicas e métodos (SOMMERVILLE, 2008)

A primeira fase é a “Situação Atual” que define o ambiente, a “Definição do Problema” indica o problema específico a ser resolvido, o “Desenvolvimento Técnico” resolve o problema de maneira que satisfaça as necessidades, e por último a Integração da Solução“entrega a solução ao cliente”.

Essas quatro fases formam um ciclo, dentro de cada uma dessas fases, existe outro ciclo com um problema em escala menor, e assim sucessivamente. Essa recursividade acaba em níveis racionais, quando uma solução ao problema é definido (PRESSMAN, 2006).

Ciclo de Vida Clássico – CASCATA.

São utilizados conceitos de Engenharia de Software, a qual prevê atividade de verificação (estamos fazendo o produto de forma correta?), validação (estamos fazendo o produto certo?) e de controle de qualidade. É um paradigma que utiliza um método sistemático e seqüêncial em que o resultado de uma fase se constitui na entrada de outra.

É o modelo mais utilizado no mercado, porém não é considerado o maiseficaz, pois raros projetos seguem fluxo linear, além de mudanças de requisitos queocorrem no projeto não serem de fácil adaptação, porque alteram toda a documentação desenvolvida (PRESSMAN, 2006).

As vezes chamado de modelo cascata, este paradigma abrange atividades (ou ciclos) de:

Engenharia de Software: quanto mais dados forem coletados em nível de sistema, menor será a probabilidade de haver "bugs" no sistema, consequentemente diminuirá os futuros reparos no mesmo. Também conhecido como estudo de viabilidade.

Análise e Especificação de Requisitos de software: é importante saber o que o cliente quer que o software tenha, com relação à recursos. Os requisitos devem ser documentados e revistos com o cliente antes de começar a execução do projeto.

Projeto: envolve muitos passos que se concentram em 4 atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface. O processo de feitura do projeto traduz quanto à qualidade antes de iniciar acodificação.

Codificação: o projeto deve ser transformado em programa, usando uma linguagem de programação, isto é, traduzido numa linguagem de máquina.

Testes e Integração do sistema: deve-se testar todas os programas a procura de erros. A Integração consiste das junções das várias unidades e programas desenvolvidos. O resultado real deve concordar com o projeto ou resultado exigido. Depois de testado, o software é entregue ao usuário.

Manutenção e Operação: o sistema é instalado e colocado em uso, indubitavelmenteo software sofrerá mudanças depois que foi entregue ao cliente, e, mesmo softwareembutido sofre upgrade de tempos em tempos. A manutenção ocorre basicamente com a correção de erros não detectados (manutenção corretiva), com a adaptação daaplicação às mudanças do ambiente (manutenção adaptativa) e na adição de novas características e qualidades do software (manutenção evolutiva).

O ciclo de vida clássico é o paradigma mais antigo e o mais amplamente usado em Engenharia de Software, mesmo assim surgirão, ou surgem problemas como:

Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe O cliente, amiúde, não saberá declarar todas as suas exigências. O cliente deve ter paciência, pois qualquer erro detectado após a revisão do programade

trabalho pode ser desastroso.

Os problemas são reais, mas, mesmo assim o ciclo de vida clássico continua sendo o maisusado no desenvolvimento de software. Este modelo é apropriado para sistemas transacionais onde as rotinas e procedimentos a serem automatizados são altamente estruturados. A principal desvantagem desta abordagem é o alto custo de correção das especificações quando nas fases de Teste e Implantação..

Prototipação

Muitas vezes, as dúvidas do cliente e do programador, em relação ao software, levam aoprocesso de prototipação. A prototipação capacita o desenvolvedor a criar um modelo desoftware que será implementado. O objetivo é antecipar ao usuário final um modelo de sistema para que ele possa avaliar sua finalidade, identificar erros e omissões, quando em utilização, efetuando de imediato correções e ajustes. O modelo pode assumir uma das três formas citadas:

Um protótipo em papel ou em PC, que retrata a interação homem máquina, podendo ver quantas interação haverá.

Um protótipo que implemente funções específicas, da função exigida pelo software. Um programa existente que executa parte ou toda a função desejada, mas que tem

características que deverão ser melhoradas.

Como todas as abordagens ao desenvolvimento de software, a prototipação inicia-se com a coleta de requisitos. Faz-se então um projeto rápido contendo os aspectos que serão visíveis ao cliente. O projeto rápido leva à construção de um protótipo, que, será avaliado pelo cliente/usuário. Esta avaliação será usada para refinar requisitos para o software desenvolvido. Idealmente, o protótipo serve como um mecanismo para identificar os requisitos de software. Muitas vezes, é preciso descartar um protótipo e, partir do início para evitar perda de tempo com correções.

Esse paradigma pode apresentar problemas pelas seguintes razões:

O cliente quer resultados, e, muitas vezes não saberá, ou não entenderá, que um protótipo pode estar longe do software ideal, que ele nem sequer imagina como é. Mesmo assim, a gerência de desenvolvimento cede às reclamações e tenta encurtar o prazo de entrega, o qual já estava prolongado.

O desenvolvedor, na pressa de colocar um protótipo em funcionamento, é levado a usar um SO ou linguagem de programação imprópria por simplesmente estar a disposição ou estar mais familiarizado. Essa atitude poderá levar à um algoritmo ineficiente.

A filosofia de protótipos possui as seguintes vantagens:

Maior garantia de sucesso técnico e psicológico; Redução no fator tempo: "O usuário gosta de ver o sistema funcionando"; Ideal para sistemas gerenciais e de apoio a decisão.

Como desvantagens tem-se: Exige elevada capacitação gerencial por parte da equipe do projeto; Aparentemente, mais dispendioso (a longo prazo esta desvantagem tende a desaparecer); Exige uma ferramenta apropriada de prototipação.

O protótipo é baseado no feedback dos usuários, devido a isso mudanças são feitas no protótipo. Dependendo do comentário dos usuários, estas mudanças podem ser menores, de modo que alterem formatos, ou podem ser maiores, de modo que são requeridas mudanças estruturais no protótipo.

Ainda que possam ocorrer problemas, o uso da prototipação é um paradigma eficiente naEngenharia de Software. O segredo é o entendimento entre o desenvolvedor e o cliente.

O Modelo Espiral.

Foi desenvolvido para abranger as melhores características do ciclo de vida clássico e daprototipação, ao mesmo tempo que adiciona um novo elemento, que é a análise de risco. Este modelo de ciclo de vida se utiliza de protótipos por se adequar muito bem com esta filosofia de desenvolvimento. Cada passo através do ciclo inclui: planejamento, análise e projeto, prototipação e avaliação. Os passos vão sendo repetidos até que um produto seja obtido.

Sendo assim definiu-se 4 importantes atividades:

Planejamento, determinação de objetivos, alternativas e restrições do ciclo, considerando os resultados do ciclo anterior ou da análise dos requisitos.

Análise dos riscos, análise das alternativas e identificação (resolução) dos riscos. Engenharia, Desenvolvimento e verificação da solução escolhida. Avaliação do Cliente, avaliação dos resultados e planejamento do ciclo seguinte.

Os riscos são circunstancias adversas que podem atrapalhar o processo de desenvolvimento e a qualidade do produto a ser desenvolvido, assim é possível prever e eliminar os problemas de alto

risco através de um planejamento e projetos cuidadosos. Este éum modelo que atende os seguintes casos:

o problema a ser resolvido não está totalmente entendido; a realidade pode mudar enquanto o sistema está sendo desenvolvido; a própria solução adotada pode ter algum efeito colateral desconhecido; a preocupação está centrada mais na qualidade e funcionalidade do que se produz.

Com base na experiência adquirida com a primeira versão, estabelecem-se novos requisitos para o sistema, e uma nova versão é concebida e implementada. A prototipação no ciclo de vida espiral tem como objetivos:

estabelecer um diálogo intensivo entre usuários e analistas/projetistas; encurtar ao máximo o ciclo "concepção-implementação-utilização-avaliação" do sistema; possibilitar a evolução do sistema através de vários ciclos ou refinamentos sucessivos; avaliar constantemente o sistema.

Baseado principalmente em decisões de prosseguir / não prosseguir, de acordo com aavaliação, seja do cliente ou do desenvolvedor, o modelo espiral tende à uma trajetória que ruma para o modelo mais completo do sistema.

O paradigma de modelo espiral, é atualmente a abordagem mais realista para o desenvolvimento de softwares e sistemas em grande escala. Ele usa uma abordagem "evolucionária", capacitando o desenvolvedor e o cliente a entender e reagir aos riscos, em cada etapa evolutiva da espiral. Usa a prototipação como um mecanismo de redução de riscos, e a mesma pode ser aplicada em qualquer ponto evolutivo. Porém, pode ser difícil convencer grandes clientes de que a abordagem evolutiva é controlável. Se um grande risco não for descoberto, com certeza ocorrerão problemas.

Esse paradigma é relativamente novo, e não tem sido amplamente usado como os 2 paradigmas anteriormente explicados. Somente o tempo, que gera a experiência, poderá comprovar a eficácia do modelo espiral.

Técnicas de 4a Geração (4GT) – Realizar um trabalho com a turma.

Modelo Por Iterativo e Incremento

Nos modelos por incremento, também chamado de modelo evolutivo, um único conjunto de componentes é desenvolvido simultaneamente, num primeiro tempo o núcleo do software e depois os incrementos vão sendo agregados.

As atividades de desenvolvimento e validação são desempenhadas paralelamente, com um rápido feedback entre elas. O processo de desenvolvimento de cada incremento é realizado usando um processo clássico dos já estudados anteriormente.

As vantagens são: Cada desenvolvimento é menos complexo. As integrações são progressivas. A cada interação, uma nova versão do produto pode ser distribuída.

Os riscos são: Os problemas no núcleo do software, inviabilizando novos incrementos, e

determinando o fim do ciclo de vida do software. Incapacidade de integrar novos incrementos

São usados em grandes projetos e também em softwares desenvolvidos para distribuição em grande escala, por permitir evolução e melhorias sem descaracterizar o software.

Neste modelo é criado um protótipo do software, geralmente sem um processo formal de desenvolvimento, utilizada para elucidar ou validar os requisitos do produto. Seria basicamente vários ciclos de cascatas em miniatura. Assim você consegue ter um feedback do cliente de forma mais rápida. Existem três tipos de modelos incrementais: Evolutivos – Onde produtos de cada etapa de desenvolvimento são aproveitados em cada nova etapa; Descartáveis – Produtos das etapas de desenvolvimento são descartados e cada novo protótipo é construído no início; Operacional – Requisitos são elucidados através de protótipos e o produto final é construído paralelamente a construção dos protótipos; Vantagens: Disponibilidade de partes prontas do sistema mais cedo; Facilidade nos testes: Geralmente, testar cada incremento é mais fácil do que testar o software pronto e tudo de uma vez só; Feedback do cliente a cada incremento feito; A aprendizagem do desenvolvedor numa linguagem é favorecida: Pode se optar em resolver as partes mais fáceis antes, enquanto ele aprende a linguagem, e deixar as partes mais complexas do sistema para depois. Desvantagens: A possibilidade de o sistema ser dividido em partes como pré-requisito, já que nem sempre um sistema pode ser dividido; Dificuldade na integração das partes desenvolvidas; Negociação com o cliente a respeito do pagamento do produto de software final pode ser problemática, uma vez que o desenvolvimento em passos incrementais costuma induzir o cliente a acrescentar requisitos e funcionalidades que não estavam previstas no escopo inicial do projeto, o que resulta no encarecimento do desenvolvimento do produto final.

Processo Unificado de Desenvolvimento de Software - RUP (Rational Unified Process).

O RUP, abreviação de Rational Unified Process (ou  Processo Unificado racional), é um

processo proprietário de Engenharia de Software criado pelaRational Software Corporation,

adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM

RationalUnifiedProcess e tornando-se um brand (marca) na área de Software, fornecendo técnicas

a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de

aumentar a sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado

utilizando a notação UML (UnifiedModelingLanguage) para ilustrar os processos em ação. Utiliza

técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de

desenvolvimento e a grandes Projetos, porém o fato de ser amplamente customizável torna possível

que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma

solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de

desenvolvimento de software.

A linguagem de modelagem UML (UnifiedModelingLanguage) é utilizadapara padronizar a

documentação dos projetos desenvolvidos utilizando o RUP, UML foi originalmente criado pela

Rational® Software e agora é mantido pela Object Management Group (OMG).

O RUP é uma metodologia iterativa, trabalha em ciclos e cada ciclo trabalha com uma versão nova

do produto, cada ciclo é divido em quatro fases consecutivas: Concepção, elaboração, construção,

transição.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é

apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de

seus "RationalSuites".

Gestão de requisitos

Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve

como documentar a funcionalidade, restrições de sistema, restrições de projeto e requisitos de

negócio. Para tanto o RUP, busca adotar uma linguagem de definição, que tem um padrão global de

aceitação – para tanto utiliza-se em associação a sua implementação a UML. Um bom exemplo

disso são oscasos de uso e os cenários que são utilizados para criar seus artefatos.

Uso de arquitetura baseada em componentes – importante.

A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível,

promovendo a reutilização de software e um entendimento intuitivo. Um componente normalmente

se relaciona com um objeto na programação orientada a objetos.

O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir

uma arquitetura executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em

larga escala.

Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o

COM (Modelo de Componentes de Objectos).

O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo

o processo e envolvendo todos os membros da equipe de desenvolvimento.

Gestão e Controle de Mudanças do Software

Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos

para controlar e monitorar mudanças. Como uma pequena mudança pode afetar aplicações de

formas inteiramente imprevisíveis, o controle de mudanças é essencial para o sucesso de um

projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças

efetuadas em outro sistema não afetarão o seu sistema.

O USDP (Processo unificado de desenvolvimento de software – RUP) consiste em cinco fluxos de trabalho do núcleo e quatro fases e é interativo.O RUP também se baseia nos 4 Ps:

1. Pessoas2. Projeto3. Produto4. Processo

FASES DE RUP.

Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um

projeto. As fases (vide figura abaixo) indicam a ênfase que é dada no projeto em um dado instante.

Para capturar a dimensão do tempo de um projeto, o RUP divide o projeto em quatro fases

diferentes:

1. Iniciação ou Concepção: ênfase no escopo do sistema;

2. Elaboração: ênfase na arquitetura;

3. Construção: ênfase no desenvolvimento;

4. Transição: ênfase na implantação.

Fase de Concepção

Na fase de concepção delimita-se o escopo total do projeto, paraisto se identifica todos os fatores

envolvidos no projeto e suas interações. Nesta fase também se verifica a viabilidade econômica do

projeto e a estimativa dos recursos que serão utilizados.

A fase de iniciação ou concepção contém os  workflows ( fluxo de trabalhos)  necessários à

concordância dos stakeholders - as partes interessadas - com os objetivos, a arquitetura e o

planejamento do projeto. Se essas partes interessadas tiverem bons conhecimentos, pouca análise

será requerida. Caso contrário, será exigida uma análise mais elaborada. Nesta fase, os requisitos

essenciais do sistema são transformados em casos de uso. O objetivo não é fechá-los em sua

totalidade, mas apenas aqueles necessários à formação de opinião. A etapa é geralmente curta e

serve para definir se é viável continuar com o projeto e definir os riscos e o custo deste último.

Um protótipo pode ser feito para que o cliente possa aprovar. Como cita o RUP, o ideal é que sejam

feitas iterações, mas estas devem ser bem definidas quanto à sua quantidade e aos objetivos.

Fase de Elaboração.

O propósito da fase de elaboração é analisar o problema principal, eliminar os principais riscos e

definir a arquitetura do projeto.

A fase de elaboração será apenas para o projeto do sistema, buscando complementar o

levantamento / documentação dos casos de uso, voltado para a arquitetura do sistema, revisa a

modelagem do negócio para os projetos e inicia a versão do manual do usuário. Deve-se aceitar:

Visão geral do produto (incremento + integração) está estável?; O plano do projeto é confiável?;

Custos são admissíveis?

Fase de Construção

A ênfase desta fase é o desenvolvimento dos componentes do projeto e outras funcionalidades do

sistema. Nesta fase é onde ocorre a maior parte

da codificação do projeto. Na fase de construção, começa o desenvolvimento físico do software,

produção de códigos, testes alfa. Os testes beta são realizados no início da fase de Transição.

Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem

"baseline".

Fase de Transição

Esta fase é onde ocorre a “transição” do software de seu desenvolvimento para o usuário, tornando-

o disponível e compreensível para o usuário final. Testa-se o sistema para validá-lo contra as

expectativas dos usuários finais. Nesta fase ocorre também, o treinamento e capacitação dos

usuários.

Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e

entrega, acompanhamento e qualidade do software. Produtos (releases, versões) devem ser

entregues, e ocorrer a satisfação do cliente. Nesta fase também é realizada a capacitação dos

usuários.

No final de cada fase existe um marco, milestone, bem definido onde decisões críticas devem ser

feitas. Nesses milestones a fase anterior e seus resultados são analisados e verificam-se critérios

específicos em cada milestone, caso não estejam em conformidade com os critérios estabelecidos

deve se determinar se o projeto será abortado, re-planejado ou continuará sendo desenvolvido

antes de passar para próxima fase.

Conceitos Importantes .

Processo Unificado Empresarial (EUP - Enterprise UnifiedProcess ) é uma variante, aumentada,

do RationalUnifiedProcess (RUP) ou Processo Unificado Rational/Racional (PUR) - metodologia

criada pela Rational Software Corporation e que se tornou conhecida, também, como IBM

RationalUnifiedProcess (IRUP) ou Processo Unificado IBM/Rational (PUIR), após a aquisição

daquela pela IBM. O Processo Unificado Empresarial foi desenvolvido por Scott W. Ambler e Larry

Constantine, em 2000, sendo reformulado, em 2005, por Ambler, John Nalbone e Michael Vizdos1 .

Originalmente concebido para superar algumas carências do Processo Unificado Rational/Racional,

quais sejam, a falta de suporte e a eventual retirada de um sistema de software. Assim, foram

adicionadas duas fases e várias novas disciplinas. O PUE ou EUP vê o desenvolvimento de

software não como uma atividade independente, mas integrado ao ciclo de vida do sistema (a ser

construído, melhorado ou substituído), o ciclo de vida de TI da empresa e o ciclo de vida da própria

empresa/organização2 .Trata-se do desenvolvimento do software, pelo ponto de vista do cliente.

Em 2013, os trabalhos começaram a expandir o EUP, de maneira a ser baseado no

método DisciplinedAgileDelivery (DAD) ou Entrega Ágil Disciplinada (EAD), ao invés do Processo

Unificado.

O RUP define nove disciplinas de projeto:

Modelagem de Negócios; Requisitos; Análise e Projeto; Implementação; Teste; Desenvolvimento; Configuração e Gerenciamento de Mudanças; Gerenciamento de Projetos; e Ambiente.

O EUP acrescenta, a estes, uma disciplina de projeto:

Operações e Suporte.

E sete disciplinas corporativas:

Modelagem de Negócios Empresariais; Gestão de Portfólio; Arquitetura Empresarial; Reuso Estratégico; Gestão de Pessoas; Administração Empresarial; e Melhoria de Processos de Software.

Cada fase do RUP também pode ser subdividida em iterações, neste caso uma iteração seria a

repetição desta fase. Além das fases outro conceito importante do RUP são os quatro

elementos: funções, atividades, artefato, disciplinas workflows).

Funções: define as responsabilidades de um individuo ou de um grupo de indivíduos, no RUP

funções são como os indivíduos ou grupo de indivíduos devem exercer seu papel no projeto.

Um membro da equipe do projeto geralmente desempenha muitas funções distintas.

Atividades: a atividade é uma unidade de trabalho que uma função pode ser solicitada a

executar. A atividade tem um objetivo claro. Por exemplo, executar umteste de performance.

Artefato: artefato é uma informação produzida, utilizada por um processo de desenvolvimento

de software, pode ser um documento, um modelo ou um software

Disciplinas: as disciplinas também conhecidas como workflows, são descrições em sequência

das atividades, artefatos e papéis envolvidos para produzir um resultado observável. Existem

nove disciplinas básicas no RUP, sendo seis de engenharia de software e três de suporte:

Disciplina de engenharia de software -

Modelagem de negócio (Business Modeling)

Requisitos (Requirements)

Análise e Design (Analysis& Design)

Implementação (Implementation)

Testes (Tests)

Implantação (Deployment

Disciplina de Suporte ou Apoio -

Gerência de Projeto (Project Management)

Gerenciamento de Configuração e Mudança (Configuration&Change Management)

Ambiente (Environment)

Disciplinas de Engenharia Relacionada ao RUP

Disciplina de Modelagem de Negócios

As organizações estão cada vez mais dependentes de sistemas de TI, tornando-se imperativo que

os engenheiros de sistemas de informação saibam como as aplicações em desenvolvimento se

inserem na organização. As empresas investem em TI, quando entendem a vantagem competitiva

do valor acrescentado pela tecnologia. O objetivo de modelagem de negócios é, primeiramente,

estabelecer uma melhor compreensão e canal de comunicação entre engenharia de

negócios e engenharia de software. Compreender o negócio significa que os engenheiros de

software devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais

problemas na organização e possíveis melhorias. Eles também devem garantir um entendimento

comum da organização-alvo entre os clientes, usuários finais e desenvolvedores.

Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será

implantado e como usar esta visão como uma base para descrever o processo, papéis e

responsabilidades.

Disciplina de Requisitos

Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-

los em um conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído

e fornecem requisitos detalhados para o que deve fazer o sistema.

No RUP padrão, o fluxo Requisitos objetiva estabelecer o que o sistema deve fazer. Este fluxo é executado para sistematicamente elícitar, documentar, organizar e acompanhar as mudanças dos requisitos de um sistema.

Elicitação:esclarecimento dos requisitos - ---- é o processo através do qual clientes e usuários são questionados por um desenvolvedor para falarem “o quê” o software deve fazer (ou seja, os requisitos). Esta fase será mais detalhada na seção

Análise: Avaliação do profissional, sobre as reais necessidades do cliente ---- é o processo onde são analisadas as necessidades dos clientes e usuários para se chegar na definição dos requisitos de software.

Especificação:documento especifico que desmembra e cataloga os requisitos já colhidos -----é o processo de criação de um documento no qual estão definidos todos os requisitos analisados.

Verificação: refininamento dos requisitos , ver se o que foi pesquisado e colhido esta de acordo com o que foi projetado e com que esta sendo construído -------é o processo que busca assegurar que a especificação de requisitos de software está em concordância com os requisitos elicitados e analisados nas fases anteriores, ou seja, estão de acordo com o desejo do cliente.

Gerenciamento: Contotrole de todas atividades de requisitos -----é o planejamento e controle da atividade de elicitação, especificação, análise e verificação dos requisitos.

Meios ou técnicas utilizadas.:Observação, Entrevista, Análise de Protocolo, JAD é colocar

autoridades representativas e gerenciais juntas dentro de um workshop estruturado para promover

decisões Prototipação, Cenários.

Disciplina de Análise e Projeto("Design")

O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um

sistema que:

Execute, em um ambiente de execução específico, as tarefas e funções especificadas nas

descrições de casos de uso

Cumpra todas as suas necessidades

Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais

Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de

análise. O modelo de design serve como uma abstração do código-fonte, isto é, o projeto atua como

um modelo de "gabarito" de como o código-fonte é estruturado e escrito. O modelo de projeto

consiste em classes de design estruturado em pacotes e subsistemas com interfaces bem definidas,

representando o que irá se tornar componentes da aplicação. Ele também contém descrições de

como os objetos dessas classes colaboram para desempenhar casos de uso do projeto.

Disciplina de Implementação

Os efeitos da implementação são:

Para definir a organização do código, em termos de subsistemas de implementação

organizadas em camadas

Para implementar classes e objetos em termos de componentes (arquivos-fonte,

binários, executáveis e outros)

Para testar os componentes desenvolvidos como unidades

Integrar os resultados produzidos por implementadores individuais (ou equipes), em

um sistema executável

Sistemas são realizados através da aplicação de componentes. O processo descreve como reutilizar

componentes existentes ou implementar novos componentes com responsabilidades bem definidas,

tornando o sistema mais fácil de manter e aumentar as possibilidades de reutilização.

Disciplina de Teste

As finalidades da disciplina de teste são:

Para verificar a interação entre objetos

Para verificar a integração adequada de todos os componentes do software

Para verificar se todos os requisitos foram corretamente implementados

Identificar e garantir que os defeitos são abordados antes da implantação do

software

Garantir que todos os defeitos são corrigidos, reanalisados e fechados

O RationalUnifiedProcess propõe uma abordagem iterativa, o que significa que deve-se testar todo o

projeto. Isto permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo

de reparar o defeito. Os testes são realizados ao longo de quatro dimensões da

qualidade:confiabilidade, funcionalidade, desempenho da aplicação, e o desempenho do sistema.

Para cada uma destas dimensões da qualidade, o processo descreve como você passar pelo teste

do ciclo de planejamento, projeto, implementação, execução e avaliação.

Disciplina de Implantação

O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o

software para seus usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção

de releases externos do software, a embalagem do software e aplicativos de negócios, distribuição

do software, instalação do software e prestação de ajuda e assistência aos usuários. Embora as

atividades de implantação estejam principalmente centradas em torno da fase de transição, muitas

das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação, no

final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP

contêm menos detalhes do que outros workflows.

Disciplina de Ambiente

O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele

descreve as atividades necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta

das atividades de ambiente é prover à organização de desenvolvimento de software os processos e

as ferramentas que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não

entendem que o RUP é um framework de processo, eles podem percebê-lo como um processo

pesado e caro. No entanto, um conceito-chave dentro do RUP foi que o processo RUP pode e,

muitas vezes, deve ser refinado. Este foi inicialmente feito manualmente, ou seja, por escrito, um

documento de "caso de desenvolvimento" que especificou o processo refinado para ser utilizado.

Posteriormente, o produto IBM RationalMethod Composer foi criado para ajudar a tornar esta etapa

mais simples, engenheiros de processos e gerentes de projeto poderiam mais facilmente

personalizar o RUP para suas necessidades de projeto. Muitas das variações posteriores do RUP,

incluindo OpenUP/Basic, a versão open-source e leve do RUP, são agora apresentados como

processos distintos, por direito próprio, e atendem a diferentes tipos e tamanhos de projetos,

tendências e tecnologias de desenvolvimento de software. Historicamente, como o RUP, muitas

vezes é personalizado para cada projeto por um perito do processo RUP, o sucesso total do projeto

pode ser um pouco dependente da capacidade desta pessoa.

Disciplina de Configuração e Gerência de Mudança

A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos

específicos: de configuração, de solicitações de mudança, e de status e medição.

Gerenciamento de configuração: A gestão de configuração é responsável pela estruturação

sistemática dos produtos. Artefatos, como documentos e modelos, precisam estar sob controle

de versão e essas alterações devem ser visíveis. Ele também mantém o controle de

dependências entre artefatos para que todos os artigos relacionados sejam atualizados quando

são feitas alterações

Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de

sistemas com muitos artefatos existem diversas versões. O CRM mantém o controle das

propostas de mudança

Gerenciamento de status e medição: Os pedidos de mudança têm os

estados: novo, conectado, aprovado, cedido e completo. A solicitação de mudança também tem

atributos como a causa raiz, ou a natureza (como o defeito e valorização), prioridade, etc.

Esses estados e atributos são armazenados no banco de dados para produzir relatórios úteis

sobre o andamento do projeto. A Rational também tem um produto para manter a solicitações

de mudança chamado ClearQuest. Esta atividade têm procedimentos a serem seguidos

Disciplina de Gerência de Projeto

O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou planos

de Fase que descreve todo o projeto, e uma série de alta granularidade ou planos deIteração que

descrevem os passos iterativos. Esta disciplina concentra-se principalmente sobre os aspectos

importantes de um processo de desenvolvimento iterativo: Gestão de riscos; Planejamento um

projeto iterativo através do ciclo de vida e para uma iteração particular; E o processo de

acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta

cobrir todos os aspectos do gerenciamento de projetos.

Por exemplo, não abrange questões como:

Gestão de Pessoas: contratação, treinamento, etc

Orçamento Geral: definição, alocação, etc

Gestão de Contratos: com fornecedores, clientes, etc

Desenvolvimento Baseado em Componentes (DBC)

A primeira vez que se citou componentização para o desenvolvimento de software foi em 1968, durante uma conferencia de Engenharia de Software nos Estados Unidos. Nela Mcllory, apresenta uma proposta de produzir software reutilizável. E propiciar aos desenvolvedores a possibilidade de escolher os componentes que querem utilizar segundo as suas necessidades. Depois na década de 80 surge os conceitos de orientação à objetos o que fortaleceu ainda mais o paradigma de reutilização de software.

Conceitos: Um componente é uma unidade de composição com suas interfaces definidas emcontratos e com dependências explicitas relativas ao contexto. Um componente de software pode ser desenvolvido separadamente, independentemente, e, posteriormente, participar da composição (SZYPERSKI, 1998).

Um componente é uma não trivial, semi-independente, e realocável parte de umsistema que possui uma clara função dentro do contexto de uma bem definida arquitetura. Um componente, nesta definição se adequa e provê a realização física deum conjunto de interfaces.

Componentes Concretos: Um componente concreto ou de prateleira (off-the-shelf) é uma unidade de código escritacom o uso de linguagens de programação convencionais (Java, C++, etc), internamenteUm componente concreto ou de prateleira (off-the-shelf) é uma unidade de código escrita com o uso de linguagens de programação convencionais (Java, C++, etc), internamente

Construir um aplicativo, segundo esta linha, passa a ser uma atividade de busca emontagem de componentes pré-moldados, chamados de caixa-preta (black-box), que atendam às necessidades do usuário final.Estes componentes podem ter sido criados em épocas diferentes, por grupos distintos e com diferentes usos em mente. Desta forma, o processo de desenvolvimento passa a ser uma descoberta dos componentes, suas capacidades, suas definições internas e as incompatibilidades que podem surgir quando da composição (BROWN et al., 1998).

Componentes Abstratos: Ao contrário do caso anterior, no qual eram reusados apenas componentes concretos, códigos guardados em repositórios, aqui, o reuso se dá a um nível mais abstrato, através de um correlacionamento entre requisitos, projeto e componentes. Neste, os requisitos levantados são analisados e mapeados para o projeto que, sendo baseado em arquitetura e definição de interfaces, terá seus componentes arquiteturais mapeados para os componentes de código, ou concretos, implementados. (BROWN et al., 1998).

A existência de uma arquitetura pré-definida garante a integração dos componentes e o reuso destes no desenvolvimento de novos aplicativos dentro deste domínio.

Entre as principais vantagens do uso de componentes abstratos estão os fatos de não haver: perdas por povoamento incorreto, incompatibilidade entre os componentes, ou perda de funcionalidade uma vez que os componentes têm suas especificações originadas de uma arquitetura de base. Com o uso de componentes abstratos, os problemas de customização foram reduzidos, apesar de persistirem a necessidade de ferramentas de auxílio para a gerência de componentes (BROWN et al., 1998).

A principal ideia da abordagem de Desenvolvimento Baseado em Componentes(DBC) é construir sistemas a partir de componentes já existentes, o que traz algumas consequências para o processo de desenvolvimento, dentre elas (CRNKOVIC et al., 2006):

Separação entre o processo de desenvolvimento de sistemas baseados em componentes e o processo de desenvolvimento de componentes: os

componentes já devem ter sido desenvolvidos para serem utilizados em outros produtos.

Surgimento de três importantes etapas: busca, avaliação e adaptação de componentes;

Diferença de foco das atividades do processo quando comparadas às do processo de desenvolvimento tradicional: no desenvolvimento de sistemas baseados em componentes existe uma grande ênfase na procura por componentes adequados. O desenvolvimento de componentes tem como foco principal o desenvolvimento de componentes reutilizáveis.

Com o intuito de promover a reutilização em todo o processo de desenvolvimento, SAMETINGER (1997) define algumas etapas que devem integrar as atividades do processo de desenvolvimento baseado em componentes:

1. Entendimento do Problema: Estudar o problema e desenvolver uma estrutura de solução baseada em componentes já existentes;

2. Reconfiguração: Adaptar a estrutura de solução para aumentar a possibilidade de se utilizar componentes disponíveis;

3. Busca: Obter, avaliar e instanciar componentes já existentes;

4. Adaptação: Modificar e adaptar os componentes selecionados que não atendam completamente aos requisitos;

5. Integração: Integrar os componentes ao produto final;

6. Avaliação: Avaliar os componentes que precisaram ser desenvolvidos e os que foram modificados quanto à possibilidade de reutilização e inserção no repositório de componentes.

Para que haja reúso efetivo, é necessário que haja um processo que dê ênfase às duas perspectivas do desenvolvimento baseado em componentes: desenvolvimento de componentes e desenvolvimento de sistemas a partir de componentes.

O desenvolvimento de componentes deve ser voltado para reutilização (CRNKOVIC et al., 2006). É desejável que um componente reutilizável atenda a características como: ser geral e autocontido; ter alta coesão e dependência mínima deoutros componentes; utilizar modelos de arquiteturas padrão e interfaces padronizadas; haver possibilidade de parametrização; haver independência de hardware, compilador esistema operacional; e possui documentação adequada (SAMETINGER, 1997).

A Adaptação de um Componente.

Conforme pesquisas realizadas, segundo Bosch 8 , têm mostrado que raramente um componente é

reutilizado como foi originalmente desenvolvido e que geralmente necessita de alguma forma de

alteração para se adequar à arquitetura da aplicação ou aos demais componentes.

As abordagens mais comuns são:

Encapsulamento caixa-branca(White box wrapping) – aqui, a implementação do

componente é diretamente modificada para resolver incompatibilidades. Isso é,

obviamente, possível apenas se o código-fonte do componente estiver disponível, algo

extremamente improvável no caso de COTS.

Encapsulamento caixa-cinza(Grey box wrapping) – Neste caso, a adaptação é feita

por uso de uma biblioteca do componente fornecendo uma linguagem de extensão do

componente ou API que possibilite a remoção ou mascaramento de conflitos.

Encapsulamento caixa-preta(Black box wrapping) – Caso mais comum, onde não é

possível o acesso ao código-fonte, e a única maneira de adaptar o componente é por

pré/pós processamento a nível de interface.

É responsabilidade do engenheiro de software determinar se os esforços para encapsular um

componente adequadamente são justificados, se seria menos custoso criar um componente que

solucione os conflitos. Também, uma vez que um componente foi adaptado é necessário verificar a

compatibilidade para integração e realizar-se testes para tentar antecipar quais comportamentos

inesperados que surjam devido as modificações realizadas.

Desenvolvimento Orientado a Reuso

Segundo FREEMAN (1987), reúso é a utilização de qualquer informação já disponível que um desenvolvedor necessite no processo de criação de software. Já TRACZ (1995) diz que reúso é a utilização de software projetado para ser reutilizado. Há uma discussão importante no contexto da reutilização de software sobre a possibilidade de modificação do software a ser reutilizado. COOPER (1994) define reutilização de software como a capacidade de um componente de software previamentedesenvolvido ser reutilizado, com ou sem modificação, em parte ou no todo. Em uma visão mais geral, a reutilização de software pode ser vista como o processo de criação de software a partir de software já existente, ao invés de construí-lo do zero (KRUEGER, 1992).

Na maioria dos projetos de software já ocorre de modo informal algum reuso de software.A abordagem aqui descrita propõe a utilização de componentes previamente desenvolvidos e que podem ser utilizados por vários sistemas da forma que foram confeccionados. Existe uma ampla base de componentes de software reutilizáveis, que podem ser acessados, e com alguma infra-estrutura de integração para esses componentes.

Este modelo tem a vantagem de reduzir a quantidade de software a ser desenvolvido, portanto de reduzir custos e riscos, permitindo desta forma a entrega mais rápida do software. Contudo, as adequações nos requisitos podem ser inevitáveis e pode resultar em um sistema que não atenda as necessidades do usuário, além de que novas versões dos componentes reutilizáveis podem não estar sob controle da equipe de desenvolvimento.

O software é desenvolvido a partir de componentes de software reutilizáveis. O modelo orientado a reuso o necessita de:

uma ampla base de componentes de software reutilizáveis  que implementem diversas funcionalidades.

Uma infraestrutura de integração para esses componentes. A vantagem desta abordagem é a redução na quantidade de software a ser desenvolvido. A desvantagem é que as adequações sobre os requisitos são inevitáveis e o controle sobre 

a evolução do sistema é  perdido.

Além dos benefícios de melhoria de qualidade, SAMETINGER (1997) tambémaponta alguns benefícios sobre a redução do esforço necessário ao desenvolvimento, a saber:

Trabalho redundante / tempo de desenvolvimento: ao se desenvolver todos os sistemas do zero, trabalhos redundantes são realizados, como o desenvolvimento de interfaces com usuário e algoritmos básicos. Ao se disponibilizar essas partes como componentes reutilizáveis, evita-se esse trabalho redundante e, por conseguinte, reduz-se o tempo de desenvolvimento;

Documentação: mesmo sendo considerada importantíssima para manutenção dos sistemas, muitas vezes a documentação é tratada com negligência. A reutilização de componentes de software reduz a documentação a ser escrita, uma vez que apenas a estrutura geral do sistema e os novos componentes desenvolvidos necessitam ser documentados;

Custos de manutenção: espera-se que poucos defeitos sejam encontrados ao se utilizar componentes reutilizáveis – uma vez que eles já passaram por diversos testes – e, consequentemente, menos esforço de manutenção para o sistema é esperado. Os componentes reutilizáveis são mantidos por um grupo separado;

Tamanho da equipe: equipes grandes sofrem com o problema da comunicação interna. A produtividade de uma equipe não aumenta proporcionalmente ao tamanho da equipe e, com isso, dobrar o seu tamanho não acarreta necessariamente em dobrar a produtividade. Se boa parte dos componentes de um sistema puder ser reutilizada, ele pode ser desenvolvido por uma equipe menor.

O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

ATIVIDADES DE DESENVOLVIMENTO DE SOFTWARE

Este capítulo aborda as principais atividades envolvidas no processo de desenvolvimento de software, independente do modelo de ciclo de vida adotado. Ao final do capítulo discute-se a automação deste processo através do uso de ferramentas CASE.

MODELAGEM DE NEGÓCIO

A modelagem de negócios vem sendo explicitadas de diversas formas, em diversas linguagens e modo de expressão, existem alguns termos que designam uma mesma direção, pois quando falamos das regras de negócios o das engenharia de processos de negócios, estamos dizendo que uma regra de negócios que pode estar encaixadas dentro do processo e mesmo assim. Estes e outros termos dizem respeito a compreensão do negócio do cliente pelo arquiteto (engenheiro) de software.

Segundo Ross (2003), regras de negócio (RNs) são diretivas cujo objetivo é influenciar ou guiar o comportamento de um negócio. Para o Business Rules Group (2000), RNs são declarações que definem ou restringem algum comportamento de um negócio. Ainda para o Business Rules Group (2000), uma RN expressa restrições específicas na criação, atualização ou remoção de dados persistentes em um sistema de informação. Numa definição mais detalhada, Wiegers (2006) afirma que RNs são políticas da companhia, padrões de indústria ou leis e regulamentações governamentais que definem, restringem ou governam alguns comportamentos de um negócio. Ainda de acordo com Date (2000) cita que um sistema de informação, que implementa alguma função de negócio, pode ser dividido em três partes, sendo elas:

1. Funcionalidades de Apresentação 2. Funcionalidades de Banco de Dados 3. Funcionalidades específicas da função de negócio em si.

Nos últimos anos a relação entre as RNs e a engenharia de software gerou duas linhas distintas de pesquisa, a primeira, foca a obtenção e representação sistemática das RNs por meio de várias técnicas, como: a linguagem natural, Object Constraint Language (OCL), eXtensible Markup Language (XML), Lógica de Primeira Ordem (LPO), entre outras (Martins, 2006; Morgado 2005). O objetivo primário dessa linha de pesquisa é a obtenção das RNs pelos especialistas de negócios, sua posterior tradução para uma representação computacional e sua integração com os sistemas de informação da empresa pelo código gerado.

As RNs, podem ser classificadas de diversas formas de acordo com a variação do autor escolhido, cada uma possui uma visão especifica em cada singularidade, mas todas ela possue uma estrutura base que independe da forma como são classificadas, elas sempre são compostas de termos e fatos.

De acordo com (Ross, 2003) termos e fatos estruturam o conhecimento básico do negócio. O entendimento destas palavras é que basicamente iniciam e norteiam o andamento do processo de software dentro de uma empresa. Onde podemos conceituar o termo como: uma palavra ou frase ou expressão que tenha um significado claro e compreensível que não gere duvidas ou seja não pode ser ambíguo e deve caracterizar a particularidade do negócio. E os fatos e/ou regras são as materialização da referência aos termos da cultura empresarial, modos e todo o arcabouço que envolve o planejamento. Assim Ross afirma que para que um termo possa ser usado ele precisa possuir três características (Ross, 2003): Básico: Termos não podem ser derivados ou associados a outros termos. Atômico: Termos devem representar conceitos indivisíveis. Gerar conhecimento: Termos devem sempre representar conceitos que produzem algum tipo de conhecimento.

Princípios Básicos das Regras de negócio Para elaboração da regras de negócio, deve ser estabelecidos certos critérios, assim Ross (2003), durante a explanação sobre sua abordagem de RNs, mostra os princípios básicos das RNs, que funcionam como um guia para a elaboração correta dessas regras dentro do contexto de negócio, como segue:

Regras devem ser escritas de forma explícita; Regras devem ser expressas em linguagem clara; Regras devem existir independentemente de procedimentos e workflows; Regras devem ser construídas sobre fatos, e os fatos devem ser construídos

sobre conceitos representados por termos; Regras devem guiar ou influenciar comportamentos da maneira prevista; Regras devem ser movidas por fatores de negócio identificáveis e importantes; Regras devem ser únicas; Regras devem ser especificadas diretamente pelas pessoas que tem um

conhecimento relevante sobre elas; Regras devem ser gerenciadas.

Segundo Bajec e Krisper (2004), outro princípio, não menos importante, sobre RNs é que por sua natureza, as RNs estão em constante mudança devido às influências sofridas, sejam elas influências internas ou externas à organização.

A metodologia de RNs proposta por Von Halle (2002), defende que os softwares que implementam RNs devem sempre manter separados três elementos do software: regras, dados e processos. Considerando que o foco dessa metodologia são as regras, nela a autora defende que todo software que incorpora conceitos de RNs (e em sua opinião todos os softwares que manipulam informações coorporativas deveriam incorporá-los) deve respeitar alguns princípios básicos que tem por objetivo garantir a separação e gerenciamento das RNs, algo que geralmente é negligenciado nas metodologias tradicionais de desenvolvimento de software. Esses princípios são:

1. Separação (Separate): As RNs devem ser projetadas de forma separada do núcleo do software. Esse princípio busca incentivar o reúso das regras e possibilitar que elas possam ser alteradas independentemente de outras características do sistema;

2. Rastreamento (Trace): As RNs devem possuir uma rastreabilidade que permita identificar os artefatos de software utilizados para sua implementação, com isso, o impacto sobre a alteração de uma regra pode ser mensurado. Além disso, esse princípio apóia as tarefas de manutenção do sistema;

3. Exteriorização (Externalize): Toda a regra deve ser expressa num formato compreensível para que seja possível a realização de auditorias de negócio, por pessoas não-técnicas;

4. Posicionamento (Position): As RNs devem estar preparadas para mudanças, uma vez que por meio das regras pode-se mudar o curso regular do negócio. Em resumo, deve ser possível alterar-se uma RN de forma fácil e rápida.

Segundo Santos (2002, p.1), a Engenharia de Processos de Negócio (EPN) pode ser definida como “uma arquitetura (framework) para entendimento, análise e melhoria dos processos dentro e entre organizações”. Para Cameira & Caulirauxx (2000) pode-se encontrar a seguinte definição de EPN: “é uma técnica muito utilizada quando se deseja entender ou mapear como uma parte de uma organização, uma organização ou, até, um conjunto de organizações (uma cadeia de suprimento) opera, como são realizados os processos, como a informação flui através desses processos, quais recursos são utilizados, quem realiza as atividades, permitindo entender as cadeias de valor existentes”.

As propostas de Eriksson e Penker (2000) formam uma Arquitetura baseada na linguagem UML para a modelagem de negócios onde podem ser adicionados stereotypes, tagged values e constraints convenientes para cada linha de negócios. Fundamentam-se na hipótese de que um negócio pode ser modelado através de objetos e dos relacionamentos entre estes, que a arquitetura de modelagem fornece vistas para a modelagem com foco em aspectos significativos e cada vista pode ser modelada por um ou mais tipos de diagramas. Oferecem as seguintes vistas para a Arquitetura:

– Visão do Negócio (Business vision): modela conceitos e objetivos a serem seguidos de acordo com a estratégia do negócio;

– Processo do Negócio (Business process): modela os processos de negócio e seus relacionamentos com os recursos a serem seguidos para atingir os objetivos;

– Estrutura do Negócio (Business structure): modela a estrutura dos recursos (físicos, informacionais, humanos);

– Comportamento do Negócio (Business behavior): modela o comportamento e a interação entre recursos e entre processos.

O Diagrama de Processos de Negócio e o Diagrama de Linha de Montagem têm um papel importante na ligação entre requisitos de negócios e casos de uso. O primeiro descreve os processos de negócio através de suas relações com Objetos (Objetivos, Entradas, Saídas, Fornecedores e Controles).

Workflow para Modelagem de Negócio

O workflow definido para a modelagem de negócio é apresentado na Figura 3. A seguir, as descrições de cada atividade proposta e seus respectivos produtos:

 

 

 

– Modelar os Objetivos do Negócio: a modelagem dos objetivos deve identificar os principais objetivos e subobjetivos do negócio em uma estrutura hierárquica que permita a visualização de dependência entre tais objetivos. Este modelo servirá de base para a definição dos processos de negócio. A modelagem dos objetivos do negócio deve ser feita com base em entrevistas realizadas com os conhecedores do negócio. Produto resultante: Diagrama de Modelo de Objetivos.

– Modelar os Processos de Negócio: os processos de negócio devem ser definidos buscando-se a realização dos objetivos identificados no Modelo de Objetivos do Negócio. Porém, não é necessário haver uma relação um para um entre processos de negócios e objetivos do negócio, pois muitos processos auxiliares não estarão necessariamente relacionados a um objetivo do Modelo de Objetivos do Negócio. Entrevistas com os envolvidos no negócio também devem ser realizadas para fornecer subsídios à definição dos processos de negócio. Produto resultante: Diagrama de Processos de Negócio.

– Modelar os Recursos Envolvidos: os recursos, informações e unidades organizacionais devem ser modelados através dos diagramas da Vista de Estrutura do Negócio. A modelagem destes elementos deve ser feita paralelamente às atividades de Modelagem de Processos de Negócio, a fim de melhor entender os termos relacionados ao negócio e, conseqüentemente, ter maior consistência na modelagem do mesmo. Produtos resultantes: Diagramas de Modelos de Recursos, de Informações e de Organização.

– Modelar Comportamento dos Recursos: um Diagrama de Estados de Recurso pode ser criado para facilitar a determinação dos processos de negócio quando este se caracteriza por refinamentos de um mesmo objeto ao longo da cadeia de valor. Por exemplo, considerando-se um negócio de vendas, o pedido pode ser abordado como um objeto cujo estado vai sendo alterado (refinado) ao longo de toda a cadeia de valor, desde a abertura do pedido até a confirmação do pedido entregue ao cliente. Em um caso como este, a identificação dos estados possíveis de tal objeto (como pedido solicitado, pedido em verificação de estoque, pedido em produção, pedido em expedição e pedido entregue) pode facilitar a identificação dos processos de negócio necessários ao cumprimento das mudanças de estado do produto. Produto resultante: Diagrama de Estado de Recurso e Diagramas de Interação de Recursos e de Estados.

– Definir Papéis e Responsabilidades: cada processo de negócio deve possuir um responsável, uma vez que geralmente não estará ligado a uma única unidade organizacional, mas passando por mais de uma delas. Cada processo, por sua vez, define um fluxo de eventos que pode envolver um ou mais atores. É necessário definir quais atores agem em cada um dos processos. Isto pode ser feito através de uma análise do fluxo de eventos e associação destes aos atores envolvidos no processo. Produto resultante: Tabela de Papéis e Responsabilidades.

Abordagens das atividades propostas para Modelagem de Negócios

As abordagens das atividades propostas em cada fase de desenvolvimento estão descritas a seguir:

Modelar os Objetivos do Negócio

Na fase de Concepção – o Modelo de Objetivos deve abordar todos os objetivos relevantes ao projeto, desde os de nível mais estratégico até os que estejam ao nível dos objetivos de processos de negócio.

Na fase de Elaboração – deve-se atualizar o modelo de objetivos em função de possíveis esclarecimentos posteriores.

Modelar os Processos de Negócio

Na fase de Concepção – deve-se identificar os principais processos de negócio, suas relações com os recursos (entradas, saídas, fornecedores, controles e objetivo), e a seqüência de

execução dos mesmos. Porém, não é necessária a descrição detalhada do fluxo de eventos ocorrido internamente no processo.

Na fase de Elaboração – detalhar o fluxo de eventos dos processos que serão abordados na iteração atual.

Modelar os Recursos Envolvidos

Na fase de Concepção – devem ser modelados todos os recursos significativos identificados no Modelo de Processo de Negócio definido na fase Concepção, de forma a analisar a dependência entre tais recursos e suas propriedades.

Na fase de Elaboração – modelar todos os recursos significativos identificados durante o detalhamento dos fluxos de eventos de cada processo de negócio.

Modelar Comportamento dos Recursos

Na fase de Concepção – modelar o comportamento de recursos nos casos em que ocorram várias alterações ao longo dos processos de negócio, já que esta dinâmica de alterações precisa ser melhor entendida.

Na fase de Elaboração – detalhar os Diagramas de Estado de Recursos, caso tenham sido criados na fase Concepção, com base no detalhamento dos fluxos de evento dos processos.

Definir Papéis e Responsabilidades

Na fase de Concepção – definir apenas os responsáveis por cada processo de negócio, sejam eles unidades organizacionais ou funções.

Na fase de Elaboração – definir os papéis (atores) associados aos eventos que ocorrem no fluxo de evento de cada processo de negócio.

Workflow de Levantamento de Requisitos

A seguinte atividade foi adicionada ao Workflow de Levantamento de Requisitos:

– Identificar Necessidades de Informatização: nesta atividade é necessário associar os processos de negócio aos sistemas de informação que lhes dão suporte e, assim, identificar a possível necessidade de novos sistemas de informação, com a caracterização de carências de suporte automatizado de informação e operações aos processos. Sugere-se a utilização do Diagrama de Linha de Montagem como base para a realização desta atividade. Produto resultante: Diagrama de Linha de Montagem com os pacotes de linha de montagem identificados.

A atividade Encontrar Atores e Casos de Uso, já existente no UP, foi atualizada:

– Derivar Casos de Uso dos Processos de Negócio: os casos de uso devem ser identificados com base nos processos de negócio. Esta atividade deve resultar em uma Relação de Casos de Uso na qual deve-se associar cada caso de uso identificado ao processo (ou processos) de negócio a que este atende. Sugere-se a utilização do Diagrama de Linha de Montagem como base para a realização desta atividade (exemplo na Figura 2). A identificação dos casos de uso no Diagrama de Linha de Montagem se dá através do agrupamento de referências (entre o processo e os sistemas) de mesma natureza. Produto resultante: Diagrama de Linha de Montagem com casos de uso identificados.

Abordagens das atividades propostas para Levantamento de Requisitos

As abordagens destas atividades em cada fase de desenvolvimento considerada são descritas a seguir:

Identificar Necessidades de Informatização

Na fase de Concepção – identificar sistemas de software que dão suporte aos processos de negócio, bem como identificar a necessidade de novos sistemas e subsistemas. Utilizar o Diagrama de Linha de Montagem como recurso de apoio ao desenvolvimento desta atividade. Deve-se começar com os pacotes em um alto nível de abstração, representando os sistemas já existentes e a natureza das informações das referências que estes fazem a cada processo de negócio analisado. Aplica-se, então, uma primeira avaliação quanto à natureza das informações e às operações necessárias ao processo e o atendimento destas pelos sistemas existentes, de forma a identificar tipos de informações e operações que não estão sendo mantidas pelos sistemas de software disponíveis. Tais necessidades de informação e de operações devem ser referenciadas a um outro pacote representativo do sistema (ou sistemas) a ser construído para atender a tais requisitos.

Na fase de Elaboração – deve-se atualizar e aprofundar a análise iniciada na Concepção, com base na descrição do fluxo de eventos dos processos. É necessário avaliar cada fluxo de evento e identificar eventos que podem ser auxiliados por sistemas de informação, mas que ainda não são. Tais auxílios devem ser representados como referências do processo aos sistemas que os realizam. Considerando o escopo de um sistema identificado na concepção, deve-se representar cada linha de montagem como uma classe do sistema e distribuir a responsabilidade entre as classes através das referências feitas a cada uma delas pelos processos. Cada evento a ser informatizado deve resultar em uma referência à classe que o realizará e quando esta não existir, deverá ser criada como uma nova linha de montagem. Este processo deve ser feito respeitando-se o conceito de encapsulamento.

No sentido de garantir uma visão mais ampla de todo o negócio pode-se considerar um conjunto de 04 (quatro) vistas que se complementam (ERIKSSON, PENKER, 2000), não sendo modelos separados; elas são diferentes perspectivas de um ou mais aspectos específicos do negócio. Combinadas, os vistas criam um modelo completo e abrangente do negócio.

Visão total do negócio: esta visão descreve uma estrutura objetiva da empresa e ilustra problemas que devem ser solucionados no sentido de alcançar os resultados esperados pela organização. Alguns fatores importantes no momento de modelar a visão do negócio:

Missão – o objetivo mais macro da organização;

Objetivos – objetivos mais específicos da organização;

SWOT: Oportunidades – áreas externas de potencial crescimento da organização, bem como fatores externos benéficos; Fragilidades – fatores externos prejudiciais ao crescimento da organização; Pontos fortes – fatores internos que são diferenciais da organização; Pontos fracos – fatores internos que são prejudiciais e que necessitam ser melhorados;

Fatores críticos – pontos que são imprescindíveis para o crescimento da organização;

Estratégia – ações de curto, médio e longo prazo que irão possibilitar atingir os objetivos descritos;

Principais competências – áreas do negócio que tem mais importância;

Papéis dos envolvidos – as funções específicas dos envolvidos no negócio;

Organograma – grupos de divisão interna da organização;

Processos chaves – as principais atividades para alcançar os objetivos;

Visão dos processos de negócio: é o ponto principal da modelagem de processos de negócio. Ela representa as atividades e valores criados no negócio, e ilustra as iterações

entre os processos e os recursos no sentido de alcançar os objetivos de cada processo, definidos anteriormente. A Visão também pode demonstrar a iteração entre diferentes processos. Alguns fatores importantes no processo de modelagem:

Que atividades são necessárias?

Em que seqüência as atividades são executadas e quando?

Por que as atividades são executadas, para atingir que objetivos?

Como as atividades são executadas?

Quem e o que estão envolvidos nas atividades?

O que está sendo consumido e produzido?

Qual o volume de atividades executadas?

Quem controla o processo?

Quais são os processos inter-relacionados?

Visão da Estrutura do Negócio: mostra a estrutura entre os recursos no negócio, tais como a organização do negócio, estrutura dos produtos criados e informações do processo. Esta visão é mostrada através de um modelo de classe com objetos relacionados. os modelos que o compõem são: modelo de recursos; modelo de informações; modelo da organização;

Visão do Comportamento individual do Negócio: Cada recurso é um processo importante no modelo do negócio. Para isso é importante modelar o estado com a modelagem de comportamento de um recurso e seus possíveis estados de acordo com o processo. Para tal utilizam-se os seguintes diagramas: diagrama de estados; diagrama de seqüência e colaboração; diagrama de processo.

Por fim a linguagem UML –

UML é uma linguagem para especificar, visualizar, construir, e documentar artefatos (documentos) de sistemas de softwares, bem como para modelagem de negócio e outros sistemas que não são softwares. Ela representa uma coleção das melhores práticas de engenharia que tem sido aprovadas com sucesso na modelagem de sistemas complexos e de grande escala.

Para Booch et al. (2000) a UML é definida como uma linguagem padrão para a visualização, especificação, construção e documentação de artefatos que fazem parte do processo de elaboração da estrutura de projetos de sistemas complexos de software.

Na modelagem de negócios, os principais objetivos a serem alcançados ao se utilizar a UML, conforma OMG (2003), são: “fornecer aos usuários uma linguagem de modelagem expressiva que ajude no desenvolvimento e na troca de modelos significativos; oferecer mecanismos de extensão e especialização dos principais conceitos; suportar especificações que sejam independentes de qualquer linguagem de programação e processo de desenvolvimento; fornecer uma base formal para entendimento da linguagem de modelagem; suportar conceitos de desenvolvimento de alto nível como componentes, colaborações, frameworks e padrões; integrar a melhores práticas”.

Os principais diagramas gerados e utilizados pela UML encontram-se na Figura 2.1.

Delmir Peixoto de Azevedo Junior; Renato de Campos - Definição de requisitos de software baseada numa arquitetura de modelagem de negócios <disponível em: http://www.scielo.br/scielo.php?pid=S0103-65132008000100003&script=sci_arttext >

ANTONIO, MARCO DE GRANDI - UMA ABORDAGEM DE IDENTIFICAÇÃO E MODELAGEM DE REGRAS DE NEGÓCIO E SEUS RELACIONAMENTOS TRANSVERSAIS - Disponivel em < http://www.dataplussistemas.com.br/wp-content/uploads/2011/01/Dissserta%C3%A7%C3%A3o_Final.pdf >.

PLANEJAMENTO

ENGENHARIA DE REQUISITOS

O objetivo do desenvolvimento de software é a criação de sistemas de software que correspondam às necessidades de clientes e usuários. Uma correta especificação dos requisitos do software é essencial para o sucesso do esforço de desenvolvimento.

Mesmo que tenhamos um sistema bem projetado e codificado, se ele foi mal especificado, certamente irá desapontar o usuário e causar desconforto à equipe de desenvolvimento, que terá de modificá-lo para se adequar às necessidades do cliente.

De acordo com o Insitute of Electrical and Electronics Engineers - IEEE, o processo de aquisição, refinamento e verificação das necessidades do cliente é chamado de engenharia de requisitos [IEEE1984].

A Engenharia de Requisitos (E.R.) aborda uma etapa crucial no ciclo de vida do desenvolvimento de Software por tratar de conhecimentos não apenas técnicos, mas também gerenciais, organizacionais, econômicos e sociais. Várias abordagens têm sido propostas para apoiar a engenharia de requisitos, sendo a maioria baseada em linguagens capazes de expressar os desejos dos clientes/usuários. Entre os aspectos importantes das linguagens de especificação de requisitos, são destacados:

Poder de expressão: o conjunto de construtores disponíveis na linguagem deve ser rico o suficiente para permitir uma tradução (mapeamento) natural dos fenômenos do mundo real em descrições escritas na linguagem;

Formalidade: definição de regras precisas de interpretação, que permitam a prova de propriedades da especificação dos requisitos, bem como a possibilidade de descobrir inconsistências e/ou incompletudes.

Boehm [Boehm1989] define E.R. como uma disciplina para desenvolver uma especificação completa, consistente e não ambígua que sirva como base para um acordo entre todas as partes envolvidas, descrevendo o que o produto de software irá fazer (mas não como ele será feito). Observe que Boehm define a E.R. como um processo que envolve uma grande colaboração entre o cliente e o desenvolvedor. A especificação de requisitos funciona como um meio de comunicação para atingir um acordo acerca do software pretendido. É enfatizada também a importância de se tentar evitar decisões de projeto no momento da definição de requisitos (desejável, porém difícil de obter na prática).

Meyer [Meyer1988] afirma que especificar o documento de requisitos de um software é definir de uma forma completa e não ambígua:

As características externas do software oferecidas aos usuários; A forma pela qual o software é integrado no sistema.

Já Davis [Davis1993] informa que, durante a etapa de requisitos, é necessário analisar e, portanto, entender o problema a ser resolvido. A análise do problema é a atividade que inclui o entendimento das necessidades do usuário, bem como as limitações impostas na solução.

Estudos mostram que existe um grande número de sistemas de informação que não são apropriados para as necessidades de seus usuários. De fato, o nível de aceitação para sistemas de informação comercial é da ordem de 40%, enquanto para sistemas de tempo real, o índice de aceitação sobe para 75%. Muitas vezes, o motivo de tal insucesso é devido ao fato de que os requisitos não foram bem definidos e/ou entendidos.

Do ponto de vista jurídico, desejamos que o documento de requisitos funcione como um acordo contratual entre os clientes e fornecedores de software. Portanto, é necessário que existam técnicas apropriadas para especificação de sistemas. A equipe responsável pelo desenvolvimento de software deve ter a obrigação de inquirir sobre os requisitos dos seus clientes, visando a uma melhor compreensão do sistema a ser desenvolvido. Assim, é necessário um melhor conhecimento das técnicas de aquisição de requisitos. Os desenvolvedores de software também devem se obrigados a informar seus usuários sobre a solução proposta, não bastando apenas um manual de usuários. Uma forma razoável para apresentar o sistema seria através da definição apropriada dos requisitos do sistema.

Estudos realizados mostram que, cerca de 40% dos erros cometidos, ocorrem na etapa de especificação de requisitos do sistema (vide Figura 5.1). Como esses erros são os mais caros de consertar, a correção de problemas oriundos da etapa de especificação atinge um patamar de 66% do custo total de correção de erros do projeto.

Muitos estudos têm mostrado que, quanto mais tarde for detectada uma decisão errada, mais caro será corrigi-la [Boehm1989]. Por exemplo, a correção de um erro de especificação é cerca de cinco vezes mais cara do que uma correção de um erro de codificação.

A engenharia de requisitos força os clientes a considerarem os seus requisitos cuidadosamente e revisá-los no contexto do problema. O objetivo desse processo é alcançar uma especificação completa do sistema de software. São feitas anotações e refinamentos dos requisitos, aumentando a transparência do sistema de software e melhorando a comunicação entre clientes e desenvolvedores. Um projeto só será bem

sucedido se houver um consenso entre as partes envolvidas (clientes e desenvolvedores), que é representado pela especificação de requisitos. A especificação de requisitos funciona como um padrão contra o qual o projeto e a implementação pode ter sua completude e corretude testadas. As atividades da engenharia de requisitos servem também como importante ponto inicial para as subseqüentes atividades de controle e gerência, tais como: estimativa de custo, tempo e recursos necessários.

Características Específicas da Engenharia de Requisitos

Os perfis do engenheiro de software e do engenheiro de requisitos são bastante distintos. O engenheiro de software é movido por tecnologia, usa uma abordagem transformacional (isto é, procura transformar uma especificação em código) e se preocupa em provar suas transformações (pelo menos num futuro próximo).

Já o engenheiro de requisitos se interessa tanto pelo sistema a ser construído, quanto pelo ambiente no qual ele irá funcionar. Ele precisa modelar os conhecimentos, ou seja, representar os conhecimentos adquiridos, através de uma notação adequada. Não existe a possibilidade de se provar formalmente que os requisitos modelados são, de fato, aqueles que o cliente apresentou. O processo é caracterizado por interações humanas que envolvem comunicação, aprendizagem e negociação (vide Figura 5.2).

Figura 5.2: Engenheiro de Requisitos X Engenheiro de Software

As tarefas do engenheiro de requisitos podem ser divididas em quatro grandes etapas [Pressman2001]:

Reconhecimento do problema; Avaliação e síntese; Especificação; Validação.

A etapa de reconhecimento do problema visa entender os elementos básicos, de acordo com a percepção do cliente/usuário. O engenheiro de requisitos precisa estabelecer contato com a equipe técnica e gerencial da organização do cliente/usuário e da organização responsável pelo desenvolvimento do software. O gerente de projeto poderá atuar como coordenador, para facilitar o estabelecimento de caminhos de comunicação.

Durante a etapa de avaliação e síntese de solução, o engenheiro de requisitos deve avaliar o fluxo e estrutura de informações, refinar as funções do software em detalhe, estabelecer características da interface com o usuário e descobrir limitações que afetam o projeto. O resultado dessa etapa é a síntese de uma solução para o problema.

As tarefas associadas com a especificação de requisitos existem para prover uma representação do software que possa ser revisada e aprovada pelo usuário. A descrição inclui informações básicas de funcionalidade, performance e interface. Os critérios de

Cliente

Analista (Eng)

RequisitosEngenheiro de Software

validação são descritos visando facilitar a tarefa de determinar se uma implementação é bem sucedida, ou seja, se atende aos requisitos especificados.

Esses critérios servirão como base para os testes durante o desenvolvimento do software. No caso onde não é possível elaborar um protótipo, poderá ser produzido um Manual Preliminar do Usuário.

Freqüentemente, questionam-se quais as características necessárias para um engenheiro de requisitos. São várias as tarefas realizadas, exigindo diferentes capacidades:

Habilidade de lidar com conceitos abstratos, reorganizando-os em divisões lógicas e sintetizando as soluções de acordo com cada divisão;

Habilidade de absorver fatos pertinentes a partir de fontes conflitantes e confusas;

Habilidade de entender o ambiente do usuário/cliente; Habilidade de lidar com problemas complexos; Habilidade de aplicar elementos de software/hardware ao ambiente do

usuário/cliente; Habilidade de comunicar-se bem, tanto de forma escrita, como oral; Habilidade de evitar detalhes desnecessários, concentrando-se nos objetivos

gerais do software.

A atividade de engenharia de requisitos requer uma intensa atividade de comunicação. Durante a comunicação, problemas de omissão e má interpretação podem causar dificuldades entre o engenheiro e o cliente/usuário. Freqüentemente, informações obtidas de usuários entram em conflito com requisitos descritos anteriormente por outras pessoas. Nesses casos, é preciso negociar uma solução para o impasse. A qualidade da negociação depende de um bom entendimento e de uma análise rigorosa. Porém, essa atividade não é trivial, pois os indivíduos sabem bem mais do assunto do que são capazes de informar (o chamado de conhecimento tácito) e nem sempre desejam, necessariamente, um sistema baseado em computadores.

Grandes sistemas de software possuem, usualmente, uma clientela bastante heterogênea. Diferentes clientes desfrutam de variadas prioridades. Diferentes requisitos possuem diversos graus de importância. Dificilmente, quem encomenda o sistema (o cliente, responsável pelo pagamento) será o usuário (principal) do software.

É comum a imposição de requisitos que são devidos à questão organizacional ou limitações financeiras da empresa. Essas solicitações podem entrar em conflito com os requisitos dos usuários. Portanto, as visões parciais dos clientes muitas vezes não são consistentes entre si.

A evolução dos sistemas é um outro aspecto de suma importância. Sabemos que, independentemente da etapa de desenvolvimento de um sistema, ocorrerão mudanças nos requisitos. Portanto, devemos abordar a questão da coordenação das mudanças dos requisitos, seu impacto em outras partes do software e como corrigir erros de especificação, de forma que efeitos colaterais sejam evitados (ou minimizados). Muitas vezes, as mudanças são realizadas apenas no código, causando uma divergência entre o sistema de software implementado e sua especificação de requisitos. Assim, entre as metas da engenharia de requisitos estão:

Propor técnicas de comunicação que visem facilitar a aquisição de informações; Desenvolver técnicas e ferramentas que resultem em especificações de

requisitos adequadas e precisas; Considerar alternativas na especificação de requisitos.

A produção de uma boa especificação de requisitos não é uma tarefa fácil, tendo em vista os problemas já expostos. A seguir, são enumeradas as propriedades que uma especificação apropriada deve satisfazer [Stokes1994]:

Não ambigüidade: todas as especificações devem, idealmente, ter uma única

interpretação. Essa é uma propriedade difícil de ser alcançada, até mesmo através da aplicação de métodos formais;

Completude: uma especificação de requisitos deve descrever cada aspecto significante e relevante do sistema e deve incluir detalhes a respeito de todas as informações. A natureza subjetiva da definição de completude faz com que essa propriedade seja impossível de ser garantida;

Consistência: não devem existir requisitos contraditórios na especificação; Verificabilidade: quando o sistema for projetado e implementado, deverá ser possível verificar se seu projeto e implementação satisfazem os requisitos

originais; Validação: o usuário/cliente deve ser capaz de ler e entender a especificação de

requisitos e, então, indicar se os requisitos refletem as suas idéias; Modificação: como os requisitos estão freqüentemente sujeitos a mudanças,

todas as especificações de requisitos devem permitir que alterações sejam feitas facilmente, sem a necessidade de que tais modificações sejam realizadas em toda a especificação. Isso exige, geralmente, que alguma estruturação seja imposta na especificação;

Compreensão: clientes, usuários, analistas, projetistas e engenheiros devem ser capazes de entender os requisitos. Como eles possuem formações diferentes, podem preferir utilizar distintas representações para os requisitos;

Rastreamento: devem ser feitas referências entre os requisitos, aspectos de projeto e implementação. Dessa forma, efeitos das modificações nos requisitos, projeto e implementação serão controlados.

Requisitos Funcionais e Não-Funcionais

Uma forma de melhorar a compreensão dos requisitos é dividi-los em requisitos funcionais e não-funcionais. Embora as suas fronteiras nem sempre sejam precisas de se determinar, essa divisão tem sido bastante usada na literatura.

Os Requisitos Funcionais definem as funções que o sistema ou componentes do sistema devem executar. Eles descrevem as transformações do sistema ou de seus componentes que transformam entradas em saídas.

Os Requisitos Não-Funcionais, também referidos com requisitos de qualidades, incluem tanto limitações no produto (performance, interface de usuários, confiabilidade, segurança, interoperabilidade), como limitações no processo de desenvolvimento (custos e tempo, metodologias a serem adotadas no desenvolvimento, componentes a serem reutilizados, padrões a serem aderidos etc.).

O Processo de Engenharia de Requisitos

Esta seção apresenta brevemente as atividades do processo da engenharia de requisitos, mostrando as relações existentes entre elas. Para nossos propósitos, o processo será dividido nas seguintes atividades: elicitação de requisitos, modelagem de requisitos, análise de requisitos e validação de requisitos.

As atividades de elicitação e validação de requisitos correspondem à etapa de aquisição de requisitos, enquanto as atividades de modelagem e análise de requisitos correspondem à etapa de especificação de requisitos (vide Figura 5.3).

Figura 5.3: Processo de engenharia de requisitos Elicitação

Na atividade de elicitação, o engenheiro de requisitos procura capturar os requisitos do sistema, buscando também obter um conhecimento do domínio do problema. Usualmente, são feitas entrevistas com o cliente e/ou é consultado material existente descrevendo objetivos e desejos da organização. Também se observam sistemas similares. É importante observar que o uso apenas de entrevista não é suficiente para obter todas as informações necessárias. O engenheiro de requisitos precisa se envolver com o trabalho do cliente, se misturar com os funcionários, observar, aprender e questionar.

Um dos objetivos da etapa de elicitação deve ser o entendimento da razão pela qual os procedimentos atuais do cliente são feitos da forma que são. Trata-se, portanto, de uma atividade de aprendizagem:

Do comportamento de sistemas existentes, incluindo:• Procedimentos manuais;• Engenharia reversa de softwares existentes;• Interfaces.

Do conhecimento do domínio de aplicação, ou seja, da parte específica do domínio que está relacionada com o sistema de software a ser implementado;

Dos objetivos e limitações dos usuários, incluindo:• Limitações funcionais;• Limitações organizacionais.

ModelagemOs resultados da etapa de elicitação são documentados em forma de modelos conceituais, que descrevem, estática e dinamicamente, aspectos do problema e do domínio de aplicação. O modelo conceitual seleciona propriedades do domínio de aplicação que são de interesse do cliente, mas ignora detalhes e relações que podem ser importantes para outros propósitos. Nesse trabalho, o interesse maior é na parte de modelagem e de análise.

AnáliseDurante a atividade de análise, o objetivo é a obtenção de uma especificação que seja consistente e completa. Pelas razões expostas acima, é muito provável que a descrição obtida até então possua várias inconsistências. O engenheiro de requisitos, durante a análise, deve ser capaz de detectar e resolver inconsistências. A análise é intercalada

Análise

Modelagem

Validação

Elicitação

Aquisição Especificação

com a elicitação, pois problemas podem ser descobertos quando os requisitos são elicitados.

A especificação pode estar incompleta, com muitas implicações que precisam ser explicitadas. Um grande esforço deve ser empreendido para completar a especificação de requisitos, embora saibamos que tal tarefa é praticamente impossível. É bastante comum a existência de omissões no que diz respeito a condições de erro ou exceções. Porém, principalmente em aplicações que são do tipo crítico/segurança (controle de tráfego aéreo, reatores nucleares etc.), um esforço deve ser feito no sentido de definir o comportamento do sistema em situações não desejadas. Trabalhos recentes [Gotel1994] mostram a importância de acompanhar (rastrear) os requisitos, desde a sua concepção, passando por sua especificação, até a sua implementação. Isso se torna bastante importante, por exemplo, quando da necessidade de gerenciar/modificar o sistema.

ValidaçãoQuando validamos uma especificação estamos garantindo que ela, de fato, retrata as necessidades do cliente. Se a validação não for adequada, mal entendidos e erros serão propagados para as etapas de projeto e implementação, ocasionando, como foi visto anteriormente, um alto custo da correção.

Geralmente, um nível aceitável de validação é obtido através do teste de aceitação, que é uma técnica de confirmação que garante que a especificação de software está de acordo com um critério pré-estabelecido pelo cliente.

Quando uma especificação de requisitos é executável (um protótipo), o trabalho de validação é bastante facilitado, pois os usuários podem experimentar com partes da especificação, dando imediatamente suas impressões sobre o sistema. Dessa forma, os próprios usuários contribuem para que o software seja adequado às suas necessidades, reduzindo custos e colaborando para que os prazos sejam cumpridos.

Modelos Conceituais e Linguagens para a Engenharia de Requisitos

Idealmente, dever-se-ia usar linguagens que possuíssem uma única interpretação com o mundo real, ou seja, que cada parte da linguagem (ex. palavra) tivesse um único significado no mundo real. Se isso fosse sempre possível, o engenheiro de requisitos seria capaz de fazer descrições que fossem “não ambíguas” e que pudessem ser corretamente entendidas por usuários/clientes e engenheiros/projetistas (vide Figura 5.4). Nessa seção, serão discutidas as principais abordagens de linguagens para representação de requisitos, isto é, linguagens naturais, linguagens rigorosas e linguagens formais.

Figura 5.4: Linguagens para especificação de requisitos

Linguagens Naturais.

Analista de Cliente

Queria uma programa...

Que

Então o Senhor quer, um Sistema

Obviamente, a linguagem natural é a que oferece maior grau de compreensão de acesso para o início de uma descrição [Ford1994]. No nosso caso, o Português poderia ser adotado. O uso de linguagem natural é bastante atrativo pois:

Usa o conhecimento já existente da linguagem pelo engenheiro de requisitos; Permite que as idéias sejam comunicadas de um modo que seja entendida pelo

público em geral; Possui a vantagem de não fazer nenhuma tentativa de prescrever um método

para implementação.

Infelizmente, há muitos problemas com as linguagens naturais [Ryam1993]. Inicialmente, os textos tendem a ser desestruturados. As pessoas tendem a escrever de uma forma desorganizada. Somente após muito treino é que um escritor se habitua a estruturar suas descrições e observações. Também, na prática, a linguagem natural torna-se ambígua, dando margem a interpretações diferentes, dependendo dos diferentes tipos de pessoas e suas experiências. Torna-se inviável determinar se a especificação está completa.

De fato, é muito difícil usar linguagens naturais na especificação de requisitos sem deixar nenhuma ambigüidade ou má interpretação para leitores com diferentes experiências. A origem do problema está no uso de palavras e estruturas que sejam interpretadas de formas diferentes pelo leitor. Uma determinada característica do sistema em desenvolvimento pode ser tão óbvia que ninguém terá a preocupação de escrevê-la, pois a necessidade dela é perfeitamente entendida por todos os membros da equipe.

Como conseqüência, essa característica pode nunca ser incluída na especificação e, portanto, não ser implementada. Muitas vezes, é feita uma superespecificação, abordando detalhes que na realidade são de projeto ou implementação.Especificações em linguagem natural podem apresentar redundâncias e contradições difíceis de detectar.

Na prática, existem sugestões que a linguagem natural seja usada de uma forma estruturada, muitas vezes refraseando especificações para uma linguagem baseada numa linguagem de programação de alto-nível. Pelo menos na teoria, o uso dessas linguagens pode ser eficiente para remover ambigüidades e más interpretações dos requisitos do sistema. A maior desvantagem dessa técnica é a dificuldade do engenheiro de requisitos de se expressar de forma independente do paradigma de implementação. Logo, há um risco maior da especificação ser escrita mais em termos de “como ela será implementada”, do que em termos do “que deve ser entregue”.

Linguagens Rigorosas

Desde a década de 1970, tem sido desenvolvido um grande número de técnicas, métodos e ferramentas que ajudam na produção de requisitos. As descrições dos requisitos passaram a ter uma sintaxe mais formal, muitas vezes usando gráficos, acompanhados de informações textuais. Apesar de parte da especificação ainda ser informal, as linguagens passaram a possuir uma limitada interpretação formal. Isso tem permitido encontrar contradições e incompletudes básicas de uma forma mais sistemática.

A linguagem UML [Booch1998] é um exemplo de uma notação que se enquadra nessa categoria. Nessa linguagem, os requisitos funcionais são expressos através de diagramas de casos de uso, os quais possuem uma sintaxe precisa. No entanto, a especificação mais detalhada dos casos de uso e a especificação dos requisitos não-funcionais ainda continuam a serem feitas usando-se uma linguagem natural.

Linguagens FormaisAs técnicas de especificação formal são baseadas em notações matemáticas, que possuem regras de interpretação não-ambíguas. Por intermédio de um sistema de inferência, é possível deduzir (provar) propriedades do sistema. Muitas vezes, essas

técnicas são acompanhadas por uma metodologia que facilita tanto a especificação, como a verificação formal.

As vantagens do uso de técnicas formais são: clareza, não-ambigüidade, independência de implementação e completude da especificação. Os métodos formais existentes não são muitos atrativos, exatamente pela necessidade de se ter uma certa base matemática para se usufruir totalmente da técnica, pois essa habilidade não é encontrada na maioria dos usuários. Contudo, experiências recentes sugerem que, motivados a escrever um software de alta-qualidade (talvez por ser um software crítico), o desafio de usar um método formal é algo a ser considerado, mesmo para aqueles que não têm maiores inclinações matemáticas. Uma vantagem adicional é a possibilidade de se obter especificações que sejam executáveis, permitindo que um protótipo do sistema seja produzido rapidamente.Existem limitações nas linguagens formais, decorrentes do sistema matemático usado. Muitas vezes, o formalismo escolhido pode não ser apropriado para modelar todas as propriedades do sistema. Por exemplo, as questões do tempo e de concorrência exigem uma base matemática apropriada. Dentre as linguagens de especificação formal, Z [Spivey1989] tem sido uma das mais usadas.

Considerações

Durante a última década, as pesquisas têm se concentrado em como descreveros requisitos de grandes sistemas feitos sob encomenda. Atualmente, verifica-se a existência de um mercado de distribuição para as massas. Estes softwares orientados para massa raramente usam especificação de requisitos, pelo menos do tipo tradicional. Eles se baseiam em pesquisas de mercado, grupos de interesse e feedback de usuários que fizeram testes em versões preliminares do software. Portanto, a engenharia de requisitos precisa se adequar a essa nova realidade. Entre os vários problemas que precisam ser mais bem estudados, estão os desafios organizacionais e gerenciais. As equipes de gerenciamento, geralmente, não têm consciência do papel estratégico da engenharia de requisitos [Lubars1993]. O envolvimento e o comprometimento da gerência na E.R. são, freqüentemente, muito O Processo de baixos. Isso implica que os trabalhos de E.R. normalmente não estão relacionados com as visões de negócios e objetivos, processos de reengenharia de negócios e outras mudanças organizacionais. As organizações tendem a não “aprender” com as experiências anteriores de E.R. As especificações de requisitos não são usadas como fonte de conhecimento para futuros projetos de engenharia de requisitos.

Existe uma tendência das empresas, que antes desenvolviam software, de terceirizar sua produção. Como conseqüência, será necessário que os usuários de software melhorem suas práticas de engenharia de requisitos. Eles terão de ser mais exigentes para conseguir o que querem. No desenvolvimento tradicional de requisitos, o desenvolvedor de software é o provável executor de muitas das atividades de engenharia de requisitos descritas anteriormente. Contudo, com a terceirização, os próprios clientes/usuários deverão ser especialistas em requisitos. Finalmente, é necessário elaborar novas formas de participação de usuários na engenharia de requisitos, pois ainda existem problemas de comunicação entre desenvolvedores e clientes, ocasionando um baixo nível de validação dos requisitos.

Os usuários acreditam que os desenvolvedores conhecem seus “requisitos tácitos” e que “validam” as especificações de requisitos sem entenderem completamente suas implicações.

ANÁLISE DO PROJETO DE SOFTWARE

Nesta etapa, os requisitos do sistema são particionados em nível de subsistemas de hardware ou software, a fim de que a estrutura interna (arquitetura) seja descrita. Na prática, existe um forte relacionamento entre a etapa de projeto e a especificação do sistema, pois o projetista interage entre o projeto e a especificação, de modo que, ao final desse processo, cada uma das partes componentes do sistema (sub-sistemas)

tenham sido especificadas. Por esse motivo, a especificação do software é, muitas vezes, vista como a primeira etapa do projeto do sistema.

Na etapa de projeto, mais e mais detalhes são adicionados à especificação do sistema, de modo a definir os algoritmos e as estruturas de dados concretos a serem usados. Assim, pode-se dizer que a etapa de definição e análise de requisitos determina o que o sistema deve fazer e a etapa de projeto determina como a funcionalidade do sistema deve ser implementada. Os dois principais enfoques para o projeto de sistemas são: o “top-down” e o “bottom-up”.

No enfoque “top-down”, um sistema é recursivamente decomposto em subsistemas (geralmente chamados de módulos) até que sub-sistemas “tratáveis” (facilmente implementáveis) sejam identificados. A estrutura geral que resulta desse processo de decomposição é uma hierarquia em forma de árvore, na qual o sistema é a raiz da árvore e os sub-sistemas são seus nós. Essa hierarquia pode se degenerar em um grafo, à medida que as possibilidades de reuso dos sub-sistemas são identificadas. Esse enfoque é mais utilizado para o desenvolvimento de sistemas seguindo o paradigma imperativo, no qual o estado de um sistema é centralizado e compartilhado entre as funções que operam sobre este estado. Nesse caso, as folhas da árvore correspondem às funções a serem implementadas.

No enfoque “bottom-up”, o sistema é visto como uma coleção de buildingblocks”. Este enfoque é mais utilizado para o desenvolvimento de sistemas seguindo o paradigma orientado a objetos, no qual o estado de um sistema é descentralizado entre os objetos que compõem o sistema, ou seja, cada objeto manipula seu próprio estado. Objetos são membros de classes e têm um conjunto de atributos, os quais definem seus estados e operações que agem sobre os atributos. Ou seja, classes definem atributos e operações relacionados a objetos membros. Cada classe pode herdar o comportamento (atributos e operações) de superclasses e, dessa forma, é possível definir subclasses.

Assim como na etapa de especificação e análise de requisitos, métodos estruturados também são usados na etapa de projeto. Nesse caso, esses métodos possibilitam a descrição da arquitetura dos sistemas através de diagramas. Um método estruturado é composto por uma notação diagramática e um conjunto de diretrizes de como utilizar a notação. Atualmente, a notação UML [Booch1998] tem sido bastante utilizada na etapa de projeto. No entanto, esta notação não corresponde realmente a um método, pois pode ser usada segundo várias diretrizes existentes (ou metodologias), tais como RUP [Kruchten1998] e Catalysis [D’Souza2001]. A seguir descreveremos parte desta metodologia.

IMPLEMENTAÇÃO

Durante essa etapa, o projeto do software é implementado como um conjunto de unidades de uma linguagem de programação (ex: programas ou classes). Essa etapa baseia-se totalmente na disponibilidade de ferramentas e/ou ambientes de apoio à programação (ex: compiladores, depuradores de código e editores sintáticos). O paradigma da linguagem de programação utilizada nessa etapa está diretamente relacionado ao paradigma utilizado no projeto do sistema. Assim, ao se fazer um projeto orientado a objetos, por exemplo, é recomendado implementá-lo em uma linguagem que siga o mesmo paradigma. Independentemente do paradigma utilizado na implementação do software, a qualidade do código produzido pode ser julgada com base em alguns atributos:

Qualidade de sua documentação;Uso de um padrão de codificação;Legibilidade;Nível de complexidade;Tamanho;Tempo de execução.

A utilização de padrões de documentação ajuda na obtenção da qualidade do código. Esses padrões vão desde a definição do ambiente de programação até de comentários no próprio código.

Há vários outros atributos para tal julgamento. Alguns desses atributos podem ser avaliados através de atividades de revisão e inspeção, descritas no segundo módulo deste curso, outros podem ser avaliados através da etapa de testes, tratada na próxima seção.

TESTES DE SOFTWARE -

Existe grande possibilidade de injeção de falhas no processo de desenvolvimento de software. Assim, os custos associados às falhas de software justificam uma atividade de teste cuidadosa e bem planejada, como parte dos esforços, no sentido de garantir a qualidade do software.

IntroduçãoOs testes representam a última oportunidade de detectar erros antes de o software ser entregue aos usuários. A atividade de testes pode ser feita de forma manual e/ou automática e tem por objetivos:

Produzir casos de teste que tenham elevadas probabilidades de revelar um erro ainda não descoberto, com uma quantidade mínima de tempo e esforço;

Comparar o resultado dos testes com os resultados esperados, a fim de produzir uma indicação da qualidade e da confiabilidade do software. Quando há diferenças, inicia-se um processo de depuração para descobrir a causa.

A realização de testes não consegue mostrar ou provar que um software ou programa está correto. O máximo que os testes de um software conseguem provar é que ele contém defeitos ou erros. Quando os testes realizados com um determinado software não encontram erros, haverá sempre duas possibilidades:

A qualidade do software é aceitável; Os testes foram inadequados.

Estágios de TesteExistem diferentes estágios de teste associados ao desenvolvimento de um produto de software:

Teste de unidade: visa testar individualmente cada um dos componentes (programas ou módulos), procurando garantir que funcionem adequadamente;

Teste de integração: visa testar o relacionamento entre as diversas unidades integradas. Em outras palavras, garantir que a interface entre os módulos funcione adequadamente, pois não há garantias de que unidades testadas em separado funcionarão em conjunto;

Teste de sistema: conjunto de testes cujo objetivo primordial é colocar completamente à prova todo o sistema, baseado em um computador. Em outras palavras, testa a integração do software com o ambiente operacional - hardware, pessoas e dados reais;

Teste de aceitação (homologação): são testes realizados pelo cliente/usuário com o objetivo de validar o sistema a ser implantado. A motivação maior para esses testes é o fato do desenvolvedor nunca conseguir prever como o usuário realmente usará um software numa situação real. Os testes de aceitação podem ser de dois tipos:

• Testes alfa: são feitos por um determinado cliente, geralmente nas instalações do desenvolvedor, que observa e registra os erros e/ou problemas;

• Testes beta: são realizados por possíveis clientes, em suas próprias instalações, sem a supervisão do desenvolvedor. Cada cliente relata os problemas encontrados ao desenvolvedor, posteriormente.

Abordagens de TesteExistem basicamente duas abordagens que podem ser aplicadas aos diferentes tipos de teste:

Abordagem funcional (caixa-preta): concentra-se nas interfaces do software e visa mostrar que: as entradas são aceitas; as saídas são as esperadas; a integridade dos dados é mantida. Aplica-se, principalmente, aos testes de validação, sistemas e aceitação, mas pode ser também usada com os testes unitários;

Abordagem estrutural (caixa-branca): visa mostrar que os componentes internos do software (programas) realmente funcionam. Em princípio, os testes de caixa branca pretendem garantir que todas as estruturas dos programas e todos os possíveis casos sejam testados. Aplica-se, principalmente, aos testes unitários e de integração. Na prática, mesmo para pequenos programas, é geralmente impossível testar todas as possibilidades.

Tipos de Teste

Existem vários tipos de teste que podem ser executados nos diversos estágios de teste e utilizando as diferentes abordagens existentes:

Teste de funcionalidade: testa a funcionalidade geral do sistema, em termos de regras de negócio (fluxo de trabalho), considerando-se tanto as condições válidas como as inválidas; Teste de recuperação de falhas: seu objetivo é forçar o software a falhar de diversas maneiras e verificar se a recuperação é adequada;

Teste de segurança de acesso: tenta certificar-se de que todos os mecanismos de proteção embutidos no software, de fato, o protegerão dos acessos indevidos;

Teste de carga: tenta confrontar o software ou os programas com situações anormais. Ele executa o software de uma forma que exige recursos em quantidade, freqüência e volume bem maiores do que o uso normal;

Teste de desempenho: são testes que visam verificar o desempenho ou performance do software. São, muitas vezes, combinados ou feitos juntamente com os testes de estresse. São comuns em software de tempo real;

Teste de portabilidade: são testes que verificam o grau de portabilidade do produto de software em diferentes ambientes de hardware/software.

A execução de todos esses tipos de testes pode ser feita de forma combinada. Ou seja, nenhum desses testes exclui o outro.

Responsabilidade pelos testes

Os testes, normalmente, são feitos pela equipe de desenvolvimento, i.e., por engenheiros de software. No entanto, é ideal que pelo menos os testes de sistemas sejam feitos por uma equipe de testes independente. É importante que os grandes sistemas e programas também sejam testados por outras pessoas que não os seus desenvolvedores, e que tais pessoas sejam bastantes críticas. Assim, seria possível a seguinte distribuição de responsabilidades:

Equipe de desenvolvimento Testes de unidades;

Testes de integração.

Equipe independente de testes: Testes de sistema.

Usuário: Teste de aceitação.

Ferramentas de Teste

O processo de testes pode ser automatizado, através do uso de ferramentas CASE específicas para essa atividade. Alguns tipos de ferramentas de apoio aos testes são descritos a seguir:

Ferramenta de geração de massa de dados: gera dados para serem usados em testes. A geração dos dados é freqüentemente baseada em regras de formação definidas pelos casos de teste;

Ferramenta de teste de API: testa método a método de uma classe, a partir de uma série de combinações de parâmetros. Utiliza a abordagem caixa-preta para cada método;

Ferramenta de teste de GUI: grava (em um script) a execução da interface gráfica (cliques do mouse e entradas de teclado) e repete a entrada quantas vezes forem necessárias. O script gerado pode ser modificado através do uso de uma linguagem própria de script;

Ferramenta de teste de cobertura: após a execução da aplicação, indica quais os trechos do código foram ou não executados, bem como o número de vezes que determinado método/trecho foi executado. Utiliza a abordagem caixa branca;

Ferramenta de teste de carga e stress: simula acessos simultâneos a uma aplicação multi-usuário, bem como o envio e recuperação de altos volumes de dados;

Ferramenta de teste de desempenho/gargalos: analisa o desempenho do software, quando em execução, e detecta potenciais pontos de gargalo no código fonte.

GERÊNCIA DE CONFIGURAÇÃO e MUDANÇÃS

O desenvolvimento de software é uma atividade que precisa ser executada em equipe, principalmente para os softwares de grande porte. Freqüentemente, artefatos (ex: documentos, programas etc.) precisam ser acessados e alterados por várias pessoas da equipe e, nesse caso, a modularização do projeto normalmente não é suficiente para resolver esse problema.

A Gerência de Configuração controla as mudanças e mantém a integridade dos artefatos de um projeto. As principais atividades envolvidas com essa etapa do ciclo de vida são:

Identificação de itens de configuração (componentes individuais do software – ex: arquivos com programas fonte);

Restrição às modificações nesses itens (controle de acesso);

Criação de versões dos itens modificados;

Auditoria nos itens de configuração (para determinar por que, quando e por quem um artefato foi modificado);

Retorno a uma versão anterior de um artefato.

Estas atividades, geralmente, são apoiadas por ferramentas de controle de versões e mudanças. Essas ferramentas permitem tornar o processo de desenvolvimento mais

produtivo, uma vez que a gerência de configuração é aplicada a todos os artefatos produzidos em todas as etapas do ciclo de vida. Para garantir que todas as atividades desta etapa sejam executadas de maneira satisfatória, recomenda- se que seja produzido um Plano de Gerência de Configuração, o qual irá determinar quando, por quem e com que ferramentas as atividades dessa etapa serão executadas.

OPERAÇÃO E MANUTENÇÃO DE SOFTWARE

Nessa etapa, o sistema é posto em uso (operação). Erros e omissões nos requisitos originais, nos programas e no projeto são descobertos. A necessidade de novas funcionalidades e melhorias é identificada. Consequentemente, modificações serão necessárias para que o software continue sendo usado. Essas modificações são chamadas: manutenção do software.

A Manutenção pode envolver mudanças nos requisitos, no projeto e/ou na implementação. Consequentemente, podem ser necessários novos testes. Assim sendo, todo o processo de desenvolvimento (ou parte dele) pode ser repetido quando são feitas modificações.

As manutenções podem ser classificadas em:

Corretivas; Adaptativas; Perfectivas; Preventivas.

A manutenção é dita corretiva quando é feita para corrigir os erros não identificados durante o desenvolvimento e testes do sistema. Esse tipo de manutenção existe porque os testes de software dificilmente conseguem detectar todos os erros.

A manutenção é dita adaptativa quando alterações se tornam necessárias por conta de mudanças no ambiente computacional. Essas manutenções são necessárias porque a vida útil dos aplicativos é longa e não acompanha a rápida evolução da computação.

A manutenção é dita perfectiva quando alterações visam melhorar o software ealguma forma. Geralmente, é o resultado de recomendações de novas capacidades, bem como modificações em funções existentes solicitadas pelos usuários.

A manutenção é dita preventiva quando modificações são feitas com o objetivo de melhorar o software no que se refere à sua confiabilidade ou manutenibilidade, ou para oferecer uma base melhor para futuras ampliações.

Independentemente do tipo de manutenção, existe a certeza de que essa atividade irá ocorrer no desenvolvimento de um software. Sendo assim, o processo de software utilizado por uma organização, bem como as pessoas envolvidas nessa atividade devem estar preparadas para desempenhá-la da forma mais produtiva possível, de maneira a atender rapidamente às necessidades dos clientes

FERRAMENTAS CASE

Como qualquer outra engenharia, a Engenharia de Software envolve trabalho criativo e também uma grande quantidade de trabalho tedioso de administração e de controle. A execução das atividades não criativas pode, na maioria das vezes, ser automatizada através do uso de ferramentas CASE. O suporte automatizado ao processo de desenvolvimento de software é uma “arma” fundamental para aumentar a produtividade na execução das atividades e garantir a qualidade de um produto de software.

Uma ferramenta CASE oferece um conjunto de serviços fortemente relacionados para apoiar uma ou mais atividades do processo de software. Esses serviços vão, desde a simples edição de textos, até o gerenciamento de configurações, o teste de software e a verificação formal de programas.

As ferramentas CASE são, geralmente, projetadas para funcionar individualmente, com objetivo específico. Por exemplo, apoiar um método de análise orientada a objetos ou a programação em uma linguagem específica. Essas ferramentas, usualmente, possuem repositórios de dados mais sofisticados que simples arquivos, podendo incluir dicionários de dados ou até mesmo utilizar um gerenciador de banco de dados comercial para armazenar seus dados. No entanto, existem conjuntos de ferramentas que trabalham integradas e que são, geralmente, conhecidos como Tool suites ou Ambientes CASE. Esses ambientes podem ser de propósito específico (ex: conjunto de ferramentas que dão apoio a uma única etapa do ciclo de vida de software) ou de propósito genérico (ex: conjunto de ferramentas que dão apoio a diversas atividades do ciclo de vida).

Vale salientar que, para se extrair todos os benefícios do uso de ferramentas CASE, é necessário que as ferramentas selecionadas se adeqüem ao processo de desenvolvimento de software da organização. Assim, é primordial que tal processo esteja bem definido e institucionalizado, para que as ferramentas adequadas sejam selecionadas.

Escopo do Projeto -EAPe Kanban

Escopo. “O planejamento do escopo é o processo de elaborar e documentar progressivamente o trabalho do projeto produzindo o produto do projeto”

Escopo, em Gerenciamento de Projetos, é a soma total de todos os produtos do projeto e seus

Requisitos ou Características, e possui dois usos distintos: Escopo do Projeto e Escopo do Produto.

Escopo do projeto é "o trabalho que precisa ser realizado para entregar um produto, serviço

ou resultado com as características e funções especificadas."1

Escopo do produto são "as características e funções que caracterizam o produto, serviço ou

resultado."2

É importante observar que o Escopo do Projeto está mais orientado ao esforço (os como)

enquanto o Escopo do Produto é mais orientado para os requisitos funcionais (os o quês).

Se os Requisitos não forem completamente definidos e descritos e se não houver o Controle de mudanças efetivo em um projeto, pode-se resultar no aumento do escopo ou da exigência.

Escopo se refere a aquilo que se pretende atingir. É um substantivo masculino, com origem na palavra grega skopos que significa "aquele que vigia, que protege". Escopo é a finalidade, o alvo, ou o intentoque foi estabelecido como meta final.O escopo é o objetivo que se pretende atingir, é sinônimo de fim, propósito ou desígnio. No caso de uma auditoria, o escopo é o objetivo que se pretende alcançar com a Auditoria.

Tipos de Escopo:

Planejamento do escopo: • Desenvolver uma declaração escrita do escopo como base para decisões futuras do projeto

Definição do escopo: • Preparação da declaração detalhada do escopo do projeto

Criar a EAP (estrutura analítica do projeto): • Composição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto

Verificação do escopo: • Formalizar a aprovação do escopo (aceitação formal pelas partes interessadas no projeto)?

Controle de mudanças do escopo: • Controlar as mudanças (garantir que todas as mudanças solicitadas e ações sejam processadas)?

Estrutura Analítica de Projeto (EAP)consiste no desdobramento do Projeto em unidades menores, até chegar aos Pacotes de Trabalho, elementos discretos e mutuamente exclusivos,  o que significa que não deve haver elementos de escopo contidos em mais de um pacote de trabalho.

EAP é um processo para subdividir os trabalhos em um projeto. Dessa forma, os trabalhos tornam-se

componentes menores e mais simples de serem gerenciados. Ela é uma representação hierárquica

das entregas de um projeto. (PMBOK 4ª Edição)

As entregas são qualquer produto, resultado ou capacidade para realizar um serviço único e verificável que

dever ser produzido para concluir um processo, uma fase ou um projeto. (PMBOK 4ª Edição)

Ou seja a EAP – basicamente um processo definidos em Pacotes e Entregas.

A Estrutura Analítica de Trabalho fornece o adequado arcabouço para a estimativa de custo de cada item, bem como possibilita a adequada construção do cronograma.

Outra Forma de Conceituar A EAP (Estrutura Analítica do Projeto) é uma poderosa ferramenta para facilitar o entendimento do Projeto por parte da própria Equipe de Gerenciamento, bem como na comunicação com todos os demais participantes e interessados no Projeto. Ela é definida pelo PMI® como “uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, sendo que cada nível descendente da EAP representa uma definição gradualmente mais detalhada da definição do trabalho do Projeto.“ (PMBOK® Quarta Edição, pg. 116).

Todo o Projeto deve estar contido na EAP - A Estrutura Analítica de Projeto sendo assim todo os trabalhos deve estar descritos nela. O que não estiver na EAP não faz parte do escopo do projeto e portanto não deve ser feito A soma de todas Atividades-filha deve perfazer 100% da Atividade-mãe.

A EAP normalmente é concebida após o Termo de Abertura do projeto, na fase de Planejamento. Pode ser incluída na Declaração de Escopo.

Conceito de Pacote de Trabalho

é um subconjunto de um projeto que pode ser designado para uma parte especifica da execução. Devido a esta semelhança, pacotes de trabalho são frequentemente confundidos com projetos.

Basicamente é a caixinha da Caixinha – do ultimo sub-nivel da EAP – após ela não existe outras caixinhas – ela indica a tarefa, a atividade a ser realizada. Ou as Ações que serão executadas – Geralmente vem indicada por “verbos” que diferentemente das outros itens que no geral vem indicadas por substantivos.

Ex: Pocote de trabalho: “Instalar a portar” que se subdividem em tarefas menores (lixar, serrar, colocar fechadura etc)

Cada pacote de trabalho deve possuir: Um código de identificação único; Uma entrega específica e verificável; Um único responsável pela sua entrega; Duração (de acordo com o ciclo de acompanhamento); Recursos humanos (equipe); Um custo definido em cujo cálculo deve ser considerados recursos alocados; Cada entrega tem um cliente validador, um formato definido e critérios de aceite previamente

acordados com este cliente.

“ item da EAP é qualquer Caixinha que você tem dentro da estrutura do Projeto.

--

-- è importante saber que as tarefas (atividades ou Ações) de cada PACOTE de TRABALHo – estarão explicadas no dicionário da EAP – assim se você tem 100 pacotes de trabalho você terá pelo menos 100 dicionarios ou mais.

A EAP pode ser definida como Uma ferramenta essencial no gerenciamento de projeto para definição do escopo é a Estrutura Análitica de Projetos (EAP).

Função:O objetivo da EAP é decompor o projeto em componentes que possam ser agendados, ter seu custo

estimado, monitorado e controlado (Guia PMBOK® Quarta Edição). Esses componentes são

chamados pacotes de trabalho.

Para que serve uma EAP -Suas principais utilidades são:

Delimitar e elicitar  o Escopo do Projeto;

Facilitar a Identificação das Fases do projeto;

Facilitar a Identificação dos responsáveis;

Orientar a identificação e descrição detalhada das Entregas do projeto;

Identificar as atividades do projeto;

Facilitar a Estimativa de Esforço, Duração e Custo;

Facilitar  a Identificação de Riscos.

Estrutura da EAP.

 Serve para facilitar a organização dos pacotes de trabalho, que serão descritos na fase seguinte (antes do

cronograma) e facilita a “rastreabilidade” de um pacote de trabalho no cronograma.

PODEMOS DESTACAR TRÊS TIPOS BÁSICOS DE EAP –

A EAP pode ser construída de diversas formas conforme o propósito e tipo de projeto. As formas mais comuns

de montagem da EAP são: Por Fases, Por Entregas e Por Equipes. Abaixo são apresentados exemplos de EAPs

em cada uma das formas.

EAP por Entregas

EAP Por Equipes.

EAP por Fases.

EAP por Fases

Organiza fases no primeiro nível e eventualmente no segundo nível também.

Vantagens:

Oferece uma visão “cronológica” dos acontecimentos no projeto;

Facilita o entendimento de pessoas leigas;

Facilita o posterior gerenciamento das atividades.

Desvantagens:

Pode ofuscar a visão das partes necessárias para uma entrega específica;

Tende a incentivar que se incluam atividades administrativas (ex: Controle do projeto)

EAP por Entregas

Mostra as partes necessárias para compor as entregas do projeto.

Vantagens:

Visualiza claramente as partes que compõe o projeto;

Facilita a discussão de soluções técnicas e caminhos alternativos;

Facilita identificação de riscos técnicos;

Desvantagens:

Não oferece visão cronológica

Por Equipes

Visualiza os pacotes de trabalho a partir da divisão de Equipes do Projeto.

Vantagens:

Ótima para ocasiões em que o projeto tem equipes com responsabilidades muito diferentes.

Desvantagens:

Não mostra cronologia nem a organização das partes das entregas.

A EAP é criada como parte dos processos de Planejamento, e é parte integrante da definição do escopo do projeto, seguindo os processos de coleta de requisitos e definição do escopo, conforme podemos ver na figura abaixo:

Elementos mutuamente exclusivos: Não deve haver superposição de atividades. Um item do escopo NÃO pode estar simultaneamente em dois Pacotes de Trabalho.

NÍVEL DE DETALHAMENTO:

Um aspecto importante é quando se deve parar o detalhamento. Não há uma regra definida para isto, mas existem algumas diretrizes, ou, “ruleofthumbs”:

Apenas um recurso deve ser responsável pela atividade (pode haver mais de um executante, porém apenas um responsável); por exemplo, ao analisar “Zona de Radiação do Forno”, esta atividade pode ser subdividida, pois haverá atividades sob a responsabilidade do Encarregado de Solda (tubos da radiação) e outras sob a responsabilidade do Encarregado de Refratários (paredes refratadas). Já “Soldar serpentina de processo” pode ser considerado um Pacote de Trabalho, uma vez que, ainda que sejam diversos soldadores, esta atividade está sob responsabilidade de uma única pessoa, o Encarregado de Solda.

Cada pacote de trabalho não deve exceder 80 Homens-Hora.

A duração de cada pacote de trabalho não deve exceder a periodicidade do acompanhamento. Ou seja, se o nosso acompanhamento é semanal, os pacotes de trabalho não devem exceder uma semana.  Em uma parada de manutenção, onde o acompanhamento é diário (por vezes até por turno) cada pacote de trabalho não deve exceder um dia.

Os pacotes de trabalho devem ser de porte suficiente a que se possa estimar duração, recurso e custos de forma adequada.

E, finalmente, a regra do bom senso: devemos avaliar quando não vale mais a pena subdividir o pacote.

VISÃO DA EAP SEGUNDO O PMBOK,

“Uma conta de controle é um ponto de controle do gerenciamento onde o escopo, custo e cronograma são integrados e comparados ao valor agregado para uma medição de desempenho. Essas contas são localizadas em pontos de gerenciamento selecionados na EAP. Cada uma pode incluir um ou mais pacotes de trabalho, mas cada um deles tem que estar associado a somente uma conta de controle”

Portando, uma conta de controle é um componente da EAP usado para a contabilidade de custos do projeto.

Guarde também que: O último nível de uma EAP é chamado pacote de trabalho. Uma EAP deve ser utilizada em todos os projetos.

Abaixo, exemplo de EAP decomposta até o nível de pacote de trabalho.

Outro Exemplo:

TRIPLA RESTRIÇÃO

Um Paradigma da gestão do projeto que visa a utilização da EAP é para realizar o balanceamento das três vertentes que são a base do projeto e que são necessariamente conflitantes entre-si ESCOPO, TEMPO E CUSTO. Este balanceamento de forma adequada corrobora para a formação de um quarto componente: a QUALIDADE.

É importante ressaltar que as demandas conflitantes podem ser influenciadas (positiviamente ou negativamente) pelo risco.

Como a tripla restrição funciona ?

Ao definir um escopo, a consequência imediata é a definição do custo e do tempo necessário para terminar o projeto. Se o equilíbrio for mantido o projeto é entregue com qualidade. Por outro lado, se o prazo, por exemplo, for reduzido sem aumento do custo ou redução de escopo a qualidade será afetada. De forma geral, a alteração de qualquer componente da tripla restrição afeta os demais.

Na última edição do PMBOK,  "tempo" é chamado de  cronograma e  "custo" de orçamento. Além disso, podemos notar seis restrições: Escopo, Cronograma, Orçamento, Qualidade, Recursos e Risco.  Também existem autores que incluem o atendimento ao cliente como uma restrição. Eu acredito que mais importante para prova é entender que a alteração de uma  demanda conflitante afeta as demais.

ESTRUTURA ANALÍTICA DE PROJETO – ERROS COMUNS A Estrutura Analítica de Projeto NÃO é um cronograma, e nem os pacotes de

trabalho estão dispostos em ordem cronológica

A Estrutura Analítica de Projeto NÃO é um Organograma. Haverá pessoas responsáveis pelos pacotes, mas a colocação destas pessoas não determina subordinação funcional.

Utilização inadequada de componentes na estrutura Analítica de Projeto. Por exemplo, Desenhos não são um pacote de trabalho, são os entregáveis de um pacote de trabalho. Elaborar os documentos de construção da convecção do forno é um pacote de trabalho. Iniciação, Controle, são fases do projeto, não são pacotes de trabalho. Suporte de TI não é um pacote de trabalho.

LINHA DE BASE DO ESCOPO

 A linha de base do escopo éo composta pela declaração de escopo, EAP e o dicionário da EAP aprovados para o projeto.

Esses documentos descrevem em detalhes o trabalho do projeto. � A partir deles, se procede a criação do cronograma, alocação de recursos e o monitoramento e controle do trabalho do projeto.

Dicionário da EAP

É um dos elementos finais da construação da EAP – e também da implementação do escopo e estrutura do projeto, é no dicionário que estão registradas as descrições dos componentes de trabalho.

ESCOPO

TEMPO

QUALIDADE

CUSTO

›  Segundo o PMBOK, esse dicionário pode conter os elementos a seguir para cada um dos elementos da EAP:

Identificação do código de contas;

Descrição do trabalho do componente;

Organização responsável pela conclusão do componente;

Lista do cronograma dos marcos;

Cronogramas das atividades associadas ao cronograma dos marcos;

Recursos necessários;

Estimativas de custo;

Requisitos de qualidade;

Critérios de aceitação;

Referências técnicas;

Informação de contrato.

a) Diretrizes Gerais

São dicas para a elaboração de um EAP em todos os seus níveis, conforme detalhamos abaixo:

Visualize os produtos/serviços finais a serem desenvolvidos pelo projeto, não as atividades envolvidas;

Pense inicialmente nas grandes entregas (primeiro nível da EAP), abstraindo-se um pouco dos elementos que os compõem;

Decomponha gradativamente essas entregas nos seus elementos, mantendo a diretriz inicial (produtos/serviços, não atividades);

Pergunte-se, a cada nível, se os elementos descrevem tudo (completude) e somente (manter o foco) o que o projeto deverá entregar;

Utilize substantivos (não verbos !); Não decomponha demais (3 ou 4 níveis devem ser suficientes para a grande maioria dos projetos); Denomine os elementos de forma simples (evitar frases na EAP – deixe detalhes para o Dicionário da

EAP); Valide com a equipe !

b) Diretrizes para a Decomposição

Englobam as dicas para assegurarmos que a decomposição corresponde ao nível adequado, que é atingido quando respondemos sim a essas questões:

Cada Pacote de Trabalho (último nível da EAP) pode ser estimado com razoável nível de precisão (tempo e custo)?

Há apenas um responsável pelo Pacote de Trabalho ? (Atentar que responsável não é o mesmo que executor)

Há somente uma entrega associada ao Pacote de trabalho? Essa entrega pode ser validada por um único processo de validação ?

EstrategiasBottom-up (de baixo pra cima) X Top-Down (de cima para baixo)

Basicament ao conceito de estrutura de uma EAP – consiste do detalhamento do projeto, onde inicia-se pela sua estrutura nominal, assim o modelo usualmente de definição de uma EAP é o Top-Down, pode a detalhamento vem de cima para baixo, e vem se contruindo ela fase por fase etapa por etapa, atividade por atividade – ate se detalhar ela toda – já o processo Bottom-up funciona na engenharia reversa, o que consiste na adequação do modelo tendo por base o produto, e descrevendo assim suas atividades até chegar nas marco fases, neste modelo avalia-se as Entregas (deliverables) e vai agrupando elas de acordo com seu grupo de processo. Porem pode haver complicações, como repetição, ou mesmo não se tem uma visão geral do proteto no inicio.Decomposição é a subdivisão das entregas do projeto em componentes menores e mais gerenciáveis, até que as entregas do trabaho  estejam definidas no nível de pacotes de trabalho.

KANBAN

O método Kanban surgiu no Japão com o Toyota Production System ou simplesmente TPS [Ohno 1997] para controlar a fabricação de automóveis, é um termo japonês que significa sinal visual, onde o grande foco deste método deste método é evidenciar os problemas existentes no processo. O método Kanban faz a relação entre a demanda e o ritmo de produção, assim quanto maior a demanda maior a velocidade de produção de acordo com as requisiçõtes.

O uso do método Kanban para o gerenciamento de equipes de desenvolvimento de software registrou um aumento a partir de 2007, quando Rick Garber e David J. Anderson publicaram nas conferências “Lean New ProductDevelopment” e “Agile 2007”, os resultados obtidos no uso deste método no desenvolvimento de software. Desde então, o uso deste método vem sendo estudado e experimentado por equipes de desenvolvimento.

Dentro das metodologias para desenvolvimento de software, o Kanban é a menos prescritiva, característica essa que estimula ainda mais as equipes a adotarem esse método. Segundo Kniberg (2009) o Kanban tem apenas três prescrições: (conceitos)

Visualize o fluxo de trabalho atual; -- onde nesta primeira prescrição deve ser observado o trabalho que realmente acontece, e não apenas as atividades e fases que estão apenas prescritas.

Limite o fluxo de trabalho;- o (também chamado de WIP - Work in Progress) – é um dos pontos chaves do método, onde é definido estritamente onde se encaixa cada atividade, e que uma atividade (trabalho) so pode entrar em uma fase quando ela estiver desocupada, ou seja quando a fase que estiver sendo trabalha, sair.

Acompanhe e gerencie o fluxo de trabalho. --- nesta fase onde são definidos as formas e fluxos de trabalho, e é nesta fase onde os problemas evidenciados são retrabalhados, ou adaptados.

Sendo um método pouco prescritivo, Kanban acaba tornando-se muito adaptativo. Com isso as equipes que o adotam precisam estar atentas ao processo aplicado para visualizar locais de melhoria e adaptações para que o processo possa fluir de forma satisfatória

Just in Time A Filosofia “Just in Time”; –Desperdício é qualquer coisa além do mínimo necessário de recursos para se produzir uma unidade de determinado produto.

Desperdícios: Transportes; Tempo de Espera; Inspeção; Estoques.

•O processo posterior deve respeitar o processo anterior

•Qualquer retirada sem um cartão Kanban será proibida(puxar a produção)

•Qualquer produção que seja maior que o númerode Kanbans será proibida – ou seja somente se é produzido o essencial. Nada de desperdício.

Vantagens do Kanban

Simples

Auto-Controlado

Desburocratizante

Motivacional

Limita Estoque

Baseia-se na Demanda real

Atualmente, o Kanban é muitas

vezes usado em conjunto com o Scrum, porque são duas metodologias usadas no desenvolvimento

ágil de software. Outro conceito que por vezes é relacionado com Kanban, Just in Time e Scrum

é Kaizen, que também tem como objetivo aumentar a produtividade.

Como Funciona o KANBAN –

As tarefas ou itens de trabalho foram representadas por meio de cartões (post-its) fixados em um

quadro (cardwall). Esse quadro, por sua vez, era dividido em colunas que representavam as fases

do fluxo de trabalho (workflow) da equipe. As tarefas eram distribuídas sequencialmente nas colunas

à medida que avançavam no fluxo de trabalho. Dentro do quadro sua divisão anteriormente se

dividia em:

TO DO: Tarefas elegíveis para entrarem em execução.

DOING: Tarefas em andamento.

DONE: Tarefas concluídas.

Mas com as reais necessidades do mercado, e sua absorção de seus medos pelas metodologias ágeis, tornou-se necessário implementar esta ferramenta, de maneira o sistema foi alterado para um processo chamad: mapeamento de cadeia de valor (ValueStreamMapping) [Anderson 2010]. Foram identificados os seguintes estados das tarefas:

Próximas: Tarefas elegíveis para entrarem em execução;

Em andamento: Tarefas em andamento;

A implantar: Tarefas concluídas e aptas a serem implantadas no sistema em produção;

Implantadas: Tarefas já implantadas e em uso pelos clientes;

Notificadas: Tarefas concluídas, mas que não precisam ser implantadas, porconta de sua natureza (ajustes no banco de dados, apoio operacional).

Para melhorar a visualização das tarefas no quadro, foi adotada uma classificação estabelecida pela equipe com base nos tipos de solicitações. Essas solicitações foram divididas em categorias ou classes de serviço. Para tornar a divisão das tarefas aparente, cada classe de serviço era representada por um post-it com uma cor específica, assim sendo, tornava-se fácil identificar a proporção de tarefas de um determinado tipo que estavam sendo executadas, bastando para isso observar no quadro a predominância da respectiva cor. As cores escolhidas foram:

Verde: Relatórios ad hoc

Vermelho: Correção de bugs

laranja : Novas funcionalidades

amarelo: Ajustes operacionais

Com relação ao tempo de execução, as tarefas passaram a ser estimadas com base em um padrão de tamanho denominado T-Shirtsizing [Kniberg 2009], onde os tamanhos são atribuídos às tarefas conforme à seguinte regra:

Pequeno (P): Tarefas cuja duração média era inferior ou igual a 1 dia;

Médio (M): Tarefas com duração média superior a um dia e inferior a uma semana;

Grande (G): Tarefas com duração média maior ou igual a uma semana.

De acordo com Kniberg (2009), aumentar o número de atividades em andamentoleva diretamente ao aumento do tempo de espera. Por isso, faz-se necessário medir e controlar o número de cartões em uma coluna (WIP) ao longo do tempo. No entanto, em Kanban não é prescrita nenhuma ferramenta para acompanhar o andamento de uma iteração. Para preencher essa lacuna, lançou-se mão do Diagrama de Fluxo Cumulativo

KANBAN em 10 Passos.

1. Visualizar o Fluxo de trabalho

2. Limitar o trabalho em progresso.

3. Estabelecer politicas explicitas para garantir a qualidade – foco nas etapas com problemas.

4. Ajustar cadências

5. Medir o fluxo

6. Priorização

7. Identificação de classes e serviços

8. Gerenciamento do fluxo

9. Estebelecer SLAS.

10. Melhoria continuada.

Metodologias Ágeis

O termo “Metodologias Ágeis” tornou-se popular em 2001 quando um grupo de dezessete especialistas em processos de desenvolvimento de software decidiu se reunir nos EUA, para discutir maneiras de melhorar o desempenho de seus projetos.

Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, utilizando métodos como Scrum, Extreme Programming (XP) e outros, cada um com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo. Foi então criada a Aliança Ágil e o estabelecimento do Manifesto Ágil contento os conceitos e princípios comuns compartilhados por todos esses métodos. Desde então o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes conceitos que implicam em valorizar:

I. Indivíduos e interação entre eles são mais que processos e ferramentas; II. Software em funcionamento mais que documentação abrangente; III. Colaboração com o cliente mais que negociação de contratos; IV. Responder a mudanças mais que seguir um plano.

O Manifesto Ágil não rejeita os processos e ferramentas, a documentação, a negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações, com o software funcionando, com a colaboração com o cliente e as respostas rápidas a mudanças e alterações.

De acordo com Fagundes (2005), para auxiliar as pessoas a compreender o enfoque do desenvolvimento ágil, os membros da Aliança Ágil refinaram as filosofias contidas em seu manifesto em uma coleção de doze princípios, aos quais os métodos ágeis de desenvolvimento de software devem se adequar. Estes princípios são (COCKBURN, 2000):

1. A prioridade é satisfazer ao cliente através de entregas de software de valor contínuas e freqüentes;

2. Entregar softwares em funcionamento com freqüência de algumas semanas ou meses, sempre na menor escala de tempo;

3. Ter o software funcionando é a melhor medida de progresso; 4. Receber bem as mudanças de requisitos, mesmo em uma fase avançada,

dando aos clientes vantagens competitivas; 5. As equipes de negócio e de desenvolvimento devem trabalhar juntas

diariamente durante todo o projeto; 6. Manter uma equipe motivada fornecendo ambiente, apoio e confiança

necessário para a realização do trabalho; 7. A maneira mais eficiente da informação circular dentro da equipe é

através de uma conversa face a face; 8. As melhores arquiteturas, requisitos e projetos provêm de equipes

organizadas; 9. Atenção contínua a excelência técnica e um bom projeto aumentam a

agilidade; 10. Processos ágeis promovem o desenvolvimento sustentável. Todos

envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante;

11. Simplicidade é essencial; 12. Em intervalos regulares, a equipe deve refletir sobre como se tornarem

mais eficazes e então se ajustar e adaptar seu comportamento.

Devido as crescentes pressões do mercado por inovação, produtividade (prazos casa vez mais cursos), flexibilidade e melhoria no desempenho/qualidade dos projetos de desenvolvimento de SW, houve o surgimento dos métodos ágeis. O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.

Anos depois ainda estamos Sofrendo o Efeito da incompetência e mau uso das técnicas e projetos de software.

1994 1996 1998

2000 2002

2004 2006 2009

Successful 16% 27% 26% 28% 34% 29% 35% 32%

Challenged

53% 33% 46% 49% 51% 53% 46% 44%

Failed 31% 40% 28% 23% 15% 18% 19% 24%

(fonte: Standish Group - Chaos Report)

E o resultado consegue ser ainda pior, pois para os projetos considerados sucesso, apenas 20% da funcionalidade do SW é realmente útil.  É claro que a falha na execução de um projeto deve ser investigada e a causa pode ser dada decorrente de diversos motivos, mas de maneira geral esses erros ocorrem porque muitas vezes ao iniciar um projeto fazemos as seguintes suposições:

Os requisitos são 100% conhecidos no início do projeto e foram levantados e minuciosamente detalhados.

O desenvolvedor sabe como construir Nada irá mudar ao longo do caminho

Porém existem 3 coisas com as quais temos que conviver na época em que vivemos hoje onde os Software que produzimos estão ficando cada vez mais complexos:

O cliente descobre o que ele realmente quer, ou seja, é puro desperdício (tempo e esforço) detalhar minuciosamente os requisitos no ínicio do projeto e escrevê-los sobre pedra. Muitas vezes os requisitos mudam mas não necessariamente porque o cliente quer, mas porque a necessidade exige, porque o mercado exige.

“Um processo rígido ou resistente a mudanças produz produtos medíocres. Os clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a idéia inicial, ao invés de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor.” [Jeff Sutherland]

Os desenvolvedores descobrem como construir - idéias, novas tecnologias e opções surgem no decorrer do projeto. Desta forma uma nova idéia não deveria ser mau vista pela equipe/gestor.

Muitas coisas mudam ao longo do caminho.

Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma abordagem de planejamento e execução iterativa e incremental voltado para processos empíricos (complexos, caóticos ou com muita incerteza, tem mudança ao longo do processo, não são repetitivos e são imprevisíveis) que divide o problema em produtos menores e que visa entregar software funcionando regularmente, visa a aproximação e maior colaboração do time de desenvolvimento com os experts de negócios, comunicação face-to-face, redução dos riscos associados as incertezas dos projetos, abraçar e responder as mudanças de forma mais rápida e natural e é claro a satisfação final dos clientes por meio da adoção de práticas de gestão e de engenharia de software com foco nos valores e princípios do Lean e do agile, resumindo, seu principal objetivo é entregar o produto que o cliente realmente deseja e que será útil e com qualidade. [1]

Embora os métodos ágeis apresentem diferenças entre suas práticas, eles compartilham inúmeras características em comum, incluindo o desenvolvimento iterativo, e um foco na comunicação interativa e na redução do esforço empregado em artefatos intermediários. (Cohen et al., 2004) [2] A aplicabilidade dos métodos ágeis em geral pode ser examinada de múltiplas perspectivas. Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto (Cohen et al., 2004).2 De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três

dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas inúmeros fatores chave do sucesso podem ser identificados (Cohen et al., 2004):[2]

A cultura da organização deve apoiar a negociação. As pessoas devem ser confiantes. Poucas pessoas, mas competentes. A organização deve promover as decisões que os desenvolvedores tomam. A Organização necessita ter um ambiente que facilite a rápida comunicação entre os

membros.

Agilidade em TI é:  “a habilidade de criar e responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio turbulento” (HIGHSMITH, 2004); ou ainda, a capacidade de balancear a flexibilidade e a estabilidade.  HIGHSMITH (2004) enfatiza que a ausência de estrutura ou estabilidade pode levar ao caos, mas que a estrutura em demasia gera rigidez.

Vantagens (Cliente)

Foco e maximização do ROI (Retorno do Investimento) e do Valor de Negócio; Entregas do produto + rápida, freqüentes e regulares; Aceleração do Time-to-market o que se traduz em ganho de competitividade; Maximização do Value-to-Makert;Foco no que é prioritário e traz mais valor para o usuário,

o que se traduz em ganho de usabilidade; Transparência e visibilidade do status do projeto; Flexibilidade para mudanças de requisitos e prioridades além de maior agilidade na tomada

de decisões; Melhoria da Qualidade do produto final; Produtividade; Redução dos riscos e das indesejáveis surpresas.

Vantagens (gestor e equipes)

Escopo e objetivos claros e priorizados; Equipes auto-gerenciáveis, maior autonomia, disciplina e regularidade; Maximização do comprometimento; Melhoria na comunicação. A comunicação intensa com o cliente e a gestão de suas

expectativas são parte do processo; Inspeção e Adaptação constantes do processo em busca da melhoria contínua e a redução

dos desperdícios; Antecipação dos problemas e maior agilidade na tomada de ações.

Foco na agilidade: que quer dizer que é formado por equipes espertas, que se adequam mais rapidamente as modificações (plano de negócios e facilidades) ela da mais ênfase em produto a ser entregue, com qualidade, e menos ênfase na documentação. – pode ser aplicado a qualquer projeto de software. – o foco das metodologias Ageis, é a impresivibilidade que faz com que ela seja melhor adaptável.

O sucesso Nas metodologias ágeis está no feedback rápido pelo cliente, que possui um protótipo da aplicação, para ter conhecimento do seu andamento. Bem como a facilidade de comunicação na equipe – desde de a área de planejamento até a construção.

Refatoração muito importante para código. "refatoração é o processo de fazer mudanças em um código existente e funcional, sem alterar seu comportamento externo. Em outras palavras, alterar a MANEIRA como ele faz, mas não O QUE ele faz". – (David Astels)

Simplicidade Clareza Ausência de Repetição Desempenho (o)

SCRUM.

Nome derivativo de um jogo inglês chamado ruggby, onde os jogadores ficam ao redor de uma bola e os companheiros trabalha em conjunto violentamente para mover a bola . Segui ótimos princípios do manifesto ágil aos quais:

Pequenas equipes de trabalho focado em maximizar a comunicação; Compartilhar o conhecimento; Processos adaptáveis as técnicas novas e novidades no negócios (a realidade do

projeto); Processo iterativos que produz frequentes incrementos (que pode ser alterados,

inspecionados, testados e e documentados) Testes e documentão ao longo do produto. Declara sempre um pronto a cada entrega;

De acordo com o Autor (CRUZ,2006) o Scrum trata-se de uma abordagem simples aplicada ao gerenciamento de tarefas complexas onde é definido como uma metodologia ágil de desenvolvimento de software, que tem como principais características ser um processo empírico, iterativo e incremental. Em suas premissas temos que o desenvolvimento de software é muito complexo e imprevisível para ser planejado totalmente no início do projeto. Ao invés disso, o processo deve ser controlado empiricamente para garantir a visibilidade, inspeção e adaptação (MARÇAL; FREITAS; SOARES; MACIEL; BELCHIOR, 2007).

Segundo (FERREIRA, 2005), as principais características do SCRUM são:

• é um processo ágil para gerenciar e controlar o desenvolvimento de projetos; • é um wrapper para outras práticas de engenharia de software; • é um processo que controla o caos resultante de necessidades e interesses conflitantes; • é uma forma de aumentar a comunicação e maximizar a cooperação; • é uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de

um produto; • é escalável desde projetos pequenos até grandes projetos em toda empresa.

Valores Conforme Schwaber e Sutherland (2011), ele é baseado nas teorias empíricas de controle de processo e, como tal, acredita que o conhecimento vem da experiência e da tomada de decisões baseadas naquilo que é conhecido. Assim como na maioria das metodologias ágeis, o Scrum prega um processo iterativo e incremental para o desenvolvimento de um projeto, de forma que se torne mais previsível e tenha riscos mais controláveis. Dentre os diversos valores e regras que regem o Scrum, há três que são mais importantes:

Transparência: Todos os aspectos mais relevantes do processo tem que estar ao alcance dos responsáveis pelos resultados, sendo esses definidos de uma forma que estejam claros e causando o mesmo entendimento para estes, ou seja, todos devem “falar a mesma língua”.

Inspeção: Os usuários da metodologia devem verificar, com certa frequência, se os mecanismos Scrum e o progresso do projeto para identificar qualquer andamento que não esteja indo de acordo com o esperado. O ideal é que tal verificação seja feita por inspetores especializados em tal trabalho para que tenha um resultado melhor e também para que não venha a causar prejuízo de tempo àqueles que deveriam estar executando outras tarefas.

Adaptação: Caso seja identificado, durante a inspeção, que os aspectos de algum processo foram desviados além do que é aceitável, assim o será o produto, portanto o processo deve ser adaptado o quanto antes para eliminar possíveis futuros desvios

Esta metodologia foi desenvolvido por Ken Schwaber e Mike Beedle na década de 90, possui papéis e fases bem definidas, este é um dos grandes marcos desta metodologia.

Conceitos e Artefatos. A seguir veremos alguns dos mais importantes conceitos e artefatos utilizados dentro do processo de desenvolvimento com Scrum:

Product Backlog: Temos no product backlog uma lista priorizada dos requisitos, tanto funcional como não-funcional. Em cada item desta lista temos um valor de negócio associado, onde podemos medir o retorno do projeto e a priorização dos itens.

Sprint: Cada iteração do processo de desenvolvimento é denominada de Sprint. A duração de cada Sprint é recomendando que fique entre dois e quatro semanas. Período não superior a 30 dias, onde o projeto (ou apenas algumas funcionalidades) é desenvolvido;

Sprint Backlog: É uma lista de tarefas, onde temos o trabalho da equipe em cada Sprint do processo. A lista nasce durante o planejamento do Sprint. As tarefas do Sprint Backlog são o que a equipe definiu como sendo necessário para a fluência da realização dos itens do Product Backlog nas funcionalidades do sistema. Cada tarefa é identificada pelo seu responsável e a sua quantidade estimada de trabalho restante (SCRUM FOR TEAM SYSTEM, 2007).

Sprint Planning Meeting: Reunião de planejamento; Sprint Goal: Disparo dos objetivos/metas; Sprint Review Meeting: Revisão da reunião; Sprint Backlog: Trabalho a ser desenvolvido num Sprint de modo a criar um produto a

apresentar ao cliente. Deve ser desenvolvido de forma incremental, relativa ao Backlog anterior (se existir);

Dayling SCRUM: Reunião diária; onde são avaliados os progressos do projeto e as barreiras encontradas durante o desenvolvimento;

Scrum Meeting: Protocolo a seguir de modo a realizar uma reunião Scrum Meetings, são normalmente engenheiros de software ou da área de sistemas. Apesar de

ser gestor não tem propriamente autoridade sobre os demaismembros da equipe. Product Backlog: Produção do trabalho executado.

.

Papéis e responsabilidades. A seguir veremos três dos principais papéis implementados pelo Scrum:

Product Owner: É o “dono do produto”, identificando o interesse de todos no projeto. Além de priorizar os requisitos do projeto é o responsável pelo seu ROI (return of investment). Trocando em miúdos: é o dono do produto que sabe o que vai gerar retorno ao projeto (CRUZ, 2006).

ScrumMaster: É a pessoa responsável por fazer o Scrum funcionar. Deve ensinar a metodologia a todos os envolvidos no processo, assim como assegurar que todos sigam suas regras e práticas. Trabalha juntamente com o Product Owner na organização dos requisitos.

Team Members: Desenvolvem as funcionalidades do produto, são responsáveis coletivamente pelo sucesso da iteração e conseqüentemente pelo projeto como um todo (MARÇAL; FREITAS; SOARES; MACIEL; BELCHIOR, 2007).

Fluxo de Desenvolvimento. No Scrum, um projeto se inicia com a visão do produto que será desenvolvido. Em seu desenvolvimento, são realizados vários Sprints. A cada Sprint são estabelecidos novos itens a serem desenvolvidos, e durante sua realização temos diariamente reuniões de aproximadamente 15 minutos com os membros da equipe. No final de cada Sprint, é feita uma retrospectiva para avaliar como esta o andamento do processo, posteriormente são levantados os próximos itens a serem desenvolvidos para a realização de um novo Sprint.

Compreendendo Melhor.

No Scrum, um projeto se inicia com uma visão simples do produto que será desenvolvido. A visão pode ser vaga a principio e ir tornando-se clara aos poucos. O Product Owner (PO) então, transforma essa visão em uma lista de requisitos funcionais e não-funcionais que quando forem desenvolvidos reflitam essa visão. Essa lista, chamada de Product Backlog é priorizada pelo PO de forma que os itens que gerem maior valor ao produto tenham maior prioridade. [ 6]

O ponto de partida é dividir o Product Backlog em releases e é esperado que o conteúdo, a prioridade e agrupamento do Product Backlog sofram mudanças a partir do momento que o projeto começa. Essas mudanças refletem mudanças nas regras e requisitos de negócios e no quão rapidamente a equipe pode transformá-lo em produto [4]

Todo o trabalho é feito em Sprints que são iterações de 2 a 4 semanas. Scrum exige que o Scrum Team desenvolva um incremento de produto a cada Sprint. Esse incremento de produto precisa ser potencialmente entregável para o PO escolhe-lo para ser desenvolvido. Cada incremento deve ser bem estruturado, codificado e testado.

Cada Sprint inicia-se com uma reunião chamada Sprint Planning Meeting na qual o PO e a equipe decidem o que será desenvolvido neste Sprint. Nesta reunião o PO apresenta os itens de maior prioridade e o Scrum team seleciona os itens que serão entregues ao final do Sprint e os dividem em tarefas que compõem então o Sprint Backlog. Nessa reunião fica determinado o que fazer no Sprint. A equipe se compromete a executar essas tarefas no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos. [6] Todos os dias o Scrum Team se reúne numa reunião de 15 minutos numa reunião chamada Daily Scrum para sincronizar o trabalho da equipe toda e informar o Scrum Master de eventuais impedimentos no trabalho.

No final do Sprint ocorre a Sprint Review Meeting, reunião na qual o Scrum Team apresenta para o PO o que foi desenvolvido durante o Sprint. Depois da Sprint Review Meeting e antes do próximo Sprint o Scrum Master se reúne com o Scrum Team numa última reunião: a Retrospective Meeting. O Scrum Master encoraja o Scrum Team a revisar as práticas do Scrum e refletir sobre o que precisa ser feito para melhorar no próximo Sprint.

Juntas, a Sprint Planning Meeting, a Daily Scrum Meeting, a Sprint Review Meeting e a Sprint Retrospective Meeting implementam as práticas de inspeção e adaptação empíricas. [4]

Scrum Master O Scrum Master é responsável pelo processo Scrum, por ensiná-lo a todas as pessoas envolvidas no projeto, por implementá-lo, fazendo dele uma cultura na organização e ainda por garantir que toda a equipe siga as regras e as práticas do Scrum.[4]

Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint O Scrum Master atua como facilitador na Daily Scrum Meeting e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.[6] O papel de Scrum Master pode ser exercido por qualquer pessoa da equipe, entretanto é tipicamente exercido por um gerente de projeto ou um líder técnico.

Scrum Team –

É a equipe de desenvolvimento. Um Scrum Team típico tem de 6 a 10 pessoas auto-organizáveis, auto gerenciáveis e multifuncional[6]. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos e são responsáveis por completar o conjunto de trabalho com o qual se comprometem a cada iteração. A equipe não pode ser alterada durante o Sprint.

Quando é necessário uma equipe maior no Scrum é usando o conceito de Scrum of Scrums. Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrum, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações. [6]De acordo com Schwaber e Sutherland (2011), uma equipe de desenvolvimento deve possuir as seguintes características:

“- Elas são auto-organizadas. Ninguém (nem mesmo o Scrum Master) diz à Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; - Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

- O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. - Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e, - Equipes de Desenvolvimento não contém subequipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócio.”

Product Owner (PO) O Product Owner é responsável por representar os interesses dos stakeholders no projeto. O Product Owner é a pessoa que define todos os itens de requisito do projeto numa lista chamada Product Backlog. Utilizando essa lista ele é responsável por garantir que as funcionalidades que agreguem maior valor ao produto sejam desenvolvidas primeiro. Isto é feito através da freqüente priorização do Product Backlog para que os itens de maior valor agregado sejam entregues a cada iteração. [4] É também o Product Owner o responsável por atualizar e gerenciar o Backlog do produto (termo explicado a frente), o que inclui, conforme o manual do Scrum [2011]:

“- Expressar claramente os itens do Backlog do Produto; - Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; - Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; - Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e, - Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.” (SCHWABER, SUTHERLAND; 2011)

Sprint

No Scrum o progresso do projeto é baseado em uma sériede iterações bem definidas chamadas Sprints.. A recomendação é de que a duração da a Sprint fique entre 2 a 4 semanas. a Sprint fique entre 2 a 4 semanas.O Scrum é baseado em entrega de produto a cada Sprint, logo é recomendável que durante o desenvolvimento do produto, exista um padrão, um mesmo time-box, para todas as Sprints. Isto é importante para se conseguir medir o progresso e a produtividade da equipe no projeto.

Product Backlog

Um dos conceitos mais importantes é o Backlog do produto (ou Product Backlog), e o Backlog de Impedimentos (Impediment Backlog), ambos considerados o coração do Scrum. O Product Backlog contém uma lista de itens priorizados que incluem tudo o que precisa ser realizado, que possa ser associado com valor de negócio, para a finalização do projeto, sejam requisitos funcionais ou não. É importante ressaltar que cada item no Backlog do produto deve ter um valor de negócio associado (Business Value), onde podemos medir o retorno do projeto e priorizar a realização dos itens.

O Impediment Backlog contém todos os itens que impedem o progresso do projeto e geralmente estão associados a riscos. Estes itens não possuem uma priorização, mas estão geralmente associados a algum item

de Backlog do produto ou a tarefas do item, Exemplo “instalar ambiente para desenvolvedores”, “Instalação de banco de dados do projeto”, etc.

O controle desses itens é muito importante e o ScrumMaster é o grande responsável pela liberação desses impedimentos, abrindo caminho para o time de desenvolvimento executar a realização dos itens do Backlog do produto. Existem muitas formas para gerenciar o Product Backlog e o Impediment Backlog todas elas precisam que cada item seja identificado e estimado, em tempo ou tamanho, e que a sua ordem de importância seja estabelecida pelo cliente. Com esses atributos é possível ter os itens em uma ordem de priorização.

Backlog do Sprint O Backlog do Sprint é o produto da reunião de planejamento do Sprint, nele estão contidos todos os itens selecionados do Backlog do produto que serão produzidos no Sprint em questão. No Backlog do Sprint, além dos itens que serão desenvolvidos, está contido um plano detalhado para que as mudanças envolvidas sejam devidamente entendidas por todo o time.

Os itens do Sprint Backlog são divididos em tarefas com detalhes suficientes para que possam ser executadas em até 16 horas [4] - Um exemplo de Sprint Backlog é mostrado na Tabela 2.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.[6] Sprint Planning Meeting

A Sprint Planning Meeting é uma reunião na qual estão presentes o PO, o Scrum Master e o Scrum Team. Durante esta reunião o PO descreve as funcionalidades de maior prioridade para a equipe [6]Essa reunião, que deve ser de o horas, é dividida em duas partes [4]:

Nas primeiras 4 horas o PO apresenta os itens de maior prioridade do Product Backlog para a equipe. O Scrum Team faz perguntas para entender melhor as funcionalidades e ser capaz de quebrar as funcionalidades em tarefas técnicas que irão dar origem ao Sprint Backlog [6] e então definem colaborativamente o que poderá entrar no desenvolvimento do próximo Sprint, considerando o tamanho da equipe, a quantidade de horas disponíveis e a produtividade do Scrum Team [5]

Durante as próximas 4 horas o Scrum Team planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas no Product Backlog [5]

. Daily Scrum Meeting

A cada dia do Sprint o Scrum Master realiza uma reunião de 15 minutos com o Scrum Team. Essa reunião, chamada Daily Scrum Meeting, tem como objetivo disseminar informações sobre o estado do projeto [5]. As Daily Scrum Meetings devem ser realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho [6]. Embora qualquer pessoa possa participar da reunião, somente os membros do Scrum Team estão autorizados a falar [5]. Cada membro do Scrum Team deve então responder cada uma destas três perguntas:

1. O que você fez ontem? 2. O que você fará hoje?

3. Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. A Daily Scrum Meeting não é uma reunião de status na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual os membros da equipe assumem compromissos perante os demais. Os impedimentos identificados na Daily Scrum Meeting devem ser tratados pelo Scrum Master o mais rapidamente possível. O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo.

Sprint Review Meeting

No final do Sprint a Sprint Review Meeting é realizada. Essa reunião é planejada para ser realizada em no máximo 4 horas [5]. Nesta reunião o Scrum Team mostra o que foi desenvolvido durante o Sprint. Tipicamente, isso tem o formato de uma demonstração das novas funcionalidades.

Durante a Sprint Review Meeting, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante a Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Sprint Backlog. [6]

Kanbam e Scrum

O que o kanbam, tem haver com o scrum, bem o fato é que esses dois métodos são aliados poderosos, tendo em vista seus objetivos funcionais. Em suma já vimos como o Scrum trabalha, em blocos funcionais chamados Sprints. Que são produtos de um lista de serviços chamados Backlog. E o Kanbam o que tem haver com isto? O Kanbam como vimos é uma etapa importante no acompanhamento do projeto, ele é que avalia e acompanha sua progressão funcional, e como ele é o melhor indicado para o acompanhamento de sistemas de produção, ele se encaixa perfeitamente no Scrum.

SE VOCÊ NÂO ENTENDEU – Ai VAI COMO FUNCIONA O SCRUM

O clico do Scrum tem o seu progresso baseado em um série de iterações bem definidas, cada uma com duração de 2 a 4 semanas, chamadas Sprints. Antes de cada Sprint, realiza-se uma Reunião de planejamento (Sprint Planning Meeting) onde o time (equipe) de desenvolvedores tem contato com o cliente (Product Owner) para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima fase é a Execução da Sprint. Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias Rápidas (Daily Meeting), não mais que 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown. Ao final de cada Sprint, é feita uma revisão no produto entregue para verificar se tudo realmente foi implementado. Ao final da Sprint, deve-se realizar uma Reunião de Revisão (Sprint Review), onde o time demonstra o roduto gerado na Sprint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint. Scrum torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos, sejam eles novos ou apenas requisitos modificados. No entanto, para aplicá-lo, é preciso entender antes os seus papéis, responsabilidades, conceitos e artefatos das fases de seu ciclo.

XP - EXTREME PROGRAMMING

Surgiu antes mesmo das metodologias ágeis serem difundidas, onde Kent Bech, no Departamento de Computação da montadora de carros Daimler Crysler, procurou conhecer e adaptar esse novo método aos projetos de alto risco e com requisitos dinâmicos. O XP juntamente com o scrum, possui um conjunto bem definido de regras, e ambos vem ganhando um grande número de adeptos pelas diversas condições já mencionadas a respeito das metodologias ágeis, para exemplificar e atestar a respeito principalmente do XP podemos destacar a: Comunicação, Simplicidade, FeedBack e Coragem. – estes também são destacados como os valores do XP.

Valores do XP se baseia em quatro valores fundamentais:

• Feedback• Comunicação• Simplicidade• Coragem

Mas diferentemente do SCRUM o XP não é indicado a todo tipo, pois um das suas grandes características é possuir equipes pequenas, de 2 a 10 integrantes, que devem estar por dentro de todas as fases do desenvolvimento. Pela dinamicidade do projeto outra característica ligada a comunicação é a de manter uma equipe bastante interessada e pró-ativa, para assegurar a alta produtividade, e o cliente deve estar sempre disponível para tirar dúvidas e tomar decisões em relação ao projeto.

A comunicação com o cliente, no XP, mostra-se mais intensa que nos métodos tradicionais, devendo o cliente estar sempre disponível para tirar as dúvidas, rever requisitos e atribuir prioridades, utilizando-se de sistemas de nomes, em vez de termos técnicos para facilitar a comunicação. As equipes devem manter-se integradas com os projetos, melhorando a comunicação e a produtividade. Uma outra característica importante do XP é que o código é sempre escrito em duplas, visando a melhorar a qualidade do código por um custo muito baixo, às vezes menor do que o desenvolvimento individual. O código deve estar padronizado, para que todos na equipe possam entender o que está sendo escrito e possa ser validado durante todo o desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se saber se os requisitos estão ou não sendo atendidos.

Práticas do XP

O XP assim como todas as metodologia são guiados por algumas regras, o princípios que norteiam seu desenvolvimento, lembrando que estes princípios seguem a base de seus valores que são: Comunicação, Simplicidade, FeedBack e Coragem, portanto podemos dizer que estes valores deram origem as práticas que são:

Cliente Presente Jogo do Planejamento Stand Up Meeting Programação em Par Desenvolvimento Guiado pelos Testes Refactoring Código Coletivo Código Padronizado Design Simples Metáfora Ritmo Sustentável Integração Contínua Releases Curtos

Cliente Presente – O XP, trabalha com a premissa de que o cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema. Para que a troca de feedback possa ocorrer e o cliente possa obter o máximo de valor do projeto, é essencial que ele participe ativamente do processo de desenvolvimento. Além disso, a sua presença viabiliza a simplicidade do processo em diversos aspectos, especialmente na comunicação.

Jogo do Planejamento - O XP utiliza diversas formas de planejamento para assegurar que a equipe esteja sempre trabalhando naquilo que é o mais importante para o cliente. Por esta razão, todo projeto em XP é dividido em releases e iterações, de modo que cliente e equipe tenham diversas oportunidades de se reunir para revisar o planejamento.

Releases são módulos do sistema que geram um valor bem definido para o cliente. Iterações, por sua vez, são períodos de tempo de poucas semanas (em torno de duas, em média) no qual a equipe implementa um conjunto de funcionalidades acordado com o cliente. No início de cada release e de cada iteração ocorre o jogo do planejamento. Trata-se de uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração.

Releases são módulos do sistema que geram um valor bem definido para o cliente. Iterações, por sua vez, são períodos de tempo de poucas semanas (em torno de duas, em média) no qual a equipe implementa um conjunto de funcionalidades acordado com o cliente. No início de cada release e de cada iteração ocorre o jogo do planejamento. Trata-se de uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração.

No XP, as funcionalidades são descritas em pequenos cartões e são chamados de estórias. Durante o jogo do planejamento as estórias são estimadas, para que o cliente possa conhecer o custo da implementação de cada uma delas. A estimativa é feita utilizando-se uma unidade especial que recebe o nome de ponto.

O ponto representa uma unidade de tempo que varia ao longo do desenvolvimento de acordo com a velocidade da equipe, onde a velocidade indica o quanto a equipe foi capaz de implementar na iteração anterior. Todos os detalhes sobre releases, iterações, estórias, pontoes e velocidade serão descritos com detalhes nos capítulos subsequentes.

Stand UP Meeting - A equipe de desenvolvimento se reúne a cada manhã para avaliar o trabalho que foi executado no dia anterior e priorizar aquilo que será implementado no dia que se inicia. Trata-se de uma reunião rápida que recebe o nome de stand up meeting, que em inglês significa reunião em pé

Programação em Par - No XP, os desenvolvedores implementam as funcionalidades em pares, ou seja, diante de cada computador, existem sempre dois desenvolvedores que trabalham juntos para produzir o mesmo código. Esta prática, que recebe o nome de programação em par permite que o código seja revisado permanente, enquanto é construído. Também contribui para que a implementação seja mais simples e eficaz, já que os desenvolvedores se complementam e têm mais oportunidades de geral soluções inovadoras. – Importante saber que o “código” é domínio coletivo qualquer um da equipe pode dar “pitaco” ou seja pode implementa-los, porém é claro que isso não é feito de maneira bagunçadas, para isso existem regras e ferramentas.

Desenvolvimento Guiados pelos Testes - O XP é destinados à construção de Sistemas com alta qualidade, o que leva à necessidade de diversos mecanismo de validação para assegurar que o software está correto. Um destes mecanismo é a programação empar tal como o foi citado acima, e o outro é o desenvolver testando.

Onde os desenvolvedores “equipe” escrevem os testes para cada funcionalidade antes de codifica-las e outras para depois de sua codificação. Onde o foco então é aprofundar na análise dos testes citados, sem se preocupar com as interfaces – por consequente deixam de lado a preocupação com as classes métodos e design em geral. Assim adquirem uma massa de testes que auxiliam todos os resultados do produto.

Refactoring - “ Refatoração” Para que o sistema possa evoluir de forma incremental, a equipe deve fazer com que ele expresse os seus objetivos facilmente e esteja sempre claro e fácil de compreender. Freqüentemente, isso levará a equipe a modificar partes do sistema que estejam funcionando para facilitar a sua manutenção.

O Refactoring é o ato de alterar um código sem afetar a funcionalidade que ele implementa. É utilizado para dar mais qualidade ao código e ao software, qualidades como: Simplicidade, Clareza, Ausência de Repetição - Em outras palavras, alterar a MANEIRA como ele faz, mas não O QUE ele faz.

Código Coletivo – no XP o sistema não é segmentado em partes, de modo que cada desenvolvedor fique responsável por uma parte delas. Assim todos os desenvolvedores (até por que são uma equipe pequena) têm acesso a todas as partes do código e podem alterar aquilo que julgarem mais importante. Onde aplicam-se o conceito de repositório de código.

Isso fornece maior agilidade ao processo e cria mais um mecanismo de revisão e verificação, além de ajudar em uma versificação de ideias. Pois o que está sendo escrito hoje pode ser melhorado “refatorado” amanhã.

Código Padronizado – pelo fato do código ser coletivo, feito em pares, ele deve obedecer certas regras e normas adotadas dentro da organização, até para facilitar que as alterações sejam feitas de modo mais rápido. Ao final do software toda codificação fique homogênea. E até mesmo para permitir que a manutenção futura seja efetuada de maneira mais concisa e consciente. É importante ressaltar que existe sim documentação do código e no XP o código costuma ser bem comentado.

Design Simples - Para que o cliente possa obter feedback logo, a equipe precisa ser ágil no desenvolvimento, o que a leva a optar pela simplicidade do design. Ao invés de criar generalizações dentro do código, de modo a prepará-lo para possíveis necessidades futuras, a equipe deve sempre optar por um código que seja suficiente pra atender ás necessidades da funcionalidades que está implementado. Os desenvolvedores se baseiam na premissa de que serão capazes de incorporar qualquer necessidade futura quando e se ele surgir. Para isso, eles contam como o refactoring, os testes e as demais práticas do XP para apoiá-los.

Metáfora - Para facilitar a criação de um design simples, a equipe de desenvolvimento utiliza metáforas, já que elas têm o poder de transmitir idéias complexas de forma simples, através de uma linguagem comum que é estabelecida entre a equipe de desenvolvimento e o cliente.

40 horas de trabalho Semanal ou Ritmo Sustentável – A qualidade do design, do código, das metáforas e do sistema é determinada diretamente pela qualidade dos desenvolvedores e a capacidade que eles têm de se manter atentos, criativos e dispostos a solucionar problemas. Para garantir que a equipe tenha sempre o máximo de rendimento e produza software com a melhor qualidade possível, o XP recomenda que os desenvolvedores trabalhem apenas oito horas por dia e evitem fazer horas –extras para não se desgastarem e até mesmo afetar sua criatividade.

Integração Contínua – quando uma nova funcionalidade é incorporada ao sistema, ela pode afetar outras que já estavam implementadas. Para assegurar que todo o sistema esteja sempre funcionando de forma harmoniosa, a equipe pratica a integração contínua que leva os pares a integrarem seus códigos com o restante do sistema diversas vezes ao dia. Cada vez que um par faz isso, ele executa todos os testes para assegurar que a integração tenha ocorrido de forma satisfatória.

Uma integração sempre pode produzir erros no sistema. Sendo assim, a equipe utiliza os testes para descobrir eventuais defeitos o mais rapidamente possível já que descobri-los logo facilita e acelera a correção e diminui a probabilidade de pequenos problemas se transformarem em grandes dores-de-cabeça no futuro.

Releases Curtos – como explicado anteriormente, o XP tem como objetivo gerar um fluxo continuo de valor pra o cliente. Sendo assim, ele trabalha com releases curtos, ou seja, a equipe produz um conjunto reduzido de funcionalidades e coloca em produção rapidamente de modo que o cliente já possa utilizar o software no dia- a- dia e se beneficiar dele. Durante todo o projeto, a equipe colocará o sistema em produção diversas vezes, cada vez incorporando mais funcionalidades e gerando mais valor.

Entregas freqüentes: visa à construção de um software simples, e conforme os requisitos surgem, há a atualização do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. Idealmente devem ser entregues versões a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas caso o software seja entregue após muito tempo, melhora as avaliações e o feedback do cliente, aumentando a probabilidade do software final estar de acordo com os requisitos do cliente.

Características da equipe

Uma equipe que utilize o XP normalmente é composta por pessoas que representam os seguintes papéis:

Gerente de Projeto Coach Analista de Teste Redator Técnico Desenvolvedor

Gerente de Projeto. – é responsável pelos assuntos administrativos do projeto, ele procura liberar a equipe de questões que não estejam diretamente ligadas à atividades diária de desenvolvimento. Além disso, administra o relacionamento com o cliente assegurando que o mesmo participe ativamente do desenvolvimento e fornece as informações essenciais para que a equipe possa implementar o sistema desejado.

Coach – é o responsável técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas praticas recomendadas pelo XP. Embora também possa atuar na implementaão do sistema, as tarefa princiap é ser uma espécie de consultor, visando melhorar.

Analista de Teste - O analista de teste é responsável por ajudar o cliente a escrever os testes de aceitação. Quando estes testes não são automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iterações do projeto. Ele procura fazer com que os eventuais defeitos do sistema sejam identificados tão logo apareçam. Desta forma, fornece feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez e evitar que os problemas se propaguem.

Redator Técnico - O redator técnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presença permite que os desenvolvedores se concentrem priorioritariamente na implementação do software. Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz a maior parte do trabalho de documentação.

Desenvolvedor - é a pessoa que analisa, projeta e codifica o sistema. Em suma é a pessoa que efetivamente constrói o software, colocando as mãos na massa. Apensar de não existir dentro do XP uma divisão bem especifica dentro dos cargos, na maioria das vezes uma pessoa exerce mais de um papel.

[1] Paulo Pereira; Paula Torreão; Ana Sofia Marçal - Entendendo o Scrum Para Gerenciar Projetos de Software Ageis. https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en

[2] http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software

[1] LEFFINGWELL, Dean and MUIRHEAD, Dave, Tactical Management of Agile Development: Achieving Competitive Advantage. 2004. Boulder, Colorado

[2] SOARES, Michel dos Santos, Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete

[3] Agile Manifesto, Disponível em http://agilemanifesto.org/,

[4] SCHWABER , Ken, What Is Scrum?

[5] www.scrumalliance.org

[6] www.improveit.com.br

[7] GLOGER, Boris, Scrum Checklists.

[8] Ana Sofia Cysneiros Marçal et all, Estendendo o SCRUM segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI

[9] Bob Galen Spring, SCRUM Product Ownership: From the Inside Out. 2009. v1.4

[10] AMBLEW, Scott W., Examining the Agile Manifesto. 2009.

[11] Fagundes, Priscila Basto; Santos, Sandro da Silva dos e Deters, Janice Inês, Comparação entre os processos dos métodos ágeis, E-Tech: Atualidades Tecnológicas para Competitividade Industrial, Florianópolis, v. 1, n. 1, p. 37-46, 1º. sem., 2008.

[12] – MANHÃES, Vinicius Teles - Extreme Programming Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/143120.pdf

BOEHM, B. W; TURNER R. Balancing Agility and Discipline. Boston; Addison Wesley, 2002.

CÂMARA, FÁBIO. Um cardápio de metodologias ágeis. Visão Ágil. Disponível em: <http://www.visaoagil.com/downloads/edicoes/VA_02.pdf>. Acesso em: 01 mar. 2008.

MAURER, F; MELNIK, G. What You Always Wanted to Know About Agile Methods But Did Not Dare to Ask. Communications of the ACM, ICSE/05, Maio/2005.

GUERRA FILHO, I. A. Gerenciamento da equipe de desenvolvimento mapeando o PMBOK® em metodologias ágeis de desenvolvimento de software. 2006. Disponível em: <http://www.cin.ufpe.br/~iagf/tg/iagf_v2[1].0.doc >. Acesso em: 01 mar. 2008.

HIGHSMITH, J. Agile project management: creating innovative products. Boston: Addison-Wesley, 2004. 312 p .

PROJECT MANAGEMENT INSTITUTE – PMI. PMBOK Guide: Um guia do conjunto de conhecimentos do gerenciamento de projetos. Pennsylvania: Project Management Institute, 3. ed., 2004.

 

FAMÍLIA CRYSTAL DE METODOLOGIA (CRYSTAL FAMILY OF METHODOLOGIES)

Alistair Cockburn foi um dos idealizadores do movimento desenvolvimento ágil de softwares, com vasta experiência em liderança deprojetos foi contratado pela IBM 1991 No ano de 2000 Cockburn criou a metodologia Crystal ou Familia de Metodologias Crystal, que possui uma abordagem voltada a gestão de pessoas. Seu foco é a interação, comunidade, habilidades, talentos e comunicações, com a crença de que estes são os que têm o efeito de primeira ordem no desempenho, não descartando os outros fatores mas os colocando como secundário.

Inclui grande número de métodos diferentes que são selecionados de acordo com as características do projeto a ser desenvolvido. Hoje em dia, apenas dois dos quatro métodos propostos mantêm o desenvolvimento de novas práticas para cobrir diferentes tipos de projetos.

O termo "Crystal" refere-se as várias faces de uma pedra, em termos de software os rostos são uma visão diferente sobre o "núcleo fundamental" de valores e princípios, enquanto cada face representa um conjunto específico de elementos, tais como técnicas, funções, ferramentas e padrões. Cockburn também diferencia a Metodologia, técnicas e política:

Metodologia - conjunto de elementos (por exemplo, práticas, ferramentas); Técnicas - áreas de habilidades (exemplo, o desenvolvimento de casos de

uso) Políticas – padrões organizacionais.

Os membros da família Crystal são identificados por cores que indicam a intensidade do método. Neste caso, quanto mais escura a cor, maior é a complexidade do projeto.

Existem algumas características comuns à família Crystal, tais como o desenvolvimento incremental com ciclos de no máximo quatro meses, ênfase maior na comunicação e cooperação das pessoas, não limitação de quaisquer práticas de desenvolvimento, ferramentas ou produtos de trabalho e incorporação de objetivos para reduzir produtos de trabalho intermediários e desenvolvê-los como projetos evoluídos.

 

 

 

O ciclo de vida desta família de metodologia é baseado nas seguintes práticas:

Staging: Planejamento do próximo incremento do sistema. A equipe seleciona os requisitos que serão implementados na iteração e o prazo para sua entrega;

Edição e revisão: Construção, demonstração e revisão dos objetivos do incremento;

Monitoramento: O processo é monitorado com relação ao progresso e estabilidade da equipe. É medido em marcos e em estágios de estabilidade;

Paralelismo e fluxo: Em Crystal Orange as diferentes equipes podem operar com máximo paralelismo. Isto é permitido através do monitoramento da estabilidade e da sincronização entre as equipes;

Inspeções de usuários: são sugeridas duas a três inspeções feitas por usuários a cada incremento;

Workshops refletivos: são reuniões que ocorrem antes e depois de cada iteração com objetivo de analisar o progresso do projeto.

Local matters: são os procedimentos a serem aplicados, que variam de acordo com o tipo de projeto.

Work Products (Produtos de Trabalho): seqüência de lançamento, modelos de objetos comuns, manual do usuário, casos de teste e migração de código. Especificamente para o Clear: casos de uso e descrição de funcionalidade; Especificamente para o Orange: documento de requisitos.

Standards (padrões): padrões de notação, convenções de produto, formatação e qualidade usadas no projeto.

Tools: ferramentas mínimas utilizadas. Para Crystal Clear: compiladores, gerenciadores de versão e configuração, ferramentas de versão, programação, teste, comunicação, monitoramento de projeto, desenho e medição de performance.

A família de metodologia Crystal é dividida em cores, alguns deles citados a seguir: Crystal Clear

Crystal Yellow - Disposição Fisica, onde todos se reúnem um único ambiente. Todos separados apenas por suas tarefas.

Crystal Orange - Disposição menos acoplada, onde todos se reúnem um ambiente, mais próximo geralmente no mesmo prédio. Todos separados apenas por suas tarefas, e por projetos associados.

Crystal Red

Crystal Maroon

Estes modelos de Cor se baseiam em uma evolução da metodologia, de acordo com os aspectos do sistema e da equipe, relacionado a custos, pessoas, cronograma. A figura abaixo exemplifica melhor a evolução em relação ao acoplamento das funções, o dinheiro e as tarefas.

Entre todos os membros da família de cristal, existem algumas propriedades comuns. Cockburn descobriu que quanto mais desses princípios estavam inseridos em um projeto, as chances de obter sucessos eram elevadas.

Entrega Frequente: O modelo Desenvolvimento Incremental é utilizado na Crystal, onde cada incremento deve ter duração máxima de 4 meses, mas o recomendado até 3 meses;

Oficinas Reflexivas: Deve ser realizadas reuniões para reflexões sobre o projeto, a ideia é que a equipe possa analisar o projeto como todo e verificar

se tudo está dentro do que foi estabelecido e sempre procurando maneiras de melhorar seus processos;

Comunicação Osmótica: Se os integrantes da equipe de desenvolvimento trabalharem na mesma isso pode facilitar a transação das informações. Com relação às equipes maiores (mais de 8 ou algo assim), onde podem surgir distração, então é necessário ter cuidado para não perder o foco do projeto, faz-se então um controle mais rígido;

Convicção Pessoal: É ideal que todos tenham confiança já que isto melhorar o seu desempenho, as habilidades especificas de cada um devem ser focadas na hora da divisão das tarefas, e quanto mais o projeto avançar mais confiança a equipe terá;

Foco: Concentração é fundamental. Em cristal ele indica q todos tenham dois focos principais: primeiro lugar, concentração na sua tarefa individual dentro de um projeto e em segundo lugar, ao projeto como todo, sempre verificar se o projeto está seguindo em direção aos objetivos propostos;

Ambiente Técnico com Testes Automatizados: Deve haver integração total, se em testes for necessário alguma alteração isso deve ser feito de forma rápida e todos devem saber o que foi modificado.

Um resumo da família Crystal pode ser:· Desenvolvimento Incremental, onde cada incremento deve ter duração máxima de 4 meses, mas o recomendado é de até 3 meses;· Equipes maiores, metodologias mais complexas;· Mais feedback;· Ela não se restringe a um método ou ferramenta em especifico;· Ênfase na comunicação e cooperação entre os membros que estão inseridos na equipe;· Facilidade de Adaptação.

FDD FEATURE-DRIVEN DEVELOPMENT - Desenvolvimento Dirigido por

Funcionalidade.

A FDD - Feature Driven Development (Desenvolvimento Guiado por

Funcionalidades) é uma das seis metodologias ágeis originais, cujos

representantes redigiram o Manifesto Ágil para Desenvolvimento de Software, em

2001. Nessa ocasião, o representante da FDD foi JonKern, que trabalhava

na TogetherSoft, substituindo Peter Coad.

No contexto do FDD, uma característica “ é uma função valorizada pelo cliente que

pode ser implementada em duas semanas ou menos”. A ênfase na definição de

características fornece os seguintes benefícios:

Como as características são pequenas blocos de funcionalidade passiveis de

entrega, os usuários podem descreve-las mais facilmente, entender como

elas se relacionam uma com as outras mais prontamente e revisá-las melhor

quanto a ambiguidades, erros ou omissões.

As características é um incremento de software pssivel de entrega do FDD, a

equipe desenvolve características operacionais a cada duas semanas.

Como as características são pequenas, suas representações de projeto e de

código são mais fáceis de inspecionar efetivamente.

Planejamento de projeto, cronogramação, monitorização são guiados pela

hierarquia de características em vez de por um conjunto de tarefas de

engenharia de software arbitrariamente adotado.

Podemos Adotar como conceito de FDD como sendo um pequeno conjunto de

processos orientado a modelo e com poucas e curtas interações. A ideia é

sempre gerar "produto úteis aos olhos do cliente" em ciclo rápidos de duas

semanas, tanto quanto possivel. Como o ciclo é curto e orientado

a característica do sistema, o processo é facilmente moldável a volatilidade do

negócio.

Características Gerais:

Fornece a estrutura suficiente para equipes maiores.

Enfatiza a produção de software de qualidade.

Entrega resultados frequentes, tangíveis e funcionais.

Realiza trabalho significativo desde o inicio, antes de torna-se

altamente interativos.

Fornece informação de estado e progresso de formas simples

e compreensível.

Agrada a cliente, gerentes e desenvolvedores.

Seus princípios e práticas: proporcionam um equilíbrio entre as filosofias

tradicionais e as mais extremas, proporcionando uma transição mais suave para

organizações mais conservadoras, e a retomada da responsabilidade para as

organizações que se desiludiram com as propostas mais radicais.

A primeira descrição: oficial dos processos foi publicada no livro

"Java Modeling in Color with UML " por Peter Coad, Eric Lefebvre eJeff De Luca, em

1999. O livro de referência é "A Practical Guide to Feature-DrivenDevelopment",

por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall,

compondo uma série editada pelo próprioPeter Coad.

Referências: das vantagens e desvantagens.

Vantagens:

Uma metodologia ágil para aplicações críticas? Como FDD possui fases

muito fortes de análise, se comparada com outras metodologias ágeis, seus

autores a recomendam para qualquer tipo de desenvolvimento, incluindo

crítico. Foco em "características de valor para o cliente" (cliente-

valued features) FDD prioriza aquilo que o cliente prioriza. Na medida em

que há participação ativa do mesmo no projeto e um entendimento profundo

dos requisitos do sistema, os resultados produzido têm bastante e rápida

visibilidade.

Desvantagens:

O caso inicial de aplicação de FDD foi no desenvolvimento de uma aplicação

bancária. Entretanto, relatos confiáveis de uso bem-sucedido ainda não são

encontráveis, questionando a eficácia/aplicabilidade de FDD.

Escalabilidade do time Há controvérsias sobre o tamanho mínimo de um time FDD

Manutenção Ainda que FDD pressuponha um ciclo completo de documentação, a

especificação original da metodologia não comenta sobre sua aplicabilidade à

manutenção de sistemas.

Resumidamente, FDD é dividido em 5 fases que explicam sua função. São

elas:

1. Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de

requisitos, análise orientada por objetos, modelagem lógica de dados e

outras técnicas para entendimento do domínio de negócio em questão. O

resultado é um modelo de objetos(e/ou de dados) de alto nível, que guiará a

equipe durante os ciclos de construção.

2. Construir uma Lista de Funcionalidades: decomposição funcional do

modelo do domínio, em três camadas típicas: áreas de negócio,atividades de

negócio e passos automatizados da atividade(funcionalidades). O resultado é

uma hierarquia de funcionalidades que representa o produto a ser

construído (também chamado deproduct backlog, ou lista de espera do

produto).

3. Planejar por Funcionalidade: abrange a estimativa de complexidade e

dependência das funcionalidades, também levando em consideração a

prioridade e valor para o negócio/cliente. O resultado é um plano de

desenvolvimento, com os pacotes de trabalho na seqüência apropriada para

a construção.

4. Detalhar por Funcionalidade: já dentro de uma iteração de construção, a

equipe detalha os requisitos e outros artefatos para a codificação de cada

funcionalidade, incluindo os testes. O projetopara as funcionalidades

é inspecionado. O resultado é o modelo de domínio mais detalhado e os

esqueletos de código prontos para serem preenchidos.

5. Construir por Funcionalidade: cada esqueleto de código é preenchido,

testado e inspecionado. O resultado é um incremento do produto integrado

ao repositório principal de código, com qualidade e potencial para ser usado

pelo cliente/usuário.

The FDD Portal - http://www.featuredrivendevelopment.com/

The New Methodology – Martin Fowler -

http://martinfowler.com/articles/newMethodology.html#N102CC

ANALISE DE PONTOS DE FUNÇÃO

Indústria de software continua sentindo os efeitos da crise do software da década 80. Isto pode ser observado quando analisamos os três principais sintomas da crise do software apresentados por Pressman em 2006, a saber:

A produtividade não tem acompanhado a demanda por serviços; A qualidade do software, em alguns sistemas, não é adequada; As estimativas de prazo e custo são freqüentemente imprecisas.

Este último sintoma, que está associado a um dos principais problemas que a indústria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqüências desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade, perda de imagem da organização, e até mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantação de um processo de estimativas efetivo, visando a melhoria da previsibilidade de custo, prazo e esforço. Este artigo tem como propósito apresentar um processo de estimativas de projetos de software, aderente ao modelo CMMI, utilizando a métrica de Pontos de Função para estimar o tamanho funcional do projeto de software.

Processo de Estimativas de Projetos de SoftwareEsta seção apresenta uma visão geral de um processo de estimativas de projetos de software aderente à área de processo de Planejamento do Projeto do nível 2 do CMMI. A Figura 1 ilustra um processo de Estimativas de Projetos de Software. Este processo é descrito nos parágrafos seguintes. O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software, então, o artefato utilizado é freqüentemente um documento inicial de requisitos (por exemplo: Documento de Visão) ou até mesmo um documento do próprio cliente (por exemplo: modelo de processo de negócios ou manual do usuário, no caso de redesenvolvimento). O responsável pelas estimativas deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. O próximo passo é a derivação das estimativas de esforço, prazo (cronograma), custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização, assim como o estabelecimento da estimativa de recursos computacionais críticos. Neste ponto, as principais estimativas foram geradas, no entanto estas precisam ser documentadas.

As premissas e suposições utilizadas na geração das estimativas também devem ser documentadas. A análise das estimativas por um estimador independente, um profissional que não atue na equipe do projeto, constitui uma boa prática. O estimador independente poderá analisar a consistência das estimativas e a qualidade das suas documentações. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser re-estimado se ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto é concluído, deve-se documentar o tamanho, prazo, custo, esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas.

As lições aprendidas também devem ser documentadas. O foco deste artigo está na geração de estimativas de tamanho de projetos de software. Observe que a estimativa de tamanho é a primeira a ser gerada e a partir dela são derivadas as demais estimativas. Por isso, a importância desta estimativa. A literatura apresenta várias métricas de tamanho. Na indústria brasileira, podesse destacar a utilização de três métricas: LOC (Line of Code), Pontos por Casos de Uso e Pontos de Função. A seção seguinte apresenta as vantagens e desvantagens da utilização destas métricas.

Métricas de Tamanho de Projetos de Software

A métrica Linhas de Código (LOC) é de fato a mais antiga. A principal vantagem é que a contagem de linhas de código pode ser automatizada por uma ferramenta. As desvantagens são as seguintes: muitas vezes, o significado de uma linha de código é subjetivo, por exemplo, contar ou não linhas de comentário no código fonte; a métrica não é adequada para ser um indicador de produtividade, por exemplo, o desenvolvedor que escrever mais linhas de código será mais produtivo do que o desenvolvedor que escrever um algoritmo mais elegante e mais eficiente com menos linhas de código. Além disso, torna-se bastante complicado e subjetivo aplicar esta métrica em um processo de estimativas cujo insumo é um documento inicial de requisitos. Portanto, não é recomendado o uso da métrica LOC como unidade de medida para as estimativas de tamanho. A métrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner

com o propósito de estimar recursos para projetos de software orientados a objeto, modelados por meio de especificação de Casos de Uso. A métrica é de fácil aplicação, não requer muito tempo de treinamento ou experiência prática. No entanto, o PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa em casos de uso. Além disso, como não existe um padrão único para a escrita de uma especificação de caso de uso, diferentes estilos na escrita do caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. Assim, a métrica se torna subjetiva. E ainda, devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes existe a necessidade de se obter uma estimativa antes da finalização desta etapa. Então, esta métrica não é recomendada para utilização como unidade de medida das estimativas de tamanho de projetos de software. A métrica Pontos de Função (PF), definida por Allan Albrecht em 1979, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (International Function Point Users Group), criado em 1986, é responsável pela atualização das regras de Contagem de Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na versão 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em contagem de Pontos de Função, denominada CFPS (Certified Function Point Specialist). A métrica Pontos de Função é uma medida de tamanho funcional de projetos de software, considerando as funcionalidades implementadas, sob o ponto de vista do usuário. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” (Dekkers, 2003).

A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, a autora recomenda a utilização da métrica Pontos de Função nas estimativas de tamanho de projetos de software. A autora tem utilizado a métrica para estimar os projetos dos clientes da organização Serviço Federal de Processamento de Dados (SERPRO) desde 2003, tendo obtido excelentes resultados. A seção seguinte apresenta o método Contagem Estimativa de Pontos de Função (CEPF), utilizado para estimar o tamanho de projetos de software.

Contagem Estimativa de Pontos de Função

Antes de definir o método de estimativas CEPF, é importante destacar que “estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado” (Meli,1999). Assim, para evitar confusão, é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função.

Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG (IFPUG, 2005);

Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG.

Além do método Contagem indicativa de Pontos de Função, existem diversos métodos para estimar tamanho de projetos em Pontos de Função, descritos na literatura, dentre outros: Contagem Indicativa, Contagem Indicativa Inteligente, Estimativas Percentuais. O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função (APF):

Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE).

Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM. O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário (IFPUG, 2005). O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente (IFPUG, 2005). Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Simples.A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF.

As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:

Tabela 1 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação). Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento n x n e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI.

Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do COM (IFPUG, 2005). Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples.

Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Freqüentemente, o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também consideradosAIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas. A experiência tem mostrado que praticamente 100% dos AIEs dos sistemas são Simples. Porque, segundo o COM (IFPUG, 2005), são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada.

Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.

Considerações: Identifique as funcionalidades de inclusão, alteração e exclusões de dados. Conte separadamente as inclusões, alterações e exclusões de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas. Se você não possui conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada),considere as Entradas Externas identificadas com complexidade Média.

Tabela 4 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sema utilização de cálculos ou algoritmos. São os processos elementares do tipo “lê - imprime”, “lê - apresenta dados”, incluindo consultas, relatórios, geração de disquetes ou CDs, downloads, entre outros.

Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de CD ou de disquete? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média.

Tabela 5 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos, geração de disquetes com atualização log, downloads com cálculo de percentual, entre outros.

Considerações: Você está desenvolvendo uma funcionalidade para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação. Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média.

A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5.

Uma aplicação da Contagem Estimativa de Pontos de Função

Esta seção tem como propósito apresentar um exemplo utilizando o método CEPF, bem como a derivação das estimativas de esforço e prazo, a partir da estimativa de tamanho do projeto em PF. No exemplo apresentado, é descrito um sistema hipotético, parte de um sistema real, visando apresentar uma visão geral de um procedimento de estimativas de maneira prática. Suponha que o setor de treinamento de uma empresa solicitou um sistema, denominado STREINA, para apoiar as atividades de planejamento e acompanhamento das atividades de capacitação dos funcionários. A Tabela 6 apresenta as necessidades e funcionalidades do STREINA, retiradas do Documento de Visão do projeto. Além das funcionalidades apresentadas na Tabela 6, devese considerar os requisitos de cadastro de usuários e controle de acesso da aplicação. Estas funcionalidades estarão disponíveis para o perfil administrador do sistema. Para facilitar o entendimento da aplicação da CEPF, a Tabela 7 mostra a contribuição para a contagem de PFs não ajustados dos tipos funcionais da APF. A complexidade funcional das funcionalidades identificadas é inferida em uma contagem estimativa, quando não se possui informação suficiente do projeto para aplicar as regras de contagem do CPM. Conforme mencionado, recomenda-se utilizar a complexidade Simples para os Arquivos Lógicos (ALI e AIE) e a complexidade Média para as Funções Transacionais (EE, CE, SE). Aplicando-se o método Contagem Estimativa de Pontos de Função, tem-se o resultado apresentado na Tabela 8. Totalizando o tamanho em PFs das funcionalidades descritas na Tabela 8, tem-se 170 PFs não ajustados. Suponha que o fator de ajuste da contagem seja de 1,10. O fator de ajuste da contagem de PF é determinado com base na avaliação das 14 Características Gerais dos Sistemas, que descrevem as funcionalidades gerais das aplicações, por exemplo: performance, reuso, usabilidade, etc. O manual de práticas de contagem (CPM) apresenta a descrição das características e de suas ponderações, denominadas níveis de influência. O cálculo do PF Ajustado é obtido multiplicando-se os PFs Não Ajustados pelo Fator de Ajuste. Assim, temos 187 Pontos de Função Ajustados estimados. De posse da estimativa de tamanho, procede-se com a geração da estimativa de esforço. Neste exemplo, utiliza-se o modelo simplificado de estimativas de esforço, descrito por Hazan em 2005.

Para isto, deve-se obter um índice de produtividade por meio de análise do banco de dados de histórico de projetos da organização, observando-se os atributos do projeto em questão e o esforço realizado em projetos similares. Este projeto é pequeno (menos de 200 PFs) e será desenvolvido em JAVA por uma equipe com experiência intermediária na plata forma. Assim, o índice de produtividade hipotético utilizado é o de 12 horas/PF. Então, a estimativa de esforço é de: 187 x 12 = 2244 HH (homens_hora). O próximo passo é a estimativa de prazo, aplicando-se a fórmula de Caper Jones (1998) de aproximação de Tempo Ótimo de Desenvolvimento (Td) comum expoente t = 0,34, tem-se: Td = 1870,34 = 5,92 meses. Considerando-se o prazo estimado de 6 meses e o esforço estimado de 2244 HH, o próximo passo é a estimativa do tamanho da equipe de desenvolvimento ideal para atuar no projeto em questão. Segundo Jones (1997), a produtividade média diária no Brasil é de 6 horas/dia. E ainda, em média um mês possui 22 dias úteis. Então, tem-se: prazo = (esforço em HH) / (tamanho equipe * 6 * 22). Então, aplicando-se a fórmula, obtém-se o tamanho da equipe ideal para atuar no projeto, que deve ser constituída por três recursos, incluindo desenvolvimento e gestão. O COCOMO II também possui fórmulas para o cálculo do Td, baseadas em parâmetros de calibragem e de mapeamento (Boehm, 2000). É importante destacar que as organizações devem ter ou construir umbanco de dados histórico, contendo informações de projetos concluídos, com a finalidade de gerar as estimativas de prazo, custo e esforço com uma acurácia adequada. Aplicando-se o COCOMO II para as estimativas de esforço e prazo do STREINA, tem-se o seguinte:

Fator de Produtividade Linear (Pessoas_Mês/KSLOC) para desenvolvimento WEB: 2,51 (Roetzheim, 2005);

Fator Exponencial para desenvolvimento WEB: 1,030 (Roetzheim, 2005). 1 PF = 33 SLOC em JAVA (Jons, 1997); Esforço = Fator de Produtividade x KSLOCFator Exponencial (Roetzheim,

2005); Esforço = 2,51 x [(33 x 170)/1000]1,030 =14,83 Pessoas_Mês. Note o que o

insumo para o COCOMO é PF Não Ajustado, por isso considerou-se 170 PFs; O COCOMO considera o dia com 7h e o mês com 22 dias úteis, então o

esforço em HH é o seguinte: 14,83 * 7 * 22 = 2284 HH. Note que o cálculo do esforço estimado é próximo ao 2244 HH obtido pelo modelo simplificado;

Prazo (Td) = 2,5 x (Esforço0,32) = 5,9 meses (Aguiar, 1999); Note que o prazo estimado pela fórmula de Caper Jones – 5,92 meses, ficou

bastante próximo do prazo estimado pelo COCOMO.

Na prática, torna-se importante aplicar mais de um modelo de estimativas e analisar-se os resultados obtidos. Caso fosse utilizada a fórmula de esforço da ferramenta Cost

Xpert, apresentada por Aguiar em 1999, o resultado seria o seguinte: E= 2,4 x (V 1,05) = 14,68 Pessoa_ Mês, sendo V o tamanho do projeto em KSLOC. Note que este é bem próximo do esforço estimado, utilizando-se os parâmetros propostos por Roetzheim em 2005. Caso fosse utilizado o esforço de 14,68 como insumo para o cálculo do prazo, este continuaria sendo estimado em 5,9 meses. A estimativa de custo deve considerar o valor da hora da equipe alocada ao projeto (custo de pessoal), bem como outros custos de ambiente, ferramentas, deslocamentos, consultoria, etc. Algumas empresas possuem dados históricos de custo por PF de projetos concluídos, possibilitando a derivação direta da estimativa de custo a partir da estimativa de volume em Pontos de Função.

A estimativa de recursos computacionais críticos em um projeto WEB deve considerar, dentre outros, a disponibilidade dos servidores utilizados para desenvolvimento, homologação e produção do sistema e outros recursos de hardware relevantes. É importante ressaltar que após a geração das estimativas, deve-se adicionar um percentual, prevendo uma evolução natural dos requisitos do projeto. Este percentual deve ser obtido por meio de dados de históricos de um indicador de estabilidade de requisitos de projetos concluídos da organização.

As ferramentas de estimativas também trabalham desta forma, solicitando que o usuário (estimador) forneça tal percentual. No entanto, devido à ausência de dados históricos analisados para tal indicador, a autora tem se baseado em análise de publicações e sua experiência profissional. A autora tem utilizado um percentual de 20% a 35% para os projetos com Documento de Visão. Esta variação de percentual é diretamente proporcional ao detalhamento do Documento de Visão e conhecimento dos requisitos do projeto pelo analista de negócios. Para alguns projetos estimados, baseados apenas em atas de reunião ou documentos menos detalhados, foi utilizado o percentual de 40%. Em projetos pequenos com documentos de requisitos com um detalhamento adequado, o percentual varia de 10% a 25%. A CEPF deve ser refinada, conforme o conhecimento dos requisitos do projeto evolui, em marcos definidos no plano do projeto. Assim, não há retrabalho no processo de estimativas, as estimativas de PF anteriores não são descartadas e sim refinadas, conforme os requisitos do projeto evoluem.

ConclusãoA indústria tem demonstrado dificuldade na previsibilidade de prazo e custo dos projetos de software. No entanto, muitas organizações ainda estimam projetos, sem a utilização de processo, de maneira “artesanal”, baseando-se apenas na opinião dos líderes ou gerentes do projeto. De fato, o método de estimar projetos baseando-se na opinião de especialistas é bastante eficaz. O problema é quando a equipe não possui especialistas no domínio do projeto em questão. Este trabalho apresentou um processo para as organizações nas estimativas de projetos de software, utilizando métodos aderentes às melhores práticas do CMMI nível 2. Espera- se que com a utilização de processos, o cenário caótico em relação à previsibilidade de projetos seja melhorado. O método Contagem Estimativa de Pontos de Função tem sido utilizado com sucesso pela autora, além deste apoiar nas estimativas dos projetos, este também tem se mostrado bastante eficaz no suporte ao processo de engenharia de requisitos.

REVISTA Engenharia de Software Magazine – ANO1 Edição 02 – Autora: Claudia Hazan - claudinhah@yahoo.com Graduada em Informática pela Universidade do Estado do Rio de Janeiro (UERJ), Mestre em Engenharia de Sistemas e Computação pelo Instituto Militar de Engenharia (IME), Em Doutoramento em Engenharia de Software pela PUC-Rio,-

TESTE DE SOFTWARECada vez mais os softwares estão presentes na vida das pessoas, seja em celulares, bancos, aviões, cirurgias, entre outros. Consequentemente os mesmos estão se tornando cada vez mais complexos, devido ao surgimento de novas tecnologias. A maioria das pessoas passam por alguma experiência com um software que não funciona como o esperado, softwares que não funcionam corretamente podem levar a muitos problemas [1] e não inspiram confiança aos usuários. Existem vários exemplos de softwares que geraram problemas na fase de produção, trazendo custos altos, má reputação nos negócios e até mesmo colocou em risco a vida de seres humanos como foi o caso de pacientes de um centro médico para veteranos em Washington que receberam doses incorretas de medicamentos devido as informações incorretas exibidas pelo sistema eletrônico de registros [2]. Um outro exemplo foi a pane no sistema do site “ticketsforfun.com.br”, na venda de ingressos do show da Madonna no Brasil, devido ao grande número de acessos simultâneos causando atraso nas respostas e gerando informações múltiplas que o sistema não conseguiu interpretar[3].

Para evitar problemas como os citados acima é necessário investir em testes, pois, testes em sistemas e em documentações reduzem os riscos da ocorrência de defeitos do software no ambiente de produção onde são encontrados pelo cliente, contribuindo assim para a qualidade dos sistemas, pois, quanto mais cedo os defeitos forem encontrados antes da implantação do sistema o custo de correção é menor em relação ao encontrado da fase de produção afirma a regra 10 de Myers.[4]

O grande desafio das empresas é produzir softwares com qualidade, em um curto espaço de tempo, com baixo custo e atender as expectativas do cliente com o produto desenvolvido, ou seja, atender aos requisitos impostos pelo mesmo. Realizar testes dentro de um processo com metodologia própria é o grande “X” da questão. Os testes têm por finalidade agregar qualidade ao produto podendo também fazer uma medição desta qualidade em relação aos defeitos encontrados, pois, caso sejam encontrados poucos defeitos, o software será mais confiável, com os testes é possível também antecipar a descoberta de falhas e incompatibilidades, reduzindo assim o custo do projeto.

Devido ao projeto de testes está definido e delimitado a partir do cronograma do projeto de desenvolvimento para se obter um nível de cobertura aceitável (Número de Requisitos Mapeados X Número de Requisitos Totais) dos testes é importante que seja dado foco aos pontos críticos do sistema, os quais são de grande importância para o negócio e que caso não sejam tratados adequadamente, podem gerar prejuízos inestimáveis quando o software estiver na fase de produção. A falta de controle ou excesso de preciosismo por parte da equipe de teste pode tornar os testes custosos para o projeto, num momento em que o "custo x benefício" dos testes não compensa mais para a empresa podendo considerar o momento ideal para interrupção dos testes. [4]

Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou pode conter  Requisitos impossíveis de serem implementados, devido a limitações de hardware ou software. A implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.

O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação pode e, normalmente, varia significativamente de sistema para sistema.

Os atributos qualitativos previstos na norma ISO 9126  qualidade de produto de Software são:

Funcionalidade Confiabilidade Usabilidade Eficiência

Manutenibilidade Portabilidade

De forma geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software. Por meio da verificação será analisado se o produto foi feito corretamente, se ele está de acordo com os requisitos especificados. Por meio da validação será analisado se foi feito o produto correto, se ele está de acordo com as necessidades e expectativas do cliente.

Testar software não é somente executá-lo com a intenção de encontrar erros, existem várias atividades como: planejamento e controle, escolha das condições de teste, modelagem dos casos de teste, checagem dos resultados, avaliação de conclusão dos testes, geração de relatórios como também a revisão dos documentos. Algumas pessoas confundem a atividade de depuração (debbuging) com a atividade de teste, mas elas diferem. Pois, a atividade de teste pode demonstrar falhas que são causadas por defeitos enquanto a depuração é uma atividade de desenvolvimento que repara o código e checa se os defeitos foram corrigidos corretamente para então ser feito um teste de confirmação por um testador com a intenção de certificar se o mesmo foi eliminado. Outros conceitos chaves utilizados em testes são listados a seguir: [4]

Defeito: É o resultado de um erro encontrado num código ou num documento.

Erro: É um engano cometido por seres humanos. Falha: É o resultado ou manisfestação de um ou mais defeitos. Bug : É um erro de lógica na programação de um determinado software.[6] Testware: Define toda a documentação de teste. Caso de Teste: É uma condição particular a ser testada e é composto por

valores de entrada, restrições para a sua execução e um resultado ou comportamento esperado (CRAIG e JASKIEL, 2002). Assim uma restrições definida para cada teste a ser executado. Um ou mais casos de teste costumam estar relacionados a um caso de uso.

Procedimento de Teste: é uma descrição dos passos necessários para executar um caso (ou um grupo de casos) de teste (CRAIG e JASKIEL, 2002). [12]

Critério de Teste: serve para selecionar e avaliar casos de teste de forma a aumentar as possibilidades de provocar falhas ou, quando isso não ocorre, estabelecer um nível elevado de confiança na correção do produto (ROCHA et al., 2001).

Os critérios de teste podem ser utilizados como: Critério de Cobertura dos Testes: permitem a identificação de

partes do programa que devem ser executadas para garantir a qualidade do software e indicar quando o mesmo foi suficientemente

testado (RAPPS e WEYUKER, 1982). Ou seja, determinar o percentual de elementos necessários por um critério de teste que foram executados pelo conjunto de casos de teste.

Critério de Adequação de Casos de Teste: Quando, a partir de um conjunto de casos de teste T qualquer, ele é utilizado para verificar se T satisfaz os requisitos de teste estabelecidos pelo critério. Ou seja, este critério avalia se os casos de teste definidos são suficientes ou não para avaliação de um produto ou uma função (ROCHA et al., 2001). [12]

Critério de Geração de Casos de Teste: quando o critério é utilizado para gerar um conjunto de casos de teste T adequado para um produto ou função, ou seja, este critério define as regras e diretrizes para geração dos casos de teste de um produto que esteja de acordo com o critério de adequação definido anteriormente (ROCHA et al., 2001). [12]

Suíte de Testes: Pacote de casos de teste relacionados. Por exemplo: Suíte de cadastro, suíte de consulta.

Plano de Teste: É o documento de planejamento do projeto de teste é equivalente ao Plano de Projeto definido pelo PMI (Project Management Institute).

Script de Teste: É uma automação da execução de um caso de teste.

Read more: http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz370LArvGX Dimensões do Teste

Consiste na Técnica de Teste (Como Testar?): Técnica é o processo que assegura o funcionamento correto de alguns aspectos do software ou de uma unidade do software. Existem dois tipos de técnicas de teste de software: A Estrutural que tende a revelar erros que ocorrem durante a codificação do programa, é conhecida também como técnica de “Caixa Branca” essa técnica não determina o funcionamento correto da aplicação e sim da estrutura. E a Técnica de Teste Funcional que garante o cumprimento dos requisitos pelo sistema essa técnica é conhecida também como técnica de “Caixa Preta”. [4] Cada técnica possui tipos de testes específicos que serão listados abaixo.

Tipos de Testes (O Que Testar?): [4]

Basicamento quando falamos de técnicas de testes de Software temos 4 tipos, atualmente conhecidas e difundidas.

Técnicas de Teste Estrutural (Caixa Branca) – [4]Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno do componentes de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por estruturas de condições são testadas.

Técnica de teste que avalia o comportamento interno do componente de software (Figura 4). Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos (PRESSMAN, 2005) 

Figura 4. Técnica de Teste Estrutural. Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a construção do componente de software, cabendo, portanto, avaliação de outros aspectos além dos citados anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e componentes.[12]

Este tipo de teste é desenvolvido analisando-se o código fonte e elaborando-se casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variações originadas por estruturas de condições são testadas. A Listagem 1 apresenta um código fonte, extraído de (BARBOSA et al., 2000) que descreve um programa de exemplo que deve validar um identificador digitado como parâmetro, e a Figura 5 apresenta o grafo de programa extraído a partir desse código, também extraído de (BARBOSA et al., 2000). A partir do grafo deve ser escolhido algum critério baseado em algum algoritmo de busca em grafo (exemplo: visitar todos os nós, arcos ou caminhos) para geração dos casos de teste estruturais para o programa (PFLEEGER, 2004).[12]

Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de casos de teste para avaliar classes ou métodos desenvolvidos na linguagem Java. A técnica de teste de Estrutural é recomendada para os níveis de Teste da Unidade e Teste da Integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que são profissionais que conhecem bem o código-fonte desenvolvido e dessa forma conseguem planejar os casos de teste com maior facilidade. Dessa forma, podemos auxiliar na redução dos problemas existentes nas pequenas funções ou unidades que compõem um software. [12]

outros tipos relacionados aos testes de caixa branca, ou seja que são orientados a sua produção lógica são:

I. Teste de Execução: Verifica os tempos de resposta, de processamento e o desempenho (performance), avaliando o comportamento do software no ambiente de produção e verificando se as premissas de desempenho são atendidas. Em um sistema que possui dez módulos diferentes e que foi desenvolvido por equipes diferentes, o teste de execução avalia o sistema como um todo, é como se o teste de execução fosse um “play” no sistema.

II. Teste de Estresse: Avalia o comportamento do software sob condições críticas, tais como restrições significativas de memória, espaço em disco, etc., ou seja, coloca o software sob condições mínimas de operação.

III. Teste de Recuperação: A recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação como, por exemplo: Ao desligar o computador, queda de energia elétrica, entre outros. O teste de recuperação garante a continuidade das operações após um desastre.

IV. Teste de Operação: Avalia o processo e sua execução, são desenhados para estabelecer se o sistema é executável durante a operação normal, é um tipo de teste muito específico, depende do software a ser testado um exemplo é o software de “Call Center”.

V. Teste de Conformidade: Verifica se o software foi desenvolvido de acordo com padrões, normas, procedimentos e guias de TI.

VI. Teste de Segurança: Avalia a adequação dos procedimentos de proteção e as contramedidas projetadas, para garantir a confidencialidade das informações e a proteção dos dados contra o acesso não autorizado de terceiros.

Técnica de Teste Funcional (Caixa Preta)

Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a Entradas e Saída, a técnica de caixa-preta avalia o comportamento externo do componente, sem se considerar o comportamento interno do mesmo.4 Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação.

Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam testadas, mas na ampla maioria dos casos isso é impossível.5Outro problema é que a especificação pode estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas aceitas para o teste.6 Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema, pode-se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.

Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração,  testes e de sistema, testes de aceitação. A aplicação de critérios de teste leva o testador a produzir um conjunto de casos de teste (ou situações de teste). A aplicação do critério de Particionamento de Equivalência (ou uso de classes de equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. 

Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo (Figura 6). Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Haverá sucesso no teste se o resultado obtido for igual ao resultado esperado. O componente de software a ser testado pode ser um método, uma função interna, um programa, um componente, um conjunto de programas e/ou componentes ou mesmo uma funcionalidade. A técnica de teste funcional é aplicável a todos os níveis de teste (PRESSMAN, 2005). [12]

Figura 6. Técnica de Teste Funcional. Um conjunto de critérios de teste pode ser aplicado aos testes funcionais. A seguir conheceremos alguns deles.

Particionamento em classes de equivalência[12]

Esse critério divide o domínio de entrada de um programa em classes de equivalência, a partir das quais os casos de teste são derivados. Ele tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe, pois em princípio todos os elementos de uma classe devem se comportar de maneira equivalente. Eventualmente, pode-se também considerar o domínio de saída para a definição das classes de equivalência (ROCHA et al., 2001). [12]

Uma classe de equivalência representa um conjunto de estados válidos e inválidos para uma condição de entrada. Tipicamente uma condição de entrada pode ser um valor numérico específico, uma faixa de valores, um conjunto de valores relacionados, ou uma condição lógica. As seguintes diretrizes podem ser aplicadas:

Se uma condição de entrada especifica uma faixa de valores ou requer um valor específico, uma classe de equivalência válida (dentro do limite) e duas inválidas (acima e abaixo dos limites) são definidas.

Se uma condição de entrada especifica um membro de um conjunto ou é lógica, uma classe de equivalência válida e uma inválida são definidas. [12]

Devemos seguir tais passos para geração dos testes usando este critério: 1. Identificar classes de equivalência (é um processo heurístico)

condição de entrada válidas e inválidas

2. Definir os casos de teste

enumeram-se as classes de equivalência casos de teste para as classes válidas casos de teste para as classes inválidas

Em (BARBOSA et al., 2000) é apresentado a aplicação do critério de particionamento por equivalência para o programa identifier.c. Iremos apresentá-lo como exemplo do uso deste critério de teste. Relembrando, o programa deve determinar se um identificador é válido ou não. “Um identificador válido deve começar com uma letra e conter apenas letras ou dígitos. Além disso, deve ter no mínimo 1 caractere e no máximo 6 caracteres de comprimento. Exemplo: “abc12” (válido), “cont*1” (inválido), “1soma” (inválido) e “a123456” (inválido).” [12]

O primeiro passo é a identificação das classes de equivalência. Isso está descrito na Tabela 1.

Condições de Entrada Classes Classes

Tamanho t do identificador (1) 1 ??t???6

(2) t > 6

Primeiro caractere c é uma letra

(3) Sim (4) Não

Só contém caracteres válidos (5) Sim (6) Não

Tabela 1. Classes de Equivalência do programa identifier.c. A partir disso, conseguimos especificar quais serão os casos de teste necessários. Para ser válido, um identificador deve atender às condições (1), (3) e (5), logo é necessário um caso de teste válido que cubra todas essas condições. Alem disso, será necessário um caso de teste para cada classe inválida: (2), (4) e (6). Assim, o conjunto mínimo é composto por quatro casos de teste, sendo uma das opções: T0 = {(a1,Válido),  (2B3, Inválido), (Z-12, Inválido), (A1b2C3d, Inválido 12]

Análise do valor limite

Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no “centro”. Esse critério de teste explora os limites dos valores de cada classe de equivalência para preparar os casos de teste (Pressman, 2005). [12]

Se uma condição de entrada especifica uma faixa de valores limitada em a e b, casos de teste devem ser projetados com valores a e b e imediatamente acima e abaixo de a e b. Exemplo: Intervalo = {1..10}; Casos de Teste à {1, 10, 0,11}.Como exemplo, extraído de (BARBOSA et al., 2000), iremos considerar a seguinte situação: [12]

"... o cálculo do desconto por dependente é feito da seguinte forma: a entrada é a idade do dependente que deve estar restrita ao intervalo [0..24]. Para dependentes até 12 anos (inclusive) o desconto é de 15%. Entre 13 e 18 (inclusive) o desconto é de 12%. Dos 19 aos 21 (inclusive) o desconto é de 5% e dos 22 aos 24 de 3%..." Aplicando o teste de valor limite convencional serão obtidos casos de teste semelhantes a este: {-1,0,12,13,18,19,21,22,24,25}.[12]

Grafo de causa-efeito

Esse critério de teste verifica o efeito combinado de dados de entrada. As causas (condições de entrada) e os efeitos (ações) são identificados e combinados em um grafo a partir do qual é montada uma tabela de decisão, e a partir desta, são derivados os casos de teste e as saídas (ROCHA et al., 2001).Esse critério é baseado em quatro passos, que exemplificaremos utilizando o exemplo, também extraído de (BARBOSA et al., 2000): [12]

“Em um programa de compras pela Internet, a cobrança ou não do frete é definida seguindo tal regra: Se o valor da compra for maior que R$ 60,00 e foram comprados menos que 3 produtos, o frete é gratuito. Caso contrário, o frete deverá ser cobrado.” 1. Para cada módulo, Causas (condições de entrada) e efeitos (ações realizadas às diferentes condições de entrada) são relacionados, atribuindo-se um identificador para cada um.

Causa: valor da compra > 60 e #produtos < 3 Efeito: frete grátis

2. Em seguida, um grafo de causa-efeito (árvore de decisão) é desenhado (Figura 7).

Figura 7. Árvore de Decisão – Grafo de Causa-Efeito. 1. Neste ponto, transforma-se o grafo numa tabela de decisão (Tabela 2).

CausaValor da compra > 60 > 60 <= 60

#Produtos < 3 >= 3 --

EfeitoCobrar frete V V

Frete grátis V

Tabela 2. Tabela de decisão para o programa de compra pela Internet.

2. As regras da tabela de decisão são, então, convertidas em casos de teste. Para a elaboração dos casos de teste, devemos seguir todas as regras extraídas da tabela. Esse critério deve ser combinado com os dois outros já apresentados neste artigo para a criação de casos de teste válidos (extraídos das regras) e inválidos (valores foras da faixa definida). Os casos de teste definidos a seguir refletem somente as regras extraídas da tabela de decisão. Fica como exercício pensar nos casos de teste inválidos para este problema.· Casos de Teste (valor, qtd produtos, resultado esperado) = {(61,2,“frete grátis”); (61,3,“cobrar frete”); (60,  qualquer quantidade,“cobrar frete”)} [12]

 Outras técnicas

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade e teste de recuperação. Alguns autores chegam a definir uma técnica de teste caixa cinza, que seria um mesclado do uso das técnicas de caixa preta e caixa branca, mas, como toda execução de trabalho relacionado à atividade de teste utilizará simultaneamente mais de uma técnica de teste, é recomendável que se fixem os conceitos primários de cada técnica. [12]

Teste de Requisitos: Verifica se o sistema é executado conforme o que foi especificado. São realizados através da criação de condições de testes e cheklists de funcionalidades.

Teste de Regressão: Testa se algo mudou em relação ao que já estava funcionando corretamente, ou seja, é voltar a testar segmentos já testados após uma mudança em outra parte do software. Os testes de regressão devem ser feitos tanto no software quanto na documentação.

Teste de Tratamento de Erros: Determina a capacidade do software de tratar transações incorretas. Esse tipo de teste requer que o testador pense negativamente e conduza testes como: entrar com dados cadastrais impróprios, tais como preços, salários, etc., para determinar o comportamento do software na gestão desses erros. Produzir um conjunto de transações contendo erros e introduzi-los no sistema para determinar se este administra os problemas.

Teste de Suporte Manual: Verifica se os procedimentos de suporte manual estão documentados e completos, determina se as responsabilidades pelo suporte manual foram estabelecidas.

Teste de Interconexão: Garante que a interconexão entre os softwares de aplicação funcione corretamente. Pois, softwares de aplicação costumam estar conectados com outros softwares de mesmo tipo.

Teste de Controle: Assegura que o processamento seja realizado conforme sua intenção. Entre os controles estão a validação de dados, a integridade dos arquivos, as trilhas de auditoria, o backup e a recuperação, a documentação, entre outros.

Teste Paralelo: Comparar os resultados do sistema atual com a versão anterior determinando se os resultados do novo sistema são consistentes com o processamento do antigo sistema ou da antiga versão. O teste paralelo exige que os mesmos dados de entrada rodem em duas versões da mesma aplicação. Por exemplo: caso a versão mude e os requisitos não, os dados de saída das duas versões devem ser iguais.

Técnica de Teste Estrutura/Funcional (Caixa-cinza)

A técnica de teste de caixa-cinza é uma mescla do uso das técnicas de caixa-preta e de caixa-branca. Isso envolve ter acesso a Estruturas de dados e Algoritmos do componente a fim de desenvolver os casos de teste, que são executados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é considerado caixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso de engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens de erro.

Técnicas não funcionais

Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente ou sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, manutenibilidade e portabilidade)8.

Uma delas é o uso conjunto de teste de desempenho e teste de carga, que verifica se o software consegue processar grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina a Escalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuários é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.9 Já o tesde de confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados e processados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável de execução após estar em um estado de falha.

Alguns dos testes aplicados, nos requisitos funcionais, comtemplam a classe dos testes estruturais, porém é importante evidenciar, que os testes utilizados na classe estrutural, está voltado para o comportamento do condigo antes de gerar um modelo pronto para utilização do software. Enquanto os testes realizados na classe funcional, está voltado para base do projeto, assim sendo em como focando nas respostas dos casos de uso do projeto. Na figuração final dos implementação dos testes estruturados.

Estágios ou Níveis de Teste (Quando Testar?): É a dimensão do teste que determina a fase do desenvolvimento se aplica um determinado teste. Esses testes são listados a seguir:

I. Teste de Unidade: É aplicado aos menores componentes de código, é feito pelos programadores e testa as unidades individuais: funções, objetos e componentes.

II. Teste de Integração ou Iteração: É feito ao término de cada iteração para validar a execução das funções referentes aos casos de uso, é feito normalmente pelo analista de sistemas.

III. Teste de Sistema: Executa o sistema como um todo para validar a execução das funções acompanhando cenários elaborados (casos de teste) por um analista de testes em um ambiente de testes.

IV. Teste de Aceitação: É feito antes da implantação do software, o cliente é quem executa este tipo de teste no ambiente de homologação, tem como objetivo verificar se o software está pronto para ser utilizado pelos usuários finais.

V. Teste de Operação é a fase de teste em que o teste é conduzido pelos administradores do ambiente final onde o sistema ou software entrará em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma organização, cujo acesso pode ser feito interna e/ou externamente a essa organização. Nessa fase de teste devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de instalação, simulações com backup e restore das bases de dados, etc. Em alguns casos um sistema entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.

Teste de Operação Alfa:  versão alpha (ou alfa) de um produto (geralmente uma aplicação da área de informática) é normalmente definida quando este produto ainda está em fase de construção e testes. Mas só os programadores envolvidos têm acesso, e não ao público em geral1 . Porém, os usuários que serão beneficiados com o software poderão testar o sistema em um ambiente controlado nas instalações do desenvolvedor, caracterizando o processo denominado teste alpha.

Teste de Operação Beta:  A versão beta é a versão de um produto (geralmente software) que ainda se encontra em fase de desenvolvimento e testes e são disponibilizados para que os usuários possam testar e eventualmente, reportar bugs para os desenvolvedores. No entanto, esses produtos muitas vezes são popularizados bem antes de sair a versão final. Na prática, sempre que um programa é lançado em versão Beta, significa que o próprio desenvolvedor admite que o

programa ainda não está pronto e pode ter problemas, porém já está em um nível decente para a utilização, mesmo que sem nenhuma garantia.

Ciclo de Vida de Testes

O ciclo de vida de testes é composto pelas seguintes etapas: Planejamento que é a etapa onde se estabelece o que vai ser testado, em quanto tempo e em que momento os testes serão interrompidos. Preparação onde o objetivo é preparar toda a estrutura do ambiente de testes como: equipamentos, configuração de hardware e softwares usados (sistemas operacionais, browsers, etc.), criação da massa de dados de teste, pessoal, ferramentas de automação, entre outros. Na etapa de Especificação a atividade principal é elaborar e revisar os cenários e roteiros de testes. Na Execução executa-se os testes planejados e registrar os resultados obtidos e por fim na Entrega é onde arquiva-se toda a documentação e descreve-se todas as ocorrências do projeto relevantes para a melhoria do processo. [4]

Para se obter resultados positivos nos projetos de testes é necessário que o mesmo inicie desde a especificação dos requisitos do sistema a ser implementado, ou seja, tão logo comece o projeto de desenvolvimento do software inicia-se também em conjunto o projeto de testes de software.

Basicamente pelo Ciclo de Vida dos Testes ser um tipo de projeto (ou pelo menos um sub-projento dentro de algo maior ) ele é composto de 5 fases: Planejamento, Preparação, Especificação, Execução e Entrega.

Planejamento: Nesta fase é elaborada a Estratégia de Teste e o Plano de Teste. Preparação: O objetivo desta fase é preparar o Ambiente de Teste

(equipamentos, pessoal, ferramentas de automação, massa de testes) para que os testes sejam executados conforme planejados.

Especificação: Nesta fase temos as seguintes atividades: Elaborar/ Revisar casos de testes e Elaborar/ Revisar roteiros de testes.

Execução: Os testes são executados e registrado os resultados obtidos. Entrega: Esta é a última fase do ciclo de vida de testes, onde o projeto é

finalizado e toda documentação é finalizada e arquivada.

Dessa forma, seguindo a Figura Abaixo, o planejamento e projeto dos testes devem ocorrer de cima para baixo, ou seja:

1.      Inicialmente é planejado o teste de aceitação a partir do documento de requisitos;2.      Após isso é planejado o teste de sistema a partir do projeto de alto nível do software;3.      Em seguida ocorre o planejamento dos testes de integração a partir o projeto detalhado;4.      E por fim, o planejamento dos testes a partir da codificação.

Já a execução ocorre no sentido inverso. Conhecidos os diferentes níveis de teste, a partir da próxima seção descreveremos as principais técnicas de teste de software existentes que podemos aplicar nos diferentes níveis abordados.

Modelo V descrevendo o paralelismo entre as atividades de desenvolvimento e teste de software (CRAIG e JASKIEL, 2002)

Papéis e Responsabilidades

Segue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoa pode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos de desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, por exemplo, os papéis de arquiteto de teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto; o papel de testador pode ser assumido pelo programador ou por um segundo programador que atue num processo de programação em pares. Na fase de teste de sistema, num contexto em que haja uma equipe de teste independente, pode haver profissionais acumulando os papéis de arquiteto de teste, analista de teste e testador.

Os principais participantes no processo de testes são:

Gerente de Teste: Tem como papel defender a qualidade dos testes, planejar e gerenciar os recursos e resolver os problemas que representam obstáculos ao esforço de teste. [7]

Líder de Teste: Pessoa responsável pela liderança de um projeto de teste específico, normalmente relacionado a um projeto de desenvolvimento, seja um projeto novo ou uma manutenção. [8]

Analista de Teste: Elabora e modela os casos e roteiros de testes. Deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada.

Arquiteto de Teste: É responsável por montar a infra-estrutura de testes como: ambiente, ferramentas, capacitação da equipe, entre outros.

Testador: Executa os testes, o mesmo deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. [7]

Automatizador: Tem como papel automatizar as situações de teste em ferramentas observando as condições de teste documentadas pelo analista de teste e automatizar a execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execução de ciclos de teste sempre que se julgar necessário.[8]

Uma pessoa pode assumir mais de um dos papéis citados acima como, por exemplo, um testador pode exercer o papel de um automatizador de testes também.

O Processo de Teste

O Processo de Testes de Software representa uma estrutura das etapas, atividades, artefatos, papéis e responsabilidades buscando padronizar os trabalhos para um melhor controle dos projetos de testes. [5] O objetivo de um processo de teste (com metodologia própria, ciclo de vida, etc.) é minimizar os riscos causados por defeitos provenientes do processo de desenvolvimento como também a redução de custos de correção de defeitos, pois, o custo do software (desenvolvimento + manutenção) tendem a ser memor quando o software é bem testado. [4]

Read more: http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz370R6tPnW

Read more: http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz370M1H7R0

[1] BSTQB – Brazilian Software Testing Qualifications Board. http://www.bstqb.org.br/uploads/docs/syllabus_2007br.pdf.

[2] INFO Online. “Defeito de Software põe doentes em perigo”. http://info.abril.com.br/aberto/infonews/012009/16012009-19.shl. Publicado em 16/01/2009.

[3] G1. “Show de Madonna: fãs que tiveram cartão debitado terão ingresso”. http://g1.globo.com/Noticias/Musica/0,,MUL749176-7085,00.html. Publicado em 05/09/2008.

[4] Base de Conhecimento em Teste de Software. 2ª Edição. Rios, Emerson; Cristalli, Ricardo; Moreira, Trayahú & Bastos, Aderson. – S. Paulo, Martins Fontes, 2007.

[5] Alexandre Bartie. “Processo de Teste de Software – Parte 01”. http://imasters.uol.com.br/artigo/6102/des_de_software/processo_de_teste_de_software_parte_01/. Publicado em 07/05/2007.

[6] Wikipédia. “Problema do Ano 2000”. http://pt.wikipedia.org/wiki/Problema_do_ano_2000.

[7] Wikipédia. “Teste de Software”. http://pt.wikipedia.org/wiki/Teste_de_software.

[8] Gustavo Quezada. “Papéis e Responsabilidades na Equipe de Testes”. http://www.alats.org.br/Default.aspx?tabid=206&mid=1073&ctl=Details&ItemID=109. Publicado em 05/09/2008.

[9] Alexandre Bartie. Fábrica de Testes – Parte 01. http://imasters.uol.com.br/artigo/4435/des_de_software/fabrica_de_testes_parte_01/. Publicado em 26/07/2006.

[10] Roberto Murillo. A evolução do teste de software. http://imasters.uol.com.br/artigo/9369/des_de_software/a_evolucao_do_teste_de_software/. Publicado em 11/07/2008.

[11] Alexandre Bartie. “Fábrica de Testes Orientada a Resultados” http://imasters.uol.com.br/artigo/4665/des_de_software/fabrica_de_testes_e_orientada_a_resultados/ Publicado em 05/09/2006.

[12] CLAUDIO, Arilo Dias Neto – DEVMedica – Revista de Engenharia de Software - Artigo Engenharia de Software - Introdução a Teste de Software Disponível em: < Artigo Engenharia de Software - Introdução a

Teste de Software http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-teste-de-software/8035#ixzz370Ns0jpy >

[13] ALMEIDA, Carla– Introdução a Linha a Teste de Software Disponível em: < http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz370YEnKev>

Read more: http://www.linhadecodigo.com.br/artigo/2775/introducao-ao-teste-de-software.aspx#ixzz370LpZL4A

inherit

PROJETO DE TEMPO REAL

7.1 Introdução

Neste capitulo será apresentada algumas técnicas utilizadas no desenvolvimento desistemas de tempo real, e que é atualmente uma das atividades mais desafiadoras ecomplexas que o engenheiro de software tem.

O software de tempo real é altamente acoplado ao mundo externo, pois deve responder ao domínio do problema (o mundo real) numa escala de tempo por ele ditada. Uma vez que o software deve operar sob rigorosas restrições de desempenho o projeto é na maioria das vezes baseado na arquitetura de hardware e de software.

Robert Glass escreveu, “O computador digital está se tornando ainda mais presente navida diária de todos nós. Os computadores permitem que os nossos relógios executem jogos eletrônicos e nos digam a hora, otimizem o consumo de combustível de nossos carros de última geração e coloquem os nossos aparelhos num encadeamento lógico... [Na indústria, os computadores controlam máquinas, coordenam processos e, cada vez mais, substituem as habilidades manuais e o reconhecimento humano por sistemas automatizados e inteligência artificial.]. Todas essas interações computadorizadas – sejam elas úteis ou intrusivas – são exemplo de computação em tempo real. O computador está controlando algo que interage com a realidade numa base oportuna quanto ao tempo. De fato, o timing é a essência da interação... Um sistema de tempo real indiferente pode ser pior do que nenhum sistema em absoluto.”

Os sistemas de tempo real geram ação em resposta a eventos externos. Para cumpriressa função eles realizam controle e aquisição de dados em alta velocidade sob severasrestrições de tempo e confiabilidade. Como estas restrições são muito severas, elesfreqüentemente são dedicados a uma só aplicação.

Existem aplicações de tempo real para controle de processos, automação industrial,pesquisa médica e científica, computação gráfica, comunicações, sistemas aeroespacial,instrumentação industrial, etc.

7.2 Integração e Desempenho

Entre as muitas preocupações relacionadas ao projeto de tempo real, encontram-se acoordenação entre as tarefas de tempo real, processamento das interrupções de sistemas,manipulações de entrada/saída para garantir que nenhum dado seja perdido, especificação das restrições de timing internos e externos ao sistema e garantia da precisão de seu banco de dados. O desempenho do sistema é medido como uma das características relacionadas ao tempo, mas outras medidas, tais como, a tolerância a falhas também são usadas. Certos sistemas são projetados para aplicações em que somente o tempo de resposta ou a taxa de transferência de dados é crítico, outras aplicações exigem otimização de ambos os parâmetros sob condições de carga máxima.

Tempo de resposta do sistema é o tempo dentro do qual um sistema deve detectar umevento interno ou externo e responder com uma ação. Muitas vezes, a detecção do evento e a geração da resposta são simples, o processamento das informações sobre o evento para determinar a resposta apropriada é que pode envolver algoritmos complexos e consumidores de tempo.

Taxa de transferência de dados é a taxa que indica quão rapidamente dados seriais ouparalelos, bem como analógicos ou digitais, precisam ser movimentados para dentro ou para fora do sistema. Os fornecedores de hardware freqüentemente citam valores de capacidade e de timing para características de desempenho. Mas o importante é analisar as condições de desempenho global do hardware e não de cada componente isoladamente. deve-se analisar o desempenho do dispositivo de E/S, latência de barramento, tamanho do buffer, desempenho de disco e etc.

Freqüentemente exige-se que os sistemas de tempo real processem uma seqüência contínua de dados que chegam. O projeto deve garantir que dados não sejam perdidos, e o sistema deve reagir a eventos assíncronos.

Toda aplicação deve ser confiável, mas os sistemas de tempo real fazem exigênciasespeciais de confiabilidade, de reinicialização e de recuperação após a ocorrência de falhas. Como o mundo real está sendo monitorado e controlado, a perda de monitoração ou controle (ou ambos) é intolerável em muitas circunstancias. Deste modo, os sistemas contem mecanismos de reinicialização e de reparação de falhas e freqüentemente tem uma redundância interna para assegurar o backup.

7.3 Tratamento de Interrupções

Uma característica que serve para distinguir os sistemas de tempo real de qualquer outro tipo é o tratamento de interrupções. Ele deve responder a estímulos externos – interrupções – num tempo ditado pelo mundo externo. Uma vez que múltiplos estímulos estão presentes, as prioridades e interrupções prioritárias devem ser estabelecidas. Portanto, a tarefa mais importante deve ser atendida dentro das restrições de tempo definida, independentemente de outros eventos.

Um evento é uma ocorrência que exige imediato atendimento, e pode ser gerado ou pelohardware ou pelo software. O estado do programa interrompido é salvo e o controle é passado a uma rotina de atendimento a interrupções que se ramifica para o software apropriado a fim de manipular a interrupção. Após a conclusão do atendimento à interrupção, o estado da máquina é restabelecido e o fluxo de processamento normal continua.

Para manipular interrupções e ainda atender às restrições de tempo do sistema, muitossistemas operacionais de tempo real fazem cálculos dinâmicos para determinar se as metas do sistema podem ser cumpridas. Se os cálculos demonstrarem que é impossível manusear os eventos que podem ocorrer no sistema e ainda assim atender às restrições de tempo, o sistema deve decidir por um esquema de ação.

7.4 Linguagens de Tempo Real

Uma combinação de características torna uma linguagem de tempo real diferente de umalinguagem de uso geral. Entre estas características incluem-se as capacidades de multitarefa, construções para implementar diretamente funções de tempo real e características de programação modernas que ajudam a garantir a exatidão do programa.Por causa dos requisitos reais de desempenho e confiabilidade exigidos dos sistemas detempo real, a escolha de uma linguagem de programação é importante. Muitas linguagens de programação de propósito geral ( Fortran, C, Modula2) podem ser usadas efetivamente.Entretanto, uma classe de “linguagens de tempo real” (Ada, Jovial, HAL/S, Chill) é freqüentemente usada em aplicações militares e de comunicações.

7.5 Sincronização e Comunicação de Tarefas

Um sistema de multitarefas deve fornecer um mecanismo para que as tarefas passeminformações umas às outras de forma a garantir a sua sincronização. Para essas funções.sistemas operacionais e linguagens com suporte de run-time comumente usam semáforos de fila, mailboxes ou sistemas de mensagens. Os semáforos fornecem sincronização esinalização, mas não contem nenhuma informação. As mensagens são semelhantes asemáforos, exceto que carregam as informações associadas. As mailboxes não sinalizam, mas ao contrário, contém as informações.

Semáforos de fila são primitivas de software que ajudam a controlar o tráfego, elesproporcionam um modo de direcionar diversas filas, por exemplo, filas de tarefas que aguardam recursos, filas de acesso a banco de dados e dispositivos, filas de recursos e dispositivos. Os semáforos coordenam (e sincronizam) as tarefas em posição de espera com qualquer coisa que elas estejam esperando, sem deixar que tarefas ou recursos interfiram uns nos outros. Os semáforos são comumente usados para implementar e gerenciar mailboxes.

As Mailboxes são locais de armazenagem temporária para mensagens enviadas de umprocesso a outro. Um processo produz uma peça de informação, coloca-a na mailbox e depois sinaliza a um processo consumidor que há uma peça de informação na mailbox para que ele a use.

Sistema de mensagens é a terceira abordagem de comunicação e sincronização entreprocessos. Um processo envia uma mensagem a outro processo, este último é ativado pelo sistema de suporte de run-time ou pelo sistema operacional para processar a mensagem.

7.6 Análise e Simulação de Sistemas de Tempo Real

Vê-se um conjunto de atributos dinâmicos, que não podem estar divorciado das exigênciasfuncionais de um sistema de tempo real, tais como:

Manuseio de interrupções e troca contextual;

Tempo de resposta;

Taxa de transferência de dados e throughput;

Alocação de recursos e manipulação de prioridades;

Sincronização de tarefas e comunicação inter-tarefas.

Cada um destes atributos de desempenho podem ser especificados, mas é difícil verificarse os elementos do sistema obterão a resposta desejada, se os recursos do sistema serãosuficientes para satisfazer os requisitos computacionais ou se os algoritmos de processamento executarão com velocidade suficiente. A análise de sistemas de tempo real exige uma modelagem e uma simulação que capacitem o engenheiro de sistemas a avaliar as questões de timing e de sizing.

7.7 Métodos de Projeto

O projeto de software de tempo real deve incorporar todos os conceitos fundamentaisassociados ao software de alta qualidade. Além disso, ele apresenta um conjunto de problemas únicos ao projetista:

Representação de interrupções e troca contextual;

Concorrência, enquanto manifestada por multitarefas e multiprocessamento;

Comunicação e sincronização intertarefas;

Amplas variações nas taxas de dados e de comunicações;

Representação das restrições de timing;

Processamento assíncrono;

Acoplamento inevitável e necessário a sistemas operacionais, hardware e outros elementos externos do sistema.

Nas últimas décadas vários métodos foram propostos, alguns como extensão dos métodostradicionais e outros especialmente para software de tempo real.

7.8 Um método de Projeto Orientado para o Fluxo de Dados

Os métodos de projetos orientados para o fluxo de dados são os mais amplamente usadosna indústria. Hassan Gomaa desenvolveu extensões às representações de fluxo de dados que oferecem os mecanismos para o projeto de software de tempo real. A abordagem édenominada de Método de Projeto para Sistemas de Tempo Real (Design Method for Real- Time Systems – DARTS), que permite que os projetistas de sistemas de tempo real adaptem técnicas de fluxo de dados a necessidades especiais de aplicações de tempo real.

7.8.1 Requisitos de um método de projeto de Sistemas de Tempo Real

O método de projeto de software de tempo real DARTS baseia-se na notação e abordagem aplicadas ao projeto de software convencional orientado para o fluxo de dados.Para apoiar o projeto de tempo real, os métodos de fluxo de dados devem ser ampliados,oferecendo:

Um mecanismo para representar a comunicação e a sincronização de tarefas;

Uma notação para representar a dependência de estado;

Uma abordagem que “ligue” os métodos de fluxo de dados convencionais ao mundo do tempo real.

7.8.2 Projeto DARTS

Hassan Gomaa descreve a abordagem do DARTS como: “O método de projeto DARTSpode ser imaginado como uma ampliação do método de Projeto Estruturado/AnáliseEstruturada ao oferecer uma abordagem para estruturar o sistema em tarefas, bem como um mecanismo para definir as interfaces entre tarefas. Nesse sentido, ele lança mão daexperiência obtida em processamentos concorrentes. Como acontece com outros métodos de projeto, o DARTS pretende ser iterativo.”

Logo após o modelo de fluxo e um dicionário de dados tiverem sido criados, o sistemadeve ser examinado a partir de um ponto de vista diferente. Os DFD’s não descrevem astarefas assíncronas e concorrentes que implementam o fluxo de dados. Agora, precisamos de uma abordagem que identifique as tarefas do sistema de tempo real no contexto das funções (transformações) do sistema desenhadas num DFD. As transformações são agrupadas em tarefas de tempo real. O fluxo de dados entre tarefas recém-definidas determina os requisitos de comunicação intertarefas. Os critérios para determinar as transformações do DFD devem ser definidas como tarefas separadas ou agrupadas com outras transformações numa única tarefa:

Dependência de E/S – Dependendo da entrada ou da saída, uma transformação é limitada a funcionar na velocidade do dispositivo de E/S com o qual está interagindo. Necessita assim de ser uma tarefa separada.

Funções críticas quanto ao tempo – É uma função que precisa ser executada com prioridade elevada e deve ser uma tarefa separada.

Requisitos Computacionais – Uma função de uso computacional intensivo, pode ser executada como uma tarefa de prioridade mais baixa, executada em CPU extra.

Coesão Funcional – Transformações que executem um conjunto de funções estreitamente relacionadas podem ser agrupadas em uma tarefa, implementando as funções como módulos de uma mesma tarefa garantirá a coesão funcional, o que eliminará o tráfego de dados entre tarefas distintas, diminuindo o overhead do sistema.

Coesão Temporal – Algumas transformações realizam funções que são executadas ao

mesmo tempo, devem portanto serem agrupadas em uma tarefa, para serem executadas cada vez que a tarefa receber um estímulo.

Execução Periódica – Uma transformação que precisa ser executada periodicamente

pode ser estruturada como uma tarefa separada que é ativada em intervalos regulares.

Com as tarefas definidas, DARTS proporciona um mecanismo para o manuseio deinformações entre as tarefas, ao defini duas classes de “módulos de interface com as tarefas”:

os módulos de comunicação com as tarefas (TCM) e os módulos de sincronização de tarefas (TSM).

Um TCM é gerado por uma tarefa comunicante e usa primitivas de sincronização de sistema operacional para garantir o acesso adequado aos dados. Os TCM’s são divididos em duas categorias:

módulos de comunicação de mensagens (MCM),

módulos de ocultação de informações.

Quando o controle, em vez de dados, deve ser passado entre as tarefas, o módulo desincronização de tarefas entra em cena. Uma tarefa pode sinalizar a outra tarefa que um

evento ocorreu, ou uma tarefa pode ficar à espera de tal sinal. o TSM pode ser visto como um módulo supervisor que gerencia o controle e a coordenação quando ocorrem eventos.

7.8.3 Projeto de TarefasUma tarefa de sistema de tempo real é um programa que pode ser projetado usando-semétodos convencionais, ou seja, uma tarefa pode ser vista como um processo seqüencialimplementado com uma estrutura de programa hierarquicamente organizada, usando a filosofia de programação estruturada.

O DFD que representa o fluxo de dados dentro da fronteira de uma tarefa pode levar auma estrutura de programa, porém, para sistemas de tempo real, o controle depende tanto da entrada oferecida à tarefa como do estado atual do sistema, por isto, o controle é dependente do estado. Para isto, sugere-se um mecanismo para manejar esta situação que é denominado de gerenciador de transição de estados (STM) que é uma implementação da tabela de ativação de processos. o STM tem conhecimento do estado corrente do sistema e usa uma tabela de transição de estados para guiar o processamento.

SOA – Arquitetura Orientada a Serviços

“Oproblema é que você não pode simplesmente comprar SOA, você tem que entendê-la e vivê-la. SOA é um paradigma. SOA é uma maneira de pensar. SOA é um sistema de

valores para a arquitetura e design” [Josuttis, 2007].

Conceitos iniciaisExistem diversas definições sobre SOAe serviço, porém nenhuma delas é tida como a oficial. Muitas destas definições vêm de fornecedores que as definem de acordo com as soluções que eles fornecem. Alguns exemplos de grandes fornecedores são a IBM, Microsoft e Oracle.

Iremos definir SOA de uma maneira bem simples: SOA é uma forma de se projetar uma arquitetura baseada na composição de serviços interoperáveis e reutilizáveis. A figura abaixo mostra os principais elementos de uma SOA: o fornecedor do serviço é aquele que implementa e tem domínio sobre um serviço; o registro de serviço é um repositório onde fornecedores de serviço podem registrar seus serviços para que eles sejam localizados pelos consumidores; e o consumidor do serviço é aquele que localiza um serviço e o executa. O contrato é a especificação do serviço que possui as informações necessárias para que o consumidor possa localizá-lo e invocá-lo.

Esta é a idéia simplista que temos sobre SOA. A seguir vamos analisar SOA em um contexto empresarial e quais os benefícios que este tipo de arquitetura traz para as organizações.

Para conceituar o objeto central do estudo, a – arquitetura de software orientada a serviços (SOA) – faz-se necessário desenvolver o termo “serviço” dentro do contexto da arquitetura de software. O “serviço básico” é o mais comumente encontrado em quantidade nas organizações. Ele apresenta um nível de especificidade bastante pontual e restrita. Um exemplo seriam os algoritmos para validação de números ou de status, como os utilizados na validação do número do CPF e na averiguação da situação de crédito de uma pessoa. Um serviço também pode ser um algoritmo mais abrangente, em termos de funcionalidades, sendo assim, denominado de “serviço centrado em processo”.

A arquitetura orientada a serviço torna possível transformar aplicações monolíticas rígidas em componente de softwares flexíveis, permitindo a interoperabilidade entre diferentes tecnologias.

O ponto crucial nas aplicações de negócios enfoca: reutilização, a redução de custo de desenvolvimento e manutenção, torna soluções de negócios mais ágeis e fáceis de implementar, viabilizando as oportunidades de negocio, ai que o SOA é adotado pelas entidades (pessoas e organizações).

As organizações e as pessoas em nosso tempo visam os seguintes pontos para um negocio: reutilização, custo x beneficio, segurança e flexibilidade, esses são os pontos cruciais por empreendedores de negócios.

No ambiente computacional, há diversas outras variações de serviços; no Quadro 1 é apresentada uma tipificação de serviços desenvolvida por Krafzig, Banke e Slama (2004).Outra entidade importante na SOA é o application frontend. Mesmo não sendo um serviço, trata-se de um elemento ativo da SOA. É ele que inicia todos os processos de negócios e recebe seus resultados. Na prática, esta entidade é caracterizada pelas diversas aplicações que interagem com o usuário final (web applications, GUI applications, CICS applications etc) ou mesmo os programas que processam lotes de dados (sistemas batch). A análise e compreensão do application frontend é fundamental para o entendimento dos estágios de maturidade da SOA nas organizações e que serão analisados a seguir:

Krafzig, Banke e Slama (2004) identificaram três estágios de maturidade da SOA nas organizações: a fundamental, a em rede e a habilitadora de processos assim descritos:

SOA fundamental: é o melhor ponto de partida para as organizações que pretendem implantar a SOA. A maior parte da complexidade e da responsabilidade continua existindo ainda no application frontend, que aciona os diversos serviços básicos. Este estágio já proporciona ganhos significativos pelas facilidades de reutilização de serviços básicos. Seus maiores benefícios são os ganhos de manutenção com as aplicações internas de departamentos e com as aplicações entre departamentos;

SOA em rede: há o uso intensivo de serviços intermediários; estes agregam serviços básicos na forma de serviços mais sofisticados. Os serviços intermediários são amplamente utilizados para atender deficiências técnicas e funcionais dos softwares disponíveis na arquitetura. Os serviços intermediários, enquanto desempenham o papel de conectores e adaptadores, oferecem muita flexibilidade para integração entre softwares, independentemente das restrições tecnológicas. O application frontend torna-se menor e menos complexo que no SOA fundamental. Suas maiores vantagens são os ganhos de flexibilidade ao utilizar aplicações entre unidades de negócios e entre diferentes organizações;

SOA habilitadora de processos: neste estágio, os application frontend são utilizados apenas para interação com o usuário. Toda complexidade dos processos de negócios é delegada à SOA, mais especificamente, aos serviços centrados em processos. Há uma forte separação entre as regras para gestão do processo de negócio, desempenhada pelos serviços centrados em processos, e os códigos fontes de programas necessários para a sua execução, disponibilizados na forma de serviços básicos para execução dos algoritmos e na forma de application frontend para as interações requeridas.

Uma organização pode vivenciar simultaneamente dois ou três estágios de maturidade da SOA. Isto se explica devido aos diferentes escopos e necessidades de integração, requeridos entre áreas de negócios, empresas e integrações complexas de processos. Antes de concluir com os conceitos, há a necessidade de se definirem mais dois componentes fundamentais para o entendimento da arquitetura SOA: o repositório de serviços e o “barramento” de serviços. O repositório de serviços é a entidade que provê facilidades para o descobrimento dos serviços disponíveis na arquitetura, sobretudo daqueles fora do escopo temporal e funcional do sistema de informação, ou melhor, do processo de desenvolvimento do nosso sistema. Ele fornece informações como: localização virtual, provedor, taxas, limitações técnicas, aspectos de segurança, entre outras. O barramento de serviços é o meio utilizado para conexão entre todos os participantes da SOA (serviços e application frontends) e engloba uma grande diversidade de produtos e conceitos.

de integrações ponto a ponto  viabilizando a “conversa” entre eles. Como conseqüência temos muitas funcionalidades redundantes, e uma dificuldade em evoluir com estes sistemas, contrastando com o atual cenário onde as empresas necessitam cada vez mais de agilidade nos negócios. Por outro lado vemos a evolução da tecnologia fornecendo possibilidades de interoperabilidade, propiciadas principalmente pela evolução da internet.

Este caminho se iniciou com Tim Berners Lee (SGML-HTML-XML) e continua com o advento dos Web Services (XML/WSDL/SOAP) e suas extensões, com o apoio de importantes organizações padronizadoras como W3C e OASIS. Parece até que foi um movimento ensaiado: as empresas com a  necessidade de desenvolver  sistemas através da criação de módulos (serviços) interoperáveis e reutilizáveis, de modo a criar um ambiente normalizado e de evolução fácil e segura, e a tecnologia fornecendo as condições para que estes módulos possam “conversar” (interoperabilidade intrínseca). 

A esta nova arquitetura, orientada a serviços, deu-se o nome de SOA-Service Oriented Architecture.Mas cuidado!  Para se ter serviços que serão realmente reutilizados, é necessário que o paradigma de desenvolvimento atual sofra profundas modificações. E não estamos falando de tecnologia e sim de novos processos que retratem novas políticas. Alguém lembrou de governança? Pois é isto mesmo. E uma forma correta de se estabelecer o tamanho ideal de cada serviço (granularidade, para usar o termo adequado) é  considerarmos os 8 (oito) Princípios de Design de Serviços que são:

Serviços são Reutilizáveis Serviços compartilham um Contrato formal Serviços possuem um Baixo Acoplamento Serviços Abstraem a lógica Serviços são capazes de se Compor Serviços são AutônomosServiços evitam Informação de Estado Serviços são capazes de ser DescobertosCom isto estaremos prontos para colocar a tecnologia funcionando a nosso favor.

SOA em um contexto empresarial

Atualmente, muitas organizações possuem um conjunto de diferentes sistemas, aplicações e arquiteturas com diferentes idades, tecnologias e plataformas. Além disso, os processos de negócio destas organizações estão sujeitos a mudanças, ou devido a alguma reestruturação de negócio, ou talvez devido à abertura para novos parceiros de negócio. Neste contexto, como os sistemas da organização conseguirão acompanhar estas mudanças? Este é um cenário ideal para se pensar em adotar uma SOA. Neste contexto empresarial, SOA permite que organizações com infra-estrutura de aplicações fragmentadas, sob a administração de diferentes áreas de negócio ou departamentos, possam integrar estas aplicações no nível de serviço. Portanto, as aplicações destes departamentos se tornam fornecedores e consumidores de serviços de outros

departamentos. Além disso, serviços representam bem funções de negócio e, portanto, são considerados uma boa maneira para desenvolver aplicações que suportam processos de negócio, permitindo assim, alinhar TI às necessidades organizacionais. Cada serviço representa uma determinada funcionalidade que é mapeada para um passo, ou vários passos, em um processo de negócio.

A Figura 2 ilustra esta idéia. Perceba que os diferentes departamentos de uma empresa possuem diferentes sistemas de software que podem ser um CRM, um ERP, ou qualquer outro sistema que automatize processos de negócio do seu departamento. A idéia é disponibilizar a lógica desses sistemas em forma de serviços interoperáveis e reutilizáveis. Acima desses serviços, existe uma camada onde estão os processos de negócio que são executados através da invocação dos serviços, ou seja, os serviços são chamados em uma seqüência lógica de acordo com os processos organizacionais. Neste cenário, novas aplicações clientes, com pouca ou nenhuma lógica de negócio, Podem ser desenvolvidas em cima destes processos de negócio. Neste caso, estas aplicações clientes funcionam simplesmente como entrada e apresentação dos dados.

O cenário ideal é que analistas de negócio da organização possam fazer alterações nos processos e que isso seja refletido automaticamente no sistema empresarial como um todo, sem precisar alterar nenhuma linha de código. Esta é a idéia “Run what I just drew”, ou seja, “execute o que eu acabei de desenhar”. Este é um dos focos da área de BPM (Business Process Management). Atualmente, os conceitos de SOA e BPM estão bem relacionados e, por este motivo, as pessoas os confundem, achando que estas idéias de gerenciamento de processos pertencem a SOA. SOA dá o suporte tecnológico e metodológico para expor serviços de negócio. Já BPM tem como objetivo capturar, projetar, executar, gerenciar e monitorar processos, geralmente através de ferramentas visuais. Como estes temas estão bem interligados, ao longo deste artigo, iremos nos referir apenas ao termo SOA, sabendo que as idéias de BPM estão incorporadas a ela. É importante dizer que este é o cenário que SOA, juntamente com BPM, pode alcançar. Porém, SOA também pode ser utilizado em outros cenários mais simples que não envolva BPM.

Benefícios na adoção de SOA

A adoção de SOA traz alguns benefícios devido às suas características. Esta lista de benefícios não está completa, e é apenas uma indicação do potencial que essa plataforma arquitetural pode oferecer.

Flexibilidade

Como foi dito, todo sistema empresarial está sujeito a mudanças. Ele precisa continuamente ser adaptado para suportar novos requisitos devido às necessidades que envolvem o mercado, mudanças na lei, ou mesmo reorganizações de negócio. Portanto, a arquitetura empresarial deve ser configurada de maneira flexível. As características de SOA possibilitam o desenvolvimento de novos serviços de negócio e permitem que uma organização reuse estes serviços a fim de responder a estas mudanças.

Manutenabilidade

A comunicação entre o consumidor e o fornecedor é baseada em interfaces bem definidas e padronizadas. Esta característica aumenta o poder de manutenabilidade dos sistemas empresariais porque os detalhes de implementação ficam escondidos.

Reusabilidade

Reusabilidade tem sido um dos maiores objetivos da engenharia de software nos últimos anos, com diferentes graus de sucesso. Na SOA, a habilidade de compor novos serviços a partir de serviços existentes fornece uma maior possibilidade para o reuso e uma vantagem distinta para uma organização que tem que ser ágil para responder às necessidades de negócio. Desta maneira, o desenvolvimento das aplicações através do reuso de serviços torna mais rápido, aumenta a qualidade e diminui os custos de desenvolvimento e tempo de entrega.

Integração

Como já foi dito, muitas organizações possuem uma infraestrutura de aplicações fragmentadas na qual uma variedade de aplicações clientes têm que ser criadas utilizando múltiplas plataformas de programação e comunicação. Neste contexto, SOA pode facilitar a integração de sistemas heterogêneos já que a idéia é disponibilizar a lógica desses sistemas em forma de serviços interoperáveis.

Redução dos Custos

Pelas características de reutilização, autonomia, baixo acoplamento, abstração e estado, a SOA, visa a proporcionar uma redução de custos significativamente da empresa. Tais como a manutenção de sistemas e a produção de novos componentes monolíticos.

Assim por exemplo o custo de uma aplicação, que possui baixo acoplamento pode ser mitigado na sua utilização em vários ambientes, seria como comprar uma Roupa para Alugar, onde você pagaria R$ 100,00 pela roupa original, e alugaria ela por R$ 45,00 – sendo assim utilizando do artificio do aluno 3 vezes, você já estaria no lucro. Além disso em se tratando de software e aplicações, é mais facial melhor “ evoluir algo já existente” do que começar outro do zero.

Ingredientes para adoção

Como foi dito anteriormente, SOA não é só tecnologia. SOA é um conceito amplo, que envolve outros aspectos para que sua adoção tenha sucesso em um contexto empresarial. Neste sentido, podemos citar quatro ingredientes fundamentais para o sucesso de uma SOA: organização, processo, tecnologia e governança.

Organização

Não adianta tentar implantar uma SOA sem alinhar a TI com o negócio. Para tanto, é necessário entender a estrutura organizacional, suas áreas e unidades, assim como os processos de negócio de cada uma delas. Neste sentido, é necessário revisar, caso

existam, ou criar, caso não existam, os modelos de processos de negócio destas áreas organizacionais.

Além disso, é importante que estejam claras as expectativas e necessidades de cada área em relação à implantação da SOA. Como foi explicado, SOA é uma boa solução para integração. Mas não adianta tentar integrar sistemas de diferentes unidades organizacionais se estas não estão integradas no nível de negócio. Portanto é importante, primeiramente, integrar as áreas de negócio e seus processos.

Processo

Para desenvolver serviços que atendam os princípios da abordagem orientada a serviços, são necessários técnicas, Métodos e boas práticas de design específicas. O processo de desenvolvimento de serviços envolve duas etapas: desenvolvimento para reuso e desenvolvimento com reuso. O primeiro se preocupa em desenvolver serviços para que eles se tornem os mais reutilizáveis possíveis. O segundo é criar aplicações reutilizando os serviços existentes.

Existem algumas metodologias encontradas na literatura. Algumas delas tentam dar suporte a todo o ciclo de vida de SOA, incluindo atividades de planejamento, análise e projeto, construção, teste, implantação e governança, enquanto outras limitam seu escopo a um subconjunto destas atividades. Entretanto, este artigo não tem o objetivo de detalhar nenhuma dessas metodologias, mas de apenas dar uma noção geral de atividades que podem fazer parte de uma metodologia orientada a serviços. É comum, em um contexto empresarial, existirem diferentes áreas de negócio onde cada uma possui seu próprio time de desenvolvimento. Neste contexto, sob a perspectiva de processo de desenvolvimento, um dos principais benefícios de usar SOA, é que ela possibilita um alto grau de modularização. Esta característica permite que os serviços possam ser implementados por diversos times. Evidentemente, estes times devem respeitar os contratos de serviços.

A Figura Abaixo ilustra um processo de desenvolvimento para SOA. O processo possui duas fases. A primeira fase objetiva especificar a SOA empresarial como um todo, definindo, entre outras coisas, os serviços que irão compor a SOA. Uma vez definidos os serviços, estes são alocados para os diferentes times de desenvolvimento que tem a responsabilidade de construir os serviços sob sua responsabilidade [Dias, 2009].

As próximas subseções discutem algumas atividades que devemos considerar ao projetar uma arquitetura de sistema baseado em SOA. Porém, não significa que estas atividades são o suficiente para projetar uma SOA com sucesso, mas apenas um indicativo para mostrar que, para termos uma SOA de sucesso, não precisamos apenas de tecnologia, mas também de uma arquitetura bem projetada. Identificação de serviços Esta é uma das mais importantes atividades do projeto orientado a serviços. O objetivo é descobrir os serviços que compõe a SOA.

Em um contexto empresarial onde existem diversas áreas de negócio, é importante a participação de todos os interessados, não só dos que fazem parte da área tecnológica, mas também daqueles que são especialistas nos processos de negócio de sua área. Isto porque os serviços precisam representar bem as funções de negócio destes processos. A maioria das técnicas para identificar serviços é baseada nos modelos de processos de negócio. Por isso é importante ter estes modelos bem especificados. Aplicação dos princípios da orientação a serviços Da mesma forma que o paradigma orientado a objetos possui um conjunto de princípios que devem ser satisfeitos, o paradigma orientado a serviços também possui princípios específicos que devem ser seguidos.

Depois que os serviços são identificados, é importante garantir que eles atendam a estes princípios da orientação a serviço. Entretanto, não existe uma lista oficial destes princípios. Thomas Erl, em seu livro “SOA – Princípios de design de serviços”, lista um conjunto de princípios que devem ser atendidos, tais como: contratos, acoplamento, abstração, capacidade de reuso, autonomia, independência de estado, visibilidade e composição de serviços. Especificação dos atributos de qualidade Escolher uma arquitetura que satisfaça aos requisitos funcionais e aos requisitos não funcionais (atributos de qualidade) é vital para o sucesso de qualquer sistema. Para SOA não é diferente. É importante entender como uma SOA suporta os diferentes atributos de qualidade e quais são suas implicações para criar um projeto com sucesso. Neste sentido, as pessoas interessadas e envolvidas na definição da SOA precisam definir e priorizar os atributos de qualidade que irão ser satisfeitos pela SOA. Alguns atributos de qualidade são: interoperabilidade, performance, segurança, confiabilidade, disponibilidade, escalabilidade, testabilidade, adaptabilidade e reusabilidade. Para cada atributo definido, é necessário especificar como ele será garantido, seja através de aplicação de boas práticas de projeto, seja através de tecnologias.

Especificação dos contratos de serviços

Uma vez conhecidas as interfaces dos serviços e seus respectivos fornecedores e consumidores em potencial, é importante definir os contratos destes serviços. Um contrato de serviço contém os termos acordados pelo fornecedor e consumidor do serviço. Algumas informações importantes que o contrato deve abranger são as seguintes:

• interface do serviço: o nome e as operações do serviço;• mensagens do serviço: as mensagens que o consumidor e o fornecedor irão

trocar para executar o serviço; os tipos de dados também deverão ser especificados;

• pré e pós condições: as pré e pós condições de cada operação do serviço;• atributos de qualidade: os atributos de qualidade que o serviço deverá

satisfazer;• consumidores potenciais: a lista dos consumidores conhecidos;• fornecedor: a entidade, a área, o sistema que irá fornecer o serviço;• SLA: se houver um Service-Level Agreement envolvido no contrato, ele deverá

ser especificado.

Projetar e construir serviços Depois de projetar a arquitetura baseada em SOA, os serviços identificados serão alocados para os times de desenvolvimento. Cada time de desenvolvimento deve analisar, projetar, construir e testar os seus serviços. Para tanto, é importante observar os atributos de qualidade especificados na fase de definição da SOA. Além disso, o contrato de serviço deve ser respeitado. A equipe deverá tomar decisões de como expor as funcionalidades dos seus sistemas (caso existam) em forma de serviço.

Tecnologia

Atualmente, existe uma variedade de tecnologias relacionadas à SOA. Porém, não é necessário utilizar todas as tecnologias para dizer que está implementando uma SOA. Por outro lado, o fato de apenas utilizar uma das tecnologias não quer dizer necessariamente que está usando SOA. Outra questão importante é que SOA não está presa a nenhuma tecnologia. Porém, é evidente que algumas tecnologias já conhecidas

são ditas como a melhor forma de se implementar uma SOA, como por exemplo Web Services. Abaixo seguem algumas das tecnologias relacionadas à SOA [Davis, 2009]:

Web ServicesPara descrever Web Services, podemos seguir as definições de alguns fornecedores e institutos de pesquisa, como o Gartner: “são componentes de software com baixo fator de acoplamento, utilizados por meio de padrões de tecnologia Internet. Um Web Service representa uma função de negócio ou um serviço que pode ser acessado por uma outra aplicação, sobre redes públicas e, geralmente, disponibilizado por protocolos conhecidos”. Web Service pode ser visto como um framework de tecnologias que permite a comunicação entre aplicações heterogêneas através de serviços interoperáveis, onde estes serviços podem ser localizados e executados através de protocolos padronizados. As três especificações conhecidas do Web Services são o SOAP como protocolo de comunicação, o WSDL como padrão de descrição de serviços e o UDDI como padrão de registro de serviço.

Enterprise Service Bus (ESB)Um ESB pode ser visto como um middleware que tem o objetivo de facilitar a integração de sistemas. Geralmente um ESB possui as seguintes funcionalidades: prover segurança, prover transparência de localização, transformar mensagens, rotear e monitorar as mensagens, gerenciar os serviços, entre outros. Existem muitos produtos de ESB disponíveis no mercado atualmente de fornecedores como IBM, TIBCO, Microsoft e Oracle. A maioria desses produtos tem um background do mercado de EAI (Enterprise Application Integration). Porém também existem soluções open source tais como Mule, ServiceMix, OpenESB e JBossESB. Para quem quer se especializar mais nestes ESBs open source recomendo o livro Open Source ESBs in Action [Rademakers, 2009].

Business Process Management System (BPMS) Esta ferramenta permite a gestão automatizada dos processos de negócio da organização. Como foi dito, os serviços representam funções de negócio na organização. Neste sentido, os serviços podem ser orquestrados representando fluxos de execução dos processos de negócio. O BPMS fornece estes recursos, permitindo a execução, controle e monitoração desses fluxos. Geralmente uma ferramenta de BPMS possui as seguintes características: ferramenta para modelagem e desenho do processo; engenho de execução do processo; orquestração de Web Services e interface de workflow para usuários.

Enterprise Decision Management (EDM)Um sistema EDM incorpora uma máquina de regra de negócio para execução de regras de negócio definidas e um sistema para gerenciar estas regras. Uma regra de negócio é uma instrução bem definida relacionada ao negócio, que faz alguma afirmação sobre algum aspecto de como o negócio deve funcionar.

A idéia de um sistema baseado em regras, ou EDM, é separar as regras do código do programa, deixando estas regras centralizadas, permitindo que as aplicações ou serviços utilizem-nas.

RepositórioOs artefatos gerados em uma SOA devem ser registrados dentro de um repositório para proporcionar o reuso e fornecer infra-estrutura para gerenciamento dos ativos. Estes ativos podem incluir serviços, processos de negócio, orquestrações, regras de negócio, entre outros. Para pequenas organizações, repositórios informais podem ser utilizados, como por exemplo um wiki ou uma base de dados simples que descrevem os diversos ativos. Porém, para grandes organizações, é interessante ter um repositório mais profissional e focado nos ativos da SOA.

Governança

A Gartner declarou que a carência de planejamento relacionado à governança será o principal motivo dos fracassos em SOA. Um estudo realizado pelo SOA Forum mostra que as políticas de governança são insuficientes em 88% das organizações, o que pode comprometer o projeto. Ainda segundo a Gartner, Governança SOA está relacionada à garantia de que os ativos de software e artefatos da sua arquitetura estão operando como esperado e dentro de um certo nível de qualidade.

Na SOA, consumidores de serviço e fornecedores de serviço são executados em diferentes processos, são desenvolvidos e gerenciados por diferentes departamentos e exigem um grande esforço de coordenação para trabalharem juntos com sucesso. Para SOA ter êxito, múltiplas aplicações precisam compartilhar serviços, o que significa que eles precisam ser coordenados para se tornarem comuns e reutilizáveis. Estes são os problemas de governança e eles são muito mais complexos do que nos dias de aplicações monolíticas ou mesmo nos dias de componentes e códigos reutilizáveis [InfoQ, 2009].

Para o sucesso da governança numa organização é importante a combinação de pessoas, processos e tecnologias. Além disso, estando presente essa preocupação desde o início da implantação da SOA, a transição é mais confortável para a empresa, além de ajudar no estabelecimento do alinhamento necessário entre as áreas de negócio e a área de TI, tão importante para pontos como a redução de custos e retorno de investimento.

Desafios

De acordo com um estudo feito pela InformationWeek [InformationWeek, 2008], 32% dos projetos SOA não atenderam às expectativas. Como qualquer mudança de paradigma, a adoção de SOA envolve muitos riscos e desafios. Além do desafio de se definir os aspectos discutidos anteriormente como organização, processos, tecnologias e governança, existem alguns outros que devem ser considerados. Abaixo segue alguns dos limitadores para se adotar SOA.

Cultura

Todas as empresas possuem sua própria cultura, suas crenças e suas formas de executar suas atividades. A implantação de uma SOA em uma organização fará com que algumas pessoas tenham que mudar um pouco sua forma de pensar em relação a algumas atividades que elas executam. Qualquer mudança de paradigma é passível a resistência. Neste sentido, é importante primeiro convencer as pessoas envolvidas e interessadas no projeto SOA sobre seus benefícios. É importante que todas as pessoas envolvidas estejam motivadas e interessadas na transição para SOA.

Falta de conhecimentoMuitas pessoas acham que para adotar uma SOA é necessário comprar uma caixa com uma solução SOA pronta. Mas como vimos ao longo deste artigo, a adoção de SOA exige outros conhecimentos para ter sucesso. Neste sentido, é importante que a empresa que queira adotar uma SOA busque estes conhecimentos necessários ou então contrate uma consultoria externa.

Falta de um projeto pilotoComo diz o ditado popular: “a pressa é inimiga da perfeição”. Quando queremos realizar grandes mudanças em uma empresa, é importante que elas sejam feitas de maneira planejada e que primeiro se realize um projeto piloto, diminuindo assim os riscos. Com SOA não é diferente. Deve-se escolher um projeto piloto e executá-lo de maneira controlada para analisar os riscos.

Falta de comprometimentoComo foi dito, a adoção de SOA envolve muitas mudanças em uma organização. Por esta razão é importante ter uma equipe ou uma pessoa totalmente envolvida nestas questões.

Ainda de acordo com Gouveia (2011), aborda que as características do cenários atuais, impões ainda alguns outros desafios que devem ser superados, ações que tornam o desenvolvimentos destes serviços mais complexos, assim ainda podemos Listar:

Segurança – devida a característica da interoperabilidade, os sistemas ficam mais vulneráveis a ameaças externas.

Rastreabilidade – pela capacidade de composição dos serviços, aumenta a necessidade de monitoramento e rastreabilidade.

Disponibilidade da informação em tempo Real - o tipo de arquitetura SOA, por possuir baixo acoplamento, adequa-se melhor a sistemas que não demanda de resposta em tempo real.

Custos – Alto investimento inicial – implantar o Soa nas empresas gera um investimento inicial, bem levado devido a ser um processo novo e possivelmente lento onde deve se fazer a reengenharia dos sistemas existentes, ou até mesmo adequar esse novo padrão a cultura organizacional, - tantos nos quesitos como recursos humanos, financeiros marketing.

Nesta Visão do Soa, as aplicações se comunicam com os diversos sistemas da empresa

por meio do ESB (Enterprise Service Bus) como camada de integração, também

responsável por coordenar os processos e serviços. A gestão dos processos de negócios

(BPM – Business Process Management) deve ser realizada entre negócio e TI, a fim de

realizar a identificação e definição dos serviços bem como a composição dos fluxos de

negócios, promovendo a implementação de SOA de forma adequada às reais

necessidades da empresa. SOA é como já afirmamos uma evolução dos paradigmas de

arquitetura existentes até o momento. Que combina elementos de várias disciplinas,

como modelagem de processos de negócios (BPM), Arquitetura de Software, Orientação

a Objeto, CDB – Desenvolvimento baseado em Componentes, EAI – integração de

Aplicações Empresariais.

ENGENHARIA DE SOFTWARE DE SERVIÇO.

Como bem já vimos dentro dos conceitos apresentados, para se realizar a Engenharia

de Orientada a Serviços, não segue todos os padrões da Engenharia de Software

Normal. Esta técnica procura aplicar prospectos de um modelo mais aberto, e assim

segue uma definição aplicada a lógica - do pressuposto do mundo aberto – onde tudo é

possível desde que não seja fácil. Para simplificarmos, podemos dizer que pode-se

brincar (fazer de tudo) com esse novo paradigma de desenvolvimento de software

(Serviços). Assim apresentaremos sete princípios usados nessa técnica.

I. Federação Técnica: as vantagens proporcionadas pela Arquitetura Orientada

a Serviço trazem consigo um aumento na complexidade técnica no

desenvolvimento de sistemas. Com isso, o princípio da “Federação Técnica”

prega que a engenharia de Serviços deve fornecer aos arquitetos e engenheiros

de serviços, conceitos linguagens, métodos e ferramentas que os ajudem a

gerenciar o aumento de tal complexidade técnica. (HEUVEl et Al, 2009).

II. Dinamismo (virtualização): é um dos princípios fundamentais da SSE –

Engenharia de Software de Serviços, com relação aos serviços que são

agregados na composição de serviços em tempo de execução, bem como o

contexto altamente volátil. Em que os serviços operam. Desta maneira, o

princípio ‘ dinamismo’ implica que os métodos, técnicas e ferramentas devem

lidar com propriedades emergentes e comportamento complexo. . (HEUVEl et Al,

2009).

III. Federação Organizacional: A Engenharia de Software de Serviços deve

considerar que o desenvolvimento e manutenção de sistemas são, muitas vezes,

realizados em unidades organizacionais distribuídas, envolvimem diversas

linhas de negócio, outras empresas e instituições governamentais. Considerando

isso, o princípio de Federação Organizacional demanda mecanismo sólidos de

Governança Distribuída, a fim de gerenciar por exemplo, dificuldade de controle

de versionamento de serviços compartilhados por vários consumidores em

diferentes domínios organizacionais. . (HEUVEl et Al, 2009).

IV. Limites explícitos (contratos): serviços devem possuir limites claros por meio

do seu contrato. Quando mais rica são as interfaces com cenários e

comportamentos, mais robusta e estável será a composição de serviços. .

(HEUVEl et Al, 2009).

V. Heterogeneidade: As técnicas, métodos e ferramentas da Engenharia de

Software de Serviços devem abranger o princípio da heterogeneidade dos

serviços, uma vez que deve considerar a infraestrutura e o contexto em que

sistemas baseados em SOA operam. A heterogeneidade deve ser considerada

em todas as fases do ciclo de vida do desenvolvimento dos serviços, pois pode

levantar restrições sobre como os serviços devem ser concebidos e construídos,

uma vez que se comunicarão com serviços desenvolvidos em diferentes

paradigmas e que operam em diferentes plataformas. . (HEUVEl et Al, 2009).

VI. Alinhamento Entre A TI e o Negócio: Considerando as características de

componibilidade e reutilização apresentada pelos sistemas baseados em SOA,

que visam permitir o Alinhamento Negócio – TI, a Engenharia de Software de

Serviços deve estar “unificada” com o Business Process Management. A fim de

garantir não só a qualidade do serviço, em nível de sistema, como também a

conformidade às especificações do negócio. . (HEUVEl et Al, 2009).

VII. Abordagem Holística: A Engenharia de Software de Serviço possui uma

característica de natureza holística (que abrangem tudo), sendo assim, demanda

uma abordagem interdisciplinar para a análise e racionalização dos Processos

de Negócios, concepção de Serviços de suporte, implantação, monitoramento e

evolução. Isto significa que métodos, modelos e conceitos devem ser integrados

e que as ferramentas SSE devem ser interoperáveis. . (HEUVEl et Al, 2009).

A Engenharia de software utiliza-se de princípios sólidos e bem estabelecidos – onde de

acordo com PRESSMAN abrange Métodos; Ferramentas e Processos. Já A SSE –

Engenharia de Software de Serviços, também se utiliza dos mesmo conceitos ou bases,

mas não somente no paradigma atual, ela vai além – assim por muito que se pensa uma

ideia não se contradiz a outra, muito pelo contrário, elas se complementam e evoluem.

Processo de Engenharia de Serviço.

I. Identificação do Serviço Candidato - Serviços podem ser classificados em “ Serviços

de utilidade”, “Serviços de Negócio” ou “Serviços de Coordenação ou de Processo”.

Serviços de utilidade – implementam funcionalidades gerais;

Serviços de Negócio – implementam uma função específica do negócio;

Serviços de Coordenação ou de Processo – apoiam os processos de

negócio;

nessa fase devem ser aplicadas as características de Granularidade e Autonomia de

Serviços, bem como podem ser observados os princípios de Alinhamento Negócio-TI

e Heterogeneidade da Engenharia de Software de Serviço, uma vez que tais

princípios devem ser observados desde o início do processo pela possibilidade de

gerarem restrições ao serviço a ser construído.

II. Projeto de Serviço – é realizado a especificação de interface do serviço, aplicado

então o princípio” Limites Explícitos” da Engenharia de Software de Serviço, para

proporcionar características de Serviços como “Contrato de Serviços Padronizado” e

Abstração.

III. Implementação e Implantação dos Serviços – Nessa etapa, o Serviço projetado

anteriormente é construído e implantado.

A partir desse momento, o serviço estará disponível para consumo e/ou reutilização

para construção de fluxos de negócio ou de outros serviços, por meio da composição de

serviços, Assim como a figura abaixo.

[InformationWeek, 2008] Smith Roger. A simpler approach to SOA (2008). Disponível em http://www.informationweek.com/news/software/soa/showArticle.jhtml?articleID=209904293

[Josuttis, 2007] Josuttis, N. SOA in Practice – The Art of Distributed System Design. O’Reilly, 2007.

[Erl, 2008] Erl, Thomas. SOA – Princípios de design de serviços. Prentice Hall, 2008.

[Davis, 2009] Davis, Jeff. Open Source SOA. Manning, 2009.

[Rademakers, 2009] Rademakers, T., Dirksen, J. Open Source ESBs in Action.Manning, 2009.

[Dias, 2009] Dias, J. J.; Almeida, E. S.; Meira, S. R. L. A Systematic SOA-based Architecture Process, 21st International Conference on Software Engineering and Knowledge Engineering (SEKE), Service Oriented Architecture Track, Boston, U.S., 2009.

[InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governança SOA para suportar Iniciativas BPM? (2009) Disponível em http://www.infoq.com/br/news/2009/02/process-it-soa-governance.

HEUVEL, Willem-Jan Van Den et Al. Software Service Engineering: tenets and Challenges. Disponivel em: http://www.csrug.nl/~paris/papers/PESOS09.pdfBIERBERSTEIN, Norbet et al. Executing SOA: A Practiacl Guide for the Service – Oriented Archietect. Pearson Education, 2008.

Revista de Engenharia de software º 22

Ricardo de Castro Barbosa é diretor da Soa Master Educação e Consultoria Ltda.

PROJETO DE TEMPO REAL

PROJETO DE ORIENTADO A OBJETOS

Leituras Complementares.

http://www.cin.ufpe.br/~if717/Pmbok2000/pmbok_v2p/wsp_6.0.html link muito interessante

http://lms.ev.org.br/mpls/Custom/Cds/COURSES/218-PMBOK3/apostila/apostila.pdf --> um

link com explicações muito lúdicas. Muito bom

http://books.google.com.br/books?id=LVZCuzWt-

bIC&pg=PA63&lpg=PA63&dq=Desmembramento+da+EAP&source=bl&ots=MX8PpBe0pn&

sig=athsfCfGlCJDes_34foekwF7OlM&hl=pt-BR&sa=X&ei=he1NU96YBKfTsAS-

14C4BA&ved=0CFcQ6AEwBw#v=onepage&q=Desmembramento%20da%20EAP&f=false

Fontes: Wikipedia Handbook de TI http://www.ime.uerj.br/~vera/projeto/apostila.pdf - http://imasters.com.br/noticia/1861/gerencia-de-ti/modelos-de-ciclo-de-vida-por-que-

precisamos-deles-no-desenvolvimento - http://inf.unisul.br/~vera/egs/aula01.htm - http://www.hlera.com.br/clientes/ciclo_de_vida/index.php?s=rad Disciplina de engenharia de software - SZYPERSKI, Clemens. Back totheuniverse. Software

Development. Skokie: IL:EUA, v.10, n. 1, Sept. 2002a. Disponível: http://www.sdmagazine.com/documents/s=7556/sdm0209h/sdm0209h.htm

BIGGERSTAFF, T. Reuse Technologies andTheirNiches. INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 21st, 1999.

MCILROY, M. D.. Mass-produced Software Components. [S.l.]: In North AtlanticTreatyOrganizationConferenceon Software Engineering, Garmisch-Partenkirchen, 1968.

BOSCH, Jan.. Informationand Software Technology. [S.l.: s.n.], 1999.;Pags. 257-273